Technical SEO Checklist for WordPress: 15 Fixes That Actually Move Rankings

By SureRank Team

Here’s a scenario that plays out on thousands of WordPress sites every month.

Someone publishes genuinely good content. They’ve done the keyword research. The post is well-written, well-structured, and covers the topic more thoroughly than half the results on page one. They wait. They check the Search Console. The post gets a handful of impressions, maybe a few clicks, and then plateaus somewhere between position 18 and position 35, visible to almost nobody.

The content isn’t the problem.

Somewhere in the backend of the site, a technical issue is quietly applying a ceiling to everything published on it. Not a dramatic penalty. Not a manual action. Just a steady, invisible suppression, the kind that doesn’t announce itself, doesn’t show up in the WordPress dashboard, and doesn’t get fixed until someone goes looking for it specifically.

This checklist is looking.

Fifteen technical fixes, prioritised by how much they’re likely to be costing you right now. Work through them in order. The first few are foundational fixes before anything else, because they determine whether your content can rank at all. The middle group determines how well your indexed content competes. The final group is where compounding gains live.

What Technical SEO Is (And What It Isn’t)

Technical SEO is the practice of ensuring that search engines can find, crawl, understand, and index your site’s content and that the experience of loading and using your site meets the bar Google requires to rank it competitively.

It is not content quality. It is not keyword targeting. It is not a backlink building.

Those things matter enormously. But they operate on a foundation. If the foundation is broken, if your pages can’t be crawled, if your site loads in six seconds on mobile, if Google is indexing the wrong version of your URLs then your content and your links are doing their job on top of sand.

Technical SEO is the concrete underneath everything else.

Most wins come from technical hygiene, content structure, and internal linking. You can publish great content, but if Google struggles to crawl it, or users bounce because it loads slowly, you will not get consistent rankings.

The reason technical SEO deserves its own checklist separate from on-page and content checklists is that most technical issues on WordPress sites were created automatically. Not by anything you did intentionally. By WordPress itself, by your theme, by your plugins, or by a setting that made sense in development and was never turned off before launch.

They’re invisible from the front end. They’re invisible in the WordPress editor. And they can suppress an entire site’s rankings for months or years without anyone knowing they exist.

That’s why you check for them explicitly.

TIER ONE: Foundational Fixes

These determine whether your content ranks at all. Fix these first.

Fix 1: Check WordPress Isn’t Blocking Google Entirely

This is the most embarrassing technical SEO problem and one of the most common.

WordPress has a setting under Settings → Reading called “Discourage search engines from indexing this site.” It’s designed to prevent a staging or development site from being indexed while you’re building it. It works by adding a noindex directive to every page on your site.

This simple oversight has kept countless sites invisible to Google. Navigate to Settings → Reading in your WordPress dashboard and ensure “Discourage search engines from indexing this site” is unchecked.

The problem: this setting frequently survives the transition from development to live. The developer turns it on to protect the staging environment. The site launches. Nobody turns it off. The site publishes content for six months and wonders why nothing ranks.

The check: Settings → Reading. One box. Uncheck it if it’s checked. Then go to Google Search Console and request indexing for your most important pages.

Who this affects most: Sites launched by developers, sites built on staging environments, sites that were migrated from one host to another.

Fix 2: Audit Your robots.txt File

Your robots.txt file sits at yourwebsite.com/robots.txt. It tells Google which parts of your site it can and cannot crawl. A misconfigured robots.txt is one of the few technical issues that can completely prevent indexing at scale and it can do so silently, with no warnings in the WordPress dashboard.

Access it directly in your browser. Look for Disallow: / a forward slash alone, with nothing after it. That single line tells Google it cannot crawl anything on your domain.

Legitimate robots.txt entries block specific backend directories:

Disallow: /wp-admin/

Disallow: /wp-includes/

These are correct. They block Google from crawling your WordPress backend, which has no ranking value.

What you don’t want to see is content directories blocking anything that would prevent Google from accessing your posts, pages, or media files.

The check: Visit yourwebsite.com/robots.txt in a browser. Verify no content directories are blocked. Then validate your file in Google Search Console under Settings → robots.txt Google’s tester confirms exactly how it’s interpreting your file and lets you test specific URLs against it.

