SEO Migration: How to Move a Site Without Losing Traffic

A migration is the riskiest project most websites ever undertake. New platform, cleaner URLs, better design. Everything sounds like an upgrade until the redirects break and organic traffic falls off a cliff three weeks after launch, when nobody can remember what changed.

The uncomfortable part is that the damage is usually self-inflicted. Migration disasters are rarely Google behaving unpredictably. They come from missed steps, compressed timelines, and nobody owning the SEO side of the project.

Here is how to run an SEO migration that keeps the traffic you already earned.

What Counts as an SEO Migration

A migration is any significant change affecting how search engines crawl, index, or interpret your site.

That includes more scenarios than most teams assume:

• Moving to a new domain
• Replatforming to a different CMS
• Restructuring URLs or site hierarchy
• HTTP to HTTPS
• A full redesign with new templates
• Changing hosting providers
• Adding or restructuring international or multilingual versions

The common thread is that ranking signals attached to old URLs need to survive the move. Content, authority, internal links, and backlinks all have to arrive on the other side intact.

Why Migrations Fail

The single biggest cause of traffic loss is broken or missing redirects. Everything else is a distant second.

Other recurring culprits: changed or thinned content, broken internal links, canonical tags left pointing at the staging environment, blocked crawling, and weaker page templates that quietly lose the elements that were ranking.

Two structural problems make all of this worse.

Timelines get compressed. SEO gets the last two weeks of a six-month project.

Nobody owns it. The developer assumes the marketer handled redirects. The marketer assumes the agency did. Nobody crawled the staging site.

There is a timing trap as well. Drops rarely appear at launch. Google typically takes around three to four weeks to reprocess crawled changes at scale, so errors introduced during the move surface in Search Console well after launch, when tracing them is harder.

Phase One: Baseline Everything Before You Touch Anything

You cannot measure recovery without a reference point. This phase is where most of the outcome gets decided.

Export and store, before any development work begins:

• 12 months of Search Console data. Clicks, impressions, and average position by page and by query.
• A full crawl of the current site. Screaming Frog or equivalent, saved as a file, not a screenshot.
• Ranking positions for your priority keyword set.
• Backlink profile, so you can identify which pages carry earned authority.
• Analytics data, including organic sessions, conversions, and revenue by landing page.
• Core Web Vitals benchmarks, because a new CMS or host can quietly regress all three.
• Structured data inventory, since schema is routinely lost during platform swaps.

Then build a priority URL list. Rank every URL by traffic, conversions, and backlinks. That list determines where redirect mapping effort goes when time runs short, which it will.

Phase Two: Build the Redirect Map

One-to-one 301 mapping for priority URLs is the single most important deliverable in the entire project.

Rules that matter:

• Use 301, not 302, for every permanent change. A mix of the two is a legacy habit, not a strategy.
• Map to the closest equivalent page. Never blanket-redirect to the homepage. That throws away topical relevance entirely.
• Avoid redirect chains. Old URL to new URL, one hop. Chains waste crawl budget and dilute signal.
• Redirect at the server level rather than through client-side JavaScript.
• Handle every old URL, including ones you plan to retire. A 404 on a page with backlinks is lost equity.
• Keep redirects live for at least a year. In most cases, permanently. Old backlinks, bookmarks, and documents keep sending people to previous URLs indefinitely.

Test the map before launch by running the old URL list through a redirect checker pointed at staging. Every entry should return a single 301 to a live 200 page.

Phase Three: Audit the Staging Site

Staging is your last cheap opportunity to catch problems.

Block staging from indexing while you work, then verify it is unblocked at launch. That reversal is one of the most common and most damaging launch-day failures.

Check on staging:

• Meta titles and descriptions carried across, not regenerated as defaults
• Canonical tags self-referencing, not pointing at staging domains
• Heading structure preserved on priority templates
• Internal links updated to new URLs rather than routed through redirects
• Structured data rebuilt and validated per template
• Image alt text and file names retained
• XML sitemap generating correctly with only canonical, indexable URLs
• Core Web Vitals measured against your baseline
• Content parity confirmed on high-traffic pages

