SEO Migration Strategy for Re-platforming Projects

A re-platforming project is the single highest-leverage way to lose organic traffic in a six-month window. Done well, it produces a new stack with better Core Web Vitals, cleaner indexation, and the same or better Search visibility. Done poorly, it drops 30 to 60 percent of organic sessions in the first month and takes another two quarters to recover.

Updated for April 2026, this guide walks through the SEO migration strategy that actually keeps traffic stable through a re-platforming project. It covers the pre-migration audit, URL mapping, redirect logic, sitemap and rendering handoff, and the 30/60/90-day validation window. The frame is the same as any technical SEO audit and the related technical SEO audit checklist: a sequence of explicit decisions, not a vibe-based "let us see what happens."

When migrations destroy SEO and when they don't

Three patterns explain almost every traffic loss we have seen on re-platforming projects:

• URL changes shipped without a complete redirect map. Old URL gets a 404 instead of a 301. Backlink equity disappears. Indexation collapses on those routes.
• Rendering parity broken on the new stack. The new framework ships partial HTML for crawlers that the old stack delivered fully. Suddenly Google cannot see the content that used to rank.
• Sitemap and canonical drift. The old sitemap still references old URLs. The new canonical points to a staging domain. The two systems disagree, and the crawler picks the wrong winner.

Migrations that go cleanly avoid all three. Migrations that fail tend to fail on at least two simultaneously, which makes diagnosis harder later because the symptoms compound.

The right way to think about a migration is not as a "launch event" but as a sequence of three loosely coupled projects: the pre-migration audit, the cutover, and the post-launch validation. Each has its own deliverables and failure modes. Google's official site move with URL changes guide is the right starting point for the cutover-side checklist and lines up with the sequencing we use below.

The pre-migration audit, capture before you change

Before any code or URL changes ship, capture the state of the existing site. This is the single highest-leverage step in a migration, and it is the one teams skip most often because it feels like overhead.

What to capture:

• Full URL inventory, every indexable URL, with its current status code, canonical, last-modified, and indexation state in Search Console
• Top-traffic pages, the URLs that drive 80 percent of organic sessions, with their current rankings on the keywords that matter
• Backlink profile, the URLs receiving external links, prioritized by referring domain authority
• Template inventory, which URL patterns map to which template (homepage, listing, detail, article, category, tag)
• Internal linking map, which pages link to which, including site-wide nav and contextual links inside content
• Structured data emitted per template, JSON-LD types currently appearing in the rendered HTML
• Sitemap snapshot, the full XML at the moment of capture, including any sitemap-index files

Without this baseline, "did the migration hurt SEO?" is impossible to answer with evidence. With it, you can attribute every drop to a specific change. The capture takes 1 to 3 days for most sites and saves weeks of guesswork during recovery.

URL mapping, 1:1, 1:many, many:1, and breaking

URL mapping is where most migrations earn or lose their organic traffic. The categories:

• 1:1, every old URL maps cleanly to one new URL. The simplest case. Implement as 301 redirects.
• 1:many, the old URL becomes multiple new URLs (often when a category page is split). Pick the most representative target and 301 there. Optionally add internal links from the new pages back to the parent.
• many:1, multiple old URLs collapse into one new URL (consolidation). 301 every old URL to the consolidated target. Watch for cannibalization on the new URL.
• Breaking, the URL has no equivalent on the new site (deleted feature, retired blog post). Decide explicitly: 410 (gone) for low-value content, 301 to the closest parent for content with backlinks, and document the choice.

The right deliverable is a CSV with columns: old_url, new_url, status_code (301, 410, etc.), notes. A representative slice of that CSV looks like this:

That CSV becomes the source of truth for the redirect map, the QA team's spreadsheet, and the post-launch validation. We typically generate it from the URL inventory plus a manual mapping pass for non-trivial categories. For a 5,000-URL site, the mapping work is 1 to 2 days; for a 100,000-URL site with parameterized routes, it is a 1 to 2 week project on its own.

The status codes themselves matter as much as the mapping. The IANA HTTP Status Code Registry is the canonical reference for the full set; for migrations the only ones that should appear in the CSV are 301, 410, and (rarely) 308.

Why 301 and not 302

A 301 signals a permanent move. Google passes the link equity. A 302 signals a temporary move, which means Google may keep the old URL indexed and pass equity slowly or not at all. For a re-platforming migration, 301 is almost always correct. The MDN reference on HTTP status codes and Google's HTTP errors documentation cover the SEO-side semantics. We also walk through the full status-code SEO model in HTTP status codes for SEO and crawlers.

Redirect chains are a tax

If /old redirects to /intermediate and then to /new, you have a redirect chain. Crawlers tolerate one hop without much penalty, two hops with friction, three or more with serious indexation delays. The fix is to flatten chains in the redirect map. Every old URL should redirect once, directly to its final target.

The cheapest way to audit chain depth on a list of URLs is curl itself, no special tooling required:

curl -sI -L -o /dev/null -w "%{http_code} %{redirect_url}\n" https://example.com/old-url

-L follows redirects, -w prints the final status and the last Location header, and -o /dev/null discards the body. Wrap that in a shell loop over the old_url column of the mapping CSV and any URL that takes more than one hop falls out of the report. Anything with two or more hops is a candidate for flattening before launch.

Sitemap and robots.txt during the migration

Sitemaps are the most underused tool in a migration. Used right, they accelerate Google's discovery of the new URLs by weeks. Used wrong, they confuse the crawler and slow the recovery.

