How to Redesign a Website Without Losing Your Search Traffic

There is a familiar sequence. A company redesigns its website. The new site is better in every visible way. Six weeks later organic traffic is down 40% and nobody can explain it, because the pages look better and the content is, if anything, clearer.

The design is almost never the cause. Four other things are, and all four are preventable with work done before launch rather than after.

The four things that actually cause the drop

URLs changed and redirects did not. The most common cause by a distance. A new CMS, a new information architecture, a tidier URL pattern — each one orphans addresses that Google has indexed and other sites link to.

Content was cut for tidiness. Designers and stakeholders both like clean pages. The 900-word section that ranked for forty long-tail queries reads as clutter in a wireframe, and it disappears. So does the traffic it earned.

Internal links vanished into components. The old site linked from a blog post to a service page in body copy; the new site replaced that with a card component that links to a hub. Individually invisible, collectively a large change in how authority flows through the site.

Technical foundations were rebuilt from scratch and half of them were missed. Metadata, canonical tags, structured data, sitemap, robots directives, hreflang. Every one is something the old site had and the new one has to be given deliberately.

Before design starts: build the inventory

You cannot protect what you have not counted. Two weeks before anyone opens a design tool, produce three lists.

1. Every URL that exists. A full crawl, joined to analytics and Search Console data. For each URL: sessions, entrances, conversions, impressions, clicks, and the number of referring domains.

2. The pages that earn. Sort by organic entrances and by referring domains. The top 20% of URLs will usually account for the overwhelming majority of both. These are non-negotiable: they either survive with the same URL, or they get a redirect and a deliberate decision.

3. The pages with links pointing at them. A page with few visits and thirty referring domains is a valuable asset. Delete it and you throw away authority you will not get back.

Share all three with the design team at kickoff. A designer who knows that a particular page carries 200 links will treat it differently from one who sees a low-traffic page cluttering the navigation.

During design: the rules that protect the asset

Keep URLs unless there is a reason to change them. A prettier URL structure is not a reason. Search visibility is expensive to earn and cheap to lose; a URL change trades a certain cost against a cosmetic gain.

Preserve the substance, not the layout. A page can be redesigned entirely as long as the content that answers the query survives somewhere on it. Content preservation is a design constraint, and stated as one it is rarely controversial.

Map old sections to new. For every page in the top 20%, list its headings and confirm where each one lands. This exercise routinely catches an entire FAQ block or specification table that had been quietly dropped.

Keep body links in body copy. Component-based design tends to move links into cards and modules. Keep contextual links inside prose, where they carry the most weight — and where users actually follow them.

Set performance and accessibility targets at design time. LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 at the 75th percentile, and WCAG 2.2 AA. These constrain hero treatments, font loading, animation and colour choices, and they are far cheaper as constraints than as remediation. Retrofitting either after launch is the most predictable avoidable expense in a redesign.

Before launch: the redirect map

This is the deliverable that decides whether the launch goes well, and it should be signed off like any other.

1. One row per old URL. Every one from the crawl, not just the ones in the navigation.
2. A single destination for each, as close in meaning as possible. Redirecting a deep page to the home page is functionally a deletion.
3. 301, permanent, not 302. Temporary redirects tell search engines to keep the old URL.
4. No chains. Old A to new B, never A to B to C. Chains lose value and slow every visit.
5. Test in staging with the real list. Run the crawler against staging using the old URL list and confirm every row resolves in one hop with a 200 at the end.
6. Keep the redirects forever. Removing them a year later re-creates the problem you avoided.

Alongside the map, run a parity check: metadata for every priority page, canonical tags present and self-referencing, structured data types that existed before still present, XML sitemap regenerated and submitted, and analytics and conversion tracking verified with a real test transaction.

Launch day and the thirty days after

Within an hour: check robots.txt, spot-check the noindex tag on templates, submit the new sitemap, and manually test twenty redirects across the site including the strangest URLs on the list.

Within a week: watch Search Console coverage for a spike in 404s, crawl the live site and compare against the pre-launch crawl, and check that internal linking density on priority pages did not collapse.

Weeks two to four: expect fluctuation. Some ranking movement is normal while pages are re-crawled and re-evaluated, and a modest dip that recovers is not a failure. What is not normal is a steady decline, or losses concentrated on pages whose URL changed — that points at the redirect map.

At thirty days: compare like for like against the same period last year rather than last month, so seasonality does not tell you a story that is not there.

When you should change URLs anyway

There are legitimate reasons: a genuinely broken structure, a platform change that forces it, a consolidation of duplicated sections, or a move to HTTPS or a new domain. In those cases the answer is not to avoid the change, it is to do it once, map it completely, and avoid stacking it with three other changes so you can see what caused what.

Where possible, separate the redesign from the replatform, and both from a content restructure. Sequential changes are diagnosable. Simultaneous ones are not.

Questions we get asked

How long do redirects need to stay in place? Indefinitely. They cost nothing to keep and removing them re-orphans every external link pointing at the old address.

Should I launch all at once or in phases? Phased launches are lower risk for large sites and more work for everyone. For most business sites a single launch with a properly tested redirect map is fine; for large e-commerce catalogues, phasing by section is worth the overhead.

Will a redesign improve rankings on its own? Only through its side effects — better performance, better internal linking, better content. Design alone is not a ranking factor, and a redesign that ignores the four causes above will cost you more than it earns.

We already lost traffic after a redesign. Can it be recovered? Usually, and the first thing to check is the redirect map — most recoveries we run are 404 audits, redirect repairs and restoring content that was cut. It is faster than the original loss suggests, provided it is diagnosed rather than guessed at.

Who owns what

Redesign traffic losses are usually organisational rather than technical: everyone assumed someone else was handling the redirects. Name four owners at kickoff.

• The inventory owner keeps the URL list, the analytics join and the redirect map, and signs off that every priority URL has a destination.
• The content owner confirms, page by page, that the substance of every top-20% page survived the redesign.
• The technical owner is accountable for metadata, canonicals, structured data, sitemap, robots directives and the staging-to-production checklist.
• The measurement owner verifies analytics and conversion tracking on the live site with a real transaction, and runs the 7-day and 30-day comparisons.

One person can hold more than one of these roles. What cannot happen is a role held by nobody, which is the state most redesigns launch in.

Redesigns are worth doing. They are worth doing with the inventory in hand, which is how our interface and experience design work runs alongside technical SEO rather than ahead of it.