Why Sitemap Diffs Are A Migration Cornerstone
Site migrations — domain changes, CMS swaps, redesigns, locale rollouts, IA overhauls — share a single failure mode: URLs that existed in the old site but are not redirected in the new one. Every unmapped URL is a 404 the moment the migration lands, which means lost crawl equity, lost ranking, lost referral traffic, and, if you depend on organic search, lost revenue. The job of the migration is not just to ship the new pages; it is to make sure every URL that mattered before still resolves to something useful after.
Sitemap diffing is the cheapest, fastest way to spot the gap. An XML sitemap is the site's own declaration of what it considers crawlable and indexable. Compared across a migration boundary — old sitemap vs new sitemap — the diff tells you exactly which URLs were left behind, which are new, and which look like renames that need explicit 301s. Crawler tools like Screaming Frog or Sitebulb give richer signals (status codes, response headers, internal link counts) but they are slower to run, more expensive, and overkill for a fast sanity check the day before a launch.
What URL Normalization Buys You
Two sitemaps generated by different systems will almost never agree on cosmetic details: one emits trailing slashes, the other does not; one uses www., the other does not; one orders query parameters alphabetically, the other in declaration order; one writes hostnames in lowercase, the other uppercases the protocol. None of these are real differences in how the page is served — almost every server canonicalizes them — but a naive string comparison treats them as completely different URLs.
Normalization collapses those cosmetic variants into a single canonical form before the comparison runs. By default this tool lowercases the host, strips trailing slashes on non-root paths, drops the www. prefix, ignores http vs https, and sorts query parameters alphabetically. The diff then operates on the normalized form, so URLs that only differ in cosmetic ways land in the Common bucket where they belong. Each normalization is a separate toggle: if you specifically care about, say, http vs https as a real difference, turn the protocol normalization off and see those URLs split into the Only-in-A and Only-in-B buckets.
Similarity Matching: Catching Renames Automatically
The hardest part of a migration audit is not the URLs that vanished or the URLs that were added — it is the URLs that were renamed. A slug change from /pricing-2024/ to /pricing/, a category restructure from /blog/category/foo/ to /articles/foo/, or a CMS migration that swaps /products/widget/ for /p/widget/ all look like one URL disappearing and another appearing. Without explicit help, they bury themselves in the Only-in-A and Only-in-B columns, easy to overlook.
After the normalized diff is computed, this tool runs Levenshtein-distance similarity across the still-different URLs from both sides. For each unmatched URL in A, it searches for the closest match in B and pairs them if the similarity is above the threshold (0.85 by default — meaning the two URLs must agree on roughly 85% of their characters after normalization). The result is the Similar tab: a side-by-side list of probable rename pairs with the similarity percentage, ready to be exported and turned into 301 rules.
Greedy uniqueness keeps the pairing clean: once a URL in B is paired with a URL in A, it is removed from the candidate pool. This means each A-URL gets at most one suggested B-target and vice versa — the suggestions are useful as a draft redirect map rather than a noisy any-to-any matrix. Tune the threshold up if you see false positives, down if you suspect real renames are being missed.
Reading The Diff: A Practical Workflow
The fastest way to use the output is a four-step pass:
- Only in A → check for redirect coverage. Every URL here exists in the old sitemap but not the new one. If there is a matching entry in the Similar tab, plan a 301 to its B-side counterpart. If not, decide: was the page intentionally retired (in which case a 410, or a 301 to the closest topical replacement), or was it accidentally orphaned (in which case fix the migration before launch)?
- Similar → review and approve. Each suggested pair is a draft redirect. Eyeball the similarity score: anything above 0.90 is usually a confident rename; 0.85–0.90 deserves a quick human check; below 0.85 (if you lowered the threshold) often pairs unrelated URLs that happen to share a substring.
- Only in B → check for orphans and pollution. New URLs are expected, but watch for staging-only URLs that should not have made it into the production sitemap, faceted-navigation pages that should be noindex, or duplicates from a sloppy URL builder. The Only-in-B bucket is also where you spot pages that exist on the new site but have no internal link from the old site's content — those will need editorial backfills.
- Common → spot-check for trailing-slash and protocol drift. Even with normalization, glance at the Common tab to confirm the URLs you expect on both sides actually landed there. A surprisingly small Common bucket is usually a sign that one sitemap has a systematic cosmetic difference your normalization toggles do not currently cover.
Sitemap Indexes vs URL Sets
The sitemaps.org protocol allows two root types: <urlset>, which lists actual page URLs, and <sitemapindex>, which lists the URLs of other sitemap files. Large sites that exceed the 50,000-URL or 50 MB per-sitemap limit split their sitemaps into multiple chunks and ship an index. If you feed a sitemap index into the comparator, the diff will not be on real page URLs — it will be on the URLs of the child sitemaps themselves, which is rarely what you want.
The tool detects this case and surfaces a warning at the top of the affected panel. The fix is to download each child sitemap separately and feed them in pairs, or to merge them locally before comparing. Future versions may handle index expansion automatically; for now the explicit warning prevents the silent footgun of comparing index entries instead of page URLs.
Where Sitemap Diffs Fit In A Bigger Migration Plan
A sitemap diff is a necessary but not sufficient step. The strongest migration audits combine: (a) a sitemap diff like this tool to surface the URL-level deltas; (b) a server-log analysis to spot URLs Google crawls that are not in the sitemap at all (often the long tail with the most accumulated equity); (c) a Google Search Console export of top-performing pages to confirm none of the top traffic URLs are in the Only-in-A bucket without a redirect; (d) a post-launch crawl with status-code checks to verify every planned redirect is actually wired up correctly in production. Treat the sitemap diff as the first 80% of the audit you can run in 30 seconds, then layer the more expensive techniques on top for the high-stakes pages.
Privacy: Why Local Processing Matters Here
Sitemap files routinely include pre-launch URLs, gated content, staging environments, client work under NDA, and competitor crawls you would rather not have logged by a third-party service. Browser-side processing — the entire pipeline runs in the same tab that loaded the page — means the XML you paste never crosses a network boundary. You can verify this in your browser's DevTools network panel: after the page loads, the Compare button triggers zero HTTP requests. The same comparison logic is available as an open-source library if you need to run it in a CI pipeline or a Node.js script, but the web tool itself is fully self-contained.