The fix if something is wrong: Edit the robots.txt file either through your SEO plugin’s settings or via your host’s file manager. Most SEO plugins, including SureRank, manage this file automatically with sensible defaults.

Fix 3: Verify Your Key Pages Are Actually Indexed

Knowing that Google can crawl your site doesn’t tell you whether it has indexed your most important pages. These are two different things, and the gap between them is where a lot of silent ranking suppression lives.

The check: In Google Search Console, go to Indexing → Pages. Review each category of non-indexed pages carefully:

“Excluded by noindex tag”:  A noindex directive exists on the page. Check whether it’s intentional. If it’s a post or page you want to rank, it isn’t.

“Crawled, currently not indexed” : Google found the page but actively chose not to index it. This is the most concerning category. These pages need content improvement, not technical fixes. Google’s judgment call here is almost always about thin content, low perceived quality, or too much similarity to other indexed pages.

“Discovered, currently not indexed”: Google knows the page exists but hasn’t crawled it yet. This is often a crawl budget issue on larger sites, or simply recency on a new page.

Also use the URL Inspection tool (paste any specific URL into the search bar at the top of Search Console) to check any individual page. It tells you indexed or not, last crawl date, which canonical Google is using, and whether any coverage issues were detected.

For any important page not indexed: Use the “Request Indexing” button in the URL Inspection tool. It places the page in Google’s priority crawl queue. Factor in that field data updates in Search Console can take up to 28 days to reflect changes.

---

Fix 4: Fix Your Permalink Structure

WordPress’s default permalink structure creates URLs like yourwebsite.com/?p=123. These URLs tell Google nothing about what the page contains. They’re also not crawled with the same efficiency as clean, descriptive URLs.

The check: Go to Settings → Permalinks in WordPress. If the current setting is “Plain” (the numeric default), change it.

The fix: Set permalinks to “Post name.” This creates URLs in the format yourwebsite.com/your-post-title/ clean, readable, keyword-containing URLs that both Google and users can understand at a glance.

Important: If you’re changing the permalink structure on an existing site with indexed pages, every URL on your site will change, which means every existing indexed URL becomes a 404 until you redirect it. Before changing permalink structure on an established site, set up 301 redirects from old URLs to new ones. SureRank Pro’s redirection manager handles this directly inside WordPress without a separate plugin.

On a brand new site with no indexed pages yet, this fix takes 10 seconds and costs nothing.

Fix 5: Submit Your XML Sitemap to Google

Your XML sitemap is the map Google uses to discover every page on your site. Without it, Google discovers your content by following links which works, but more slowly and less comprehensively than a direct sitemap submission.

The check: Visit yourwebsite.com/sitemap.xml or yourwebsite.com/sitemap_index.xml in your browser. If a structured XML file loads, your sitemap exists. If you get a 404, it doesn’t.

Submitting it: In Google Search Console, go to Indexing → Sitemaps and paste your sitemap URL. Google will start using it to prioritise crawling.

What to verify in the sitemap itself: It should contain only pages you want indexed, your posts, pages, and products. It should not contain noindexed pages, 404 URLs, pages with canonical tags pointing elsewhere, or admin URLs. A bloated sitemap with non-indexable URLs creates crawl noise that slows Google’s processing of the pages you do care about.

SureRank generates and maintains your XML sitemap automatically. Every time you publish, update, or delete a page, the sitemap updates accordingly. You submit it once; it stays current.

TIER TWO: Performance Fixes

These determine how well your indexed content competes.

Fix 6: Diagnose and Resolve Your LCP (Largest Contentful Paint)

LCP is the most commonly failed Core Web Vital on WordPress sites and it’s the one with the most direct relationship to perceived page speed. When a visitor clicks your result and waits more than 2.5 seconds for the main content to appear, both the user and Google register that as a poor experience.

Sites with “Good” CWV scores rank significantly higher on average than those with “Poor” scores.

The check: Run your most important pages through Google PageSpeed Insights (pagespeed.web.dev). Focus on the mobile scores Google uses mobile-first indexing, so mobile performance is what matters for rankings.

