Website Migration: How Not to Lose Rankings

Almost nobody sets out to do a website migration. What happens is that a redesign, a platform switch, or a rebrand quietly becomes one, and by the time anyone says the word, the new URL structure has already been agreed in a meeting nobody from search was invited to.

That is why migrations fail in such a predictable way. The design is fine. The site is faster. The rankings still drop, because a few hundred addresses that Google had spent years learning stopped resolving on launch night, and the redirect list was written from memory the following week.

This guide takes the decisions in the order a consultant would take them. What actually breaks, what Google’s own documentation says about redirects, what to settle before anyone touches a staging server, and how to read the first ninety days without panicking at week two.

PART 1 · DIAGNOSE

What Actually Breaks During a Website Migration

IN BRIEFFour things break in a migration: addresses, content, internal links, and measurement. Rankings sit on all four. A website design project that changes only the look of the pages carries almost no search risk; one that changes the addresses carries all of it.

It helps to separate the word “migration” into what is actually moving. Each type carries a different risk, and quotes rarely make the distinction.

• Addresses change. New URL structure, new domain, or http to https. This is the only change Google has to be told about, and the only one where a missing instruction costs rankings outright.
• Content changes. Pages get merged, trimmed, or rewritten in the redesign. A URL that survives but loses two-thirds of its text can still lose the ranking that text earned.
• Internal links change. New navigation, new menus, orphaned pages. Pages that were two clicks from the homepage end up five, and quietly drop.
• Measurement changes. New analytics install, new Search Console property, lost historical baseline, so nobody can prove what was lost or when it started.

Only the first is genuinely technical. The other three are decisions somebody made without connecting them to search, which is why migrations are a planning problem dressed as an engineering one.

BENCHMARK BRIEFING 1 OF 4

Which Migration Types Carry the Most Ranking Risk

IN BRIEFRisk rises with the number of variables changing at once. A hosting move with identical URLs is close to invisible to Google; a domain change plus a rebuild plus new content is four migrations wearing one deadline. Sequencing them separately is the cheapest safeguard available, as any honest pre-launch SEO audit will show.

The settling windows are ranges for a reason. Google’s own documentation notes that after a domain move it will likely keep showing the old addresses occasionally, even once the new ones are indexed. That behaviour fades on its own as people get used to the new name. It is not a fault to fix.

PART 2 · DIAGNOSE

What Google Actually Says About Redirects

IN BRIEFGoogle treats a permanent server-side redirect as its strongest signal that the new address should be the canonical one. Temporary redirects deliberately do the opposite, they tell Google to keep the old URL in results. Choosing the wrong one is the single most common technical error in a migration.

Most migration advice online is written as a checklist. The more useful framing is a decision: which signal do you want Google to receive, and for how long? Google’s redirects documentation is unambiguous on the mechanics.

A permanent redirect, HTTP 301 or 308, set at the server, is recommended whenever a page’s address changes for good. A temporary redirect, such as a 302 or 307, is for genuinely temporary situations, like a service page that is briefly unavailable. Use one where you meant the other and Google will keep indexing whichever URL you told it to prefer.

BENCHMARK BRIEFING 2 OF 4

How Google Treats Each Redirect Method

IN BRIEFNot all redirect methods are read the same way. Server-side codes are the most reliably interpreted; JavaScript redirects depend on the page rendering successfully, which it may not. If your platform limits you to plugins, know which method it is really using before launch night.

One practical note the table cannot carry: Google follows redirect chains, but every extra hop is a chance for something to fail. If an old URL passes through two intermediate addresses before landing, rewrite the rule so it lands in one move.

PART 3 · DESIGN

The Decisions to Settle Before Anyone Builds

IN BRIEFThree decisions determine most of the outcome: whether URLs change at all, whether existing content moves across intact, and who owns the redirect map. Settle them before a website designer starts building, because reversing a URL structure after launch is a second migration.

The first question is the one most often skipped. Do the URLs need to change? A tidier structure is a real benefit, but it is a benefit you pay for, and the payment is a period of instability. If nothing about the current addresses is broken, keeping them is a legitimate strategic choice.

The third decision is ownership. The redirect map is not a developer task or a marketing task, it is a joint one, and it needs a named owner who signs it off before launch. Unowned maps get written the day after go-live, from a crawl of a site that no longer exists.

