There is a classic story in our field: a company commissions a beautiful new website, puts it live, and watches organic traffic halve within two weeks. The design is better, the copy is better, and still fewer people arrive. Almost always this comes down to the same handful of migration mistakes.

Below is the process we follow for every rebuild. It is not complicated, but it has to happen before you go live.

Why rankings collapse after a migration

Google has indexed your old URLs for years and assigned value to them based on links, behaviour and content. If you change the URL structure without telling Google where everything moved, Google sees hundreds of 404 pages and a set of new addresses it does not know. All the accumulated value now sits on pages that no longer exist.

On top of that, copy often gets trimmed during a rebuild "because it looks cleaner". If the page that ranked for a given term loses that content, the reason it ranked disappears with it.

Step 1: record the current situation

Before anything changes, take a baseline. Export from Google Search Console which pages get impressions and clicks, and on which queries. Also crawl the existing site so you have a complete list of URLs, including the pages you had forgotten about.

This list is your reference point. Without a baseline you cannot establish after launch whether something went wrong, let alone what.

Step 2: build a redirect plan

For every old URL that changes address, record where it goes. That becomes a 301 redirect: a permanent pointer that carries the accumulated value across to the new URL.

Point to the closest equivalent new page, not to the homepage by default. A mass redirect to the homepage is treated by Google as a soft 404 and gains you nothing.
Avoid chains: old URL to interim page to final page. Redirect in a single hop.
If there genuinely is no equivalent, return a 410 rather than letting the page quietly disappear.

Keeping the URL structure entirely? Then you need no redirects at all, and that is the safest route by far. We often advise keeping the existing structure unless there is a good reason to change it.

Step 3: preserve the content that did the work

Take your list from step 1 and walk through the best-performing pages. For each one, the new version must be at least as complete as the old. That does not mean copying the text verbatim, but it does mean continuing to answer the same questions.

Watch the things that are easily lost in a rebuild: page titles, meta descriptions, heading structure and image alt text.

Step 4: technical checks before launch

Put the new site on a staging environment and work through these:

Is there still a noindex or a robots.txt block left over from staging? This is the most common and most expensive launch mistake there is.
Do the canonical tags point at the final URLs?
Is the sitemap correct, and does it contain only indexable pages?
Do the redirects actually work? Test them automatically, not by sampling.
Is the site measurable, meaning the analytics code is back in place?

Step 5: the first weeks after launch

Submit the new sitemap in Search Console and watch the coverage report. A temporary dip of a few weeks is normal; Google has to recrawl and process the move. What is not normal is a continued decline after a month, or a growing number of 404 reports.

Check weekly whether the number of indexed pages returns to its previous level and whether your most important queries recover their positions. If they do not, the answer is almost always a missing or incorrect redirect.

What not to do

Change two things at once. If you rebuild the website and change the domain and rewrite the content, you cannot work out which change caused a problem. Do a domain migration separately from a rebuild, with a few weeks in between.

We include this process as standard in every rebuild project. See what a new website costs or put your situation to us if you want to know what your migration would involve.