The three biggest LCP killers on WordPress:

Uncompressed hero images. The LCP element on most blog posts is the featured image at the top of the page. A full-size 3MB JPEG uploaded directly from a camera will reliably push LCP past 5 seconds on mobile. Convert to WebP format and compress to under 150KB for full-width featured images. Optimizing images alone can improve page load time by 40–60% and significantly boost LCP scores.

No page caching. Without a caching plugin, WordPress rebuilds every page dynamically on every visit running PHP, querying the database, assembling HTML before sending anything to the visitor. This adds 800–1500ms of server processing time before the first byte of content is delivered. Install a caching plugin. WP Rocket is the most complete option; W3 Total Cache and LiteSpeed Cache are effective free alternatives.

Render-blocking resources. JavaScript and CSS files that must download and execute before the browser can display content push LCP back proportionally. PageSpeed Insights flags these specifically under “Eliminate render-blocking resources.” Enabling JavaScript deferral in your caching or performance plugin addresses most of these without code changes.

Fix 7: Identify and Fix Your CLS (Cumulative Layout Shift)

CLS measures how much your page layout shifts unexpectedly while loading. A CLS score above 0.1 is classified as needing improvement. Above 0.25 is poor.

Layout shifts directly increase bounce rate because users lose their place, accidentally click the wrong elements, and experience the page as unstable.

The most common CLS sources on WordPress:

Images without declared dimensions. When a browser encounters an image tag with no width and height attributes, it doesn’t know how much space to reserve for it. When the image loads, it pushes everything below it down a layout shift that Google measures and penalises. The fix: ensure every image has explicit width and height attributes set. Many performance plugins and modern WordPress themes handle this automatically.

Web fonts loading late. The page renders with a system font, then shifts to the custom font when it downloads. Use font-display: swap with size-adjusted fallback fonts to minimise the visual shift on swap. Self-hosting Google Fonts reduces the connection overhead that delays font loading.

Ads and embeds loading without reserved space. An ad slot that loads collapsed and then expands pushes content down as it fills. Set minimum height on ad containers matching your typical ad dimensions. For YouTube or Twitter embeds, set explicit aspect-ratio in CSS to reserve space before the embed loads.

Fix 8: Address INP (Interaction to Next Paint)

INP replaced FID as a Core Web Vital in 2024 and measures how quickly your page responds to user interactions, taps, clicks, form submissions throughout the entire visit.

Target: under 200 milliseconds. At this speed, interactions feel instant.

The primary cause on WordPress: Too many third-party scripts running on the main thread. Every analytics tag, chat widget, advertising pixel, and social sharing script competes for the browser’s processing attention. When a user taps something and the main thread is occupied processing scripts, there’s a delay before the tap is registered.

The fix: Audit what’s running on your pages. The Query Monitor plugin (free) shows every script loading on any given page. Identify scripts that load on every page but are only needed on some (a contact form script loading on blog posts, for example), and restrict them to only the pages where they’re used. Defer non-critical third-party scripts so they load after the page is interactive.

Fix 9: Test and Fix Mobile Usability

Google uses mobile-first indexing meaning it evaluates the mobile version of your site for ranking decisions. If your mobile experience is broken, your rankings suffer regardless of how good the desktop version is.

The check: Go to Experience → Core Web Vitals in Google Search Console and select the Mobile tab. Any URLs flagged as “Poor” on mobile need immediate attention. Also use Experience → Mobile Usability to see specific issues Google has flagged text too small to read, clickable elements too close together, content wider than the screen.

The most common mobile usability issues on WordPress:

Content wider than the viewport. Usually caused by images or embedded content (like wide tables or iframes) that aren’t set to max-width: 100%. The fix is typically one line of CSS.

Tap targets too close together. Links or buttons spaced so close on mobile that accurately tapping one without hitting another is difficult. Most modern themes handle this correctly; older themes often don’t.

Fixed-width elements. Containers set to a specific pixel width that overflows on smaller screens. These need to be converted to percentage-based or max-width values.

