WordPress Technical SEO: The Full Fix List
Why WordPress sites get crawl and indexing problems by default, and the specific settings, sitemap and canonical fixes that resolve them.
WordPress technical SEO means fixing how search engines crawl, render and index the site: a correct sitemap, a robots.txt that doesn't block the wrong things, canonical URLs on duplicate content, and clean permalinks. Most of it is settings, not code.
This sits inside WordPress SEO as the layer that makes everything else visible — the best content in the world does nothing if a crawl issue keeps it out of the index.
On this page
What counts as "technical SEO" for a WordPress site?
Four layers: whether search engines can reach a page (crawling), whether they can read it correctly (rendering), whether they choose to keep it in the index (indexing), and whether duplicate versions of the same content are consolidated (canonicalization). A WordPress site can fail at any one of these while looking completely normal in a browser.
Most WordPress technical SEO problems trace back to defaults nobody reviewed rather than deliberate misconfiguration — a "discourage search engines" checkbox left on after a staging site went live, a tag archive indexing thin content nobody meant to rank, a permalink structure changed without redirects.
How does WordPress handle crawling by default?
Reasonably well, with one setting worth checking immediately: Settings → Reading → "Discourage search engines from indexing this site." It's meant for sites still in development, and it's the single most common cause of a WordPress site that mysteriously never gets indexed at all.
Beyond that setting, WordPress's default robots.txt is permissive and generally fine unmodified. Problems usually come from a security plugin or a .htaccess rule added for another reason that ends up blocking a crawler's user agent along with the bad traffic it was meant to stop.
Is the built-in WordPress sitemap good enough?
For a small, simple site, often yes. WordPress core has generated a basic XML sitemap automatically since version 5.5, listing posts, pages and some taxonomy archives at /wp-sitemap.xml without any plugin required [1].
| WordPress core | SEO plugin | |
|---|---|---|
| Generated automatically | Yes | Yes, once configured |
| Control over included content types | Limited | Full control |
| Exclude specific posts or pages | Not supported | Supported |
| Priority and change-frequency hints | Not included | Some plugins include it |
Most sites running an SEO plugin end up using its sitemap instead, mainly for the control over what's included — excluding a thin category archive or a utility page that shouldn't be indexed is not possible through the core sitemap alone.
What causes WordPress indexing problems?
Most often, one of three things: the site is technically crawlable but the page has too little unique content to earn a separate index entry, internal links to the page are too thin for it to be discovered as important, or a noindex tag is present that nobody intended — frequently left over from a staging environment.
Check Search Console's Page Indexing report first
It tells you directly why a specific URL isn't indexed rather than making you guess — 'crawled, not indexed' and 'discovered, not indexed' point at different fixes.
Fetch the page with no JavaScript
Confirm the content a crawler needs is present in the raw HTML response, not only after client-side rendering finishes.
Check for an accidental noindex tag
Search the page source for 'noindex' directly — a leftover staging setting or a plugin's default on a specific post type is a common, invisible cause.
Add or strengthen internal links to the page
A page with no internal links pointing to it is harder for crawlers to find as important, regardless of how good the content is.
How do you fix duplicate content from categories and tags?
Decide, per taxonomy, whether it deserves its own indexed page or should stay noindexed. A category archive that functions as a real landing page — with its own intro copy and a curated set of posts — is worth indexing. A tag archive that's just a thin, auto-generated list of post excerpts usually is not [2].
Canonical tags and noindex solve different problems and aren't interchangeable: canonical says "this page's content lives at this other URL instead," which is right for genuine duplicates like a paginated archive's first page versus its canonical version. Noindex says "don't index this page at all," which is right for a thin tag archive that adds no real value of its own. Using canonical on a page you actually want deindexed just confuses the signal.
Does switching to headless change any of this?
Some of it becomes the frontend framework's responsibility instead of WordPress's. Using WordPress as a headless CMS behind a separate frontend — the same tradeoff covered in Contentful vs Sanity for those platforms — moves metadata, sitemap generation and rendering onto whatever framework serves the pages, and WordPress's own sitemap and SEO plugin settings stop being what search engines actually see.
That's not a reason to avoid headless, but it is a reason not to assume a WordPress SEO plugin's settings carry over automatically. Every one of the checks above needs re-verifying against the frontend's actual output once WordPress is only the content source and not the thing serving pages.
Sitemaps are the clearest example. A WordPress SEO plugin's sitemap reflects what WordPress itself knows about — but a headless frontend might publish pages that don't map one-to-one onto WordPress posts, or might exclude content types the plugin doesn't know to skip. The sitemap search engines actually use has to be generated by whatever serves the final pages, which in a headless setup is the frontend framework, not WordPress.
Is crawl budget something a small WordPress site should worry about?
Almost never. Crawl budget — how many pages a search engine is willing to crawl on your site within a given period — becomes a real constraint mostly on sites with tens of thousands of URLs or more, where a crawler genuinely can't get through everything in a reasonable time.
A WordPress site with a few hundred or even a few thousand pages is not going to run into a crawl budget ceiling. If pages aren't getting indexed on a site that size, the cause is almost always one of the issues above — thin content, weak internal links, or an accidental noindex — not a crawler running out of time. Spending effort optimizing crawl budget on a small site is solving a problem you don't have while the actual one goes unaddressed.
Every time a client asks about crawl budget, the real issue turns out to be indexing quality instead. It's a more technical-sounding problem to worry about, which is exactly why it's the wrong one to start with.
How do you monitor crawl and index health going forward?
With Search Console's coverage and page indexing reports, checked on a schedule rather than only when something looks wrong. A sudden jump in "crawled, not indexed" pages after a content push is worth investigating immediately, not at the next quarterly review.
Technical SEO on WordPress isn't a one-time fix — a plugin update, a new taxonomy, or a migration to a different hosting setup can quietly change crawl or indexing behavior. Pair this list with a regular look at WordPress speed optimization and a check for WordPress SEO spam signs, since both a slow site and a compromised one show up first as indexing problems before anyone notices the underlying cause.
Set a simple recurring check rather than relying on memory: once a month, skim Search Console's coverage report for new errors, confirm the sitemap still returns a 200 and lists a sensible number of URLs, and spot-check that the "discourage search engines" setting is still off. None of that takes more than a few minutes, and it catches the kind of quiet regression — a plugin update that resets a setting, a migration that drops a redirect — that otherwise goes unnoticed for months until traffic has already dropped.
Keep a short written log of what changed and when, even if it's just a few lines in a shared document. The next time indexing looks off, the first question is always "what changed recently," and a log answers that in seconds instead of requiring someone to reconstruct a timeline from memory or from digging through plugin changelogs after the fact.
Questions people also ask
Does WordPress generate a sitemap by default?
Yes, since WordPress 5.5. Core generates a basic XML sitemap automatically at /wp-sitemap.xml, though most sites replace it with an SEO plugin's version for more control over which content types are included.
Why would Google not index a page that isn't blocked?
Usually because the page has too little unique content to be worth a separate index entry, or because internal links to it are too thin for it to be discovered and judged as important — being unblocked doesn't guarantee indexing.
Do category and tag pages hurt SEO?
Not inherently, but thin ones with overlapping content can create duplicate or near-duplicate pages competing with each other. Noindexing tag archives with little unique value is a common, reasonable fix.
How do I check what Googlebot actually sees on a WordPress page?
Use the URL Inspection tool in Google Search Console, which shows the fetched HTML and any indexing issues Google found on that specific URL, or fetch the page directly with a plain HTTP request and no JavaScript.
Is crawl budget a real concern for a small WordPress site?
Rarely. Crawl budget becomes a practical constraint mainly on sites with tens of thousands of pages or more; a small site's issue is almost always indexability or quality, not how often it gets crawled.
Sources
- Learn how to build and submit a sitemap — Google Search Central (checked 23 September 2026)
- Introduction to robots.txt — Google Search Central (checked 23 September 2026)
- Consolidate duplicate URLs — Google Search Central (checked 23 September 2026)
Get your WordPress crawl and index issues diagnosed
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Ibrahem HelalCo-founder
Leads strategy and delivery.
Works on: SEO, GEO
Reviewed before publishing by Jeremy Zava, Co-founder.
- WordPress SEO: the complete guide for 2026How to do WordPress SEO properly: settings, plugins, speed, security, structure and when to leave WordPress for HubSpot or a headless stack.
- WordPress Speed Optimization That WorksThe concrete steps that move WordPress Core Web Vitals scores: caching, image handling, hosting and the plugin conflicts that undo all three.
- WordPress SEO Spam: Clean It Up and Stop ItHow to spot WordPress SEO spam like the Japanese keyword hack, clean an infected site safely, and stop it from coming back.
- Contentful vs Sanity for SEO: What MattersNeither Contentful nor Sanity renders pages, so neither determines SEO by itself. What matters is the content model and the front end built on top.