Website Redesign SEO: How Not to Lose Traffic in the Rebuild

The SEO work sits before the build, not after it. That is the whole argument.

Nobody loses rankings over a new colour palette.

They lose them because the new template has 200 words where the old page had 900. Because four service pages became one. Because the URL structure was tidied up on a Tuesday and nobody wrote down the old paths.

Every one of those decisions is made weeks before a developer touches the code. This page puts the SEO work back where it belongs in the timeline, assuming the fundamentals in our SEO guide are already in place: benchmark, design review, redirect map, launch day, first 30 days.

One honest note. Nobody can promise a redesign with zero movement — Google's site-move documentation says visibility may fluctuate temporarily and that this is normal. The goal is a dip that is shallow and recovered.

Why a redesign loses more traffic than a migration

Redesigns lose traffic because nobody labels them migrations. A domain move gets a project plan, a redirect map and a rollback option. A redesign gets a Figma link and a launch date — while the URLs, the copy, the internal links and the rendering all change anyway. Note the third column: almost every expensive decision is taken before development starts.

If the redesign also changes the name or the domain, that is a second project stacked on this one: read our guide to rebranding without losing traffic alongside this page, and never ship both on the same day.

Stage 1 — Before design: benchmark what you have

You cannot prove damage you did not measure. Before a wireframe exists, export five things and store them outside the CMS you are replacing.

1. A full crawl of the live site. Every URL with its status code, title, H1, canonical, word count and indexability. Your "before" photograph — it stops existing the moment the rebuild starts.
2. Top pages by impressions and clicks. Twelve months from the Search Console Performance report, which opens on the last three months — widen the range before you export (Search Console Help, read 28 September 2026 — no published last-updated date).
3. The queries each page earns. Not just the keyword you think it targets. Save the query list per page: it tells you which sentences are load-bearing.
4. Pages with external links pointing at them. Where a missing redirect costs most.
5. Conversions and revenue per page. A quiet page with three enquiries a month matters more than a high-traffic one. Sort by this column, not sessions.

Record clicks and impressions as the baseline. Treat average position as a drifting average — Search Console's Help pages explain the chart figure is the average position of the topmost result from your whole site, so a one-place "drop" after launch is noise. On a large site the crawl also shows how much of it Google bothers with, which changes how fast a rebuild gets re-indexed — see what moves crawl budget.

Then do the inventory nobody enjoys. Every URL gets one of four decisions — keep, update, merge, remove — and the redesign inherits them rather than inventing them later. That is exactly the scoring in our content audit guide.

Stage 2 — During design: four decisions that quietly destroy rankings

These four get agreed in design reviews as aesthetic choices, never as SEO decisions. Each has a fix that costs nothing before sign-off and a lot afterwards.

• Dropping page copy for a cleaner look. The new hero is beautiful and the page is 180 words. Those 900 words were not padding — they were why the page matched a hundred long-tail queries. If the copy cannot sit above the fold, move it down; do not delete it.
• Collapsing several ranking pages into one. Sometimes right: three thin pages competing for one topic should merge. Sometimes a self-inflicted wound: two pages ranking for two different intents merged into one that serves neither. Decide per page from the query lists, redirect the losers, and point the canonical at the survivor — our canonical tags guide explains why a canonical is a consolidation signal, not a substitute for a redirect.
• Moving text into images, or into JavaScript that renders late. Google crawls, then renders, then indexes, and a page queued for rendering "may stay on this queue for a few seconds, but it can take longer than that". The same doc recommends server-side or pre-rendering anyway "because it makes your website faster for users and crawlers, and not all bots can run JavaScript" (Google Search Central, last updated 4 March 2026). Ask one question in the build review: does this text exist in the HTML the server sends?
• Changing the URL structure for tidiness. "/services/seo-services/" to "/what-we-do/seo/" buys a neater sitemap and a redirect for every page on the site. Change URLs only when they are genuinely broken: session IDs, dates on evergreen posts, a structure nobody can navigate.

Fix performance while the templates are still open — the cheapest moment in a site's life to do it. Google's page experience documentation says "Core Web Vitals are used by our ranking systems" while being explicit that "there is no single signal" (Google Search Central, last updated 22 September 2026). Treat it as a build standard, not a ranking lever — what the three metrics measure and how to make pages faster belong in the developer's brief, not a post-launch ticket queue.

Stage 3 — Before launch: the redirect map

A redirect map says where every old URL now lives. Build it from the stage 1 crawl, one row per URL, mapped to the closest real equivalent — never everything to the homepage. Google's site-move documentation warns against redirecting many old URLs to "one irrelevant single URL destination, such as the home page of the new site", because it "can confuse users and might be treated as a soft 404 error" (Google Search Central, last updated 20 August 2026).

