Website Redesign
Redesign the site without throwing away what it already earns
A redesign is a migration wearing a design brief. The pages that bring you traffic today were earned over years, and they can be lost in an afternoon. We benchmark first, map every URL, and stage the change so the improvement does not cost you the asset.
The thing a redesign actually is
A redesign is a migration wearing a design brief. The visual work is the visible half. The half that decides whether you come out ahead is what happens to every URL, every signal and every page that was quietly earning before you started.
This matters because of who is usually in the room. Redesigns are commissioned by people who care about how the business looks and presents, which is entirely reasonable. The risk sits with people who care about crawl paths and redirect chains, and they are frequently not consulted until the build is finished.
We put both in the same conversation at the start. The benchmark, the URL inventory and the redirect map are produced before the first template is designed, not assembled in launch week from memory.
Failure modes
How redesigns lose traffic that was already paid for
None of these are exotic. They are the same four or five things, and every one of them is visible months before launch if anyone is looking.
- Somebody tidied the URLs.
- A workshop decides the structure would read better with different paths. It probably would. But every changed URL is a redirect, every redirect is a small loss and a permanent maintenance obligation, and a site that changes a thousand paths for aesthetic reasons has taken on real risk for no commercial return.
- The pages that earned were rewritten by someone who did not know they earned.
- A copywriter is handed the old site and told to improve it. They shorten a long, detailed page that had been ranking for four years precisely because it was long and detailed. Nobody flagged it, because nobody had a list of which pages mattered.
- Content got dropped rather than migrated.
- Old resources, archived posts and legacy service pages do not make it into the new content model because they did not fit the new templates. They frequently hold the inbound links the whole domain rests on. Deleting them removes the foundation and keeps the building.
- Redirects were written in launch week.
- A map produced under time pressure gets the top fifty pages right and guesses the rest, sending everything else to the homepage. Bulk redirects to the homepage are treated as soft errors and behave, in practice, like deletions.
- Nobody captured a baseline.
- Six weeks after launch there is a disagreement about whether traffic is down. Without a pre-launch benchmark of entrances, rankings and conversions by page and by template, that argument cannot be settled and usually ends with everyone tired and no fix.
How we run it
Benchmark, decide, map, stage, watch
The sequence is what protects you. Design decisions made after the inventory are cheap; the same decisions made after launch are not.
Benchmark before anything changes
Page-level organic entrances, ranking positions for the queries that matter, conversion rate by template, Core Web Vitals field data, and the inbound link profile. Captured, dated and stored so that any later argument has evidence behind it.
You get: Dated pre-redesign benchmark
Decide what to keep
Every URL gets one of four decisions: keep as is, keep and improve, merge into something better, or retire and redirect. Pages that earn are identified explicitly and marked as protected so they cannot be quietly rewritten later.
You get: URL inventory with a decision on every row
Design against the structure, not around it
Templates are designed for the pages that exist and the pages the inventory says should exist. Where the structure genuinely needs to change, it changes on purpose and with the redirect cost understood in advance.
You get: Sitemap, content model and page templates
Author the redirect map early
Written during build, tested on staging with a crawl, checked for chains and loops, and validated against the full historical URL list rather than only what the current sitemap contains.
You get: Tested redirect map and crawl report
Stage the release where it is warranted
Where organic search matters, the new site goes live in tranches with observation between them. If something behaves unexpectedly, you have lost one section for two weeks instead of the entire site for a quarter.
You get: Release plan with rollback positions
Watch, then report against the benchmark
Index coverage, crawl errors, redirect health, performance and conversion in the first weeks, then a written comparison against the pre-launch baseline at 30 and 90 days.
You get: 30 and 90-day comparison against the benchmark
Commitments
What we hold ourselves to on a relaunch
On every redesign we
- Capture and date a benchmark before any content or structure changes
- Produce a decision for every historical URL, not only the ones in the current navigation
- Test the redirect map on staging with a full crawl before launch day
- Protect pages that already earn, and name them explicitly in the brief given to writers and designers
- Report the first 90 days against the benchmark, including anything that went backwards
What we will not do
- Change URL structure for tidiness when there is no commercial reason to
- Bulk-redirect retired pages to the homepage
- Let a copy refresh rewrite a ranking page without a specific reason and a record of it
- Launch on a Friday, or on any day when the people who can fix things are unavailable
- Promise that rankings will be retained in full, because nobody can honestly promise that
Questions
Redesign questions worth asking any agency
Will a redesign hurt our search rankings?
It can, and it is one of the more common ways businesses lose organic revenue. The risk does not come from the visual design. It comes from changed URLs, removed pages, rewritten copy on pages that were ranking, altered internal linking and template-level changes to headings and structured data.
Handled as a migration, most of that risk is controllable. Expect some movement in the first few weeks while the new pages are recrawled and reassessed. A sustained decline three months later is a different thing, and it is usually traceable to a specific decision.
Should we keep our existing URLs?
Yes, unless there is a commercial reason to change them. A URL that has accumulated links and history is an asset, and "it is neater this way" is not a reason to trade that in.
Where the structure genuinely blocks growth — a flat site that cannot express services, industries and locations separately, for example — we change it deliberately, map every old path to a new one, and accept the redirect maintenance that comes with it.
What is a staged migration and do we need one?
A staged migration releases the new site in tranches: one section, or one template, at a time, with a period of observation between each. It is slower and less dramatic than a single cutover.
It is worth it when organic search is a meaningful revenue channel, when the site is large, or when the content model is changing. For a fifteen-page brochure site with little search traffic, a single cutover is fine and cheaper.
How do you decide which pages to delete?
From data, not from tidiness. Every URL gets checked for organic entrances, assisted conversions, inbound links, internal links and whether it serves a query nothing else on the site covers.
Pages that fail all of those get retired and redirected to the closest genuine equivalent. Pages that earn quietly — old resources with links pointing at them, in particular — get kept even when nobody internally remembers writing them.
How long after launch until we know it worked?
Index coverage and crawl errors tell you something within days. Ranking and traffic comparisons are not reliable until roughly four to six weeks, and seasonality means the honest comparison is usually year on year rather than month on month.
Conversion rate is the fastest signal. If the new templates convert better on the same traffic, you can see that inside a fortnight on a site with reasonable volume.
Can you redesign the site without rebuilding the platform?
Often, yes. If the content model is sound and the platform is not blocking your team, a new design system applied to existing templates is a much smaller project with much lower risk.
We will tell you which situation you are in before quoting. Replatforming and redesigning at once is sometimes right, but doing both simultaneously makes it far harder to diagnose anything that goes wrong.
Find out what your current site is quietly earning
Before you commission anything, it is worth knowing which pages produce your enquiries and which of them a redesign could break. We will look at that with you and tell you how much risk the project you are planning actually carries.
If we don't deliver the work we agreed to deliver for reasons within our control, you don't pay for the undelivered work. Read our guarantee
Related
Where to go next
- the full website build serviceWhat a ground-up project involves when a redesign is not enough.
- site speed and Core Web Vitals workA redesign is the cheapest moment to fix performance.
- launching a new website safelyThe same problem framed from the launch side.
- reasons organic traffic falls
- the pre-launch checklist we use
Last updated · Reviewed by Zubair Afzal