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.

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 four migration audit 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 →