SEO Migration Without Traffic Loss: The Method

Table of contents

• What's really at stake in an SEO migration
• Freeze the baseline before go-live: GA4, Search Console and positions
• Build a 301 redirect plan that holds up
• Test on staging without polluting your rankings
• Launch day: the sequence to follow
• Monitor indexing and traffic over the next 90 days
• The mistakes that sink a migration (and how to avoid them)
• Steering your SEO migration with Lysible
• Frequently asked questions

What's really at stake in an SEO migration

An SEO migration is a transfer of value. You move the trust Google has granted your old URLs over to the new ones, without losing any along the way. The whole challenge sits in those two words, "without losing." Google doesn't automatically follow your changes. You have to tell it, address by address, where to find the new content.

The level of risk depends on the scale of the change. Going from HTTP to HTTPS on the same URLs barely shakes anything. Reworking the entire structure of a catalog of 800 product pages is a whole different level of danger. I always rank my projects on this scale before even talking technical. A business owner needs to know whether the stakes are high or not.

Which changes trigger an SEO migration?

Five scenarios call for real SEO preparation: changing the domain name, moving to HTTPS, modifying the URL structure, changing CMS, and a design overhaul with rewritten content. Each one changes either a page's address, its content, or both. As soon as an indexed URL changes or disappears, you're in a migration, even if the word appears nowhere on your quote.

These five scenarios don't carry equal exposure. Moving from HTTP to HTTPS stays low risk if the URLs remain identical: a site-wide 301 redirect and a valid certificate are often enough. Changing the domain moves up a notch, because you have to use the change of address tool in Search Console. Modifying the URL structure and changing CMS are already in the high zone: paths change, often massively, and the mapping has to be exhaustive. The most exposed scenario is the design overhaul combined with a content rewrite. It touches URLs, text and internal linking all at once. Three variables at the same time means three times the surface for error. To help you gauge it, the risk analysis for a redesign is covered in Moz's guide to site migrations, which ranks content rewriting as the most destabilizing factor.

Why traffic drops (and by how much) without preparation

Without a clean redirect plan, a migration commonly loses 20 to 40% of its organic traffic. That drop can become permanent if no one reacts. The cause is almost always the same: old URLs returning a 404 error, or badly coded redirects that don't pass on the authority they've built up. Google ends up deindexing whatever no longer responds.

The mechanism is simple to understand. Every well-ranked page took months to earn its spot. When its URL disappears without a redirect, that capital drops back to zero. Google Search Central notes that permanent redirects pass the ranking signal to the new address. Google's official documentation on site moves details this procedure from start to finish.

Freeze the baseline before go-live: GA4, Search Console and positions

The baseline is your "before" snapshot. The SEO baseline is the measured state of your traffic and positions before any change. Without it, you'll never be able to prove you lost traffic, how much, or on which pages. It's the first thing I freeze. This step takes half a day and it's non-negotiable.

I never start a migration project until these exports are archived in a dated folder. I've seen too many redesigns where the web manager compared the after to a vague sense of how traffic looked before. A vague feeling doesn't hold up in a meeting. A dated file does.

What data should you export before touching the site?

Five exports make up a solid baseline, all doable with free tools.

1. Organic traffic per page in GA4. Export organic sessions for the last 3 to 6 months, page by page, to spot your high-traffic pages to protect first.
2. Search Console performance. Download queries, clicks, impressions and average positions per URL over 16 months, the maximum depth available.
3. Full list of indexed URLs. Search Console's "Page indexing" report lists everything Google knows about your site.
4. Positions on your strategic keywords. Record the ranking of your top 20 to 50 queries before the switch.

The fifth export is the one most often forgotten: the backlink profile. An export of inbound links via Ahrefs or Search Console's links tool identifies the pages linked from outside. Those are the ones you can't leave as a 404, because they carry authority from other sites. Losing those links means losing value that no internal redirect makes up for if the external source doesn't update its link. The weight of inbound links in ranking also stands out in SEMrush's study on ranking factors, which places them among the signals most correlated with visibility.

