Organic traffic drops of 30–60% after migrations are common — and entirely preventable. They happen because redirect maps are incomplete, canonical tags point to the old domain after launch, or the staging site was accidentally indexed before launch. The migration checklist below is ordered by phase because sequencing matters as much as coverage.
Key Takeaways
- Crawl the old site before migration to create a complete URL inventory — you can't redirect what you haven't mapped
- Every old URL that changes must have a 301 redirect to its new equivalent — a redirect to the homepage is not a substitute
- Block the staging site from indexing (robots.txt Disallow: / + password protection) before launch
- Update canonical tags, sitemap URLs, and JSON-LD URLs to the new domain before DNS cutover
- Monitor GSC Coverage and Search Performance daily for 4 weeks post-launch
Phase 1 — Pre-Migration (Weeks Before Launch)
Step 1: Crawl and Inventory the Old Site
Before changing anything, get a complete list of all indexed URLs on the current site. Use the SEO Site Audit to crawl every internal page. Export the full URL list. This becomes the source of truth for your redirect map.
Also note which pages have external links (backlinks) — these are highest priority for redirect accuracy because they carry the link equity you're trying to preserve.
Step 2: Build the Redirect Map
For every old URL that will change, create a 1:1 redirect to the most equivalent new URL. Format: old_url → new_url in a spreadsheet. Priorities:
- All top-traffic pages (check GSC Performance report for highest-click URLs)
- All pages with external backlinks
- All pages in the current sitemap
- All pages Googlebot has crawled (visible in GSC Coverage)
Step 3: Audit the New Site on Staging
Before launch, validate the staging site:
- Block indexing — robots.txt must have
Disallow: /and the site should be password-protected. Never launch a staging site that's been indexed. - Check all canonical tags point to the new domain, not the old domain
- Check the sitemap contains new URLs only
- Check JSON-LD schema URLs (
url,@id) use the new domain - Verify that the redirect map has been implemented by testing a sample of old URLs on the staging domain (if possible)
Phase 2 — Launch (Cutover Day)
Timing the DNS Cutover
Launch on a Tuesday, Wednesday, or Thursday — never Friday. If something breaks, you need business hours to fix it. Avoid major holidays or peak sales periods.
Lower the DNS TTL to 300 seconds (5 minutes) 24–48 hours before cutover. This makes the switch propagate faster and lets you roll back quickly if needed.
Immediate Post-Cutover Checks (First 2 Hours)
- Verify the old domain redirects are live — use the Redirect Tracer on a sample of old URLs to confirm each 301s to the correct new URL
- Verify the new site is accessible (no unexpected 403s, server errors, or redirect loops)
- Confirm robots.txt on the new domain is no longer blocking indexing
- Submit the new sitemap in GSC immediately after cutover
- Use GSC URL Inspection to request indexing on the 5–10 most important pages
Phase 3 — Post-Launch Monitoring
Week 1 (Daily Checks)
GSC data lags 48–72 hours, but checking daily lets you catch problems as soon as the data refreshes.
- Coverage report — watch for new 404 errors on pages that should be accessible. These indicate gaps in the redirect map.
- Performance — expect a dip in clicks for 1–3 weeks while Google processes the redirects. A sustained drop after week 3 indicates a systemic problem.
- Crawl stats — Googlebot's crawl rate should increase post-migration as it processes the new URLs. A flat or falling crawl rate suggests the new site isn't being discovered.
Weeks 2–4 (Weekly Checks)
- Re-crawl the new site with the Link Checker to find any 404s or broken internal links created during the migration
- Verify the sitemap reflects the new URL structure accurately with the Sitemap Validator
- Monitor top-traffic pages individually — check their new canonical URLs are being recognised by Google using URL Inspection in GSC
Common Migration Mistakes
| Mistake | Effect | Fix |
|---|---|---|
| Staging site indexed before launch | Google indexes old staging content, sees new domain as duplicate | Immediately noindex staging and submit new sitemap |
| Canonical tags still pointing to old domain | New pages pass authority back to old domain; new domain can't rank | Update all canonical tags before DNS cutover |
| Missing redirects for old blog/tag/archive pages | 404 errors, lost crawl budget, lost link equity from blog posts | Export all GSC-crawled URLs pre-migration, map every one |
| Redirect chains from old → interim → new | Link equity diluted through chain; slower crawl | Collapse all chains to single-hop 301s before launch |
Verify Your Redirects Are Working Correctly
Free, no signup. The Redirect Tracer follows the full hop chain for any URL — see exactly where each old URL lands, whether the redirect is a 301 or 302, and whether you have any redirect chains that need collapsing.
Try the Redirect Tracer Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.