SEO Migration Redirect Mapper & Validator

How to Build a Defensible Redirect Map

1. Collect complete inventories. Add every legacy URL that earned visits, links, rankings, or user bookmarks—not only URLs still present in the old sitemap. Supply new canonical URLs from staging or the launch site.
2. Add identity signals. URL-only matching works when structure survives the migration. Include titles or H1 values in pasted data or CSV when folders, slugs, domains, languages, or taxonomies changed.
3. Generate explainable candidates. The browser calculates every old-to-new pairing, shows the top candidates and their component signals, blocks weak automatic homepage fallbacks, and leaves matches below your threshold unmapped.
4. Resolve ambiguity. Review low confidence rows, click alternatives, type overrides, mark unchanged URLs as Keep, and inspect every many-to-one destination. A consolidation is valid only when one new page satisfies all mapped legacy intent.
5. Validate after rules are deployed. Work through every 40-row batch. Check that redirects reach the intended destination in one permanent hop and Keep URLs still return a successful page. Fix chains, temporary hops, loops, wrong targets, and redirected destinations.
6. Export and retain the evidence. Download the review CSV for sign-off, then generate the appropriate server format. Keep the approved mapping as a launch artifact and compare it with post-launch crawls.

Why Redirect Mapping Is the Highest-Risk Migration Detail

Google’s current site-move guidance says complex moves need an old-to-new URL map before redirects are implemented. Its redirect guidance recommends server-side permanent redirects for permanent moves. A direct relevant mapping helps both visitors and crawlers understand where content went.

• Protect legacy discovery: old organic results, bookmarks, backlinks, campaigns, and internal links should reach an equivalent destination.
• Avoid false consolidation: sending every deleted page to the homepage hides missing content and creates poor user journeys.
• Remove chains: old rules often survive several redesigns. Point each known legacy URL straight to the final canonical URL.
• Make sign-off auditable: confidence, alternatives, overrides, validation evidence, and review notes belong in one shared artifact.

Migration Inputs Most Teams Forget

The old XML sitemap is a starting point, not a complete legacy inventory. Add these sources before approving the map:

• Analytics: organic and referral landing pages across a representative period.
• Google Search Console: pages with clicks or impressions, including URLs no longer linked internally.
• Backlink exports: URLs with valuable external links, including historic HTTP and hostname variants.
• Server logs and 404 reports: URLs bots and people still request.
• CMS/database exports: published, archived, product, taxonomy, media, and localized records.
• Crawls: current links, canonicals, hreflang targets, pagination, assets, and existing redirect rules.
• Marketing records: email, advertising, QR, partner, affiliate, and offline campaign URLs.

Launch-Day and Post-Launch QA Checklist

1. Deploy rules to staging when possible and crawl every old URL against that environment.
2. Confirm one permanent hop to a relevant 200 destination; do not redirect into another redirect.
3. Update internal links, canonicals, hreflang, structured data, navigation, and the new XML sitemap to final URLs.
4. Keep the old domain and redirect infrastructure active long enough for users and search systems to process the move.
5. Verify both old and new Search Console properties and use Change of Address when the documented conditions apply.
6. Monitor 404s, server logs, indexing, page-level clicks, and important rankings after launch. Repair missed URLs instead of layering new chains.
7. Retest mapped URLs after CDN, CMS, routing, or domain configuration changes.

Export Format Notes

The Apache and Nginx exports create exact path matches and use 301; install them only in the matching legacy-host server context because the rule itself contains no source hostname. Cloudflare Bulk Redirect CSV follows Cloudflare’s current no-header CSV format. Vercel bulk CSV and JSON use source, destination, and permanence fields as documented for bulkRedirectsPath. Vercel sources are project-wide paths without hostnames, so split mixed-host inventories and deploy each file only to its intended legacy-host project. Always review the generated file against the version and routing layer you deploy.

Deployment formats intentionally exclude Keep/no-redirect decisions. They also skip source URLs with query strings, percent-encoded or non-ASCII paths, and non-literal paths because request-URI handling differs across servers and platforms. Every excluded decision remains in the review CSV for explicit implementation and testing. Wildcards and regex are not inferred: compressing individually approved mappings into a broad rule without testing can redirect unrelated URLs.