← Back to blog

Technical SEO · July 20, 2026 · 8 min read

Site Migration SEO Checklist: How to Replatform Without Losing 60% of Your Traffic

A complete site migration SEO checklist covering redirects, metadata parity, and post-launch monitoring to protect organic traffic during replatforming.

By FluxWriter Team

Site migration SEO is one of the highest-risk technical projects a website team can undertake — done wrong, you can shed the majority of your organic traffic in days and spend months clawing it back. Whether you're moving from WordPress to a headless CMS, switching domains, or replatforming entirely, the same failure modes appear: broken redirects, lost metadata, crawl budget wasted on orphaned URLs. This checklist is built to prevent all of them.

Why Migrations Fail (and What the Stakes Are)

A 2023 study by Zyppy analyzed 450 domain migrations and found that more than half saw organic traffic drop of 25% or more in the first 90 days. Nearly a third never recovered to pre-migration levels. The culprits are almost always the same:

• Redirect chains longer than three hops
• Canonical tags pointing to the old domain after launch
• Robots.txt on the staging environment going live by accident
• Hreflang configurations stripped during the build

The good news: every single one of these is preventable with pre-work.

Phase 1: Pre-Migration (Do This Before You Touch the New Site)

Audit and Freeze Your Baseline

Before a single URL changes, export your entire organic footprint:

1. Pull a full sitemap crawl from Screaming Frog or Sitebulb — capture status codes, title tags, H1s, canonical URLs, meta descriptions, and inbound internal links for every page.
2. Export Google Search Console performance data for the trailing 12 months at the page level. This is your baseline; you'll need it to detect drops after launch.
3. Download your top 500 landing pages by organic sessions from Google Analytics (or GA4). These are your highest-risk pages — every one needs a verified 301.

Critical: lock a content freeze on the old site once you start this audit. Any pages added after your crawl snapshot won't be mapped.

Build the URL Map

For every URL on the old site, you need a corresponding destination on the new site. Capture this in a spreadsheet with at minimum these columns:

Don't map removed pages to the homepage indiscriminately. Google's John Mueller has explicitly stated that mass redirects to an unrelated page don't pass signals — use / only when the homepage is a genuinely relevant destination, otherwise let the page 404 cleanly.

Validate Metadata Parity

Run a diff between your old crawl and the new staging environment:

• Every high-traffic page should have a title tag within ±5 characters of the original, unless you're intentionally updating it.
• Meta descriptions don't directly affect rankings but they control CTR. Don't accidentally strip them.
• H1 tags: one per page, matching (or improving on) the old target keyword intent.
• Schema markup: if you had Product, Article, or FAQ schema on the old site, replicate it on the new one.

A quick way to check at scale: export both crawls to CSV and run a VLOOKUP or use a diff tool like csvdiff. Any row with a mismatch in the title/meta columns needs manual review.

Phase 2: Staging Validation (Before Launch Day)

Test Redirects Against the URL Map

Don't assume the developers implemented every redirect correctly. Test the entire map programmatically:

while IFS=, read -r old_url new_url; do
  response=$(curl -s -o /dev/null -w "%{http_code} %{url_effective}" -L "$old_url")
  echo "$old_url -> $response"
done < redirect_map.csv

Flag anything that returns 302 instead of 301, anything that chains through more than two hops, and anything that ends at the wrong destination URL.

Check Robots.txt and Noindex Tags

This step causes more disasters than any other single item. Staging environments routinely block crawlers by default — and those settings sometimes make it to production.

• Open https://yourdomain.com/robots.txt on the new production environment immediately after DNS switches. It should not contain Disallow: /.
• Check five to ten representative pages for <meta name="robots" content="noindex">. These tags often appear in CMS themes as a "discourage search engines" checkbox.

Verify Internal Link Structure

A migration often shortens or restructures URLs. If your internal links still point to old-format paths and redirects pick them up, you're wasting crawl budget and leaking a small amount of PageRank on every hop. Update internal links in the CMS to point directly to the final new URLs.

