The pattern
It is the same story with different sites in it. The rebuild goes live. The site is faster and better looking. Within three to six weeks organic traffic is down by a third, or a half, or more, and it does not come back on its own.
What makes it disorienting is that every individual decision looked like an improvement. Cleaner URLs. Simpler navigation. Fewer pages. A lighter template. None of that is wrong in isolation, and all of it can be catastrophic in combination, because a redesign touches the one thing a site cannot afford to have touched carelessly: the structure that carries its authority.
What actually causes the loss
URLs changed without a full map
The single biggest cause. Cleaner URLs are a genuine improvement and the cost of getting the transition wrong is enormous.
The failure is rarely “they forgot the redirects”. It is subtler: the redirects were done from the old sitemap, and the old sitemap did not contain every URL that had links pointing at it. Pages deleted years earlier, old parameter versions, printer friendly URLs, the versions that existed before the last migration. Each of those was still receiving something, and now returns a 404.
A redirect that does not exist is not a small loss. It is the total loss of everything that URL had accumulated.
Redirects that point at the homepage
The fallback that feels responsible and is not. When a specific destination is not obvious, sending the old URL to the homepage looks better than a 404. It is treated as a soft 404, and passes close to nothing. It also makes the loss invisible, because nothing 404s in the report.
Internal links rebuilt from scratch
Navigation is usually redesigned wholesale, which means the internal link graph is replaced overnight. Pages that were reachable in two clicks are now reachable in five. Contextual links inside old content survive; the structural links around it do not. Authority flows along those links, and it has just been rerouted by someone who was thinking about menus rather than about equity.
Content quietly dropped
Every redesign prunes, and pruning is healthy. What is not healthy is pruning by recent traffic alone. A page with fifty visits a month and four editorial links is worth more than a page with a thousand visits and none, and nothing in the analytics view says so.
Everything changing at once
Even when each change is sound, doing them together destroys diagnosis. Template, URLs, navigation, content, hosting and sometimes the CMS, all in one release. When traffic falls there is no way to isolate the cause, so the response becomes guesswork, and the recovery takes months longer than the damage did.
Why it surfaces here rather than earlier
This is the part that matters, and it is the reason the story repeats.
Most sites that lose traffic in a redesign were already carrying the damage. Redirect chains from earlier moves, pages with no place in the architecture, equity that was never mapped. None of it was visible, because a static site hides it well.
The redesign does not create that damage. It calls it in. Rebuilding the structure forces every deferred structural decision to be resolved at once, by whoever happens to be doing the rebuild, usually without the information needed to resolve it well.
Which is why the sites that come through a redesign intact are not the ones with better designers. They are the ones that repaired before they redesigned.
The uncomfortable implication
The order matters more than the quality of the work.
A mediocre redesign on a repaired site loses nothing. An excellent redesign on a site full of deferred decisions can cost years of accumulated authority in a single afternoon, and the loss will be blamed on the design.
That is the whole argument for repair coming first. Not because repair is more important than design, but because design executed on top of damage converts invisible debt into visible loss.
What this page does not cover
How to build the URL map, what to check before the release, how to decide what to prune and how to verify a migration afterwards is protocol, and protocol belongs in the manual rather than on a public page.
What belongs here is the thing that would have prevented most of these losses: know what you are carrying before you rebuild the thing that carries it.
