Website migration SEO: how to move or rebuild your site without losing your Google rankings

Website migration SEO: the short answer

A new website keeps its Google rankings when every old page address that matters redirects to the closest matching page on the new site. The redirect must be permanent (a 301), so that people and Google both follow it. Google ranks addresses and the content on them. Change an address without a redirect, and the rankings and links attached to it stop counting.

This guide is for founders and operations leads at UK and EU companies about to replace or move their website. Website migration SEO sounds like a specialist's job. Most of it is a list, a spreadsheet and a test, and you can check all three yourself.

The surprise is where launches fail. A new site can pass every review and still lose its rankings. The review looks at the new pages, while Google goes looking for the old ones. We build websites for companies across Europe, and this is the part of a rebuild we'd ask you to check us on.

Why a new website loses its rankings

Google ranks individual pages, and it knows each page by its address, or URL. Say your cleaning company's services page ranks for "office cleaning Leeds". It ranks because of the words on it and the links other sites point at that address.

Rebuild the site so the page lives somewhere new, and Google finds a missing page where the ranking used to be. Without a redirect, the new page starts from nothing.

Tim Berners-Lee made the point in 1998 in a note called Cool URIs don't change. Addresses rarely break on their own. People break them, usually while reorganising a site.

Most rankings lost in a rebuild go in one of four ways. Google's guide to site moves warns against the first three.

1. Old addresses with no redirect, so visitors and Google get a "page not found" error.
2. Many old addresses redirected to the homepage. Google says this confuses people and may be treated as a soft 404, its term for an address that answers but doesn't deliver the page asked for.
3. A noindex tag or a robots.txt block left over from the test site, which keeps the live site out of Google.
4. Content cut in the redesign, so the page at the new address no longer answers what the old one ranked for.

Four kinds of move, from low risk to high

The risk depends on how much changes at once. A new look on the same addresses is a small job for search. A new domain changes every address you have.

A hosting move has its own shorter guide from Google. Before any move, the domain, hosting and Search Console should be in your company's name. Our guide to whether you own your website walks through the checks.

A new platform usually means new addresses, because each system writes them its own way. An old page at /services.php?id=7 might become /services/office-cleaning/ on the new site.

A new domain carries risk that redirects don't remove. WooCommerce moved its website from woocommerce.com to woo.com in October 2023, and in April 2024 it moved back. Its announcement said the new domain had made WooCommerce harder to find in Google searches, and that Google's March update made it worse.

If you don't need a new domain, keep the one you have. If you do, change it in a separate release from the redesign. Then, if rankings move, you know which change moved them.

Step 1: list every old address before anything changes

The redirect plan starts with a list of every address the old site has. Make it while the old site is still live, because several of the sources disappear when it goes.

Google's guide points to sitemaps, server logs and analytics. In practice, pull from all of these:

• The old site's sitemap, usually at /sitemap.xml, plus a full export from its content system.
• Search Console's Performance report, with the Pages tab selected. It shows which addresses people reach from Google. Export it, because it's also your "before" picture.
• Search Console's Links report. Its top linked pages table shows which of your pages other sites link to. Every one of those keeps its address or gets a redirect, whatever its traffic.
• Your analytics, sorted by landing page, including which pages start the visits that end in an enquiry.
• Files other sites link to, such as PDFs and images. Google's guide counts these as part of a move.
• Addresses in print: brochures, van livery, QR codes on signs. No crawler will find those for you.

Then mark the pages that matter most: the ones that bring search visits, links or enquiries. A person checks those one by one in step 3. If you're writing a brief for the rebuild, put the list in it. Our website brief template has a section on the current site where it belongs.

Step 2: give every old address a decision

The redirect map is a spreadsheet with two columns: the old address, and what happens to it. Every row gets one of four decisions.

Keeping the address is the best redirect there is. If your old addresses are readable, ask for the new site to reuse them.

Use permanent redirects, set on the server. Google reads a 301 or 308 as a sign that the new address should replace the old one in its results, a signal a temporary 302 doesn't send. A JavaScript redirect is a last resort, because Google may not see it.

Send each old address straight to its final page. Google's guide advises against chains, where one redirect leads to another.

Don't point everything at the homepage. Nobody sees an error, so the launch looks finished, and Google may still treat those addresses as soft 404s.

Retiring a page is fine. For Google, a 404 and a 410 mean the same thing: the page doesn't exist. The list is there so that pages are retired on purpose, not by accident.

Keep the redirects for at least a year, as Google's guide advises. After a domain change, keep paying for the old domain for at least a year too. Google recommends it so nobody else can buy the name and use it.

Step 3: test the old list, not the new design

Most launch reviews look at the new site: the pages, the copy, the form. That review can pass while every old address fails, because nobody types old addresses into a browser. A homepage redirect or a friendly error page looks fine on screen, too. The only proof is to request every address on the old list and read what comes back.

