Site migrations, redirects and recovery

Pre-migration inventory, URL mapping and 301 rules, staging controls, launch checks, monitoring for traffic loss, and what to do about a manual action.

Before the move

1. Crawl the current site completely and export every URL that returns 200, plus every URL with external links pointing at it. The second list is the one people forget.
2. Export 90 days of Search Console queries and landing pages. This becomes the priority order for redirect mapping - traffic first.
3. Build the redirect map as a file in version control. A spreadsheet that lives in someone's inbox will not survive the launch.
4. Lower TTLs on DNS records that will change, at least 24 hours before the cutover.
5. Agree how to roll back. A migration with no rollback path is a bet, not a plan.
6. Remove any noindex from the staging site, and never let staging be crawlable at launch time.

# one hop, explicit, and always to the final URL
server {
  listen 443 ssl;
  server_name old.example.com;

  return 301 https://new.example.com$request_uri;
}

# a rewritten path, mapped one to one
location = /products/widget-200 {
  return 301 https://new.example.com/p/acme-widget-200;
}

# everything else that used to exist under a removed section
location ~ ^/legacy/(.*)$ {
  return 301 https://new.example.com/guides/$1;
}

Launch checks

Launch checklist

DNS          records resolve to the new host, TTL lowered beforehand
TLS          valid certificate covering all hostnames, no mixed content
robots.txt   allows crawling, no stray Disallow: /, staging rules removed
noindex      none on any page you want indexed
Sitemap      regenerated, submitted, URL count matches expectations
Canonicals   point to the new URLs, not the old ones
Redirects    spot-check 50 URLs from the traffic-ranked export
Structured   markup validates on the new templates
404s         the new 404 page returns a 404 status
Analytics    tracking fires on the new domain
Internal     no links left pointing at the old hostnames

• Test the redirect map before the DNS switch: request the old URLs with a Host header override and confirm a single 301 to the right destination.
• Keep the old domain registered and serving redirects for years. Letting it lapse hands the redirect traffic to whoever registers it next.
• Do not run two competing changes at once. A migration plus a redesign plus a domain move makes the cause of any drop impossible to identify.

Monitoring and recovery

1. Expect a dip. Some fluctuation for days or weeks is normal because signals are re-evaluated on the new URLs.
2. Diagnose by segment: if only one section dropped, that section's redirects or canonicals are wrong. If everything dropped evenly, the problem is site-wide - robots, canonicals or the domain.
3. A drop that is still deepening after three weeks is not normal settling. Find the specific fault rather than waiting.
4. For a manual action, read the exact wording. A links action needs removal or disavowal plus a reconsideration request; a thin content action needs the content fixed.
5. If a reconsideration request is rejected, fix more and be specific about what changed. A repeat of the first request will be rejected again.

FAQ

Related

Technical SEO and measuring it Site architecture, URLs and internal linking

Last refreshed 2026-09-18.