Use permanent server-side redirects. Google's redirects documentation says the indexing pipeline treats a permanent redirect "as a signal that the redirect target should be canonical", while a temporary one keeps the source page in results, and it ranks methods "by how likely Google is able to interpret correctly" with server-side at the top (Google Search Central, last updated 14 April 2026).

Copy this shape into a sheet.

What a redirect does and does not preserve

Redirects are the most over-trusted object in a redesign.

A permanent redirect does: tell Google the target should be canonical, carry the signals from links pointing at the old address, and keep users, crawlers and old bookmarks off a dead end.

A permanent redirect does not: make a thinner destination rank for what the old page ranked for; work instantly, since for medium-sized sites Google says "it can take a few weeks or more"; update external links, which still need chasing; or fix internal links, which should point at the final URL, not travel through a chain.

Then keep them — Google's site-move guidance says to hold redirects "for as long as possible, generally at least 1 year". The map is a document you hand over at launch, not one you delete at the retro. It is the part of a rebuild we take over most often inside our SEO services: the one deliverable that must exist before the developer deploys.

The one mistake that takes an entire site off Google

Shipping the staging site's crawl block to production. Invisible to everyone admiring the new design, and it surfaces a fortnight later when someone finally looks at the traffic graph.

Staging gets blocked two ways, and they fail differently. A noindex left in the template means your pages are crawled and then deliberately dropped. A Disallow: / in robots.txt means Google cannot fetch them at all.

Both at once is the nastiest version. Google states that "for the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file" (Google Search Central, last updated 10 December 2025), so a blanket Disallow hides a template-wide noindex nobody has seen take effect. Remove the Disallow at launch, forget the noindex, and it goes live.

Note also that robots.txt "is not a mechanism for keeping a web page out of Google": "a page that's disallowed in robots.txt can still be indexed if linked to from other sites" (Google Search Central, last updated 10 December 2025). Password-protect staging instead; our robots.txt guide covers what the file is for.

The one-minute check

Run this on launch day, before you announce anything.

1. Open the new homepage, view source, and search the HTML for:  noindex
2. Check the response headers on the same URL for:  X-Robots-Tag
3. Open yourdomain.com/robots.txt and look for:  Disallow: /
4. Repeat 1-3 on one product page, one blog post and one category page
5. In Search Console, run URL Inspection and press "Test live URL" on those four
6. Read two fields only:  "Crawl allowed: Yes"  and  "Indexing allowed: Yes"

One trap in step 6, from Search Console's Help pages: "if your page is blocked by robots.txt, then Indexing allowed will always be Yes because Google can't see and respect any noindex directives" (Search Console Help, read 28 September 2026 — no published last-updated date). So read "Crawl allowed" first, always.

Stage 4 — Launch day: the order of operations

Sequence matters more than speed. Redirects and crawl access come before the announcement, because the first crawl sets Google's understanding of the new site.

1. Deploy the redirects first. Server-side, permanent, live before anything is announced.
2. Remove every crawl block — template noindex, X-Robots-Tag headers, robots.txt Disallow — then run the one-minute check above.
3. Submit the new XML sitemap in Search Console, leaving the old one available briefly so Google re-crawls the old URLs and finds the redirects.
4. Spot-check 20 redirects by hand, from your highest-impression and highest-link URLs. One chain or loop there usually means a pattern-level bug.
5. Verify tracking fired. Tags get rebuilt with the templates and silently die with them. Test a real form submission, not the tag preview.
6. Update internal links to final URLs — navigation, footers, in-content links, anything hard-coded in the templates.
7. Re-check canonicals and titles at scale. One template bug — every page canonicalising to the homepage — does more damage than any design decision above.
8. Start the log. Record status-code errors and 404 hits daily. A redesign's real damage lives in the 404 log, readable weeks before rankings move.

Stage 5 — The first 30 days: normal fluctuation vs a real problem

Google's site-move guidance says to "expect temporary fluctuation in site ranking during the move" and that this is normal. That is your defence against a panicked rollback in week one — not permission to stop watching.

Do not rewrite content in week two. You cannot separate a template problem from a settling period while both are happening. Fix redirects, crawl access and tracking; everything else waits until the crawl catches up — which for a medium-sized site, in Google's words, can take "a few weeks or more".

If recovery stalls, keep the honest baseline in view: organic work runs on a three-to-six-month horizon to meaningful results, and a redesign resets part of that clock.

Where to go from here

Every redesign that went badly shares one pattern: the SEO conversation happened after a decision, not before it. Fix the calendar, not the checklist.

• Run the benchmark exports before the design brief is signed — not before the build, before the brief.
• Put someone with Search Console access in the wireframe review, able to say "that paragraph stays".
• Make the redirect map a deployment blocker, owned by a named person.
• Book the one-minute crawl-block check into launch day as a task, not a good intention.