If your active WordPress sitemap still lists unwanted old URLs after a migration, identify whether the generator, stored content settings, or cache is supplying them. Editing the XML once is not a durable repair when the CMS will regenerate the same URLs on its next update.
First distinguish an accidental stale sitemap from an intentionally retained old-URL sitemap used to monitor a site move. Record which file you are examining and what it is meant to contain. Your active canonical inventory and your migration comparison records serve different purposes.
Capture Three Specific Examples
Choose an old homepage variant, a moved content page, and a nested page. For each, record the sitemap URL that lists it, its actual response, and its intended replacement. A sitemap index may point to several child files, so inspect the child containing the bad entry rather than only the index timestamp.
Compare those examples with the approved redirect map. Do not assume a domain-wide string replacement preserves every path. A retired page without a relevant replacement should not be redirected to an unrelated homepage merely to make the report look clean.
Find Who Generates the File
Determine whether the sitemap comes from WordPress core, an SEO plugin, a static export, or a headless publishing service. Check the active provider's settings and the source records it reads. Multiple generators can leave old files accessible even when the intended sitemap is correct.
For a headless frontend, compare the CMS URL, public canonical URL, and generated artifact using the headless sitemap checklist. The API hostname should not replace the public content hostname in the search inventory.
Explanatory test plan. Record your own observations; no customer results are shown.
Separate Generation From Caching
Fetch the same sitemap through the normal public route and an authorized origin or cache-bypass method. Preserve headers and a small diff of the affected entries. If the origin is already correct but the edge is stale, a targeted invalidation may be enough. If both are wrong, purging repeatedly only republishes the mistake.
Check object caching when the generator reads cached URL data. Use the stale object-cache sitemap guide for that branch. Avoid a site-wide cache flush during a busy period unless the operational impact is understood.
Align the New Inventory With the New Pages
Google's sitemap guidance recommends listing the URLs you want shown in search, using absolute URLs and meaningful modification dates. Verify each sampled new URL returns its intended content with the expected canonical and no accidental exclusion.
| Surface |
Expected relationship |
| Active sitemap |
Intended public URL |
| New document |
Correct content and canonical |
| Old document |
Approved migration response |
| Internal links |
Point directly to the intended destination |
| Search Console |
Correct property and observed crawl dates |
Do not mark every page as newly modified merely because the sitemap was regenerated. Do not remove redirects because the new sitemap looks correct. Google's site-move guide treats URL mapping, redirects, and monitoring as parts of the same migration.
Verify Regeneration, Then Monitor Discovery
Trigger a normal content update through the publishing system and confirm the corrected URL remains correct after regeneration. Recheck the CDN copy. Confirm the intended sitemap is registered in Search Console and read its last-read status, not only the live XML.
Google's discovered count can lag the current file. It is not a count of indexed pages, and submitting a sitemap does not guarantee indexing. Inspect representative old and new URLs and record their observed state before claiming the move is complete.
HandL WP can trace a migration sitemap mismatch across the generator, cache, redirects, and public pages. A few exact old/new examples are more useful than repeatedly resubmitting an unchanged file.
Sources checked September 26, 2026. Visuals and examples are explanatory, not customer measurements.