Testing on real devices: Google’s PageSpeed Insights and Search Console show simulated and real-user mobile data respectively. For visual testing, Google’s Mobile-Friendly Test (search.google.com/test/mobile-friendly) shows you a rendered screenshot of how your page appears on mobile.

Fix 10: Noindex Thin Archive Pages

WordPress automatically creates multiple types of archive pages: category archives, tag archives, author archives, date-based archives that aggregate posts into paginated lists. On most sites, these pages have very little unique content and represent the exact type of thin, duplicate-adjacent content that Google penalises.

When these pages are indexed, they consume crawl budgets and create indexing noise around your real content pages. A site had 4,000 indexed URLs, but only 120 real articles. Tag archives, author archives, and parameter URLs soaked up crawl budget, and important posts were stuck in “Crawled, currently not indexed.” After noindexing thin archives, more posts entered the index and several keywords moved from page two into the top five within six weeks.

The check: In Search Console’s Indexing → Pages report, look at how many of your indexed URLs are archive pages versus actual content pages. If the ratio is significantly skewed toward archives, you have a crawl budget problem.

The fix: Use your SEO plugin to set noindex on tag archives, date archives, and author archives unless these pages serve a genuine unique purpose on your site. SureRank handles this through Settings → Advanced, where you can control indexing rules for each archive type without touching code.

Category archives are worth keeping indexed if they’re well-organised and function as useful navigation hubs. Tag archives on most WordPress blogs are thin and should be noindexed.

Fix 11: Fix Redirect Chains and Loops

A redirect chain occurs when URL A redirects to URL B, which redirects to URL C. Each hop adds loading time and dilutes the authority passing through the chain.

A redirect loop is when a URL eventually redirects back to itself – URL A → URL B → URL A – creating an infinite cycle that browsers escape from with an error, and that Google simply abandons crawling.

The check: Run your site through Screaming Frog (free for up to 500 URLs) and look at the Redirect Chains report. Any chain of three or more hops should be collapsed to a single redirect pointing directly from the original URL to the final destination.

The fix: Update the initial redirect to point directly to the final destination, bypassing the intermediate URLs. For WordPress sites with frequent URL changes, SureRank Pro’s redirection manager tracks redirect paths and flags chains before they compound.

TIER THREE: Compounding Fixes

These build lasting competitive advantages over time.

Fix 12: Implement Schema Markup Across Your Content

Schema markup is structured data that tells Google explicitly what type of content each page contains an article, a product, a recipe, a FAQ, an organisation. It doesn’t directly boost rankings. It does something more valuable: it makes your pages eligible for rich results.

Only 33% of websites implement structured data, so adding it gives you a competitive advantage. In 2026, schema is also critical for appearing in AI Overviews and answering engine results.

Rich results, FAQ boxes, article carousels, star ratings, breadcrumbs, how-to steps take up significantly more space in the SERP than a standard result. More space means more visual prominence means higher CTR, even from the same ranking position.

For a WordPress blog, three schema types matter most:

Article schema on every post. This tells Google you’re publishing editorial content, with authorship, publication date, and modification date. The modification date is particularly important; it’s one of the signals Google uses to assess content freshness.

FAQ schema on posts with a questions-and-answers section. When implemented correctly, FAQ schema allows Google to display your Q&As directly in the search result as an expandable block dramatically increasing the vertical space your result occupies.

BreadcrumbList schema on all pages. This generates breadcrumb trails in search results that show the hierarchy of your site’s content Homepage → SEO → Technical SEO which increases click-through rates and helps Google understand your site architecture.

SureRank applies Article schema automatically to every published post. No setup. No code. FAQ schema is available through the on-page schema builder. BreadcrumbList schema is generated from your WordPress category and page hierarchy automatically when your SEO plugin is configured correctly.

Fix 13: Enforce HTTPS Sitewide and Verify Canonical Tags

HTTPS is a confirmed Google ranking signal. Google explicitly uses HTTPS as a ranking signal, and browsers now warn users when visiting non-secure sites. Most hosts provide free SSL certificates via Let’s Encrypt. If your site is still on HTTP, this is an emergency fix.

Beyond the certificate itself, you need to ensure your site is consistently served from one canonical URL:

• https://yourwebsite.com (preferred), not also accessible from http://yourwebsite.com
• https://www.yourwebsite.com or https://yourwebsite.com, but not both without a redirect

When both versions of your site are accessible, HTTP and HTTPS, www and non-www Google sees them as potentially duplicate sites. It has to decide which version to index, and it may split authority between versions rather than consolidating it on the preferred one.

The check: Type all four versions of your URL into a browser (http://, https://, http://www., https://www.) and watch where they redirect. All four should redirect to a single consistent version. If any version loads independently without redirecting, fix it.

Canonical tags operate at the page level, a tag in your HTML that tells Google which URL is the “official” version of a page. SureRank sets canonical tags correctly on every page by default, pointing to the clean, preferred URL version without the parameters, session IDs, or tracking strings that can create duplicate content issues.

The check: Use the URL Inspection tool in Search Console on any page and look at the “User-declared canonical” field. If it’s blank or pointing to the wrong URL, your canonical configuration needs attention.

Fix 14: Audit and Resolve Duplicate Content

Duplicate content on WordPress sites is almost never intentional, it’s generated automatically by the platform. And it quietly suppresses rankings by forcing Google to make indexing decisions it shouldn’t have to make.

The most common sources:

Paginated archives. Page two, three, and four of your blog archive contain largely the same post excerpts as page one, just with different URLs. Ensure paginated pages use rel=”prev” and rel=”next” tags (handled by SureRank automatically) or are noindexed if they serve no indexing purpose.

URL parameters. If your site uses tracking parameters (?utm_source=newsletter) or sorting parameters (?orderby=date), these create duplicate versions of every page with a unique URL. Consolidated in Google Search Console’s Legacy Tools under URL Parameters, or handled via canonical tags that strip parameters.

www vs non-www, HTTP vs HTTPS. As covered above, enforce consistent redirects so only one URL version is accessible and indexed.

WooCommerce product variations. Variable products with multiple attributes can generate dozens of near-identical product page URLs. Use canonical tags on variation URLs pointing to the parent product page.

Fix 15: Manage Your Crawl Budget on Larger Sites

Crawl budget is the number of pages Google will crawl on your site in a given timeframe. On small sites (under 500 pages), crawl budget is rarely a limiting factor, Google will crawl everything. On larger sites (1,000+ pages), it becomes significant: if Google spends its crawl budget on thin archive pages and URL parameter variations, your important content pages get crawled less frequently, indexed more slowly, and updated in Google’s index with a longer lag.

Signs you have a crawl budget problem: New posts take more than two weeks to appear in Search Console impressions data. Important content shows “Discovered, currently not indexed” status for extended periods. Your indexed page count in Search Console is significantly lower than your actual published page count.

The fixes (building on earlier items in this checklist):

• Noindex all thin archive pages (Fix 10): stops Google spending crawl budget on low-value URLs
• Fix redirect chains (Fix 11): reduces the crawl effort required to reach your actual content
• Submit an accurate, clean sitemap (Fix 5): directs crawl attention to your most important pages
• Use internal linking strategically: pages with more internal links pointing to them get crawled more frequently

For WordPress sites approaching 500+ published posts, crawl budget becomes a real limitation. Use Google Search Console to monitor crawl behavior and index coverage actively not quarterly, but monthly, or after any significant publishing push.

How SureRank Handles 6 of These 7 Areas Automatically

Working through this checklist manually running the checks, applying the fixes, verifying the outcomes takes between three and eight hours on a medium-sized WordPress site. And then it has to be done again, because sites change. New posts get published. Plugins update. Settings drift. Technical issues that didn’t exist in January exist by March.

That’s the fundamental problem with treating technical SEO as a one-time project rather than an ongoing practice.

SureRank was built to make the ongoing practice automatic for WordPress sites, handling the technical layer in the background while you focus on content and strategy.

Here’s exactly what it manages automatically, mapped to this checklist:

Crawlability (Fixes 1, 2): SureRank’s Site SEO Audit runs continuously and surfaces issues immediately — including if the “Discourage search engines” setting gets enabled accidentally, and including robots.txt configuration problems specific to WordPress. You don’t need to remember to check. It surfaces the problem when it appears.

Indexing & Sitemaps (Fix 5): XML sitemap generation is automatic and self-maintaining. Every publish, update, and deletion updates the sitemap. No manual submissions required after initial setup. SureRank also generates HTML, video, and news sitemaps in the Pro plan for sites that need them.

Noindex for thin archives (Fix 10): Archive indexing controls are configurable from SureRank’s settings in a single panel, tag archives, date archives, author archives, category archives. Set once, applied sitewide, maintained automatically.

Schema markup (Fix 12): Article schema is applied to every post automatically on publish. The schema builder in the on-page panel adds FAQ, HowTo, and other schema types without code. No separate schema plugin required.

HTTPS and canonical tags (Fix 13): SureRank sets canonical tags correctly on every page, enforcing the consistent canonical URL regardless of how the page was accessed. HTTPS canonical enforcement is included in the default configuration.

Duplicate content: pagination and parameters (Fix 14): Canonical tags and pagination tags (rel=”prev”, rel=”next”) are handled automatically across paginated content without manual page-by-page configuration.

What SureRank doesn’t handle and you still need:

Site speed (Fixes 6, 7, 8) is outside SureRank’s scope by design; a performance plugin like WP Rocket or LiteSpeed Cache handles image optimization, caching, and script deferral. SureRank is deliberately lightweight on the front end so it doesn’t contribute to the speed problem it’s helping you diagnose.

Redirect chains (Fix 11) require SureRank Pro’s redirection manager for ongoing management or a dedicated redirection plugin if you’re on the free tier.

Mobile usability (Fix 9) is a theme and template issue, not a plugin issue.

The result: a WordPress site with SureRank installed handles six of the seven technical SEO areas automatically, continuously, without requiring a quarterly audit to maintain. The remaining areas require a performance plugin and periodic manual checks, both of which are faster and more effective because the SureRank-covered areas are no longer creating noise.

Run your technical SEO check with SureRank – free, no credit card needed →

When you’re ready to add the redirection manager, Pro sitemaps, and AI-powered fixes, SureRank Pro starts at $8.25/month for up to 10 sites.

The Priority Order for Working Through This List

Not every fix on this list is equally urgent. Here’s how to triage it:

Fix immediately: these block rankings entirely:

• Fix 1: WordPress noindex setting
• Fix 2: robots.txt blocking content
• Fix 4: Permalink structure (on new sites)
• Fix 13: HTTPS enforcement

Fix within the week: these suppress competitive rankings:

• Fix 3: Key pages not indexed
• Fix 5: Sitemap submitted and clean
• Fix 6: LCP failures on important pages
• Fix 10: Thin archive pages being indexed

Fix within the month: these build compounding advantages:

• Fix 7: CLS issues resolved
• Fix 8: INP improvements
• Fix 9: Mobile usability issues
• Fix 11: Redirect chains collapsed
• Fix 12: Schema implemented across content
• Fix 14: Duplicate content resolved

Ongoing monitoring, these require regular attention:

• Fix 15: Crawl budget management as the site scales

The Bottom Line

Technical SEO isn’t the most glamorous part of running a WordPress site. It doesn’t produce the immediate satisfaction of publishing a well-written post or seeing a piece of content get shared.

What it does is remove the ceiling that’s silently sitting on top of everything else you’re doing.

Good content ranks to its full potential when the technical foundation is sound. It underperforms consistently when it isn’t. Clean up what Google crawls, speed up what users experience, and connect your content like a library, not a pile of posts. Those fundamentals compound, and they are exactly what makes rankings grow faster without guesswork.

Work through this checklist in order. Fix the foundation first. Let the compounding fixes build over time. And use a tool like SureRank to make sure the baseline never slips because the fixes you apply today only stay fixed if something is watching them.

---

Continue building your SEO foundation: the complete WordPress SEO audit guide shows how to run the diagnostic process that uncovers these issues systematically, Core Web Vitals explained covers Fixes 6, 7, and 8 in significantly more depth, and why your website isn’t ranking on Google connects technical health to the full picture of ranking factors your site is being evaluated against.

---