How much traffic drop is normal after a relaunch?

A dip of five to fifteen per cent for two to four weeks is common while search engines re-crawl and re-evaluate. Recovery to baseline or better should follow. A drop of forty per cent, or one still there after six weeks, is not settling — it is a fault, and it is usually redirects or accidental noindex.

Do we need to keep our old URLs?

Keep them where you can. Every URL change spends a little of the authority that page has accumulated. If the old structure is genuinely poor, change it — but map every old URL to its closest new equivalent with a 301, and never to the homepage in bulk.

How long should redirects stay in place?

At minimum a year. In practice, forever — they cost nothing to keep and old links keep arriving for years. Removing them later quietly breaks inbound links you have forgotten about.

Should we launch all at once or in stages?

All at once for the site itself, so you have one clean before-and-after to measure. Stage the content migration beforehand if it is large. What you should not do is run old and new versions in parallel on different URLs — that competes with itself and confuses everything.

Web9 min

How to Redesign a Website Without Losing Your Search Rankings

Traffic collapses after a relaunch more often than anyone admits, and the cause is almost always the same three things. Here is the checklist we run before, during and after.

BunnyDevs8 Apr 2026

Site relaunches lose traffic far more often than agencies mention in their case studies. The new site looks better, everyone is pleased, and eight weeks later somebody notices enquiries are down by a third.

In nearly every case we have been called in to fix, the cause is one of three things: URLs changed without redirects, the staging site's noindex shipped to production, or content that was carrying the rankings was cut as part of the tidy-up.

All three are entirely preventable, and none of them are design decisions.

Before you change anything: measure

You cannot detect a problem without a baseline, and you cannot build a redirect map without an inventory.

Export every URL that exists. Crawl the current site, then add everything from your analytics and Search Console over the last twelve months. The crawl finds what is linked; the other two find what is ranking, including orphan pages nobody remembers.

Record what each page earns. Sessions, conversions, and the queries it ranks for. This is the list that decides what must survive. It is common to find that a page nobody in the business thinks about brings in a meaningful share of enquiries.

Save the current numbers. Traffic, rankings for your priority terms, conversion rate, Core Web Vitals. Screenshot them. In six weeks these are how you tell success from a slow decline.

Note your best backlinks. Which pages have external sites linking to them. Those URLs matter most and must not break.

Build the redirect map before the design is signed off

This is the step that gets postponed, and postponing it is how relaunches fail.

For every old URL, write down the new URL that best matches it. A spreadsheet with two columns.

The rules:

One to one wherever possible. Old page about a service goes to the new page about that service.

Never redirect everything to the homepage. Search engines treat a bulk redirect to the root as a soft 404 and the accumulated value is discarded. It is the single most damaging shortcut available.

Use 301, not 302. Permanent, not temporary. A 302 tells search engines to keep the old URL, which is not what you mean.

No chains. Old A to new B, not A to B to C. Chains lose value and slow everything down. If you have redirects from a previous migration, flatten them so they point directly at the final destination.

Redirect deleted pages to the closest relevant page, not to a generic index. If nothing is relevant, return a real 404 — that is honest and it is better than a misleading redirect.

Have someone check a sample by hand. Automated mapping by URL similarity produces confident nonsense.

The pre-launch check

Run this on the staging site, the day before:

Is noindex still set? Staging sites carry noindex and password protection. Both must be removed at launch and both are forgotten regularly. This one mistake can remove a site from search results within days.
Does robots.txt block anything it should not? The staging Disallow: / shipping to production is the classic version of the same error.
Do titles and meta descriptions exist on every page? Templates sometimes lose them.
Are H1s present and correct? Redesigns frequently turn headings into styled divs.
Is the canonical tag pointing at the right URL? Including the correct protocol and whether you use www.
Does the XML sitemap list the new URLs and only the new URLs?
Does structured data still validate?
Is the analytics tag on every page? Otherwise you will spend a fortnight investigating a traffic drop that is a measurement gap.

Launch day

Deploy, then immediately test in this order:

Spot-check redirects by hand. Twenty of your most valuable old URLs. Confirm each returns 301 and lands somewhere sensible.

Crawl the live site. Look for 404s, redirect chains, and any page returning something other than 200 that should not.

Submit the new sitemap in Search Console and request indexing for your most important pages.

Check the site on a phone, on a normal connection, not office wifi.

Confirm analytics is recording. Real-time view, load a page, see it appear.

The weeks after

Watch Search Console daily for the first fortnight. The Pages report will show you crawl errors and anything excluded. This is where a noindex mistake surfaces before it becomes a disaster.

Expect a dip. Five to fifteen per cent for two to four weeks is normal. Search engines re-crawl, re-evaluate, and settle.

Know the difference between settling and breaking. A dip that recovers gradually is normal. A cliff on launch day that stays flat for six weeks is a fault. Go back to redirects and indexing before assuming it is "just the algorithm".

Re-check Core Web Vitals after real traffic arrives. Field data differs from lab data, sometimes considerably.

The content trap

Redesigns come with an urge to tidy. Fewer pages, cleaner navigation, less clutter.

Be careful. Pages that look like clutter to the business are sometimes the pages doing the work — an old article that ranks for a long-tail query and quietly produces enquiries every month. Your inventory tells you which is which, and that is exactly why you built it first.

If a page earns traffic, it survives the redesign in some form even if it does not appear in the navigation.

What we do differently

We build the redirect map at the same time as the sitemap, before design starts, because it is a content decision rather than a technical one. And we check indexing directives in the deploy pipeline, so a staging noindex cannot reach production — that failure is too common and too costly to leave to a checklist someone might skip on a busy launch day.

If you are planning a relaunch and want the migration side handled properly, or you have already launched and the traffic has not come back, tell us what happened.