Site Migration Audit: Don't Lose Traffic on Replatform

Site migrations — replatform, redesign, domain change, HTTPS, URL structure overhaul — are the single biggest cause of avoidable organic traffic loss. The reason is almost never the new platform; it's the migration execution.

The Site Migration Audit runs comprehensive pre-migration baselining, validates the 301 redirect plan, checks schema preservation, and monitors post-migration recovery against the baseline so you catch and fix issues before they compound. This guide covers the full migration audit lifecycle. It doubles as a migration audit checklist for before and after the move.

Why migrations lose traffic

The four common causes of migration traffic loss, in order of frequency:

Broken 301 mapping — old URLs go to 404 or generic redirect instead of the right new URL
Lost schema — new platform doesn't replicate the structured data that the old one served
Lost on-page signals — title tags, meta descriptions, H1s, canonical URLs change in ways nobody planned
Slower performance — new platform is heavier, CWV regresses, ranking follows

All four are avoidable with discipline. The Migration Audit enforces the discipline.

The website migration checklist: four phases

Phase 1: Pre-migration baselineFull snapshot of current URLs, schema, on-page signals, rankings and performance. The "before" picture you'll compare to.

Phase 2: 301 mapping validationEvery old URL has a planned destination on the new site. Validate destinations exist and are appropriate.

Phase 3: Pre-launch validationStaging-side check that the new site matches plan — schema, signals, CWV, robots, sitemap.

Phase 4: Post-launch monitoringDaily monitoring of rankings, traffic, indexation, errors against baseline for 90 days.

Phase 1: Pre-migration baseline

Capture, on the old site, before any migration work begins:

Full URL inventory — every indexed URL, from Search Console + Ahrefs + site crawl
Per-URL on-page signals — title, description, H1, canonical, robots meta, lang, hreflang
Per-URL schema — what JSON-LD blocks are present
Per-URL backlinks — top 50 backlinks per page (to preserve link equity routing)
Per-URL traffic — clicks, impressions, position last 90 days from Search Console
Per-URL performance — CWV scores
Indexation state — what's indexed vs noindexed vs blocked
XML sitemap snapshot
robots.txt snapshot

This baseline is the ground truth for everything that follows. Don't start migration without it.

Phase 2: 301 mapping validation

The 301 mapping spreadsheet has one row per old URL with: new URL, redirect type (301 typically, sometimes 410 for genuinely-removed content), priority tier (top revenue / top traffic / archive). Validate:

Every URL has a planned destination — no gaps
Destinations actually exist on the new site (verify in staging)
Destinations are topically relevant — old "/laptops/macbook-pro" goes to "/laptops/macbook-pro-new" not "/laptops"
No redirect chains — old URL → new URL, never old → intermediate → new
Top-50 backlinked pages get specific destinations, not just routed to homepage
410s where appropriate — products discontinued forever, not just for now

⚠️ The biggest migration failure mode is "everything redirects to homepage". This kills backlink equity routing and confuses Google about your site structure. Specific destinations matter even for low-traffic pages.

Phase 3: Pre-launch validation

On staging, compare to baseline:

Every old indexed URL's new equivalent: does it have a title that matches plan?
Schema: is the JSON-LD on each page-type present? Validate with Rich Results Test on samples.
Canonical URLs: do they point to the right place on the new structure?
Robots meta and X-Robots-Tag: nothing accidentally noindexed
Sitemap: new sitemap generates from new URL structure, no orphans
robots.txt: not blocking anything by mistake
Performance: CWV on top page-types — better or equal to baseline
Hreflang (if applicable): all locale URLs cross-reference correctly

Phase 4: Post-launch monitoring

Day 0 through day 90, daily:

Indexation — Search Console index count for new domain/structure
Coverage errors — Search Console Coverage report; alert on spikes
301 health — sample old URLs daily; confirm 301 to expected destinations
Ranking drift — top 100 revenue queries; alert on more than 5 positions move
Traffic — total clicks vs baseline; alert on more than 15% sustained drop
404 explosion — log monitoring; alert when 404 rate exceeds baseline

The 6-week rule

Expect a 10-30% temporary dip in the first 2-4 weeks even with perfect execution — Google needs time to re-crawl, re-index and re-evaluate. After week 4 traffic should be tracking back to baseline. After week 6, if you're still under 90% of baseline, something is wrong and warrants intervention. After week 12, if traffic hasn't recovered, the migration failed — diagnose root cause via the 4 phases above and remediate.

Frequently Asked Questions

How long before migration should the audit start?

Phase 1 (baseline) should happen at least 4 weeks before migration. This gives you a comparison window that's seasonally representative, lets you spot issues in the current site that should be fixed before migrating, and gives the team time to build a complete 301 mapping. Tight migration timelines that try to start audits 1-2 weeks before are a major cause of post-migration traffic loss.

Can I skip the 301 mapping for archive pages with no traffic?

Tempting but risky. Archive pages often carry surprisingly valuable backlinks even when they have minimal direct traffic. Better approach: 301 archive URLs to the closest topically-relevant new URL (often the new category page), use 410 only for content genuinely permanently removed with no equivalent. Mapping all URLs is cheap; failing to map them and losing equity is expensive.

Do I need to keep the old domain after a domain change?

Yes, indefinitely. Renew the old domain forever; route it to 301 redirect chains pointing to the new domain. Letting the old domain expire after 1-2 years loses the redirect chain and all the backlinks that point to old URLs. Most migration failures happen 18-36 months later when the old domain is allowed to lapse.

What's the recovery timeline if a migration goes badly?

Depends on how badly and how quickly you intervene. Small issues caught within 2 weeks usually recover within 4-8 weeks of fix deployment. Larger structural issues — broken 301 mapping, lost schema, killed canonicals — can take 3-9 months to fully recover even after fix, because Google's re-evaluation is gradual. Catastrophic migrations sometimes never fully recover. The Migration Audit is fundamentally about prevention.

🔀 Audit your site migration

Pre-migration baseline, 301 mapping validation, pre-launch validation and 90-day post-launch monitoring.

Open Site Migration Audit →