Content parity deserves particular attention. Redesigns frequently trim copy for aesthetic reasons, and the trimmed sections are sometimes exactly what was ranking.

Phase Four: Launch Day Sequence

Order matters more than speed.

1. Deploy with redirects live from the first minute, not added later in the day.
2. Remove staging noindex directives and confirm robots.txt allows crawling.
3. Verify the new property in Search Console and submit the new sitemap.
4. If moving domains, use the Change of Address tool.
5. Crawl the live site immediately and compare against the pre-migration baseline.
6. Spot-check your twenty highest-value URLs by hand.
7. Update PPC destination URLs, email templates, and social profile links.
8. Confirm analytics and conversion tracking fire correctly on new templates.

That last item is routinely forgotten and produces a fake traffic collapse that sends everyone hunting for an SEO problem that does not exist.

Schedule launch for a low-traffic period, and never immediately before a holiday, a peak season, or a week when the technical lead is away.

Phase Five: The 90-Day Monitoring Protocol

Rankings and traffic do not recover automatically. Monitoring is what turns a manageable dip into a non-event.

Useful reference points from practitioners: a temporary dip of roughly 10–15% is normal in the weeks after launch. A sustained 30% drop is not, and needs investigation rather than patience.

If performance is still declining eight to twelve weeks after launch with no sign of recovery, that points to an unresolved technical issue rather than a normal recovery curve. Stop waiting and start crawling.

Never Change Two Variables at Once

This is the discipline that separates controlled migrations from guesswork.

Bundling a domain move with a URL restructure with a redesign with a replatform means that when traffic drops, you cannot isolate the cause. You are left changing things at random and hoping.

Where the business allows, sequence changes. Move the platform first, stabilise, then restructure URLs. Above all, never combine URL changes with a domain move.

Business pressure usually pushes the other way, because doing everything at once looks efficient. It is efficient right up until something breaks.

What Migrations Break That People Forget

• Structured data. Platform swaps routinely drop schema entirely. Inventory it beforehand and rebuild it deliberately.
• AI visibility. Citations in AI Overviews and chat-based answers depend on the same clean redirects and structured data as rankings, and can be lost the same way.
• Internal linking. New templates often reduce contextual links, quietly changing which pages receive authority.
• Pagination and faceted URLs. Frequently regenerated with different parameters, creating a new crawl waste problem on day one.
• Hreflang. Almost always breaks on international migrations and almost never gets tested.
• Image URLs. Image search traffic disappears if these change without redirects.

Recovery Timelines and Realistic Expectations

Published figures vary, partly because site size and migration scope vary enormously.

Traffic often stabilises within four to eight weeks for smaller, well-executed moves. Fuller recovery on medium-sized sites is more commonly cited at three to six months, and longer for large or complex properties.

The number worth showing stakeholders before you start: one analysis found that 17% of sites never returned to pre-migration traffic levels even after 1,000 days. Poorly executed migrations are commonly reported to lose 30–50% of organic traffic, with recovery taking anywhere from three to twelve months.

That is the case for spending properly on the pre-launch phase. The expensive part of a migration is never the planning.

Mistakes That Cost Traffic

• Starting development before exporting baseline data.
• Blanket-redirecting old URLs to the homepage.
• Leaving staging canonicals or noindex tags live after launch.
• Adding redirects the day after launch instead of at deployment.
• Removing redirects after a few months.
• Combining a domain move with a URL restructure.
• Assuming a flat first fortnight means everything worked, when Google has not finished reprocessing.
• Launching before a peak trading period.

The One Thing to Get Right

If your timeline collapses and you can only protect one thing, protect the redirect map for your top-traffic and top-backlink URLs.

Everything else can be fixed afterwards. Lost link equity from unredirected URLs is the one failure that is genuinely difficult to reverse, and it is the reason most migration horror stories exist.

Export your baseline today, before anyone touches a line of code. That single hour of work is what makes every later decision measurable.

FAQs