How do you validate redirects during a site migration before traffic is put at risk?

Treat redirects as a data-mapping problem and test them before DNS or routing changes go live.

Export all meaningful legacy URLs from analytics, Search Console, XML sitemaps, crawls, backlink tools, server logs, and important campaign lists. Deduplicate them into one migration inventory.

Assign each old URL one explicit destination based on content equivalence. Do not default everything to the homepage. If no relevant replacement exists, a 404/410 can be more honest than an irrelevant redirect.

Automate prelaunch checks against the staging mapping:
- Old URL returns one redirect hop whenever possible.
- Final destination returns 200.
- Destination is indexable and self-canonical.
- Destination content satisfies the same intent.
- No loops or chains.
- Query strings needed for functionality are preserved intentionally.
- Protocol, hostname, casing, and slash conventions resolve consistently.

Create exception reports for any legacy URL that maps to the same generic destination in suspiciously large batches.

At launch, crawl the old URL set externally and compare actual outcomes with the planned map. Then monitor 404s and bot requests in server logs for missed legacy paths.

Update internal links and XML sitemaps immediately so the site is not depending on redirects for routine navigation. Redirects should preserve old signals, not become the permanent internal architecture.

For high-value pages, track impressions, clicks, rankings, and landing-page traffic separately for several weeks. Migration success is not “the redirects return 301”; it is that users and search engines consistently reach the correct replacement with minimal signal loss.