BENCHMARK BRIEFING 3 OF 4

Where the Work in a Safe Migration Goes

IN BRIEFModelled as shares of total migration effort, mapping and testing dominate, not the launch itself. Owners who budget for a launch and not for the fortnight either side are the ones who discover problems from a customer’s phone call rather than from a performance check.

Read the bottom row again. Launch night is the smallest slice of the work and the only slice most quotes describe in detail, which tells you where the unpriced risk usually sits.

PART 4 · DEPLOY

Launch Day: The Order of Operations

IN BRIEFSequence matters more than speed. Redirects live before the announcement, the staging site’s crawl block removed at go-live, sitemaps resubmitted the same day, and the Change of Address request filed if the domain changed. Each step out of order costs days of confused crawling.

How to launch a website migration without losing rankings

These steps assume the redirect map is signed off and the new site has been tested on staging. Work through them in order on launch day.

1. Remove the staging crawl block. The noindex tag or robots.txt disallow that protected the staging site becomes the single most damaging leftover in a migration. Check it first, not last.
2. Publish the redirects before you announce anything. Every old URL should resolve to its new match in one hop. Spot-check the top twenty traffic pages by hand.
3. Submit the new sitemap in Search Console. Keep the old sitemap available briefly as well, so Google is prompted to recrawl the old addresses and discover the redirects faster.
4. File the Change of Address request if the domain changed. Google’s tool forwards signals from old to new for 180 days and asks it to prefer the new site when choosing canonical pages.
5. Verify both properties in Search Console. You need the old and new domains verified to watch the handover from both sides.
6. Re-check analytics and conversion tracking. Forms, calls, and enquiry events break silently during migrations, and a lost baseline makes every later argument unwinnable.

BENCHMARK BRIEFING 4 OF 4

What to Watch in the First 90 Days

IN BRIEFDifferent signals matter at different points. Crawl errors matter in week one, indexing in weeks two to four, rankings from week four onward. Judging a migration by rankings on day three is the most common reason good migrations get “fixed” into bad ones.

PART 5 · DRIVE

How to Tell If the Migration Actually Worked

IN BRIEFJudge the migration on enquiries against a pre-launch baseline, not on total sessions. And keep the redirects running long after everyone has stopped watching, retiring them is a quiet second migration, one that ongoing website maintenance should be responsible for.

Success has a specific shape. Impressions recover before rankings, rankings recover before traffic, and traffic recovers before enquiries, so a migration that looks flat at week six may still be working through that sequence normally.

Two habits separate the businesses that come out ahead. The first is keeping a written baseline: organic sessions, top twenty landing pages, and enquiry counts for the three months before launch. The second is leaving redirects in place indefinitely. Google’s Change of Address tool forwards signals for 180 days, but old links on other people’s websites do not expire on that schedule.

FAQ

Frequently Asked Questions

1. How long does it take to recover rankings after a website migration?

Most well-executed migrations settle within four to twelve weeks. It depends on how much changed at once, a protocol change or a redesign on the same URLs is usually quick, while a domain change plus a rebuild can take three to six months. The recovery order is consistent: crawling first, then indexing, then rankings, then enquiries.

2. Do 301 redirects lose SEO value?

No. Google recommends permanent server-side redirects whenever a page’s address changes for good, precisely because they pass the signal cleanly. What does cost you is the surrounding execution, chains of several hops, redirects pointing at the homepage instead of the matching page, or old URLs with no redirect at all.

3. Should I keep the old domain after migrating?

Yes, keep it registered and keep the redirects live. Google’s Change of Address tool forwards signals for 180 days, but backlinks, printed materials, and saved bookmarks on the old domain outlive that window by years. Dropping the domain later undoes part of what the migration protected.

4. Can I redesign my website without changing any URLs?

Usually yes, and it is often the wiser choice. Templates, layout, and imagery can all change while the addresses stay identical, which removes the largest source of migration risk. The trade-off is inheriting an existing URL structure, worth accepting unless that structure is genuinely holding the site back.

5. What is the most common website migration mistake?

Leaving the staging site’s crawl block in place after go-live. A noindex tag or robots.txt disallow that protected the site during the build will quietly remove the new pages from search, and it can run for weeks before anyone connects the drop to it. Check it within an hour of launching.