Redesign a website without losing Google rankings
The step almost every redesign skips — and why it costs more search traffic than any design decision ever will.
A redesign goes live. It is faster, it looks far better, everyone is pleased. Six weeks later enquiries are down by half and nobody can explain it.
This is one of the most common and most preventable failures in web work, and it almost never has anything to do with the design.
Rankings are attached to addresses, not to sites
Search rankings accumulate against specific URLs. Years of links, references and crawl history attach themselves to /services/web-design, not to "your website" as an abstraction.
Change the address without telling search engines where it went, and that history does not follow. The new page starts from zero — however much better it is.
What a 301 actually does
A 301 response means "this moved permanently, here is where." Search engines follow it, transfer the accumulated authority, and eventually update their index to the new address.
The alternatives all fail differently:
- 404 — the ranking is gone, and anyone clicking an old link hits a dead end
- 302 (temporary) — search engines keep the old URL indexed and may never consolidate
- A JavaScript redirect — slow, unreliable, and treated with suspicion
- Redirecting everything to the homepage — reads as a soft 404, and often ranks worse than the 404 would have
Only a server-side 301 to a genuinely equivalent page does the job.
Your sitemap is not the inventory
This is the part that catches people, and it caught us.
Rebuilding this site, the existing sitemap listed 135 URLs. It seemed reasonable to treat that as the full picture.
It was not close. Google Search Console showed Korean-language pages being crawled every week that appeared nowhere in the sitemap. Crawling the site properly turned up 1,331 distinct addresses — including 255 Korean and 319 Chinese URLs the sitemap had no knowledge of whatsoever.
Had we trusted the sitemap, we would have silently dropped roughly 90% of the site's indexed surface.
Build the inventory from three sources, never one:
1. Every sitemap variant the old platform generates 2. The Search Console "Indexed pages" export — this is what Google actually has, which is the number that matters 3. A real crawl, seeded separately for each language subtree
Mapping old to new
Every old address needs a destination, and the destination has to be genuinely equivalent. Sending a page about online marketing to a page about pricing is technically a 301 and practically a 404.
A few rules that hold up:
- Equivalent page where one exists. Obvious, and most of the map.
- Category and tag archives → the blog index, not the homepage. Thirty archive URLs all converging on the homepage looks like a soft 404 to Google; a topically adjacent index does not.
- Keep the language. If an old URL served English, send it to the English equivalent. Dropping someone into another language undoes the relevance the ranking was built on.
- Preserve query strings.
/contact-us/?utm_source=googleadsmust arrive with its parameters intact, or every legacy ad and tagged backlink stops being attributable. - Truly unknown paths should 404. Redirecting typos to the homepage produces soft-404 judgments. A real 404 is the correct answer.
Verify before you switch, not after
Test every old URL and assert three things:
1. It responds 301 (or 410 for things deliberately removed) 2. The final destination returns 200 3. The chain is one hop. /a → /b → /c technically works and still leaks authority — and Google gives up on long chains.
That third check is the one people skip, and chains are easy to create accidentally: a trailing-slash rule followed by a redirect rule produces two hops without anyone intending it.
After launch
Submit the new sitemap in Search Console, keep the old one until the redirects are picked up, and watch the "Page with redirect" report. Anything unexpected appearing there — especially your homepage — means a rule is misbehaving.
Expect a few weeks of turbulence regardless. That is normal. A permanent drop is not.
---
If you are planning a redesign and want the migration handled properly, get in touch. The audit is the part worth paying attention to, and it happens before anything gets built.