A website rebuild is one of the most expensive decisions a small or mid-sized business makes — and one of the most reliably wrong-headed. We get briefs every month where the brief is "we need to rebuild the site" and the underlying problem is something a rebuild will not fix. We also get briefs where the brief is "we just need a refresh" and the honest answer is that the underlying stack has aged out and a refresh is throwing money at a foundation that will not support it.
This post is the framework we use internally to tell which case a project is in — when to rebuild, when to leave the site alone, and how to do the rebuild without losing the SEO you have spent years earning.
The honest summary
- Rebuild when the site has architectural ceilings that block business goals — performance you cannot reach, integrations you cannot fit, content management that breaks at scale, design that fights the template at every turn.
- Do not rebuild when the visible problem is content, conversion, or strategy — those are cheaper to fix than the rebuild and the rebuild will not address them. A bad message on a new platform is still a bad message.
- Almost never rebuild because the site "looks dated" — design tastes shift faster than infrastructure; a redesign costs a fraction of a rebuild and addresses the actual problem.
- The rebuild-without-losing-SEO playbook is well-known and reliable — the projects that go wrong are the ones that skip steps, not the ones that hit unsolvable problems.
The five signals that justify a rebuild
These are the signs that the stack — not the content, not the strategy, not the brand — is the limiting factor.
1. Core Web Vitals are stuck in the red after real optimisation work
If a competent engineer has spent a real engineering month on Core Web Vitals and the metrics will not move into the green, the architecture is the ceiling. Common cases: a jQuery-era WordPress install with twenty active plugins, a Shopify theme with six analytics tags compounding, a single-page-app marketing site that renders nothing on the server. In each case, the optimisation runway is exhausted and the next dollar buys nothing.
2. Every feature request requires "we'll need to rebuild [X] for that"
This is the diagnostic test. When the marketing team asks for a new page template and the dev response is "the CMS does not support that", when the product team asks for a new integration and the answer is "the current architecture cannot accommodate it", when the design team asks for a modest interaction change and the answer is "the theme would have to be replaced" — the site has hit the limits of its substrate.
A rebuild expands the design space. Patching a site that has aged out is the more expensive way to spend the same money on smaller results.
3. The CMS has become a graveyard
The signs are familiar:
- Twenty active plugins, half of which the team is afraid to update.
- Custom code scattered across functions.php and a child theme.
- Page templates that were duplicated for a one-off launch three years ago and never cleaned up.
- A content team that has built workarounds for limitations nobody can explain anymore.
Each individual decision was reasonable at the time. The compounded result is a system that is more expensive to change than to rebuild — and increasingly fragile under updates.
4. The brand has materially evolved
A serious brand refresh — new positioning, new visual system, new tone of voice — usually requires more than a paint job on the existing site. Templates, components, page structures, even the information architecture often need to follow. At that point, a redesign that fights the existing structure costs nearly as much as a rebuild that starts fresh and ships cleaner.
5. The business model has changed
A consultancy that now sells productised services. A DTC brand that now wholesales. A SaaS that now has a marketing site separate from the product. When the business has fundamentally evolved, the website that was correct for the previous business is rarely the right substrate for the new one. A rebuild is not vanity here — it is alignment with the actual operating model.
The three reasons not to rebuild (even when it feels overdue)
These are the reasons we talk clients out of rebuilds — including out of working with us when the case does not support it.
"The site looks dated"
A redesign costs a third of a rebuild. If the underlying stack is healthy, you do not need a new stack to deliver a fresh look. We have refreshed sites built on five-year-old WordPress installations and Shopify themes that looked entirely new on the same substrate.
"Conversion is low"
A rebuild does not fix conversion. Conversion is a function of messaging, traffic quality, offer, trust signals, and friction in the funnel. A new website with the same problems converts the same. The cheaper test: run a focused CRO sprint on the existing site — better copy, sharper offer, clearer CTAs, faster checkout — and see whether the numbers move. If they do, you did not need a rebuild. If they do not, you have learned something the rebuild also needs to know.
"The CMS is annoying to use"
Maybe. Maybe the CMS needs a focused workflow overhaul — better templates, cleaner editing surfaces, removed unused complexity — that costs a fraction of a rebuild. We have done this for several clients. The CMS gets noticeably better; the underlying stack does not need to change.
The cost of not rebuilding (when you should)
The other failure mode is the opposite: postponing a rebuild that is genuinely needed and paying compounding costs in the meantime.
- Tech debt compounds. Every patch on an aged stack costs more than the equivalent change on a healthy one. The gap widens every year.
- Performance erodes ranking. Sites that cannot pass Core Web Vitals lose marginal ranking positions on competitive queries, and the loss compounds with traffic-share concentration at positions 1–5.
- Talent gets harder to find. A WordPress install from 2018 is increasingly hard to staff. A custom build on a modern stack is easier to maintain because the maintenance talent exists.
- Opportunity cost compounds. Every quarter the rebuild is delayed is a quarter where the marketing or product team is working around limitations instead of leveraging capabilities.
A useful threshold: if you can name three projects this year that were scoped down or skipped because the current site could not support them, the rebuild has already cost you more than its price tag.
The expensive part of the rebuild is not the rebuild. It is the year of workarounds that came before you decided to rebuild.
The rebuild-without-losing-SEO playbook
Done well, organic traffic dips for 2–3 weeks during cutover then recovers to baseline within 6–8 weeks — often surpassing the old site within 3 months on the back of improved Core Web Vitals and cleaner architecture. Done badly, you lose 30–60% of organic traffic for months and never fully recover.
The difference is discipline on five steps:
- URL inventory. Crawl the existing site (Screaming Frog or similar) and produce a complete URL list before any architecture decisions. This is the source of truth for the redirect map.
- Information architecture mapping. Map every old URL to its new equivalent. If a page is being removed, map it to the most relevant nearest page (not the homepage — that is a 301 anti-pattern). Document the cases where multiple old URLs collapse into one new one.
- 301 redirects on day one of cutover. Every old URL → new URL, server-level (not JavaScript), with the correct status code. Test every redirect before launch.
- Schema and metadata preservation. Every page on the new site should have the same or improved metadata (title, description, canonical, schema markup) as the old equivalent. Schema completeness on a rebuild is often better than before — which is part of why rebuilds typically recover above baseline.
- Launch outside peak organic windows. If your peak organic traffic is November, launch in February. The cutover dip is real; pick a window where it costs less.
A few specifics that are easy to get wrong:
- Do not change URL slugs unless you have to. Slug changes are an unnecessary tax on the rebuild. Keep them where you can.
- Submit the new sitemap to Search Console immediately. Do not wait for Google to discover the new structure organically.
- Monitor 404s daily for the first month. Catch the redirects you missed and fix them while the rebuild is fresh.
A simple test for whether you should rebuild
Three honest questions:
- What can you not do on the current site that you need to do? If the answer is a clear list of three or more architectural limits — rebuild. If it is "make it look better" or "improve conversion" — probably not.
- What would change in your business in the 12 months after a rebuild that would not change without one? A clear, specific answer means the rebuild has a business case. A vague answer means it is a cosmetic exercise dressed as infrastructure.
- Is the team ready to commit to the work? A rebuild is a 8–14 week project with significant client-side involvement — content audits, design reviews, stakeholder sign-offs. If the team that owns the brief is not booked for the calendar, the project will slip and the cost will balloon.
The best rebuild is the one you walked away from when the case did not support it. The second best is the one you committed to with clear eyes, a real business case, and the discipline to execute the SEO playbook. The worst is the one you started because the site felt tired and ended six months and a 40% traffic drop later.
Decide on the substrate question first. Everything else is downstream.
