WordPress Technical SEO Audit: Step-by-Step Checklist

A technical SEO audit answers one basic question: can search engines actually find, access, and understand your pages? Content quality and backlinks matter, but neither helps if a page can’t be crawled, gets blocked by accident, or sends conflicting signals about which URL should rank. This checklist, part of the Technical SEO series, walks through a practical, WordPress-focused audit in the order that actually matters, from crawl access through to page experience and structured data.

What a technical SEO audit covers

A technical SEO audit examines the mechanical, non-content factors that determine whether a page can be crawled, indexed, and correctly understood: server responses, crawl directives, canonical signals, structured data, page experience, and internal linking. It does not evaluate the quality of the writing itself, though thin or duplicate content does surface as part of the indexing checks covered below.

Preparing an audit baseline

Before changing anything, record the current state: which pages are indexed (via the Search Console Pages report), current Core Web Vitals status, and a list of known site sections (blog, categories, tags, any e-commerce or membership areas). As covered in How to Measure WordPress Speed Before Making Any Changes, a documented baseline is what makes it possible to confirm a fix actually worked rather than assuming it did.

Checking HTTPS and preferred domain consistency

Confirm the site serves every page over HTTPS with no mixed-content warnings, and that exactly one version of the domain is treated as canonical, for example https://example.com rather than also serving https://www.example.com as an independent, unredirected version. Running both without a redirect between them creates duplicate, competing versions of every page on the site.

Crawlability versus indexability

These are related but distinct: crawlability is whether a search engine’s crawler can reach and download a page at all; indexability is whether that page is then eligible to appear in search results. A page can be perfectly crawlable and still excluded from the index due to a noindex directive, a canonical pointing elsewhere, or a quality assessment on Google’s side. Confusing the two is a common source of misdiagnosed problems, since fixing a crawl block won’t help a page that’s being intentionally excluded by a different signal.

Robots.txt review

Visit yourdomain.com/robots.txt directly and confirm it returns a normal 200 response rather than an error, and that it isn’t accidentally disallowing important content, CSS, or JavaScript needed to render pages correctly. Robots.txt controls crawling, not indexing: a blocked URL may still appear in results without a useful snippet if Google discovers it elsewhere. When exclusion is the goal, allow crawling and use a noindex directive so Google can see it.

XML sitemap review

Confirm the sitemap is reachable, returns a 200 status, and lists only canonical, indexable URLs, not pages that are blocked, redirected, or marked noindex, since including those creates a mixed signal Google has to reconcile. Submit or confirm the sitemap in Search Console under Sitemaps, and check for reported errors or warnings there.

Index coverage and URL inspection

Search Console’s Page indexing report (previously known as Index Coverage) groups indexed and non-indexed URLs by status and reason. The URL Inspection tool provides a per-URL view, including whether Google could fetch the page, whether indexing is allowed, and which canonical Google selected.

Status codes and broken links

Crawl the site with a tool capable of reporting HTTP status codes and confirm important pages return 200, not 404 (not found) or 5xx (server error) responses. Broken internal links waste crawl activity and create a poor user experience; both internal links and any significant external inbound links pointing to now-broken URLs should be identified and corrected or redirected.

Redirect chains and loops

A redirect chain occurs when one URL redirects to a second URL that itself redirects again before reaching the final destination. Google’s own guidance recommends redirecting directly to the final destination where possible, and advises keeping any unavoidable chain short, ideally no more than a few hops, since long chains add latency and are not reliably followed by every crawler or browser. A redirect loop, where a chain eventually points back to its own starting URL, prevents the page from ever resolving and should be treated as a critical fix.

Canonical URLs

Every indexable page should carry a single, consistent canonical signal, ideally a self-referencing rel="canonical" tag on the page itself, matching what’s listed in the sitemap and what internal links point to. As covered in more detail in Canonical URLs, Redirects, and Duplicate Content in WordPress, conflicting canonical signals across different mechanisms are a common, difficult-to-spot cause of indexing problems.

Duplicate and thin URLs

Look for near-identical pages generated by URL parameters, filtering, or tracking codes, and thin pages with very little unique content, tag pages with only one or two posts, for example. These don’t need to be deleted outright; the appropriate fix (canonicalization, consolidation, or leaving them alone) depends on whether the page provides genuine standalone value, a judgment call covered further in the canonical and duplicate-content article referenced above.

Pagination, archives, tags, and attachment pages

WordPress automatically generates category, tag, date, and author archive pages, and, depending on theme and settings, a separate attachment page for each uploaded media file. Review whether each of these archive types provides genuine navigational or search value for your specific site; a tag applied to only one post, or an attachment page with no meaningful content beyond the image itself, is a common source of low-value indexed pages, without this needing to be treated as an automatic case for blanket noindexing across the board.

WordPress permalink structure

Confirm the permalink structure (Settings → Permalinks) is a clean, descriptive structure rather than the default, non-descriptive query-string format, and that it hasn’t changed recently without corresponding redirects in place for the old URL structure. Changing permalink structure on an established site without redirecting old URLs is one of the most damaging technical SEO mistakes possible, since it effectively breaks every existing indexed URL and inbound link at once.

Mobile usability

Since Google uses mobile-first indexing, the mobile rendering of a page is what’s primarily evaluated. Check Search Console’s mobile usability reporting for flagged issues (text too small, clickable elements too close together, content wider than the viewport) and manually review key templates on an actual mobile device or viewport emulation, not just a description of the theme as “responsive.”

Core Web Vitals and page experience

