Rebrand without losing your search traffic: the migration checklist

Almost everything written about rebranding and SEO is scaremongering. Changing your logo does not affect your rankings. Changing your colours does not affect your rankings. Rewriting your homepage copy, if the page keeps its address, affects them only to the degree that the new copy is better or worse than the old.

One thing genuinely puts your search traffic at risk, and it is the one businesses treat as an afterthought: changing the addresses of your pages. That happens when you move to a new domain, and it also happens when a new website quietly reorganises /services/web-design into /what-we-do/digital/web.

This is the checklist for doing that without throwing away what you have built. It assumes you have already decided the rebrand is worth doing, which is a separate question.

Before anything is switched off

The single most common failure is starting the migration after the old site is gone. Once it is down you cannot reconstruct what it had, and you will be guessing.

Crawl the old site and keep the output. Every URL, its title, its status code. This is the document the entire migration is built on, and it takes an afternoon.

Export your Search Console data. Queries, pages, clicks and impressions for the last sixteen months, which is all Google keeps. After the move this is the only way to answer “were we ranking for that before?” — and you will want to answer it.

List your inbound links. You are about to ask the significant ones to update, and you cannot ask if you do not know who they are.

Record what your analytics currently say. Sessions, conversions and their sources for the last twelve months, so the dip can be measured against something real rather than against a memory.

The redirect map

This is the part that matters, and it is tedious rather than difficult.

Every URL on the old site gets a line: old address, new address, and a 301 redirect, which tells search engines the move is permanent. A 302 says temporary and does not transfer value the same way, which is why a 302 left in place by mistake is a quietly expensive error.

Three rules that decide whether this works:

One page to its equivalent page. The old pricing page goes to the new pricing page. Not to the homepage. If genuinely no equivalent exists, the nearest relevant page is still far better than the homepage, which carries no topical relationship at all.

No chains. Old page to intermediate page to final page loses value at every hop and slows crawling. Every old URL should reach its destination in one redirect, even if that means rewriting a rule you wrote last week.

Nothing left out. Including the pages you forgot about: old blog posts, PDFs, landing pages from campaigns that ended years ago, the image URLs. Anything that anyone ever linked to is carrying value you are about to either move or discard.

Your own links come next

Redirects exist for other people’s links. They should not be doing the work for yours.

Update every internal link in your own content to point at the new URL directly. Menu items, in-body links, footer links, buttons, canonical tags, the sitemap, and the links inside old blog posts, which is where they are always missed.

A site where internal navigation runs through redirects works perfectly well for visitors and looks, to a crawler, like a site that has not finished moving.

Telling search engines

Submit a change of address in Search Console if the domain changed. It is a specific tool for exactly this, and it meaningfully shortens the reassociation period.

Keep both properties. Verify the new domain, do not remove the old one. You need both to watch the handover happen, and you will want the old one’s history.

Submit the new sitemap and leave the old one accessible for a while. It helps search engines discover the redirects faster.

Update the canonical tags. A new page that still points its canonical at the old URL is telling Google the old one is the real version, which is the opposite of what you just spent a month arranging.

Everything that is not the website

A rebrand is a name and address change, and your name appears in more places than your website.

Google Business Profile, first, because it feeds the map results that local customers actually use. Then every directory, listing and portal carrying your name, address and phone number. Inconsistency across those is a genuine local ranking problem, not a tidiness one.

Then the practical list: email and DNS planned as their own exercise with their own owner, social profiles and their handles, invoices and contracts, signage, vehicles, packaging, stationery, and the email signatures of everyone in the company.

After launch

Watch the status codes, not the traffic, in week one. Traffic will be strange and will tell you nothing. A redirect returning a 404 tells you something immediately and is fixable in minutes.

Check the index coverage weekly for a month. Pages dropping out tells you where the map is wrong.

Expect the dip and do not panic into action. A few weeks of reduced visibility is normal and not evidence that something is broken. Changing things in week two, before the first set of changes has been digested, is how a recoverable migration becomes an unrecoverable one.

Keep the old domain registered. For years, not months. It costs almost nothing and it is the only thing keeping every link anyone ever built to you alive.

The honest summary

If you are keeping your domain, most of this does not apply and your risk is close to zero. Change the visuals, change the words, keep the addresses, and nothing happens to your rankings.

If you are changing your domain, the redirect map is not a technical detail at the end of the project. It is the part that determines whether you keep the audience you already paid to build, and it deserves its own owner, its own budget line and its own deadline, separate from the design.