Website Design and Rebuilds That Do Not Destroy Your Search Visibility
There is a pattern I have been called in to fix more times than any other. A company invests properly in a new website, the result is genuinely better looking, everyone is pleased at launch, and six weeks later organic traffic is down by half and nobody can explain why.
The design was not the problem. The problem is that a redesign is one of the most destructive things you can do to a site's search visibility, and almost none of the damage is visible to the people approving it. I work alongside your designers and developers to make sure the new site keeps everything the old one earned.
Why Redesigns Lose Traffic
The causes are mechanical, they repeat across almost every project, and every one of them is decided before a single pixel is designed.
The first and largest is URL changes without a complete redirect map. A rebuild almost always restructures URLs, often for good reasons. If every old address does not point to its closest new equivalent, every page that was ranking starts again from nothing, and the accumulated value of years of work is discarded in an afternoon. Partial maps are nearly as bad as none, because the pages usually missed are the deep ones that were quietly earning.
The second is content removed in the name of visual cleanliness. Designers are trained to reduce, and a page with two thousand words of substance is harder to make elegant than one with two hundred. The trouble is that the two thousand words were the reason the page ranked. I have watched a company remove its best-performing page because it did not fit the new layout, then spend a year trying to work out what happened.
The third is rendering. Modern builds frequently move content into scripts that assemble the page in the browser. It looks identical to a person and can be effectively empty to a crawler. This one is particularly dangerous because it passes every visual check and every stakeholder review. The detail is in content that is not crawled because of client-side rendering.
The fourth is internal linking, which almost nobody protects because it is invisible. Old sites accumulate contextual links between pages over years. A rebuild replaces them with a clean navigation menu, and suddenly the pages that were reachable through those links sit several clicks deeper or become orphans. See internal linking architecture and crawl depth.
What I Actually Do on a Website Project
URL architecture and the redirect map
Deciding the structure before it is built, then producing a complete old-to-new mapping with a genuinely relevant destination for every existing URL. This is unglamorous, it is checked line by line, and it prevents more damage than everything else combined.
Content protection
Establishing which pages and which sections of pages are earning, before anyone decides what to cut. The output is a short list of things that must survive the redesign in substance, which lets the design work proceed freely everywhere else.
Rendering and technical review
Confirming that what a crawler receives matches what a person sees, that the important text is in the HTML, and that the build has not introduced speed or markup regressions. Covered further in technical SEO.
Internal linking design
Treating links between pages as a deliberate structure rather than a by-product of the menu. This is where most rebuilds quietly lose their deep pages, and it is straightforward to specify up front.
Structured data continuity
Making sure the markup that existed is rebuilt, accurate and matched to the visible page. Rebuilds routinely drop this entirely because nobody on the project owns it.
Launch and post-launch monitoring
A pre-launch checklist, then close monitoring of indexation, crawl behaviour and rankings for the weeks afterwards, when problems are still cheap to fix and largely invisible in analytics.
When to Bring Me In
The pre-launch checklist:
- A complete old-to-new URL map, with a relevant destination for every existing address
- The list of pages and sections that must survive in substance, agreed and honoured
- Rendered HTML confirmed to contain the content a person sees
- Internal linking specified deliberately rather than left to the navigation
- Structured data rebuilt, accurate, and matching the visible page
- Page speed measured against the current site, not against an aspiration
- Analytics and Search Console continuity, so you can actually see what happens after launch
- A monitoring plan for the first eight weeks, when problems are cheapest to fix
How This Works With Your Design Agency
I am not replacing anyone. The most common version of this is me sitting alongside a studio doing excellent work in a discipline that simply does not include any of this.
Your agency owns the design
Brand, visual direction, user experience, art direction and build quality stay entirely with them. I have no useful opinion on your typography and will not pretend otherwise.
I own the visibility decisions
URL structure, redirects, content that must survive, rendering, internal linking and structured data. These are engineering and strategy decisions that happen to live inside a design project.
The overlap is small and specific
In practice it is a handful of constraints handed over early, a few reviews during build, and a launch checklist. It is not a parallel workstream and it should not feel like one.
Nobody is being marked
Agencies are usually relieved rather than defensive, because losing a client's traffic after a launch is a bad outcome for them too and it is rarely something they had the specialist knowledge to prevent.
If You Are Starting From Nothing
Everything above assumes an existing site with something to protect. A new build has no rankings to lose, which removes the risk and introduces a different opportunity: getting the foundations right at the only point where they are nearly free.
Retrofitting a sensible URL structure onto a live site is a redirect project. Deciding it before launch costs nothing. The same is true of crawlable rendering, a deliberate internal linking structure, structured data generated at template level, and analytics configured to answer real questions. Each is straightforward at the start and expensive once there is traffic depending on the current arrangement.
This is also the right moment to decide what the site is actually for in search terms: which pages are meant to earn, what they need to contain, and how somebody arriving on each one is supposed to move forward. That is a strategy conversation, not a build task, and it is the difference between a website that looks finished and one that starts compounding. See how I work as a consultant and the underlying SEO programme.
The Migration, Step by Step
A domain change, a platform change or a restructure is the highest-risk thing you can do to a site. It is also entirely survivable when it is sequenced properly.
The pattern in that sequence is that almost all of it happens before launch. Migration recovery work is expensive precisely because it is reconstructing decisions that would have cost very little to make correctly in the first place. The recovery version is covered in URL pruning and redirects without losing traffic.
Speed Is a Design Decision Before It Is an Engineering One
Page speed gets treated as something developers fix at the end, and by then most of it has already been decided. The weight of a page is largely determined by choices made during design: how many typefaces, how much imagery, whether there is video above the fold, how many third-party tools are embedded, and whether animation is doing anything useful.
None of those are engineering failures. They are design and marketing decisions with performance consequences that nobody quantified at the time. A developer handed a design containing four custom fonts, an autoplaying background video and six tracking scripts can optimise the delivery of all of it and the page will still be slow, because the problem is the payload rather than the plumbing.
The fix is to make the cost visible while the decisions are still cheap. A performance budget agreed at the start, in terms designers understand, turns an argument at the end of the project into a constraint at the beginning. It also tends to produce better design, because most of what gets cut was not contributing much.
Fonts
Each additional weight and family is another blocking request. Two families and three weights is usually plenty and the difference from five is imperceptible to everyone except the designer.
Imagery and video
The largest single contributor on most sites. Correct formats, correct dimensions and genuine lazy loading below the fold, decided as a rule rather than negotiated per page.
Third-party scripts
Analytics, chat, heatmaps, consent tools, personalisation and testing all queue up in the same place. Each is individually defensible and collectively they are frequently the reason a site is slow.
Above the fold
What has to be ready before anything else can happen. Keeping this deliberately small does more for perceived speed than any amount of optimisation further down the page. See Core Web Vitals at template level.
What a Good Website Brief Contains
Most of the damage I get called in to repair traces back to a brief that never mentioned any of this.
The pages that must survive
Named explicitly, with the sections of them that are load-bearing. Designers cannot protect content they were never told mattered, and they are almost never told.
The URL structure, agreed up front
Decided before the sitemap is signed off rather than emerging from whatever the platform defaults to. Changing it later is a redirect project.
A performance budget
Expressed as a target on real devices and real networks, with the trade-offs named. This is the single most useful line in a website brief and it is almost always absent.
Who owns search decisions
A named person with the authority to say that a proposed change will cost traffic. Without that, the decision defaults to whoever feels most strongly in the room.
Website Design and SEO Questions
Do you build websites?
I am not a web design studio and I do not compete with one. I work alongside the designers and developers building your site, owning the decisions that determine whether it keeps its search visibility: URL structure, redirect mapping, what content survives, how navigation and internal links are built, and how the whole thing is rendered. Most agencies do excellent visual work and have no reason to know any of that.
Why do websites lose traffic after a redesign?
Almost never because of the visual design. The usual causes are mechanical: URLs changed without a redirect map, content cut because it looked cluttered, text moved into scripts that crawlers cannot read, internal links replaced by a tidier menu, and structured data lost in the rebuild. Each is preventable before launch and painful to reverse afterwards.
When should you be involved in a redesign?
Before the sitemap is signed off, which is far earlier than most people expect. The decisions that cause traffic loss are made during planning, not during build. Being brought in a week before launch means auditing damage rather than preventing it, which costs more and recovers less.
Can you fix a redesign that has already gone wrong?
Usually a large part of it. Recovery starts with comparing what ranked before against what exists now, rebuilding the redirect map, restoring content that was removed and repairing the internal link structure. How much comes back depends on how long the site has been in the broken state and whether the old URLs are recoverable.
What about a new site with no existing rankings?
Different job, same principles applied earlier. There is nothing to protect, so the work is making sure the build starts with a sensible URL structure, crawlable rendering, a real internal linking plan and the technical foundations in place, rather than retrofitting all of it in year two at several times the cost.
Do you work with any platform or CMS?
Yes, though the specific traps differ. Headless and JavaScript-heavy builds bring rendering problems, page builders bring bloat and template-level performance issues, and hosted platforms bring URL structures you cannot fully control. The principles hold everywhere, the implementation details do not.
Related: redesign recovery, technical SEO, redirects without losing traffic, crawl depth and site architecture, Core Web Vitals at template level, and conversion rate optimisation.
Planning a rebuild, or trying to work out what a launch just cost you?
The decisions that determine whether a redesign keeps its traffic are made before anything is designed. If you are already live and the numbers have fallen, most of it is usually recoverable.
Book a Free Strategy CallGet an SEO Audit