To choose which pages to watch closely, lean on the website traffic statistics to track first. A handful of pages often drives most of the conversions.

How do you map all existing URLs?

A full site crawl with Screaming Frog lists every real URL, including those Google hasn't indexed yet. This technical inventory complements the indexed URLs seen on the Search Console side. By cross-referencing the two, you get the exhaustive list to handle in your redirect plan.

Screaming Frog stays free up to 500 URLs, which covers a good share of brochure sites and small stores. Beyond that, the paid version becomes necessary, but the investment is trivial next to the cost of a forgotten page. Always cross-reference this crawl with your Search Console export. An indexed URL missing from the crawl signals content Google knows but that your site no longer links to internally. That's exactly the kind of page that falls into a 404 after migration.

Build a 301 redirect plan that holds up

Every old indexed URL must point to its closest equivalent with a permanent 301 redirect. This is the heart of any migration, the part that decides whether you keep your traffic. A 301 tells Google: "this page has moved permanently, transfer its value to this new address."

URL mapping is the table that pairs each old URL with its destination. An "old URL" column, a "new URL" column, a "match type" column. This file becomes the contract for your migration. On a store with 300 products, it runs to 300 rows minimum, often more with categories, blog posts and content pages. It's tedious, and that's exactly why people rush it. Don't rush it.

How do you map old URLs to new ones?

Each row in your URL mapping falls into one of three decision categories. This simple rule keeps you from getting stuck on ambiguous cases.

The last row is worth pausing on. Google treats a redirect to the homepage that's unrelated to the original page as a "soft 404." It's a false redirect that passes no value. Google's guidance on redirects is clear on this point. A removed product page redirects to its category, not to the home.

Should you redirect to the homepage when there's no equivalent?

No, except as a last resort. Redirect to the closest page by topic: the parent category for a product, the nearest article for a blog post. The homepage only keeps the value if the old page was truly generic. Ahrefs' migration checklist recommends the same logic of semantic relevance.

Watch out for redirect chains too. If URL A redirects to B, and B to C, Google loses value at each hop and takes longer to consolidate. Always fix it with a direct 301: A points straight to C. It's a classic trap when several migrations have piled up on the same site over the years.

Test on staging without polluting your rankings

A staging site accessible to Google's robots is a time bomb. It creates a duplicate site, indexed in parallel with yours, a classic cause of duplicate content. I've seen redesigns sabotage their own launch. The test version ended up in Google's results before the official go-live.

The problem is sneaky. Your agency or developer builds the new site on a temporary address, something like staging.yoursite.com. If nothing blocks the robots, Google discovers it, crawls it and indexes it. You end up with two versions of the same content live, and Google no longer knows which one to favor.

How do you stop Google from indexing a staging site?

Two reliable methods, ideally combined. The most robust is HTTP password protection, authentication at the server level. Google simply can't reach the page. The second is to add a noindex tag on all staging pages, which asks Google not to display them.

A robots.txt file alone isn't enough. It blocks crawling, but Google can still index a URL discovered elsewhere, with the "blocked by robots.txt" note. web.dev's documentation on indexing confirms that password protection remains the safest barrier. The crucial point, often forgotten: remove this protection and the noindex on go-live day, otherwise you're blocking your real site.

How do you check that staging stays invisible?

Test access in private browsing, without being logged into your account. If the page shows up without asking for a password, the barrier isn't active. Then check how the robots.txt file renders and whether the noindex tag is actually present in the source code of each page type. An Ahrefs report on common technical errors shows that indexed test environments are among the most frequent crawl leaks. This ten-minute check avoids a surprise deindexing on launch day.

Launch day: the sequence to follow

Go-live plays out in a precise order, not haphazardly. A sequencing error opens a window where the old and new sites coexist without a redirect. Google then crawls both. Here's the time-stamped runbook I have people follow, minute by minute.

