Where the fear comes from
Ask around and you'll find the story quickly: a business rebuilt its dated website, the new one looked far better, and within a month the phone went quiet. Traffic halved. The rankings that took years to earn were gone.
The story is real — it happens constantly. But it isn't evidence that redesigns are dangerous. It's evidence that a specific, boring set of steps got skipped. Rankings don't live in your design. They live in your URLs, your content, and Google's accumulated understanding of both. A redesign only threatens them when it discards those things without telling Google where they went.
That distinction matters, because the fear of losing rankings keeps a lot of businesses on websites they outgrew years ago — which quietly costs more than a rebuild ever would.
What actually loses rankings
Nearly every post-redesign collapse traces back to one of five mechanisms.
Pages that ranked disappear without redirects. This is the big one. Your old site had a page at /services/loft-conversions that ranked for years. The new site puts that content at /what-we-do, or drops it entirely. Anyone clicking the old Google result now hits a 404 — and Google, finding nothing there, eventually removes the listing. Every renamed or deleted URL needs a permanent (301) redirect to its true replacement. Not to the homepage — to the page that actually replaces it. Redirecting everything to the homepage is barely better than redirecting nothing.
The content that earned the rankings gets thrown away. Designers understandably want clean, sparse pages. But if your old services page ranked because it explained the work in five hundred specific words, replacing it with a headline and three icons removes the very thing Google was ranking. The page can absolutely be redesigned — the substance needs to survive the redesign.
The new site launches with the brakes on. Development sites are deliberately hidden from Google — a noindex tag or a blocked robots.txt keeps the work-in-progress out of search. Launch with either still switched on and you have politely asked Google to remove you. It obliges. This is the most avoidable disaster in the list, and it still happens weekly.
The new site is slower than the old one. Page speed and the Core Web Vitals metrics are ranking signals. A rebuild loaded with oversized images, heavy scripts, and animation libraries can genuinely rank worse than the dated site it replaced — the old site was ugly, but it was probably light.
Invisible structure gets dropped. Titles, meta descriptions, heading hierarchy, and structured data (the machine-readable markup that powers rich search results) all live in the code, not the visible design. A rebuild that doesn't deliberately carry them over silently deletes them.
What Google itself says
None of this is folklore — Google documents it. Its site move guidance is explicit that permanent redirects don't cause a loss in PageRank: a properly redirected page passes its authority to its successor. It also says to expect temporary ranking fluctuation while the new site is recrawled — a few weeks for a medium-sized site — and recommends submitting a sitemap and watching Search Console through the transition.
One more piece of Google advice worth taking seriously: isolate big changes where you can. If you change your design, your URLs, and your platform all at once and traffic dips, you can't tell which change caused it. Sometimes changing everything together is unavoidable — then the redirect map and content parity simply have to be right, because there's no second variable to blame.
The checklist that preserves rankings
This is what a safe migration looks like, whoever does it.
Before anything else, crawl the old site and export its pages, and pull the last year of data from Search Console — you need to know which pages actually get search traffic, because those are the ones that must survive. Then, for every URL that changes or dies, decide its single true replacement and write it down. That document — the redirect map — is the most important artefact of the whole project.
During the build: keep the substance of every ranking page, carry over titles, meta descriptions and heading structure (improving them is fine — deleting them is not), preserve or upgrade the structured data, and hold the new site to a performance budget so it launches faster than the old one, not slower.
At launch: implement every redirect server-side, remove the noindex tag and unblock robots.txt, submit the new sitemap in Search Console, and click your own most important old URLs to watch them land in the right places.
After launch: live in Search Console for a few weeks. Its coverage and 404 reports will show you the URLs you missed — there are always a few — and each one is a two-minute fix if you catch it early. Expect some movement in the first weeks; per Google's guidance, fluctuation is normal, and it settles if the fundamentals are right.
When a redesign helps your rankings
Done properly, a rebuild is more often a ranking gain than a risk — because most dated sites are held back by exactly the things a good rebuild fixes: painful load times, no mobile experience worth the name, thin pages with nothing for Google to rank, missing structured data, and content that hasn't matched what the business does for years.
The clearest example from our own work is the bike shop rebuild. It started as an underperforming site with a stock problem underneath, and the rebuilt catalogue — real product content, accurate stock, proper structure — is a large part of why online sales went from around two thousand pounds a year to over two hundred thousand in the first year. That result is an e-commerce systems story rather than a typical brochure-site rebuild, but the principle transfers: the site didn't rank because it was pretty. It ranked because the rebuild gave Google something worth ranking.
If you're weighing up whether you need a rebuilt website or something more, our plain-English guide to websites versus web apps covers that decision.
Do you need to hire someone for this?
Honestly: not always. If your site is small, you know which handful of pages get traffic, and the new site keeps the same addresses, this is careful-DIY territory — most website platforms and hosts have solid redirect tools, and the checklist above is the whole job.
Where it goes wrong unaided is scale and platform changes: dozens of URLs, a move between platforms that forces every address to change, or an old site so tangled nobody knows what's in it. That's when the redirect map needs to be someone's actual job. It's a standard, unglamorous part of every website rebuild we take on — not an optional extra, because a redesign that loses your traffic isn't a redesign, it's a demolition.
Where we land
Redesigns don't lose rankings — skipped steps do. The three that matter most: redirect every URL that changes to its true replacement, keep the content and titles that earned the rankings in the first place, and launch without the development brakes still on. Google's own documentation backs each of these, expects a few weeks of settling, and gives you Search Console to catch the stragglers. If your website is overdue a rebuild, the ranking risk is manageable with discipline — and staying on a site that embarrasses the business carries a cost that compounds every month.