WordPress crawlability and indexation: the SEO that happens before ranking

Most SEO advice starts at the end of the story: keywords, content, links, rankings. But ranking is the last step in a chain, and the steps before it are where WordPress sites quietly lose. Before Google can rank a page, it has to find it, crawl it, render it, and decide it is worth keeping in the index. Miss any of those and the best content in the world ranks for nothing, because as far as the index is concerned, the page does not exist.

This is the unglamorous layer of technical SEO, and it is where the highest-impact problems tend to hide. They do not show up in the content, they rarely show up in a plugin’s audit score, and they stay invisible until you go looking at how search engines actually move through the site.

Crawl, render, index, rank, in that order

Search is a pipeline, and each stage can silently drop a page. Discovery is how Google learns a URL exists, through links and the XML sitemap. Crawl is the fetch of the raw HTML. Render is Google executing JavaScript to see the final DOM, the way a browser would. Index is the decision to store and understand the page. Rank is everything most people think of as SEO, and it only happens for pages that survived the first four steps.

The mental model that matters: ranking optimizations are wasted on a page that is not being indexed, and indexing is wasted on a page that is not being crawled. You fix this chain from the front, not the back.

Where WordPress leaks crawl budget

Crawl budget is the finite attention Google gives a site: how many URLs it will fetch, and how often. WordPress, left to its defaults, manufactures a surprising number of low-value URLs that compete for that attention:

  • Tag, category, and author archives. Every tag spins up its own paginated archive. A blog with 300 tags can generate thousands of thin, near-duplicate archive URLs that exist for no one.
  • Attachment and media pages. WordPress creates a standalone page for every uploaded image by default. Most sites have hundreds of these, each a dead-end URL with no real content.
  • Paginated archives with no ceiling. /blog/page/47/ deep into a feed, each page a thin list of excerpts Google has to crawl to reach nothing new.
  • Parameter and faceted URLs. Filtered, sorted, and search URLs (?orderby=, ?s=, faceted navigation) multiply into near-infinite crawlable combinations on larger sites.
  • Duplicate paths to the same content. The same post reachable through a category, a tag, a date archive, and its canonical URL is four crawls for one piece of content.

On a small brochure site, none of this matters; Google crawls everything regardless. On a site with thousands of products, a deep blog, or faceted navigation, it is the difference between your money pages getting recrawled daily and getting visited once a quarter.

Indexation: the right pages in, the wrong pages out

Crawl budget is half the problem. The other half is index hygiene: making sure the pages that should rank are indexed, and the pages that should not are kept out without wasting crawls on them.

  • noindex the pages that exist for humans, not search. Internal search results, thank-you pages, thin tag archives, login and cart URLs. They serve a purpose on the site; they have no business in the index.
  • Canonicalize duplicates. When the same content lives at multiple URLs, a rel="canonical" tag tells Google which one is the real one and consolidates the ranking signals onto it instead of splitting them.
  • Keep the XML sitemap honest. A sitemap should list exactly the pages you want indexed, with no noindexed URLs, no redirects, and no 404s. A sitemap full of junk teaches Google to trust it less.

Index bloat, meaning thousands of low-value URLs sitting in the index, is not harmless. It dilutes the site’s perceived quality and spreads crawl attention thin. Pruning it is often the single highest-leverage technical SEO move on an older WordPress site.

How to actually diagnose it

None of this is visible in a plugin’s green-light score. The real signals live in the data search engines hand you:

  • Search Console, Pages report. Indexed versus not indexed, with the reason for each exclusion: “Crawled, not indexed,” “Discovered, not indexed,” “Duplicate,” “Excluded by noindex.” This report is the single best map of where the pipeline is breaking.
  • Crawl Stats. What Googlebot is actually spending its time fetching. If a third of your crawl activity is hitting tag archives and attachment pages, that is crawl budget you are not getting back.
  • Server log analysis. The unfiltered truth: every request Googlebot made, to which URLs, and how often. Logs reveal crawl traps and wasted budget that no other tool surfaces.
  • The site: query. A rough but instant gut check. While Google notes this operator provides an estimation rather than an exact reflection of the index, site:yourdomain.com showing 40,000 results when you have 400 real pages is index bloat you can see in five seconds.

Why this is mostly a one-time fix

The reason crawlability and indexation are satisfying to work on is that the fixes are architectural, not perpetual. You decide once which archive types to keep, set the noindex and canonical logic at the template level, prune the sitemap, and close the crawl traps. After that it holds, with only occasional attention when the site’s structure changes. It is the opposite of the content treadmill. Get the foundation right and the whole site crawls and indexes cleanly for years.

It also compounds with everything above it. A page that is crawled efficiently and indexed cleanly is a page whose structured data and content can actually do their job. This is the groundwork the rest of technical SEO is built on, and the part most often skipped. It is exactly the kind of systemic, template-level issue a technical SEO engagement is built to find and fix.

Let's talk about what you're building

No proposals. No pitch decks. Just a conversation about your project and whether I'm the right fit to build it.

Start a Conversation