Relaunch without losing traffic: the work before launch day

The new website has been live for four weeks. It looks better than anything the electrical contractor had before, and loads faster. The phone still rings less: eight to twelve enquiries a month before, four this month. Search Console lists 140 "Not found (404)" messages, and two thirds are the pages that used to bring the traffic.

The drop after a relaunch almost never comes from the new design and almost always from the addresses. This piece shows how to build the list of old URLs from four sources, what the mapping table looks like, and what happens on launch day in what order. The work that prevents the drop happens before you go live, not after.

Does a relaunch have to change your URL structure at all?

This one question decides the entire workload, and it usually never gets asked.

A relaunch where design, technology and copy are new but the addresses stay the same is manageable. Google finds the same URLs, every link on the web still points there. A relaunch with a new URL structure is something else: you throw away every address Google spent years collecting signals for. The best redirect is the one you never need.

So, plainly: "nicer URLs" is not a good reason. The gain is cosmetic, the risk is real, and nobody ever lost a job because the address ended in .html. Good reasons look different: the new CMS forces another structure, the old addresses were technical identifiers (/index.php?id=417), or the company changed its name.

There is an uncomfortable position attached: do not change everything at once. Switching design, URL structure, CMS, copy and domain in one go makes root cause analysis impossible. If enquiries fall by forty percent, you cannot say whether the redirects are broken, the copy fits the query worse, or the consent banner is swallowing the measurement. Split it if it can be split.

The URL list comes from four sources, not from the crawl alone

The central artefact is a list of every address the old site had. Almost everyone makes the same mistake: they crawl the old site and treat the result as complete. A crawl only finds what is linked, and the pages you miss painfully afterwards were often never in the menu.

From Search Console take two views: the page indexing report, and the performance report on the "Pages" tab set to 16 months, all Google keeps. If the property does not exist yet, fix that weeks before the relaunch: set up Search Console. From GA4 take Engagement → Landing page over twelve months, no channel filter.

Paste the four exports into one sheet, drop the duplicates, and you have your list. A law firm I did this for had 210 URLs in the crawl, 340 in Search Console, 380 in the union. The ones the crawl missed were client bulletins going back ten years, and two of them brought a fifth of all search visitors.

Now sort by clicks and impressions, descending. This makes the work realistic: on nearly every site, twenty percent of the URLs carry eighty percent of the visibility. At the law firm that was 41 addresses, and those go through the mapping one by one.

The mapping table: stays, redirected, gone

The artefact has three columns: old address, new address, decision.

Stays is the best decision and therefore the one you check first. Character for character identical, trailing slash included: /services/Safety-Check/ and /services/safety-check are two pages to a server.

Redirected applies when the content lives on at a different address. The target is the topically matching page, not the homepage and not the category page. Somebody who arrived via "safety check cost" wants a page about safety checks, not an overview of fourteen tiles.

Gone is allowed, but only deliberately. The rule: an address with clicks in the last twelve months never simply disappears. If the content is gone but the query is alive, you need a replacement page. What may genuinely go: the spring offer from 2019, the thank you page of a dead form.

Redirects done right: 301, one hop, never the homepage

Permanent is the default. An address change in a relaunch is permanent, so 301. A temporary redirect (302) is only for things that really are temporary, like a maintenance page overnight.

One hop, not a chain. Every old address points straight at its final target. Chains build themselves as rules fire one after another: /service/safety-check.html goes to /services/safety-check, that redirects again over the missing trailing slash, and the http rule pushes it to https. Googlebot follows up to ten hops, but each costs time, and sooner or later the report says "Redirect error".

No redirect that itself points at a redirect. On the second relaunch, the rules from 2021 point at addresses that stopped existing in 2024. Rewrite them to the new target instead of stacking another layer.

Deliberately removed pages get a clear answer. If the content is gone with no successor, 410 Gone is the honest reply: it existed, it does not anymore. A 404 is just as fine, Google treats the two almost identically and drops the address slightly faster on a 410. A 404 is no blemish.

Which is why you never bulk redirect to the homepage. The most popular shortcut and the most damaging. Google recognises that the target has nothing to do with the old page and treats the redirect like an error page: the report shows "Soft 404", the address leaves the index anyway, and the value of the old links evaporates.

Your staging site is the most common cause of a total wipeout

This is where the real disasters live. Two mistakes, both expensive.

Mistake one: staging is unprotected and gets indexed. Then staging.example.com competes with the live site, Google picks the wrong version as canonical for some pages, and a staging URL ends up in the search results. Deciding which version counts works as in canonical tags done right.

Mistake two is worse: the protection travels into production. A <meta name="robots" content="noindex"> in the global template, or a Disallow: / nobody touched during the switch, deletes your visibility overnight. Search Console starts showing "Excluded by 'noindex' tag" or "Blocked by robots.txt", and pages leave the index within days.

Which leads to advice you rarely read: protect staging with a password, not with noindex. A password fails loudly on launch day, because nobody can see the new site, the boss included. A forgotten noindex fails silently, because the page looks normal. The difference is the volume at which they fail. Which tool does what: robots.txt and noindex.

# staging.example.com/robots.txt only
User-agent: *
Disallow: /

