How to Redesign a Website Without Losing Your Google Rankings

A redesign that loses half your organic traffic is depressingly normal, and it is close to entirely avoidable. The cause is almost never the design. It is that the new site quietly threw away the URLs, content and technical signals the old one had spent years accumulating.

If your current site gets meaningful traffic from Google, that traffic is an asset you already paid for. Here is how not to spend it.

Why redesigns lose traffic

Four causes, in order of how often I see them:

1. URLs changed with no redirects. Every ranking page becomes a 404. Google drops them, and so does every external link pointing at them.
2. Content was cut for being "too wordy". The 1,500-word page that ranked gets replaced with 200 words and a nicer photograph. The rankings went with the words.
3. Technical regressions. Missing titles, no schema, a staging noindex that shipped to production.
4. Speed got worse. The new design is heavier, and Core Web Vitals fall over.

Before you start

1. Crawl the existing site

Get a complete list of every live URL. Screaming Frog does this free up to 500 URLs. You cannot redirect what you have not inventoried, and "I think it was about forty pages" is how pages get lost.

2. Record a baseline

Export from Search Console (last 12 months): every page receiving clicks, every query driving them, and total impressions and clicks. Export your top landing pages from analytics too.

Without this you cannot prove afterwards whether anything broke — and "traffic feels lower" is not something anyone can act on three months later.

3. Identify what is actually earning

Sort by clicks. There is usually a small set of pages producing most of the organic traffic, and it frequently is not the homepage — often an old blog post nobody remembers writing.

Those pages are not up for redesign at will. They can be restyled. Their URL, their headings and their substance need to survive.

Build the redirect map

This is the single most important artefact of the whole project, and it belongs in a spreadsheet before development starts, not after launch.

Rules that matter:

• Every old URL gets a row. No exceptions, including ones you think nobody visits.
• Redirect to the closest equivalent page, not the homepage. Bulk redirects to the homepage are treated as soft 404s and pass nothing.
• Use 301 (permanent), not 302.
• If a page genuinely has no replacement, let it 404 deliberately — that is an honest signal, and better than a misleading redirect.
• Avoid redirect chains. Old → new, one hop.

Keep what ranks

For every page on your earning list:

• Keep the URL if you possibly can. The cleanest migration changes no URLs at all.
• Keep the H1 and heading structure. They tell Google what the page is about.
• Keep the substance. Restructure and tighten, but do not cut a page that ranks down to a paragraph because the new design has less room. Change the design, not the argument.
• Keep the title and meta description unless you have a specific reason and a specific replacement target.

Technical parity checklist

Before launch, confirm the new site has all of this:

• Unique title tag and meta description on every page
• Exactly one H1 per page, with a sensible H2/H3 hierarchy
• Self-referencing canonical tags
• An XML sitemap listing the new URLs
• A robots.txt that blocks nothing important
• No stray noindex tags — check every template, not just the homepage
• Structured data at least matching what the old site had
• Alt text on every image
• Core Web Vitals no worse than before — measure, do not assume
• Every internal link pointing at new URLs directly, not through redirects

Launch day

1. Deploy with redirects already live. Not an hour later.
2. Spot-check twenty redirects by hand, including deep and obscure ones.
3. Crawl the new site and look for 404s and redirect chains.
4. Confirm the site is not blocking crawlers — the "discourage search engines" setting, robots.txt, and any HTTP auth still on staging.
5. Submit the new sitemap in Search Console.
6. Use URL Inspection on your top ten pages and request indexing.

The two weeks after

Expect a wobble. A modest, temporary dip while Google reprocesses the site is normal even on a clean migration. What is not normal is a sustained drop.

Watch daily for the first fortnight: the Pages report for a spike in "Not found (404)", Core Web Vitals for regressions, and Performance compared against the baseline you exported. If a specific page has lost its position, check first that its redirect resolves in one hop and that its content actually survived.

The short version

Inventory every URL. Record a baseline. Find the pages that earn. Map every old URL to its closest new equivalent with a 301. Keep the content that ranks. Verify technical parity before launch, not after. Then watch the numbers for a fortnight.

None of this is difficult. It is just work that has to happen before launch, which is exactly when everyone is busy with the design. If you would rather it were handled, migration SEO is part of both WordPress development and SEO services.