Site Migrations: The Redirect Map Is the Whole Job

Site migrations produce the largest single-event traffic losses in SEO, and the cause is almost always the same: an incomplete or wrong redirect map, discovered after launch.

The work that prevents it is unglamorous and entirely front-loaded.

Build the URL inventory first

Before anything else, assemble every URL that currently exists and matters. One source is never enough, because each misses a different category:

• Crawl the live site. Catches everything internally linked.
• Export from Search Console. Catches URLs that receive impressions, including ones your crawl missed.
• Export from analytics. Catches URLs with traffic from any source.
• Server logs. Catches URLs being requested and crawled that appear nowhere else — often the most valuable source, because it finds orphaned pages that still earn links.
• Existing sitemaps, including old ones.
• Backlink data. Catches URLs with external links, including long-dead ones being redirected today. These are the most costly to break.

Deduplicate the union. That list, not the crawl alone, is the migration's scope.

Prioritize by what would hurt to lose

Not every URL deserves equal attention. Rank the inventory by organic clicks over the last twelve months, then by external referring domains. The top few hundred URLs typically account for the large majority of the value — those get individually verified mappings. The tail can be handled by pattern rules.

This prioritization matters because it makes the job finite. "Map 40,000 URLs perfectly" is not achievable in a launch window. "Individually verify the 300 URLs that carry 80% of the value, then pattern-map the rest" is.

Map to the closest equivalent

Each old URL needs a destination that serves the same intent. The rules:

• Map to the closest equivalent page, not to the homepage. Bulk redirects to the homepage are treated as soft 404s and lose the signals you were trying to preserve.
• If no equivalent exists, decide deliberately: redirect to the nearest relevant category, or return 410 Gone. A 410 on genuinely retired content is honest and better than a misleading redirect.
• Avoid chains. Old A → new B, not old A → old B → new C. Chains lose signal at each hop and slow crawling. If the site already has redirects, resolve them against the final destination when building the new map.
• 301, not 302, for permanent moves. This is the signal that consolidation should happen.
• Preserve query strings where they carry meaning, drop them where they do not.

Test the map before launch

The map is a data file, so it can be tested like one. On a staging environment with the new site and redirect rules live:

while read old; do
  code=$(curl -s -o /dev/null -w '%{http_code}' -L "$old")
  final=$(curl -s -o /dev/null -w '%{url_effective}' -L "$old")
  hops=$(curl -s -o /dev/null -w '%{num_redirects}' -L "$old")
  echo "$old,$code,$final,$hops"
done < old-urls.txt > redirect-test.csv

Then check the output for: anything not ending in 200, anything with more than one redirect hop, anything landing on the homepage that should not, and anything whose destination does not match the map.

Running this before launch converts the migration's biggest risk into a spreadsheet you can fix in an afternoon. Running it after launch converts it into an incident.

Launch day

• Keep the old sitemap accessible and submitted for a while — it gives Google a list of URLs to re-crawl and discover the redirects.
• Submit the new sitemap immediately.
• Use Search Console's Change of Address tool for domain moves specifically. It does not apply to restructures within a domain.
• Do not block the new site in robots.txt. A staging Disallow: / shipped to production is a recurring and severe migration failure.
• Monitor server logs from the first hour. Bots find the new structure fast, and 404 spikes in the logs are your earliest signal.

The weeks after

Expect a dip. Some fluctuation is normal while Google re-crawls, re-indexes, and re-associates signals. What is not normal is a dip that does not begin recovering within a few weeks.

Watch specifically: 404s in Search Console's Page Indexing report and in server logs, the indexed page count trending toward the old total, and clicks for your top pre-migration queries.

If recovery stalls, the diagnosis is almost always in the redirect map — a pattern rule that matched too broadly, a section nobody inventoried, a chain that broke. Which is why the inventory step at the beginning determines the outcome at the end: you cannot redirect URLs you never knew you had, and after launch is a bad time to find them.