How to Redesign a Website Without Losing Your Google Rankings

This is the fear that stops people commissioning a rebuild, and it is a reasonable one. Plenty of businesses have launched a new website and watched three years of search visibility disappear inside a fortnight.

It is also entirely avoidable. Rankings are not lost because the design changed. They are lost because the addresses changed and nothing told Google where things went.

What actually causes the drop

In order of how often we see it:

• URLs changed with no redirects. The old page ranked, the new site put that content somewhere else, and the old address now returns a 404. Every signal that page had accumulated is orphaned.
• Everything redirected to the homepage. A well-intentioned catch-all rule. Google treats a redirect to an irrelevant page as a soft 404 and the value does not carry.
• Content thinned out. A page that ranked on 1,200 words of detail gets replaced by 200 words and a nicer photograph. It no longer answers the question it was ranking for.
• The staging site was left indexable. The rebuild is crawled before launch, duplicates the real site, and confuses everything.
• The new site is slower. Surprisingly common when a page builder and a heavy theme replace something simple.
• noindex left switched on. Set during development, never removed. This one is brutal and takes about ten seconds to check.

Start with an inventory, before anything is designed

This is the step that makes the difference, and it has to happen before the structure of the new site is agreed, not after.

Export from Search Console: every URL, its clicks, its impressions, and the queries it ranks for. Twelve months of data. Then sort by impressions and read it properly.

You are separating your pages into three piles:

1. Pages that earn. Clicks, or meaningful impressions at a decent position. These are assets. Their URLs should survive the rebuild unchanged wherever possible.
2. Pages that could earn. Impressions but poor position, usually because the page is thin or answers the wrong question. These get rewritten and kept at the same address.
3. Pages that earn nothing. No clicks, no impressions, twelve months. These get retired deliberately rather than migrated. Carrying them across is work you pay for twice.

Most businesses are surprised by this exercise. The pages people assume are important are frequently not the ones doing the work, and there is usually at least one old post quietly earning traffic that nobody knew about.

Keep the URL wherever you can

The simplest way not to lose the value of a URL is not to change it.

There is a strong instinct during a rebuild to tidy the structure: shorter slugs, neater hierarchy, a new naming convention. Resist it for any page that earns. A slightly untidy URL that ranks is worth considerably more than a beautiful one that does not.

Change URLs only where there is a real reason: the old one is genuinely broken, the page is merging with another, or the structure is actively preventing the site from ranking.

Redirect properly when you must change

Three rules, and the third is the one people get wrong.

• Use a 301, not a 302. A 302 says temporary and does not pass value the same way.
• One hop. Old URL straight to final URL. Chains of redirects leak value and slow the page.
• Point at the closest equivalent, not the homepage. If a page about commercial roofing is being retired, it redirects to the roofing services page, not to the front door. If there is genuinely no equivalent, letting it 404 is more honest than a redirect to something unrelated.

Build the redirect map as a spreadsheet during the inventory, with old URL and new URL side by side, and have it signed off before launch rather than written in a hurry afterwards.

Rewrite valuable content in place

If a page is earning and the content is dated, the instinct is to write a better version and publish it at a new address. Do not.

Rewrite it at the existing URL. Keep the original publication date, let the modified date carry the update, and display “Updated” rather than the publish date if the page shows one. You keep every accumulated signal and lose the staleness.

We did exactly this with three articles from 2019 during our own rebuild. They were dated and off-message, but one of them was quietly earning a couple of thousand impressions a year. Retiring it and starting again would have thrown that away for no reason.

The launch sequence

1. Before launch: redirect map complete and tested on staging. Staging blocked from indexing. Analytics and Search Console ready on the new site.
2. Record the baseline. Rankings, clicks, impressions and speed, the week before you launch. Without this you cannot tell a normal settling period from a real problem.
3. Launch, then immediately: check for noindex, check robots.txt, spot-check ten redirects by hand, submit the new sitemap in Search Console.
4. Week one: watch Search Console coverage for a spike in 404s. That is your redirect map telling you what it missed.
5. Weeks two to four: expect movement, including some downward. Google is recrawling and reassessing. Do not panic and do not start changing things.
6. Week six onwards: if you are still materially below the baseline, something is wrong and it is worth investigating properly.

Common questions

Should we launch the new site all at once or in phases?

All at once, in almost every case. A phased launch means running two structures simultaneously, which is harder to redirect correctly and harder to diagnose when something moves.

How long should we keep the redirects in place?

Permanently. There is no benefit to removing them, they cost nothing, and old links from other websites keep sending people for years.

Does changing platform hurt rankings?

Not in itself. Google does not care what the site is built on. It cares about the URLs, the content and the speed. A platform change becomes a problem only when it forces a URL structure change and nobody plans for it.

What if our rankings have already dropped after a rebuild?

It is usually recoverable. Start by crawling the old sitemap, if you still have it, and finding what now 404s. Most of the damage in these situations is a missing redirect map, and building one after the fact still works. It is slower than doing it first, but it works.