No old URL gets left behind by accident.

Why the sitemap is never enough

Most agencies, if they do this at all, export the old sitemap and call it the inventory. Sitemaps are routinely stale, partial, or auto-generated from a plugin that never knew about half the site. On one recent project the sitemap listed 168 URLs and crawling the internal links surfaced 57 more, several of which were ranking pages.

So the inventory comes from two directions: the sitemap, and a crawl that follows every internal link from the navigation, every hub or index page, and one level below each. Where the client can give me Search Console access, the list of pages that have earned impressions is a third source, and the most authoritative one.

The playbook

1. Crawl the full current site and collect every known public URL from sitemap, links, and Search Console.
2. Diff those sources against each other. Any path in one and not the others gets looked at by hand.
3. Assign each URL one of three dispositions: PRESERVE, 301, or RETIRE. No URL is left unassigned.
4. Gate every RETIRE against Search Console evidence. If a page has earned impressions, it is not retired without the owner saying so in writing.
5. Build the route or the redirect, and verify that every target resolves to a real page rather than another redirect.
6. Run the automated check that requires MISSING equals zero before launch.
7. Watch Search Console and live 404s after launch for paths the inventory missed.

What each disposition means

PRESERVE keeps the page at its exact address. This is the default for anything with search value: service pages, town pages, articles. The writing may be rewritten where the old copy made claims we cannot support, but the address does not move.

301 is a permanent redirect to the page that replaced it, in one hop. Chained redirects leak value and are treated as a defect, not a shortcut.

RETIRE means the page is genuinely obsolete and gets redirected to the most relevant section index rather than left to 404. Tag archives and paginated query URLs are the usual candidates. Retirement is a decision someone made and recorded, which is the difference between this and letting Google work it out.

The check that runs before launch

The migration map is not a promise, it is a file, and a script reads it. It resolves every URL in the old inventory against the new route table and reports three counts plus MISSING. If MISSING is anything other than zero, there is a URL that ranks today and will 404 after cutover, and the launch does not proceed.

You get the map. You can read any line of it and check that line yourself against the live site. That is the point of writing it down.

After launch

MISSING equals zero is a launch gate, so nothing should be broken on day one. What the first thirty days catch is the category no inventory can cover: an address that was never linked, never in a sitemap, and never crawled, but that somebody out there still has bookmarked or printed on a business card.

So live 404s get watched rather than assumed away, Search Console coverage is checked for pages dropping out of the index while engines re-crawl, and the redirect table gets added to when a real path surfaces. Finding two or three of those is normal. Finding thirty means the inventory was done badly.