Confirm Canonical Tags

On the new site, every page's canonical should point to itself (the new URL). After migration, a common bug is canonical tags that still reference the old domain — this tells Google the old site is the authoritative version, suppressing the new one.

Phase 3: Launch Day

Do not launch on a Friday. Migrations need active monitoring for the first 48 hours. Tuesday through Thursday are your windows.

Launch day sequence:

1. Verify DNS propagation is complete before announcing anything publicly.
2. Immediately submit the new XML sitemap in Google Search Console under the new property.
3. Use the URL Inspection tool to request indexing on your 10 highest-traffic pages.
4. Check server response times — a new hosting environment under real traffic load often reveals performance issues that staging never surfaced.
5. Verify that the old domain's Search Console property still exists and is receiving the redirect signals (you'll see crawl activity shift over the next few weeks).

Phase 4: Post-Launch Monitoring

The 30/60/90 Day Check

Track these metrics against your pre-migration baseline:

30 days: Organic impressions and clicks in GSC (Performance report). You expect a dip of 5–15% as Googlebot re-crawls and re-indexes. Anything beyond 20% needs investigation.

60 days: Average position for your top 50 keywords. Positions may wobble for the first month; by day 60 they should be stabilizing back toward baseline.

90 days: Organic sessions in GA4. This is the headline number. Full recovery to pre-migration traffic typically takes 60–180 days depending on site size and crawl frequency.

Watch Crawl Coverage in GSC

In Google Search Console, open Indexing → Pages. You want to see the number of indexed pages climbing toward your old site's indexed count. If you see a large "Excluded" bucket, click through to understand why — common post-migration causes include soft 404s, redirect errors, and duplicate content from URL parameter handling.

Set Up Alerting

Create a weekly email alert in GA4 for organic traffic drops greater than 15% week-over-week. The earlier you catch a problem, the less damage accrues. Google's algorithm can take weeks to fully process a migration, so a sharp drop in week 3 is often not visible until you compare to day-of-launch numbers.

Common Migration Anti-Patterns

Consolidating to a new domain during a CMS migration. Domain changes and platform changes are each independently high-risk. Combining them doubles the failure surface area. If you must do both, do the platform migration first on the same domain, stabilize, then do the domain move.

Using 302 temporary redirects instead of 301 permanent redirects. A 302 does not pass link equity. Auditors routinely find entire migrations running on 302s because someone used the wrong redirect rule in the web server config.

Not migrating site speed improvements. If your old site loaded in 4.2 seconds and your new site loads in 3.8 seconds, that's a win. But if the new platform adds JavaScript bloat that pushes Core Web Vitals LCP above 2.5 seconds on mobile, the migration may rank worse despite better content.

FAQ

How long does it take to recover traffic after a site migration? Most sites see full organic traffic recovery within 60 to 180 days, assuming all technical elements (redirects, canonical tags, metadata) are correctly implemented. Sites with large crawl budgets (100k+ pages) or weak pre-migration link profiles can take longer. If you're not seeing stabilization by 90 days, audit your redirect chains and GSC coverage reports first.

Should I inform Google before a migration? There's no formal pre-announcement mechanism for platform migrations on the same domain. For domain changes, Google Search Console has a "Change of Address" tool under Settings — use it after the old domain is fully redirecting. Don't submit it before redirects are live.

What's the biggest red flag that a migration has gone wrong? A sudden drop in GSC impressions (not just clicks) within 48–72 hours of launch usually indicates a crawlability problem: robots.txt blocking, a mass noindex tag, or a canonical loop. A drop in clicks with impressions holding steady usually indicates a ranking issue rather than a crawl issue — check if your page titles changed significantly or if there are new competing pages.

Migrations are recoverable — but they're much easier to get right than to fix after the fact. Run through this checklist in two passes: once on staging two weeks before launch, and once on production within six hours of going live. If you're producing ongoing content alongside a migration, tools like FluxWriter can help keep your editorial calendar moving without dropping quality during the disruption.

← All posts