How to test a redirect map before a site migration

Build the old URL population from several sources

Start with the current sitemap and CMS export, then add URLs found in analytics, server logs, Search Console links and a crawl. These sources answer different questions: a sitemap reflects the URLs the site submits, while logs and links can expose older paths that still receive visits. Include valuable image and document URLs where they are moving too.

Normalise duplicates carefully. A trailing slash, uppercase path, query parameter or alternate hostname may be a deliberate variant with a different response. Keep the original requested URL in the test set even when several variants will share one rule. Record where each URL came from and whether it has traffic, links or a business-critical use.

For the wider sequence of baseline, staging and launch controls, use the website migration SEO checklist alongside this URL-level test.

Make every destination an explicit content decision

Give each old URL a proposed final URL, a decision type and an owner. The usual decisions are equivalent page, genuinely consolidated page, retired with no replacement, or investigate. A page that has no relevant successor should not be sent to an unrelated page merely to avoid a 404. Google warns that mass redirects to an irrelevant homepage can confuse users and may be treated as soft 404s.

Review the difficult rows with the people who know the content and customer journey. A product that no longer exists may have a useful category successor; a policy document may need its own archived page. That judgement cannot be made from matching URL strings alone. Keep an unresolved state visible rather than silently accepting a guessed destination.

• Old requested URL and source of discovery
• Final destination or intentional 404/410 decision
• Content-equivalence reason and decision owner
• Priority, based on traffic, links or business use
• Expected status and observed test result

Test the response path, not only the final page

Run each old URL without automatically following redirects first. Record its status and Location header, then follow the full path and save every hop. For a permanent move, Google recommends server-side permanent redirects such as 301 or 308. A 302 used for a permanent migration sends a different signal, while a JavaScript-only redirect can be harder to observe and depends on rendering.

Flag loops, missing Location headers, unexpected domains, protocol downgrades and chains. Google recommends sending an old URL directly to the final destination where possible; each extra hop adds latency and another place to fail. The final URL should return the intended content, not a generic page with a 200 response. Check its heading, canonical, robots directives and relevant internal links.

Use a layered sample before full validation

Before launch, rehearse representative paths from every rule family and template: high-traffic pages, linked legacy URLs, retired content, parameters, case variants, files and alternate hostnames. This catches rule-order and pattern problems while the map is still editable. A handful of successful examples is not proof that a broad rewrite rule is correct, so run the full map against a production-like environment once the sample passes.

Keep automated checks separate from editorial review. A script can compare expected and observed statuses, hops and final URLs. It cannot decide whether a redirected page actually satisfies the intent of an old one. Have a reviewer inspect the destination for the highest-risk groups and any many-to-one mappings.

Recheck the public release and keep an exception log

After launch, run the same test against the public domains. Save the deployment identifier, test time, old URL, observed redirect chain and final response. Compare the new sitemap, self-referencing canonicals and internal links with the final destinations; links on the new site should generally point directly to those URLs rather than relying on redirects.

Triage failures by impact and pattern. A shared rule sending a whole section to the wrong host is different from one retired low-traffic URL. Use server logs and Search Console to find old URLs still being requested and new pages returning errors. Google recommends keeping migration redirects for at least a year, and longer may help users who still follow old links. Retest after every rule change so the exception log can close with evidence.

The search-critical website release checks cover the other live artefacts that should be verified at the same time.