Swapping a WordPress theme feels like a cosmetic change. You are repainting the house, not moving the load-bearing walls. So when indexed page counts start sliding a week or two after the switch, most people look everywhere except the theme — they blame an algorithm update, a competitor, or a crawl glitch. The theme is almost always the culprit, and the reason is unintuitive: your theme has been quietly performing search-engine duties you never see in the editor. Change it, and you either drop the signals the old theme was carrying, or you inject new defaults you never asked for. Often both at once.

This article is about why that happens — the specific machinery — and how to read Google Search Console to pin down which mechanism broke. If you understand the mechanism, the fix is usually fast.

What a theme actually controls in search

A WordPress theme is not just CSS and layout. The header.php template (or its block-theme equivalent) is where <head> output is assembled, which means a theme can emit — or suppress — canonical tags, meta robots directives, JSON-LD structured data, Open Graph tags, and hreflang. Many modern themes (Kadence, Blocksy, GeneratePress Premium, Astra Pro) ship their own SEO and schema modules. Genesis child themes historically baked schema and breadcrumb markup straight into the template files.

This creates two distinct failure modes when you switch, and they are opposites of each other:

Dropped signals: the old theme hard-coded something Google relied on, and the new theme simply doesn't emit it.
Injected conflicts: the new theme adds its own SEO output that now collides with the dedicated SEO plugin you already run.

The single most important distinction — the one that separates a clean diagnosis from a week of flailing — is who owns the head: the theme or the SEO plugin?

The theme-vs-plugin ownership problem

If you run Yoast, Rank Math, or SEOPress, those plugins are supposed to own canonicals, meta descriptions, robots directives, and schema. A well-behaved theme stays out of their way. But plenty of premium themes turn their SEO modules on by default, and the moment you activate such a theme you get two systems writing to the same <head>.

The classic symptom is two canonical tags on the same page — one from Rank Math, one from the theme — sometimes pointing at slightly different URLs (http vs https, www vs non-www, with or without a trailing slash). Google sees an inconsistent self-reference and falls back to its own canonical choice, which may not be the URL you want ranking. You get the same collision with duplicate JSON-LD Article blocks or competing meta robots tags.

The fix here is not to add anything. It is to turn the theme's SEO/schema module off and let the plugin be the single source of truth. Five minutes in the theme's customizer settings, and the duplicate tags disappear on the next crawl.

Reading the diagnosis off Search Console

You do not have to guess which mechanism broke. The Pages report in Google Search Console (the "Page indexing" report) names the exact reason for every excluded URL, and each status string maps to a specific theme-swap cause. Learn to read them and the audit takes minutes.

"Duplicate without user-selected canonical"

This is the canonical-conflict fingerprint. Google found your page but the canonical signals were contradictory, so it picked its own and may have folded the page into a different URL. Almost always caused by the theme's SEO module fighting your plugin, or by the new theme emitting bare https://sitename.com/ when the old one emitted the www variant. Confirm by viewing the rendered <head> (below), kill the duplicate source, done.

"Excluded by 'noindex' tag"

Pages you want indexed are suddenly carrying a noindex directive. Some themes ship template parts — landing-page or "blank" templates, or a maintenance/coming-soon toggle — that inject noindex. If a chunk of URLs flips to this status right after the swap, a template default is the prime suspect.

The inverse problem: archives that should be noindexed but aren't

The opposite is just as damaging and shows up as a surge of new low-value URLs entering the index or sitting in "Crawled — currently not indexed." SEO plugins typically noindex tag archives, author archives, and date-based archives because they are thin and duplicative. That setting lives in the plugin, so a theme swap shouldn't touch it — but if your old theme was the thing suppressing those archives (or you re-ran a setup wizard during the switch), Googlebot can suddenly discover hundreds of thin archive URLs. They compete for crawl budget with your real content. Re-apply noindex to tag/author/date archives in your SEO plugin and the bloat drains back out over a couple of weeks.

"Discovered — currently not indexed"

Google knows the URL exists but hasn't bothered to crawl it. This often reflects a weakened internal-link graph. Themes carry a lot of sitewide internal linking through their widget areas, menus, and footer — a "popular posts" or "related" block on every page funnels link equity to your cornerstone content. Rebuild the sidebar in a new theme without that block and those pages lose their sitewide internal signal, so Google de-prioritizes crawling them. Restore the equivalent block (or a curated "Featured" widget) and the internal signal returns.

The signal you can only see in the rendered HTML

None of this is visible while you're logged in admiring the new design. You have to look at the page the way Googlebot does. Two tools:

GSC URL Inspection → "View crawled page" / "Test live URL" → "View tested page." This shows you the actual rendered HTML and the resources Google loaded. Check the <head> for exactly one canonical, the meta robots you expect, and your structured data.
View source vs. rendered DOM. Modern themes lean on JavaScript. If your new theme builds its menu, "related posts," or body content client-side — or lazy-loads links that only appear on scroll — Googlebot's render pass can miss them. Internal links that exist only in JS-injected markup are weaker signals than links present in the initial HTML. Verify your important internal links appear in the raw source, not just after scripts run.

This is also where you catch missing structured data. If the old theme (or its schema module) emitted Article and Organization markup and the new one doesn't, your rich-result eligibility quietly evaporates. Restore it via your SEO plugin's schema settings so it isn't theme-dependent again. Validate with Google's Rich Results Test.

Don't forget performance — but keep it in proportion

A "performance-first" theme can still be slower in practice if it loads animation libraries, web fonts, or a heavy block-rendering bundle you don't need. Watch your Core Web Vitals: LCP under 2.5s, INP under 200ms (INP replaced FID in March 2024), CLS under 0.1. A regression here rarely deindexes pages on its own, but it suppresses rankings and, on a slow site, reduces how aggressively Google crawls. Disable unused animation/effect modules and dequeue scripts the theme loads globally.

A theme-swap pre-flight you can actually run

Because every mechanism above is invisible in the editor, capture a baseline before you flip the switch — ideally on staging — so you can diff it afterward:

Save the rendered <head> of your homepage, one post, one page, and one archive. Diff canonical, robots, and schema before vs. after.
Export the XML sitemap and your robots.txt, and screenshot every SEO-plugin setting (titles, archives, schema).
On the new theme, immediately turn off any built-in SEO/schema module if you run a dedicated SEO plugin — this prevents the most common conflicts before they start.
Watch the GSC Pages report daily for the first two weeks. The statuses above will tell you precisely what broke while it's still cheap to fix.

Theme changes don't have to cost you indexing. They cost you indexing when an invisible duty silently changes hands. Know who owns the head, read the status strings, and check the rendered HTML — and a swap that scared you into a traffic panic becomes a fifteen-minute correction.

Why Google Stopped Indexing My Pages After A Theme Change