The goal is to minimize the time during which a URL can return a 404 or inconsistent content. The shorter that window, the less reason Google has to deindex. Schedule this switch during a low-traffic period, a Tuesday morning rather than a Friday evening before a weekend when no one is watching.

In what order do you activate redirects, sitemap and indexing?

The XML sitemap is the file that lists all your URLs for Google. Always test your redirects in real conditions after the switch, not just on staging. A production server can behave differently. Take your 20 most strategic pages, the ones that carry weight in your GA4 baseline, and check by hand that they redirect properly to the right destination with a 301 code. This thirty-minute manual check avoids unpleasant surprises.

Monitor indexing and traffic over the next 90 days

Post-migration tracking runs over 90 days, the period during which Google re-evaluates each URL. A well-executed migration recovers its traffic level in 4 to 12 weeks. Those who stop on go-live day miss the drifts. They're still easy to fix at D+15.

On an e-commerce redesign I followed closely, organic traffic had dropped about 20% at D+15. Going back through the mapping, we found roughly a hundred product pages all redirecting to the category page, when an exact equivalent existed. Mapping corrected, XML sitemap resubmitted, back to the initial level in eight weeks. Without a baseline to spot the gap, this loss would have gone unnoticed until the quarterly review.

How long before you recover your traffic?

Count on 4 to 12 weeks for a clean migration, more for a heavy redesign with content rewriting. Google has to recrawl all your URLs, follow the redirects and transfer the value. This timeline depends on your site's crawl frequency: a frequently updated site stabilizes faster. A temporary drop in the first two weeks is normal and shouldn't trigger a rushed correction. Figures from Internet Live Stats on the volume of pages crawled are a reminder of the scale at which Google re-evaluates the web, which explains these consolidation delays.

Which metrics should you watch after the migration?

Six metrics tell the story of your migration's health. If I had to watch just one as the absolute priority in the first two weeks, it would be the number of pages indexed in Search Console. A drop of more than 10% versus the baseline signals a mapping or redirect problem, even before GA4 reflects it in traffic.

You can track organic traffic in GA4 or in Matomo, the open source tool that hosts your data on your own servers. This cross-check between Search Console and your analytics tool takes about thirty minutes by hand each week, or runs continuously if you automate your metric tracking. To build your dashboard, lean on our guide to the website traffic statistics to steer and on the indexing diagnosis via Search Console.

The mistakes that sink a migration (and how to avoid them)

The number one cause of migration failure isn't technical: it's the lack of a measured baseline before go-live. The official docs and many providers put the technical audit at the center of the project, which is useful but not enough. Without a quantified starting point, you don't even know you've lost traffic, or where to look.

This paradox comes up on several projects. A technically flawless site, clean 301 redirects, XML sitemap submitted, but no "before" snapshot. The result: no way to tell whether the drop comes from the migration, seasonality or a Google update. The SEO baseline isn't a formality, it's your only way to steer. Fix this blind spot and you get a head start on most redesigns.

Why do 302 redirects lose traffic?

A 302 signals a temporary move to Google, so it keeps the old URL in memory and delays the transfer of value. Many CMSs and plugins create 302s by default, without anyone noticing. Check the code of each redirect. A 302 used where a 301 was needed slows down stabilization and can cost positions.

The other classic traps, in order of frequency in my audits: redirect chains, indexed staging, mapping to the homepage, canonical tags left pointing to the old domain, and an unupdated sitemap. Each one is fixable, but every day of delay costs traffic. If your migration is part of a broader project, our step-by-step e-commerce SEO audit method helps you spot these blockers before they take hold.

Steering your SEO migration with Lysible

An SEO migration is won or lost on data, not on luck. The baseline file, the row-by-row mapping, the weekly tracking of the six metrics: all of it exists for one reason. Knowing at all times where you stand relative to the "before." The real cost of this rigor isn't the data: it's free in GA4, Matomo and Search Console. It's the time to cross-reference it every week, especially during the critical 90 days. This ongoing cross-referencing work is centralized in Lysible, so that monitoring no longer rests on your Monday morning calendar.