The traffic drop after a relaunch is not inevitable. It is the predictable result of four things nobody assigned to anyone.

Rebuilds lose traffic for boring reasons. Every one of them is preventable, and every one of them is preventable only before launch.

The four causes

1. URLs changed and nothing redirected.
2. Content was "tightened" and the pages that ranked lost the text that ranked them.
3. The new site is slower on mobile than the old one.
4. Staging was indexed, or production was not.

None of these four are subtle once you are looking for them. All four are routinely missed, because a redesign project is organised around what the new site should look like, and none of the four live in that conversation — they live in a technical checklist that gets written, if it gets written at all, in the final week before launch, by whoever remembers.

Why URL changes are the most damaging, and the easiest to prevent

Every inbound link, every bookmark, and every ranking signal a search engine has accumulated about a page is tied to that page's URL, not to its content. Change the URL without a redirect and all of that resets to zero — the new page starts from nothing, even if the content on it is identical to the page that used to rank. A 301 redirect from the old URL to the new one passes the overwhelming majority of that accumulated signal across. Skipping it, even for what feels like a minor restructuring, is the single most common reason a redesign's traffic does not recover for months.

What "tightening" quietly removes

Content gets cut during a redesign for good reasons: a page reads better shorter, a design system does not have room for six paragraphs where it used to have two. The problem is that a paragraph reads as filler to a copywriter and reads as topical coverage to a search engine — the specific detail, the named use case, the answered edge-case question that made a page the best answer to a narrow query. Cut it for readability and the page gets cleaner and less findable at the same time, and nobody notices until rankings for queries nobody was tracking quietly disappear.

What to do before launch

• Export every URL with traffic or links from the last twelve months — not a guess at "the important pages," an actual export from analytics and from whatever backlink data you have access to.
• Map each one to its destination, and write the redirects as part of the build, not after it. A redirect map written the week of launch under time pressure is where mistakes live.
• Diff the copy on the top twenty pages. If a page is losing more than a third of its words, someone should sign off on that deliberately — not discover it by comparing before-and-after screenshots after rankings have already moved.
• Check the robots directives on both environments the morning of launch. Staging environments are routinely set to noindex during development; that setting getting left on in production, or turned off on staging and indexed by mistake, happens more often than it should.

The speed regression nobody notices until it is live

A new design frequently ships slower than the site it replaced, not because anyone chose that but because nobody measured against the old baseline. Heavier images, a new animation library, a font that was not there before — each addition is individually small, and collectively they add up to a page that takes longer to become readable on a mid-range phone than the site it replaced. Search engines use page experience as a ranking input; more immediately, so do visitors, who bounce off a slow page before ever getting the chance to be convinced by the redesign at all. The fix is not avoiding every new visual element — it is measuring the new site against the old site's real performance numbers before launch, not after.

Who should own this list

Redirect mapping, content diffing and robots checks all fall into a gap between roles on most projects: not quite design, not quite development, and easy for a project manager to assume someone else owns. On our projects one named person is responsible for this list specifically, checked off before launch is scheduled rather than during a post-launch scramble, because "someone will catch it" is exactly how staging environments end up indexed and redirect maps end up half-finished.

After launch

Watch coverage and impressions rather than sessions for the first fortnight. Sessions are noisy — a launch week often sees a temporary bump from people checking out the new design, which can mask a real ranking problem underneath it. Impressions in Search Console tell you whether the pages are still eligible to rank at all, which is the actual signal you need in the first two weeks, well before session data would show a trend either way.

If impressions do drop on specific pages, check the four causes above in order before assuming anything more exotic. A missing redirect or an accidental noindex explains the overwhelming majority of post-launch traffic drops, and both are fixable within a day once identified — which is more than can be said for whatever a broader "the algorithm changed" theory would have you do instead.

The case for a phased launch

Launching an entire site at once maximises the number of things that can go wrong simultaneously, and makes the specific cause of a traffic drop harder to isolate afterwards — if URLs changed, content shortened and speed regressed all in the same release, working out which one actually mattered takes real effort. Where the platform allows it, we prefer launching in sections: a redesigned blog first, then the product pages, then the homepage last. Each phase is small enough to monitor cleanly, and a mistake in phase one gets caught and fixed before it is repeated across the rest of the site. This is not always possible — some platforms and some architectures only allow a single cutover — but where it is an option, it turns one high-stakes event into several low-stakes ones.

What we tell clients who want to launch faster

That every shortcut on this list has a specific, attributable cost, and that the cost is not evenly distributed across time. Skipping the redirect map saves a few days now and can cost months of recovered rankings later, because search engines re-evaluate a URL's authority slowly, not instantly, once it starts receiving the old page's signal again. A launch date moved up by skipping the pre-launch checklist is not actually a faster launch — it is the same launch with the recovery period moved to after the fact, where it is harder to plan around and considerably more visible to whoever is watching the traffic numbers.

In short

A redesign does not have to cost you rankings. It costs you rankings when redirects, content parity, speed and indexability are treated as launch-week details instead of build requirements — assign the checklist to a name, not a hope, and check it before the old site goes away, not after.