After a Migration, Your Sitemap Is Probably Lying to Google

Why migrations break this specifically

A migration changes URLs. A sitemap is a list of URLs. The two are obviously connected and the connection is almost always somebody's assumed responsibility rather than anybody's actual one.

The developer assumes the SEO plugin regenerates it. The plugin regenerates it from a database that may still hold old paths, or from a cache, or on a schedule that has not fired. The agency checks that redirects work — which they do — and never opens the sitemap itself.

And the failure is completely silent. Search Console will happily report a successfully fetched sitemap with 1,240 URLs. It does not tell you that 1,240 of them redirect, and the page count looks reassuringly like the old one because it is the old one.

Every URL in a stale sitemap is you telling Google, on purpose, that the old address is still the right one.

Six failures, in order of frequency

1. The sitemap still lists old URLs

The classic. Redirects catch the visitors, so nothing appears broken. But crawl budget is being spent on hops, and a sitemap full of redirects is a signal that your canonical URLs are the ones you just retired.

Check: open the sitemap and click three URLs at random. If they redirect, it is stale.

2. The robots.txt declaration points at the old path

Very common when the platform changes — a WordPress-to-static move, or Yoast to a different plugin. The Sitemap: line still names /sitemap_index.xml while the new site publishes /sitemap.xml, or the reverse.

Check: read your robots.txt and load the URL on that line. It takes ten seconds and it is the single highest-yield check on this list.

3. The sitemap itself 404s

The generator moved, the plugin was replaced, or the file was static and did not survive the deploy. Search Console will eventually report a fetch error, but only if the sitemap was submitted there, and only when you next look.

4. http URLs after an HTTPS migration

Every entry redirects, and often the sitemap file itself is served over http too. This one compounds: a redirecting sitemap containing redirecting URLs is two layers of “this is not the address you want”.

5. Mixed domains inside one file

Half the entries on www, half without. Or a handful still on the staging subdomain, which is both an SEO problem and a small disclosure of your infrastructure. Crawlers ignore entries outside the sitemap's own domain, so those URLs are simply not submitted at all — while your count suggests they are.

6. A sitemap index pointing at children that no longer exist

The index file survived; the individual sitemaps it names did not. It fetches cleanly, parses cleanly, and delivers zero URLs. Nothing about this looks like an error unless you follow the children.

The post-migration checklist

Run this the day the site goes live, not a month later. In order:

1. Load /robots.txt and confirm the Sitemap: line names a URL that resolves. Also confirm there is no Disallow: / that travelled from staging — that failure is worse than everything else here combined.
2. Fetch the sitemap and check the status code, the URL count and whether it is an index. A count that exactly matches the old site is a warning sign, not a reassurance.
3. Click five URLs at random. Every one should return 200 at the address listed — no redirect, no 404.
4. Confirm protocol and domain consistency across the file. All https, all one hostname.
5. If it is an index, follow each child and repeat steps two and three on them.
6. Spot-check canonicals on the live pages with the SEO page checker. Canonicals pointing at the old domain are the second most common migration fault and they are invisible in the sitemap.
7. Resubmit in Search Console. Remove the old sitemap entry if the path changed, and add the new one. Then watch the indexing report weekly for a month.

Twenty minutes, once. The alternative is discovering the problem in week six from a traffic graph, having spent five weeks assuming the drop was a normal post-migration dip.

What recovery should look like

Setting expectations matters here, because the shape of a normal recovery and the shape of a broken one are distinguishable — but only if you know what normal looks like.

• Week 1–2: a dip is normal. Google is recrawling and reprocessing. Do not change anything.
• Week 3–4: recovery should be visibly underway. New URLs appearing in the index, old ones dropping out. If nothing is moving, something is wrong.
• Week 6–8: most of the way back for a small or mid-sized site. Large sites take longer, sometimes considerably.
• Beyond that with no movement: stop waiting. Something is blocking discovery, and the sitemap and robots.txt are the two cheapest places to look first.

Why fetch it rather than trust the plugin

“The plugin handles the sitemap” is true right up to the moment it is not, and the moment it stops being true is exactly a migration — when the database, the URL structure, the caching layer and sometimes the plugin itself have all changed at once.

The sitemap checker fetches the file the way a crawler does and reports what is actually there: the HTTP status, the URL count, whether it is an index, the child sitemaps listed out so you can check each in turn, protocol and domain consistency, size against the 50,000-URL and 50 MB limits, and malformed entries. It is free, needs no account, and stores nothing.

It fetches server-side because a browser cannot read XML from another domain — the same-origin policy prevents it. The fetch is restricted to public addresses, re-validates redirects on every hop, enforces a hard timeout and a size cap, and keeps nothing afterwards.

It will not fetch every URL inside your sitemap; that would mean requesting thousands of pages, which no free tool should do to your server or anybody else's. For per-URL status after a migration, the Pages report in Search Console is the right instrument. This tool answers the question that comes first: is the file itself telling the truth about which site you now have?

FAQ