Websites · 8 min read
Six signs you need a new website, and four that mean something cheaper will fix it
A rebuild is the most expensive answer available and the one most often reached for. Some problems genuinely require it: an unsupported platform, an architecture that cannot express what you now sell, a site nobody can change without buying developer time. Most of the reasons people give are not on that list.
Written by Zubair Afzal, FounderUpdated
Before the symptoms
The most expensive answer is the one most often reached for
A new website is the largest available intervention, it takes months, and it resets nothing except your own cost base. It is also the first thing suggested when a business feels its marketing is not working, partly because it is visible and partly because it is what the people being asked happen to sell.
That is not an argument against ever rebuilding. Some problems are genuinely structural and no amount of careful work on the existing site will reach them. It is an argument for establishing which kind of problem you have before committing the budget, because the two categories look identical from the outside and cost very different amounts to fix.
The distinction we use is simple. Anything to do with what the site says, how it looks, how fast it loads or how well it converts is almost always fixable in place. Anything to do with what the site is built on, how it is structured, and who can change it usually is not.
Genuine reasons
Six symptoms that do justify a rebuild
Each of these is structural: the problem is produced by how the site is built rather than by what is on it, and work on the existing site cannot reach it.
- Nobody in the business can change a page without buying developer time.
- This is the clearest structural signal there is. If a paragraph change needs a quote and a two-week wait, the site stops being updated, and a site that stops being updated stops being accurate. The cost is not the developer invoice; it is every improvement nobody bothered to request.
- The platform is unsupported or cannot be patched.
- An end-of-life content management system, a framework version no longer receiving security updates, or a bespoke build whose original developer is unreachable. This is a security exposure with a deadline attached rather than a marketing preference, and it does not improve by waiting.
- The structure cannot express what the business now sells.
- The site was built for three services and you now have eleven, or for one country and you now operate in four, or for a product catalogue that has since acquired variants, categories and relationships the templates cannot represent. Adding pages into a structure that cannot hold them produces navigation nobody can follow.
- Accessibility failures are built into the templates.
- Colour contrast and alternative text can be corrected on any site. Keyboard navigation order, focus management, form labelling and heading semantics generated by a page builder frequently cannot, because you do not control the markup it emits. Where the failures are structural, remediation costs more than replacement and still leaves you constrained.
- The mobile experience is effectively a separate, worse site.
- A distinct mobile version with less content, a different structure, or interactions that only work with a mouse. Most visits are on a phone, so this is not a secondary consideration, and it is usually a consequence of an architecture that predates the assumption.
- The site has to do something it was never built to do.
- Take payment, hold accounts, integrate with an operational system, serve several languages properly, or publish at a volume the current setup cannot handle. This is a change in requirements rather than a fault, and it is the most defensible reason on this list because the case can be written down in terms of what the business needs to be able to do.
Rebuild, redesign or fix in place
Three interventions of very different size, frequently discussed as though there were only one. The middle option is the one most often skipped.
| Dimension | Rebuild | Redesign on the same platform | Fix in place |
|---|---|---|---|
| What it changes | Platform, structure, templates and content model. Effectively a new site. | Visual design, templates and page structure, on the existing platform and content model. | Specific pages, copy, images, speed, forms and conversion paths. |
| What it can actually fix | Editability, unsupported technology, structural accessibility, architecture and new capabilities. | Presentation, navigation, message, layout and conversion, without touching the foundations. | Speed, clarity, messaging, forms, individual page performance and most conversion problems. |
| Risk to existing search performance | Highest. URLs, content and structure all change at once, so it is a migration whatever it is called. | Moderate and manageable if URLs are preserved and content is not silently dropped. | Low. Changes are incremental and individually reversible. |
| Typical elapsed time | Months, and content is usually the constraint rather than development. | Shorter, because the platform, integrations and content model already exist. | Days to weeks per change, running continuously rather than as a project. |
| When it is right | When the foundations are the problem: the platform, the editability, the architecture or a new capability. | When the foundations are sound and the presentation, structure or message is not. | When the site works and specific pages or journeys underperform. |
| The failure mode | Spending a large budget to arrive at the same content and the same problems in a nicer wrapper. | Discovering mid-project that the platform cannot support what the design assumes. | Patching indefinitely around a foundation that genuinely does need replacing. |
A worked example
Speed is the symptom people most often misread
These are the published Core Web Vitals thresholds, assessed from real visits rather than from a testing tool. Failing them is a strong signal — and a weak argument for a rebuild.
- Largest Contentful Paint threshold for a good rating
2.5s
Largest Contentful Paint threshold for a good rating
Source: Google, web.dev: Core Web Vitals
- Interaction to Next Paint threshold for a good rating
200ms
Interaction to Next Paint threshold for a good rating
Source: Google, web.dev: Core Web Vitals
- Cumulative Layout Shift threshold for a good rating
0.1
Cumulative Layout Shift threshold for a good rating
Source: Google, web.dev: Core Web Vitals
These are assessed from real visits on real devices, which is why a build can pass every synthetic test and still fail the measurement that counts, and why a low score in a testing tool is a prompt to investigate rather than a verdict.
The reason this belongs in an article about rebuilding is that failing these thresholds is regularly presented as proof that a site is finished. It usually is not. The common causes — oversized images, a stack of third-party tags, slow server response — are all fixable without replacing anything. Rebuild only when the slowness is produced by how the pages are constructed, which is a diagnosis somebody should make and show you rather than assert.
Not reasons
Four symptoms that point somewhere cheaper
These are real problems. None of them is evidence that the foundations need replacing, and each has a smaller intervention that addresses it directly.
- It looks dated. A visual refresh on the existing platform addresses this, and the honest first question is whether looking dated is costing anything measurable or mainly bothering the people who work there.
- A competitor launched a new site. Their build says nothing about your foundations. If theirs converts better, find out which specific thing is doing that and copy the idea rather than the project.
- Organic traffic dropped. Rebuilding a site during an unexplained decline destroys the evidence and adds a migration to an existing problem. Diagnose the drop first; it is very often unrelated to the site itself.
- The site produces no enquiries. Usually a traffic-quality, message-match or friction problem, all of which are testable on the current site for a fraction of the cost. Rebuild after that work, if it is still needed, with better information about what to build.
Questions
Questions people ask before committing to a rebuild
How often should a website be replaced?
There is no correct interval, and replacing on a schedule is how businesses buy the same problems again. A well-built site on a maintained platform with a clear structure can serve for many years with periodic work.
Replace when something structural is genuinely blocking the business — the platform, the architecture, the ability to change it, or the way it fails people using assistive technology. Not because a number of years have passed.
Our site is slow. Is that a reason to rebuild?
Rarely on its own. Most slow sites are slow because of large uncompressed images, a stack of third-party scripts, and hosting that takes a long time to respond, and all three are fixable without touching the design.
It becomes structural when the slowness is produced by how the pages are built — a page builder emitting deeply nested markup, or a front end that renders nothing until a large bundle has downloaded and executed.
Will a new website improve our rankings?
Not by itself, and a redesign carries genuine risk in the other direction. Search performance follows content, structure, links and technical health. A new site can improve those, and it can also lose them if URLs change without a proper map.
If search performance is the reason for the project, the work that produces it should be specified explicitly. A visual refresh alone will not do it.
The site looks dated next to our competitors. Is that enough?
It is a real consideration in categories where visual credibility affects whether people take you seriously, and it usually does not require a rebuild. A visual refresh on the existing platform — typography, spacing, imagery, the key page templates — addresses most of it.
The question worth asking is whether looking dated is costing you anything measurable, or whether it is mainly uncomfortable for the people who work there. Both are legitimate. They justify very different budgets.
How do we decide between rebuilding and fixing?
Ask whether the problem is in the content and presentation or in the foundations. Content, layout, messaging, images, speed and conversion are almost always fixable in place. Platform support, architecture, editability and structural accessibility usually are not.
If the honest answer is a mixture, sequence it: fix what is fixable, measure what changes, and let that evidence size the case for a rebuild instead of assuming it.
Get a straight answer about whether you need one
We will look at your site and tell you which of the three options fits — including the frequent case where the answer is that the site is fine and the problem is elsewhere. We would rather say that than sell a build that will not help.
Last updated