Field guide · technical workflow
Compare source and destination sitemap coverage
A destination sitemap can be perfectly valid XML yet omit pages that generated valuable organic enquiries on the old site. Counting sitemap entries is not enough: the decision is whether important source URLs have a relevant surviving destination and a crawlable route to it.
Who this is for: Give a migration owner an auditable reconciliation between old canonical URLs, new destination inventory and intentional removals.
Editorial preview — facts, worked examples and publication approval are still being checked.
The practical problem
A practical compare source and destination sitemap coverage exercise: Join old sitemap URLs to real crawl and GSC landing-page evidence. The outcome is a documented decision backed by classify missing destinations, redirect-only urls and new canonical routes. The final check is to verify destination sitemap and old URL redirects on production after authorisation.
What you will be able to check
- Join old sitemap URLs to real crawl and GSC landing-page evidence.
- Classify missing destinations, redirect-only URLs and new canonical routes.
- Verify destination sitemap and old URL redirects on production after authorisation.
Reproducible scenario
Worked example: Compare source and destination sitemap coverage
An illustrative B2B website replaces a 120-URL source sitemap with a new 95-URL sitemap. The project team celebrates the reduced page count, but the 25 missing URLs include older service explainers and product specification documents that search visitors still use. Not every missing URL needs an exact replacement, yet every high-value one deserves an explicit map or retirement decision.
Starting assumptions
- The owner can export both old and new sitemap files and one additional source of real old landing-page evidence.
- A technical reviewer can request selected URLs and inspect final canonical and HTTP status from the destination environment.
Decisions and checks
Combine sitemap differences with the actual old content inventory
Compare normalized source and destination paths, but also include old URLs found in crawls and Search Console that never appeared in the sitemap. Identify a genuine missing landing rather than assuming every omitted sitemap URL is an error.
What to verify: A reconciliation labels source URLs as retained, mapped, consolidated, intentionally retired or unresolved.
Check whether each new sitemap entry represents a preferred, useful destination
Request representative new pages and compare redirects, canonicals and internal links. A sitemap can contain valid XML and still list redirect-only or noncanonical URLs. Confirm actual content and indexability before adding entries by quota.
What to verify: A destination set where each sampled entry corresponds to the intended canonical page and useful site navigation.
Use the unresolved high-value delta as a release blocker
Where an important old service page lacks a successor, require a decision before cutover. Preserve the original source route with a relevant mapping or clear removal response; do not treat the new sitemap count as a performance metric.
What to verify: A signed migration delta with no unexplained high-value omissions and a repeatable post-launch crawl sample.
Expected output: The reconciliation exposes the gap between a technically valid sitemap and preservation of useful visitor destinations. It enables an explicit decision on each priority missing source and clearer release accountability. Google indexing and subsequent traffic must still be measured separately; a complete spreadsheet cannot promise search continuity.
This migration sitemap comparison migration story is hypothetical and is not an observed client cutover or verified ranking result.
Create a source-of-truth URL inventory
Collect the old sitemap alongside the source crawl and first-party landing-page list. Not every valuable source URL necessarily appears in an old sitemap, so avoid using the XML file as the only source of truth. Mark the top service, product and resource routes by actual commercial importance.
Reference: official · 2026-11-07
Reconcile new sitemap destinations
For each destination page, check the canonical and sitemap membership. A redirect-only old address should not remain the main preferred sitemap target. Record old URLs without a new equivalent, unexpected new URLs and destination pages with no inbound navigation.
Reference: official · 2026-11-07
Use the delta as a cutover release check
Use the reconciliation before launch and repeat it after the production deployment. Test representative old-to-new redirects and check that the new sitemap is publicly accessible on the intended domain. A sitemap aids discovery but cannot prove that search engines have indexed every page.
Reference: official · 2026-11-07
Decision aid
Decision table: Migration sitemap comparison before launch
| Legacy issue or URL class | Relevant decision | Real evidence required |
|---|---|---|
| Old service URL missing but matching new content exists | Create an approved old-to-new mapping and check destination parity. | Inspect source landings, redirect, final content and canonical. |
| Old duplicate archive omitted after deliberate consolidation | Confirm the consolidated destination serves the same reader task. | Review old topic overlap and final replacement article. |
| New sitemap contains a URL that returns 301 | Replace it with the approved final canonical URL. | Record actual response, Location and destination metadata. |
What a passing test looks like
These checks describe the evidence that should exist after a real implementation. They are not reports of tests already completed on a customer website.
Combine sitemap differences with the actual old content inventory
Expected result: A reconciliation labels source URLs as retained, mapped, consolidated, intentionally retired or unresolved.
Keep as evidence: Archive the exact source URL requests, final destination and reviewer signoff for combine sitemap differences with the actual old content inventory.
Check whether each new sitemap entry represents a preferred, useful destination
Expected result: A destination set where each sampled entry corresponds to the intended canonical page and useful site navigation.
Keep as evidence: Archive the exact source URL requests, final destination and reviewer signoff for check whether each new sitemap entry represents a preferred, useful destination.
Use the unresolved high-value delta as a release blocker
Expected result: A signed migration delta with no unexplained high-value omissions and a repeatable post-launch crawl sample.
Keep as evidence: Archive the exact source URL requests, final destination and reviewer signoff for use the unresolved high-value delta as a release blocker.
Scope and limitations
The example URL counts are hypothetical and do not describe a tested migration. Real sitemap coverage may be partial, intentionally scoped or generated by plugins. The correct comparison uses actual canonical URLs and first-party search evidence rather than treating every numerical difference as a defect.
Sources and verification
These references explain documented technical behaviour. The worked decisions are illustrative until checked on your own installation.
- official reference — Google notes that sitemaps assist with URL discovery but do not guarantee indexation and need accurate site links and canonical destinations. Recorded: 2026-11-07