What happens on launch day, in order

The order is not arbitrary. The checklist you tick off:

1. Remove the protection. noindex out of the template, Disallow: / out of robots.txt, password off.
2. Switch the redirects on and spot check them. Request the top thirty addresses from your sorted list. What you want is a single 301 and a 200 at the end. Fetching every old address and logging status codes is the part a crawler does for you.
3. Check robots.txt. Open the live file and read it.
4. Check the canonicals. Do they point at the live domain or still at staging? The second most common thing to travel across.
5. Submit the new sitemap. Generate a fresh one and submit it under "Sitemaps".
6. Point internal links at the new addresses. Menu, footer, links in copy, form targets. Redirects are for strangers, not your own navigation.
7. On multilingual sites, check the language markup. Do the hreflang entries point at the new addresses, and is every pairing reciprocal? See set up hreflang.
8. Check analytics and the consent banner. Is the tag on every new page, are the events firing, is the banner passing consent through correctly?

Step eight gets skipped most often and bites latest: a drop that is only a broken measurement costs weeks of panic.

The four weeks after: dip or defect?

A dip is normal. Google has to recrawl every changed address, see the redirect several times and transfer the signals, and it explicitly gives no deadline. In practice the most important addresses of a small site are reprocessed within one to two weeks, the long tail takes weeks to months. The normal shape: a decline in the first two weeks, then week by week back up.

A defect looks different, in four places:

• The page indexing report shows a rising "Not found (404)" count listing addresses that used to have clicks. A redirect is missing or not firing.
• Pages show up as "Page with redirect" although they are the target and not the source. Usually a canonical still points elsewhere.
• URL Inspection shows a chain of several hops for an important address, or it says "Redirect error".
• Visibility keeps falling in weeks three and four instead of recovering. The clearest signal it is not a dip.

What to check next is in page not indexed. If the addresses are technically fine and the rankings are gone anyway, the cause is usually content trimmed during the relaunch: the case in lost rankings.

And because it always comes up: the redirects stay permanently. Google recommends at least a year, but that is the floor, not the goal. Old links on the web do not disappear, bookmarks do not either, and the flyer with the old address sits in a waiting room for years.

Where to start

1. Build the list: crawl, Search Console export over 16 months, sitemap, landing pages from GA4. One sheet, duplicates dropped.
2. Sort by clicks and mark the top twenty percent. That is where mistakes hurt.
3. For every marked address, enter the decision: stays, redirected, gone. When redirecting, pick the topically matching target, never the homepage.
4. Check whether the addresses have to change at all. Every "stays" row is one row less risk.
5. Protect staging with a password rather than noindex, and put "remove the protection" first.

Frequently asked questions

Why did my traffic drop after the relaunch?

Usually because the old addresses got no redirect or the wrong one. Check the page indexing report for addresses under "Not found (404)" that used to have clicks. Suspect two is a noindex or Disallow: / that travelled over from staging. If both are fine, look at the measurement: a missing analytics tag looks exactly like a drop.

How long does it take to recover after a relaunch?

Google gives no deadline. In practice the most important addresses of a small site are reprocessed within one to two weeks, the rest takes weeks to months. A decline in the first two weeks that shrinks afterwards is normal. Visibility still falling in week four is not.

301 or 302 for a relaunch?

301. An address change in a relaunch is permanent, and only the permanent redirect tells Google unambiguously that the new address is the right one. The 302 belongs to things that really are temporary: a maintenance page, a weekend test. Google eventually reads a long standing 302 as a move too, but do not rely on it.

Should I redirect old URLs to the homepage?

No. Google recognises that the homepage has nothing to do topically with the old page and treats the redirect like an error page. The indexing report shows "Soft 404", the old address leaves the index anyway, and the value of inbound links is lost. With no matching target, a 410 is more honest.

How long do I need to keep redirects?

Permanently. Google recommends at least a year, because the redirect has to be seen several times before the signals transfer. That is the floor for the search engine, not for people: old links do not disappear, bookmarks stay put, printed material keeps circulating. Deleting them is rarely worth the effort.

Do I have to change URLs in a relaunch?

No, and in most cases you should not. If the addresses stay while design, technology and copy get replaced, the risky part of the project disappears. "Nicer URLs" is not a good reason, because the gain is cosmetic and the risk real. Good reasons: a CMS that forces another structure, or a new company name.

What do I do with pages that no longer exist?

If the content is permanently gone with no successor, give a clear refusal: 410 Gone or 404. Google treats both almost identically, and a 410 drops the address slightly faster. Redirecting to a vaguely related target is worse. One exception: if the page still had clicks, the demand is still there and you need a replacement.

When is the best time for a relaunch?

In the weakest phase of your year, not the strongest. An online shop goes live in February, not November, and an accountant not in tax season. If the dip is unavoidable, let it land where it costs least. The weekday matters too: early in the week, so working days are left with fixers reachable.

What is different about a domain change?

Two things get added. First, you need a separate Search Console property for the old and the new domain, and you report the move through the change of address tool under Settings. It checks the redirects for your top addresses, so those have to be in place first. Second, the trust the old domain built up does not transfer on command. Which is why you never bundle a domain change with new structure and new design.