The pattern that works:

1. Day -7 (pre-launch): deploy the new sitemap pointing at the new URLs to staging. Validate every URL responds with 200.
2. Day 0 (launch): replace the production sitemap with the new one. Submit to Search Console. Old URLs already redirect to new ones at this point.
3. Day +7: keep the old URLs in a separate "archived" sitemap referenced from the sitemap index. This signals to Google that the redirects are intentional and helps recrawling.
4. Day +30: drop the archived sitemap once Search Console shows the redirects fully processed.

Robots.txt should not change at launch unless the migration deliberately blocks new sections. We have seen migrations break because someone "tidied up" robots.txt during the cutover and accidentally blocked the new template. Don't change two things at once. The full sitemap architecture model lives in XML sitemap guide for technical SEO.

Rendering parity in the new stack

If the new stack uses a different rendering model, moving from server-rendered to React Server Components, from PHP to Next.js, from a static generator to a hybrid framework, verify rendering parity before launch. This is the failure mode that sinks JavaScript-heavy migrations.

The check we run on every migration:

1. Fetch the production HTML for the top 50 URLs with curl -A "Googlebot" (or equivalent).
2. Fetch the staging HTML for the equivalent URLs.
3. Diff the two. Look for missing content, missing canonical, missing structured data, missing internal links.
4. For URLs with significant diffs, decide whether the new behavior is acceptable. Sometimes it is, the new template is intentionally different. Sometimes it is a regression that has to ship with the launch.

This catches the silent migrations that ship "successfully" but with degraded crawler-facing HTML. We cover the broader mechanics in SSR cloaking risks and semantic parity and the operational checklist in rendering QA checklist for SEO releases.

When prerendering helps the migration

If the new stack is JavaScript-heavy and rendering parity is a known risk, prerendering can be the safety net. The migration still needs the URL mapping and redirect logic. The prerendering layer ensures crawlers receive complete HTML for the routes that matter most, even when the framework's defaults haven't been fully optimized at launch.

This is part of the broader argument for prerendering for technical SEO on JS-heavy templates, it is also the cheapest way to de-risk a migration where rendering reliability is uncertain.

Search Console handoff

Search Console settings need a deliberate handoff:

• Domain change, if the migration changes the apex domain, use the Change of Address tool documentation in Search Console. Required for cross-domain migrations.
• Property setup, if the new site is on a separate Search Console property, verify it before launch and start collecting data immediately.
• URL inspection, sample 20 to 30 critical URLs at launch and request indexing. Speeds up the rediscovery for high-value pages.
• Sitemap submission, submit the new sitemap on day 0 and the archived sitemap by day 1.

For migrations that change rendering, also check that the new structured data validates in the Rich Results Test. Schema regressions during migration are common and usually invisible until rich results disappear from the SERP.

Post-migration validation, 30, 60, 90 days

The launch is not the end. The validation window is 90 days, and the work is a structured review at each milestone.

Day +1 to +7

• All redirects respond with 301, no 404s for previously indexed URLs
• Sitemap submitted, accepted, no errors
• Search Console crawl stats show no spike in errors
• The top 20 traffic URLs return correct canonical, title, structured data
• Rendering parity check passes on top 50 URLs

Day +7 to +30

• Indexation in Search Console matches expectations (small dip is normal, recovery is expected within 2 to 3 weeks)
• Organic sessions track within 10 percent of pre-launch baseline
• No spike in 404s in server logs
• New URLs appearing in search results for the keywords the old URLs ranked for

Day +30 to +90

• Organic sessions return to or exceed baseline
• Backlinks updated where possible (outreach to top referring sites)
• Old URLs effectively dropped from Google's index
• Long-tail traffic recovers (this is the slowest signal, long-tail keywords often take 60 to 90 days to fully transition)

When traffic drops and stays down

If organic sessions are still down 20 percent at day +30, treat it as an incident. Diagnose with:

• Server logs: are crawlers hitting the old URLs and seeing redirects?
• Search Console: which queries dropped? Are they for templates that changed rendering?
• Rendering parity: did the new stack ship a regression that wasn't caught at launch?

The diagnosis playbook is the same as any post-launch SEO incident, covered in SEO incident response playbook and indexation recovery after site migrations.

Common engineering mistakes

Patterns we see when migrations go wrong:

• Shipping the redirect map after launch instead of before
• Letting old URLs return 404 because "Google will figure it out" (it won't, fast enough)
• Forgetting to update internal links from old URL patterns to new ones (creates cycles of internal redirects)
• Changing canonical strategy mid-migration (don't move two systems at once)
• Skipping rendering parity checks on the assumption that the framework "handles SEO"
• Treating Search Console verification as optional on the new property
• Removing the old sitemap immediately at launch instead of keeping it as an archived sitemap for 30 days

Migrations are operations problems, not just engineering problems. The team that runs them like a sequence of explicit checks survives. The team that runs them like a feature ship loses traffic and spends a quarter recovering.

Conclusion

A clean SEO migration depends on three things, a complete URL map with explicit redirect logic, rendering parity verified before launch, and a structured validation window after. Skip any of the three and the recovery cost compounds.

Treat the migration as a system with a baseline, a cutover, and a recovery curve. Capture the baseline before you start. Stage the cutover with explicit deliverables. Watch the recovery for 90 days. Then the next migration the team runs starts with a working playbook instead of a blank page.

Frequently Asked Questions