The UK government did this at scale in 2012, when it moved Directgov and Business Link into GOV.UK. Its team gathered about 8,000 Directgov and 40,000 Business Link addresses from traffic logs, records and crawling. It then wrote a test that checked every address returned either a 301 redirect to a working page or a 410.

By December that year the setup covered more than 83,000 addresses, so people following old bookmarks, or links from old printed publications, still reached the right page.

You don't need a government team. Google's guide suggests its URL Inspection tool for single addresses and a script for many. A crawler such as Screaming Frog can check a pasted list. The test passes when:

1. Every old address returns a 301 or 308 to a working page, or a deliberate 404 or 410.
2. No address lands on the homepage unless the map says it should.
3. No redirect leads to another redirect.
4. The pages marked in step 1 keep their content, title and main heading, checked by a person.

Put one address on the list that you know should fail. If the test doesn't flag it, the test isn't checking anything. Then run it twice: on the test site before launch, and on the live site on launch day. Server settings often differ between the two, and Google only sees the live one.

While the new site sits on a test server, keep it out of Google with a password rather than a noindex tag. Google recommends a password for anything that shouldn't be public. A password left on at launch gets noticed within minutes. A forgotten noindex tag goes unnoticed until your traffic does.

After launch: what to check, and what's normal

Launch day is the start of the checking, not the end. This is what to look at, and when.

For a new domain, use Google's Change of Address tool on launch day. It's only for moves between domains or subdomains, and you must own both the old and new sites in the same Search Console account.

A wobble is normal. A page that brought steady visits and now brings none isn't. When you find one, check its old address first, because a missing or misdirected redirect is the likeliest cause. The sooner the fix goes in, the sooner Google can credit the new page.

Measure enquiries as well as traffic. A site that keeps every ranking but breaks its quote form has still failed. On the sites we build, analytics is wired to a question you actually have. After a rebuild, that question is simple: are the same pages still bringing in the same enquiries?

When you don't need a full migration plan

Scale the work to what changes.

• A hosting move that keeps every address is a small job. Follow Google's shorter guide, copy the DNS records, and check the site on launch day. Your current developer can usually do it.
• A small site with little search traffic needs the list and the redirects, but not a crawl. If the site has twelve pages, the redirect map has twelve rows.
• A new platform isn't a reason to change addresses. Most platforms let you keep them, and every changed address is a redirect someone has to maintain.
• A redesign isn't a reason to change the domain. If you need both, do them in separate releases.

You may not need a rebuild at all. If the complaint is speed, a dated look or a form that goes nowhere, fixing the current site can be the better answer. Our guide to signs your website needs a redesign, and signs it doesn't helps you decide.

When we're asked to take over a site, we start with an audit and a written recommendation. If a rebuild isn't worth it, we'll say so.

What to ask your agency before the rebuild starts

Get these in writing before work starts, from any agency, including us:

1. A list of every old address, built from the sitemap, Search Console, analytics and the Links report.
2. A redirect map, as a file you keep, with a decision on every row.
3. The test site behind a password, and a launch checklist that removes any noindex tag.
4. The old-list test run before launch and again on launch day, with the results sent to you.
5. Search Console and analytics in your company's name, with the agency added as a user.
6. Named checks in the weeks after launch, and who fixes a missing redirect.
7. Redirects kept for at least a year, with a note of where they're set, so the next developer can find them.

A quote for a rebuild should show this work. Our guide to what sets the price of a website in the UK lists redirects among the things a proper quote spells out.

On the sites we build, the redirect map is a line in the written scope, and it lives in your code repository. We run the old list against the shared staging environment before launch, and against the live site on launch day. The domain, hosting and repository sit in your accounts, so the redirects stay yours when the work ends.

This week, open Search Console, go to Performance, select Pages and export the list. If you rebuild, that file is the first thing your agency needs, and it's the "before" picture you'll check every page against in the weeks after launch. If nobody at your company can open Search Console, fix that first.

Questions

Do images and PDFs need redirects too?

The ones people link to or find in search do. Google's guide to site moves includes images, videos and other embedded files in the plan. A brochure or spec sheet that other sites link to is a page like any other, so give it a row in the redirect map.

We're leaving Wix or Squarespace. Who sets up the redirects?

Whoever runs the new site. Redirects live on the server your domain points to, so once the domain moves to the new host, the old platform plays no part. What you need from the old platform is the list of addresses. Save its sitemap and export your Search Console data before you cancel the plan.

We've already launched and our traffic dropped. Is it too late?

No. Open Search Console's Page indexing report and look at the pages listed as \"Not found (404)\". Those are old addresses with no redirect. Add redirects for the ones that had visits or links, using the Performance report's older date ranges to see which pages used to bring traffic. Google picks up new redirects as it recrawls, so the sooner they go in, the sooner the old addresses count again.

How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.