How to Redesign a Website Without Losing Your Rankings

Nobody sets out to lose traffic with a redesign. The new site is faster, cleaner, better written, and on launch day everyone is pleased. Three weeks later organic sessions are down 40% and the agency is explaining that "rankings always fluctuate after a launch". Sometimes they do. More often, something specific was broken — and it was avoidable.

This is the process we use to protect rankings through a rebuild. It is not complicated. It is just easy to skip when the deadline is close.

Why redesigns lose traffic

In roughly descending order of frequency, on the post-mortems we have run:

• URLs changed and were not redirected — or were redirected to the homepage, which Google treats as a soft 404.
• Content was removed or thinned. The old service page had 900 words and answered questions; the new one has a hero, three icons and a button.
• Titles, headings and internal links changed in ways that dropped the terms pages ranked for.
• The new templates are slower or render key content only with JavaScript, so Core Web Vitals fall and crawlers see less.
• The staging site was indexed — sometimes months before launch — and now competes with the live one, or the noindex used to hide it shipped to production.
• Canonical, robots or sitemap mistakes: canonicals pointing at staging, a sitemap full of old URLs, a robots.txt that blocks the CSS the renderer needs.
• Two live versions of the site — www and non-www, or trailing slash and no slash — because the server config was rewritten and nobody re-added the redirects.

Before you design anything: the baseline

You cannot preserve what you have not measured. Before a wireframe exists, capture:

1. A full crawl of the current site (Screaming Frog or similar): every URL, its status, title, H1, meta description, canonical, word count and inbound internal links.
2. Search Console exports: the last 16 months of pages and queries, so you know which URLs earn impressions and clicks and for what.
3. Backlink inventory: which URLs have external links pointing at them. These are the pages you must not break.
4. Core Web Vitals field data per template from the CrUX report, so the new site has a number to beat rather than a vibe.
5. Analytics by landing page: sessions and conversions per URL, so the redesign's success can be judged on the pages that mattered.

This is the same work as a pre-redesign audit, and it usually changes the brief: pages nobody thought about turn out to bring in a third of the leads.

The URL and redirect map

The single most important document in the project is a spreadsheet with two columns: every old URL, and the new URL it will become. Rules that keep it honest:

• Keep URLs the same wherever possible. A redesign does not require new URLs. If the structure is sound, do not touch it.
• One-to-one redirects. Each old page goes to its closest equivalent, not to the homepage or a category. If no equivalent exists, ask whether the page should really be removed.
• No chains. Old → new, in one hop. If an older redesign already left redirects, update them to point at the final destination.
• Include everything the crawl found: images that rank in image search, PDFs, paginated archives, parameter variants that got indexed.
• Test the map on staging with a script before launch, and again in production within the first hour.

Content parity

Pages rank for the words on them. For every URL in the Search Console export with meaningful traffic, the new page should keep — or improve — the topics covered, the questions answered and the depth. Redesign the presentation freely; do not quietly delete the paragraphs that were doing the ranking. Where the new design has less room, move the detail into an expandable section rather than removing it.

Technical parity checklist

Compare the staging crawl against the baseline crawl, URL by URL:

• Title and H1 preserved or deliberately improved (not shortened to fit a card)
• Meta descriptions present and unique
• Canonical tags self-referencing on the production domain — not staging
• Structured data (Organization, Service, Article, FAQ, Breadcrumb) carried over and validated
• Internal links: the pages that had many internal links still have them; the navigation and footer link to the money pages
• Image alt text and file names retained where images ranked
• Hreflang, if used, correct on every page
• XML sitemap regenerated from the new URLs, with real lastmod dates
• robots.txt allows CSS and JS; no stray Disallow from staging
• One canonical host and one URL format, enforced by 301 at the server: www or not, trailing slash or not

Performance parity — or better

A redesign should never make the site slower, and it frequently does: new fonts, bigger images, an animation library, a framework where HTML would do. Agree a performance budget before design — page weight, Largest Contentful Paint, Interaction to Next Paint, third-party script cap — and test templates on a throttled mid-range phone before they are approved. This is how we run every web build, and it is the difference between a launch that gains rankings and one that spends three months recovering them.

Staging safety

Staging sites leak into the index constantly: a shared link, a crawler following it, a developer's portfolio. Protect staging with HTTP authentication, not just noindex — and then make absolutely sure the noindex, the authentication, the staging canonicals and the staging analytics ID are all removed at launch. A checklist with a named owner for each item is not overkill; shipping noindex to production is the most expensive single mistake in this list.

Launch day

1. Deploy in a low-traffic window, with the redirect map loaded and the old site still recoverable.
2. Run the redirect test script against production immediately.
3. Crawl the live site: no 404s, no noindex, canonicals correct, sitemap live.
4. Submit the new sitemap in Search Console; use URL Inspection on the top ten pages to confirm they render and are indexable.
5. Verify analytics and conversion events fire once each.
6. Check Core Web Vitals in the lab on each template; field data will follow.

The eight weeks after

Rankings move after any launch as Google recrawls and re-evaluates. What you are watching for is a problem, not a wobble:

• Search Console → Pages: new "Not found (404)" or "Redirect error" entries mean the map missed something. Fix daily in week one.
• Search Console → Performance: compare clicks by page against the baseline export. A few pages down and a few up is normal; every page down 30% is not.
• Core Web Vitals report: the 28-day field window means the new templates' real numbers appear around week four to five.
• Server logs or analytics: hits to old URLs that are not redirected show up here first.

If traffic drops anyway

Diagnose in this order, because it is the order of likelihood: missing or wrong redirects → changed titles and headings on the affected pages → removed content → a template that is slower or renders content with JavaScript → indexing problems (noindex, canonical, robots) → duplicate live versions of the site. Each has a specific check and a specific fix. "Rankings fluctuate" is not a diagnosis.

A redesign is a migration that happens to include new visuals. Treat it like one — baseline, map, parity, launch checklist, monitoring — and it becomes one of the few changes that reliably gains traffic instead of risking it.