Search “technical SEO checklist,” and you’ll find dozens of guides that explain crawlability, indexing, and Core Web Vitals in careful detail, then arrive at the section titled “checklist” and give you a paragraph instead. The reader came for a list they could work through. They got a summary of concepts they already understood from the intro.
This is that checklist, with the actual items, organized by what WordPress specifically does to cause each problem. Generic technical SEO advice treats every CMS the same. WordPress has its own repeat offenders: taxonomy archives generating duplicate content, page builders injecting render-blocking scripts, a “Discourage search engines” setting that’s one accidental checkbox away from deindexing an entire site. Fixing WordPress technical SEO means knowing where WordPress specifically breaks things, not just knowing what technical SEO is in general.
Layer 1: Crawlability and Indexing
If Google can’t crawl or index a page, nothing else on this list matters. Start here.
| Check | What to look for | WordPress-specific cause |
|---|---|---|
| Site-wide indexing setting | Go to Settings > Reading in WP Admin | The “Discourage search engines from indexing this site” checkbox is often left on after a staging site goes live. It can deindex the entire site with one setting. |
| Robots.txt | Visit yourdomain.com/robots.txt directly | Check for a broad Disallow: / line, which blocks the entire site. Most sites should manage this through an SEO plugin (Yoast, Rank Math) rather than editing the file by hand. |
| XML sitemap | Check yourdomain.com/sitemap_index.xml exists and is submitted in Search Console | WordPress SEO plugins generate this automatically, but a sitemap listing pages that don’t actually exist, or missing pages that do, usually means a plugin conflict or a stale cache. |
| Taxonomy archive indexing | Check whether category and tag archive pages are set to noindex or indexed | WordPress creates a page for every category and tag automatically. Thin, near-duplicate tag archives are one of the most common sources of indexing waste on WordPress sites specifically. |
| Canonical tags | View source on key pages, confirm the canonical URL points to itself | Page builders and some caching plugins can output conflicting or duplicate canonical tags if misconfigured. |
| Orphan pages | Check whether every important page has at least one internal link pointing to it | Common after a WordPress redesign, where old pages get rebuilt but never relinked from the new navigation or menus. |
The robots.txt and noindex distinction matters and gets confused constantly. Robots.txt controls whether a crawler visits a page. A noindex tag controls whether a page that was crawled gets stored in the index. Blocking a page in robots.txt while also trying to noindex it backfires: Google can’t see the noindex instruction if it’s blocked from crawling the page in the first place, so the URL can still show up in search results with no description. For taxonomy pages you want hidden, set them to noindex and leave them crawlable.
Layer 2: Core Web Vitals and Performance
Once pages are crawlable, speed and responsiveness become the next gate. We’ve covered the full WordPress-specific breakdown of this separately, since it deserves its own depth: see our WordPress Core Web Vitals guide for causes and fixes. The short version for this checklist:
| Check | Target | Common WordPress cause |
|---|---|---|
| Largest Contentful Paint (LCP) | Under 2.5 seconds | Unoptimized hero images, no caching, cheap shared hosting |
| Interaction to Next Paint (INP) | Under 200 milliseconds | Heavy page builder JavaScript, plugin overload |
| Cumulative Layout Shift (CLS) | Under 0.1 | Ads or embeds injected without reserved space, web fonts loading late |
These thresholds and how Google measures them are defined in Google’s Core Web Vitals documentation.
Layer 3: Structure and Rendering
This layer covers how efficiently WordPress delivers content to both users and crawlers.
| Check | What to look for | WordPress-specific cause |
|---|---|---|
| Crawl depth | Important pages reachable within 2-3 clicks from the homepage | Deep category structures or poorly planned menus bury service and product pages |
| JavaScript rendering | Compare what a browser renders versus what appears in “View Page Source” | Heavy reliance on page builder JavaScript for content that should be in the initial HTML can delay how quickly Google can read the page |
| Internal linking | Every important page has contextual links from related content | WordPress doesn’t do this automatically. It has to be built deliberately into how posts and pages reference each other |
| Structured data | Check for schema markup errors in Search Console | SEO plugins add basic schema automatically, but custom page builder layouts can sometimes override or conflict with it |
| Crawl budget | Review Search Console’s Crawl Stats report for wasted crawl activity | Duplicate URLs from filtered or paginated content, and parameter-based URLs from search or sorting features, waste crawl budget that should go to real pages |
Crawl budget is described in detail in Google’s own guidance on managing crawl budget for large sites. It matters less for a five-page brochure site and considerably more for a WooCommerce store with filtered product listings generating hundreds of near-duplicate URL variations.
Why WordPress Specifically Has These Problems
WordPress itself is lean. What gets built on top of it usually isn’t. A default WordPress install with a heavy multipurpose theme, a page builder, and fifteen active plugins accumulates crawl and indexing problems that a hand-coded static site never would, simply because there are more moving parts generating URLs, scripts, and archive pages automatically.
None of this means WordPress is a poor platform for SEO. It means WordPress SEO requires knowing which of its automatic behaviors, tag archives, category pages, and plugin-generated scripts need to be actively managed rather than left on default settings.
When to Run a Full Technical SEO Audit
Not every week. Run a full audit:
After a WordPress redesign or migration, since URL structures and redirects are the most common casualties.
- When organic traffic drops without an obvious content or algorithm cause.
- Before launching a new site section, especially a WooCommerce catalog expansion.
- Roughly every 3 to 6 months as routine maintenance for an active site.
- Running audits more often than that on a stable site usually surfaces noise rather than real problems.
Stop Guessing Which Technical Issues Are Actually Hurting You
If your WordPress site’s rankings feel stuck despite good content, technical issues are the most common reason and the least visible one. We run WordPress-specific technical SEO audits that check every item in this list against your actual site.
