We don’t rebuild websites page by page. We rebuild the system behind them.
A redesign changes what the site looks like. A rebuild changes what it can explain, what it can support, and what search systems can understand about the business.
The reasons that actually come up.
Almost nobody rebuilds because they want a new website. They rebuild because something stopped working and the site is in the way of fixing it.
It describes a smaller, simpler business than the one that exists now.
Every edit risks breaking something, so nothing gets edited.
Profitable services have a sentence where they need a page.
Pages compete for the same searches and none of them win.
Hosting, theme or builder can’t support what comes next.
Traffic dropped after launch and never came back.
A better-looking version of the same structure changes very little.
If the problem is that five services share one page, a new colour palette does not solve it. If the problem is that the site never mentions half the work the company takes on, neither does a new hero image.
We start from the existing site and work out what it currently explains, what it leaves out, and which parts are already doing real work. Only then is it possible to say what the architecture should become.
What we read before we design anything.
Everything the company actually does, ranked by what it wants more of.
Where the work genuinely comes from, and where it realistically could.
What people ask before they are ready to call.
Knowledge that exists in the team and nowhere on the site.
Projects, credentials, reviews and history that can be shown honestly.
How somebody actually gets from reading to contacting.
What is worth keeping, what needs depth, what should go.
What other results already explain that this site doesn’t.
From a search to a phone call.
Somebody searches a symptom, lands on a page, decides whether the company handles their kind of problem, and either contacts you or goes back. Every step of that is a structural decision, not a design one.
We map the route before building it — which page answers the question, what it connects to, and where the obvious next action sits.
Before we decide what should change, we determine what should not be lost.
An established site has earned things: indexed URLs that rank, pages other sites link to, content that answers a question well enough that people keep finding it, and familiarity with your own customers. None of that appears on a design mockup, and all of it can be discarded in an afternoon.
So the inventory comes first — every URL, what it earns, what points at it — and the redirect map is written against the real list rather than the intended one. Where a URL doesn’t need to change, it doesn’t change.
The unglamorous list that decides whether a launch goes well.
Unchanged where possible; permanently redirected to the closest equivalent where not.
Existing chains and loops inherited from earlier rebuilds get resolved, not extended.
Titles and descriptions that already work are kept, not regenerated.
What the site declares about itself, rebuilt to match what is visible.
The relationships between pages, deliberately reconstructed.
Measurement continuity, so before and after can actually be compared.
Tested by sending real submissions, not assumed.
Checked on launch day and again a week later.
Search, local and answer engines are reading the same thing.
Technical health, service structure, local relevance and the questions customers ask are not separate projects. They are the same body of evidence, read by different systems.
Google’s published guidance for AI experiences is unusually plain about this: there is no special markup and no separate optimisation track — the advice is the same as for Search. Which is convenient, because it means one job done properly rather than four done partially.
Research, build, validate, launch, verify.
Work is built and reviewed away from the live site. Changes are tested before they ship, not after. Launch day has a checklist, and the week after launch has one too — because a missed redirect shows up in Search Console long before it shows up in a conversation.
A drop after launch is treated as a fault to diagnose, never as a phase to wait out.
This is where the work goes.
These frames are reserved for real material from real projects: the site before and after, the architecture that replaced it, the measured technical change, and the verification carried out at launch.
They are empty because we only publish evidence we have permission to publish. Nothing here is a mockup of results, and no figures are shown until there are approved ones to show.
Presentation frame. Approved project evidence will be placed here.
A rebuild is the start of the maintainable phase, not the end of the project.
Indexing is checked. Links are crawled. Forms are tested by sending one. Performance is measured rather than assumed. Then the site is watched weekly for a month, because that is when a missed redirect surfaces.
After that, the question becomes how the site keeps matching the business as the business moves — which is a different service.
Start with what the current site has already earned.
Before we recommend a rebuild — or recommend against one — we want to understand what the business does and what the existing site is already doing well.
Typical investment
Typical timeframe: 4–10 weeks
A rebuild is scoped around the actual system rather than a page count, which is why the range is a range.