Core Web Vitals (LCP, INP, and CLS) are part of Google’s page experience signals. As covered in Largest Contentful Paint in WordPress, Interaction to Next Paint in WordPress, and Cumulative Layout Shift in WordPress, these are assessed at the 75th percentile of real visits, separately for mobile and desktop, and are worth checking as part of a full technical audit even though they’re covered in dedicated detail elsewhere.

Structured data validation

Where structured data (schema markup) is used, validate it using Google’s Rich Results Test and check the Search Console structured data reports for errors or warnings, since invalid or incomplete markup can prevent eligibility for the rich result types it targets. Only mark up content that’s genuinely present and visible on the page; structured data describing content the page doesn’t actually contain is inconsistent with Google’s structured data guidelines.

Internal linking and orphan pages

An orphan page has no internal links pointing to it from anywhere else on the site, making it difficult for both crawlers and visitors to discover through normal navigation, even if it’s technically indexable. Reviewing a site crawl for pages with zero or very few internal inbound links, and adding relevant links from related content where appropriate, is a straightforward, low-risk improvement.

Image and media SEO checks

Confirm images have descriptive alt text (for accessibility and image search visibility), that image URLs aren’t accidentally blocked in robots.txt, and that image dimensions and formats follow the practices covered in How to Optimize Images and the LCP Element in WordPress, since image-heavy pages that are slow to load also affect the page experience signals discussed above.

JavaScript-rendered content considerations

If a theme or plugin renders significant content client-side via JavaScript, confirm that content is actually visible to Google by testing with the URL Inspection tool’s rendered HTML view. Content that only appears after JavaScript execution can be indexed correctly in many cases, but it depends on the specific implementation, and blocking the JavaScript files themselves in robots.txt (a mistake covered above) can prevent this rendering from happening at all.

Search Console and crawling tools

Search Console is the primary source of truth for how Google actually sees the site: the Pages report for indexing status, the Sitemaps report for submission health, the mobile usability and Core Web Vitals reports for page experience, and URL Inspection for a per-page view. A separate third-party crawler is useful for site-wide checks Search Console doesn’t directly surface, such as a full redirect-chain report or a comprehensive internal-link map.

Prioritizing issues by impact and risk

Fix crawl blocks and indexing-preventing issues first, since nothing else matters if pages can’t be found at all. Next, address conflicting signals (canonical, sitemap, and internal links disagreeing with each other) and broken redirect chains. Page experience and structured data refinements are valuable but generally lower-urgency than a fundamental crawl or indexing block.

Rechecking after fixes

After making a change, use URL Inspection’s “Request Indexing” option where appropriate, and monitor the Pages report over the following weeks, since Google needs to recrawl affected URLs before the index reflects a fix. Avoid concluding a fix “didn’t work” based on a same-day check.

Common WordPress technical SEO mistakes

Leaving the WordPress “Discourage search engines from indexing this site” setting enabled after launch
Blocking CSS or JavaScript directories in robots.txt, preventing accurate rendering
Changing permalink structure without redirecting the old URLs
Submitting a sitemap that includes noindexed, blocked, or redirected URLs
Applying blanket noindex to all tag or archive pages without evaluating individual value
Assuming a same-day recheck reflects Google’s updated index

Practical audit checklist

Confirm HTTPS and a single preferred domain version, redirected consistently
Verify robots.txt returns 200 and doesn’t block important content, CSS, or JS
Confirm the XML sitemap is reachable and lists only canonical, indexable URLs
Review Search Console’s Pages report for indexing status and excluded-URL reasons
Crawl the site for broken links, redirect chains, and loops
Confirm self-referencing canonical tags on all indexable pages
Review archive, tag, and attachment pages for genuine navigational value
Check mobile usability and Core Web Vitals reports
Validate structured data with the Rich Results Test
Identify orphan pages with no internal links

Key Takeaways

Crawlability and indexability are distinct; a page can be perfectly reachable and still excluded from search results by a separate signal.
Robots.txt controls crawl access, not search-result exclusion; use noindex for that purpose instead.
Conflicting canonical, sitemap, and internal-link signals are among the most common silent causes of indexing problems.
WordPress-generated archive and tag pages need individual evaluation, not a blanket noindex or blanket approval.
Fix crawl and indexing blockers first; page experience and structured data refinements come after the fundamentals are solid.

FAQs

How often should I run a full technical SEO audit?

Quarterly is a reasonable general cadence, with a check immediately after any major site change: a permalink structure change, a theme switch, or a migration.

Does blocking a page in robots.txt remove it from Google’s index?

Not reliably. Google’s own documentation notes that a disallowed page can still be indexed, typically without visible content, if other pages link to it. Use a noindex directive on the page itself if the goal is exclusion from search results.

Should I noindex all my WordPress tag pages?

Not automatically. It depends on whether the tag pages provide genuine navigational or search value on your specific site. A tag applied to dozens of related posts may be a useful page; a tag applied to a single post generally isn’t.

My sitemap shows no errors, so why aren’t all my pages indexed?

A clean sitemap only confirms the URLs are submitted correctly; it doesn’t guarantee indexing. Check the Pages report for the specific exclusion reason, common causes include duplicate content, thin content, or a canonical pointing to a different URL.

How long does it take for Google to reflect a technical SEO fix?

It varies significantly by site size and crawl frequency; there’s no fixed timeline. Allow at least several weeks before concluding a fix hasn’t worked, and use URL Inspection to check individual URLs in the meantime.

WordPress Technical SEO Audit: A Step-by-Step Checklist