A website can look old and still work. It can also look modern while quietly losing enquiries because the structure, forms, tracking or platform underneath it is failing.
That is why “we need a new website” is often the wrong starting point.
The better question is: what exactly is broken, and how deep does the fix need to go?
For most business websites, there are three different jobs hiding behind the word redesign: repair the current site, redesign the experience while keeping a healthy foundation, or rebuild because the foundation itself is now the constraint.
The short answer
Repair when the business model, platform and information architecture still make sense, but specific things are broken.
Redesign when the technical foundation is healthy but the website no longer communicates clearly, guides visitors well or reflects the level of the business.
Rebuild when the existing platform, codebase, ownership setup, content architecture or integrations make meaningful improvement harder than starting from a controlled foundation.
The cheapest option is not always the smallest project. Repeatedly patching the wrong foundation can cost more than rebuilding once. But rebuilding a healthy site simply because the design feels dated can also waste money and create unnecessary SEO risk.
Start with the business problem, not the design
Before discussing colours, layouts or frameworks, identify what the website is failing to do.
A service business may have traffic but very few qualified enquiries. A hotel may depend on third-party platforms because its own booking journey is weak. A consultant may have a credible offer but a website that makes visitors work too hard to understand it. A growing company may be unable to edit basic content without calling the original developer.
Those are different problems. They should not automatically receive the same solution.
I separate the diagnosis into five layers:
- Commercial: Is the site attracting and converting the right people?
- Content: Can a visitor quickly understand the offer, proof and next step?
- Experience: Do mobile journeys, navigation, forms and calls to action work cleanly?
- Technical: Is the site fast, secure, maintainable and correctly integrated?
- Ownership: Does the business control its domain, repository, hosting, analytics and other critical accounts?
The deeper the problem sits, the more likely a rebuild becomes reasonable.
Repair the website when the problem is isolated
Repair is usually the right first move when the site has a sound foundation and a limited set of failures.
Examples include a contact form that no longer delivers enquiries, broken mobile navigation, one slow template, missing analytics, a specific booking or payment defect, or technical SEO problems that do not require changing the whole architecture.
This is where diagnosis can save money. If the underlying system is healthy, replacing everything is unnecessary.
A useful test is: if the broken component were fixed tomorrow, would you still want to replace the rest of the site? If the answer is no, start with repair.
If you are dealing with an abandoned or partially broken build, see what to do when a website developer disappears before paying for a fresh build.
Redesign when the foundation works but the experience does not
A redesign is more than changing fonts and colours. Done properly, it changes how the website explains the business and moves a visitor toward a decision while preserving the parts of the current system that still work.
Redesign is a strong fit when the brand has matured, visitors struggle to understand services, important proof is buried, mobile layouts feel awkward, calls to action are weak, or the website simply no longer reflects the level of the business.
This matters especially for lead-generating sites. A visual refresh can make a page prettier without fixing why visitors do not enquire. If conversion is the problem, the redesign should examine messaging, hierarchy, proof, friction, forms and measurement together.
Rebuild when the foundation has become the constraint
A rebuild becomes justified when the current system fights every meaningful improvement.
Common signals include:
- the platform cannot support the workflows the business now needs;
- small changes repeatedly break unrelated features;
- no one can safely maintain the codebase;
- the business does not properly control critical accounts or source code;
- the site has accumulated incompatible plugins, scripts or workarounds;
- important integrations need to be redesigned rather than patched;
- the CMS makes normal publishing unnecessarily difficult;
- a platform migration is required;
- the information architecture needs to change substantially;
- security, permissions or data handling cannot be fixed confidently inside the existing structure.
The key distinction is that a rebuild changes the system, not merely the appearance.
For a brochure website, that may mean moving to a cleaner content architecture and deployment setup. For a product or MVP, it may mean revisiting authentication, database permissions, payment state, testing and observability before adding more features.
If AI generated much of the current application, do not rebuild merely because AI wrote the code. Rebuild when review shows that the architecture cannot be made production-ready at reasonable risk. The AI-generated code review guide explains what should be checked before making that decision.
Do not throw away working SEO during a rebuild
A rebuild can improve a website while still damaging search visibility if migration is treated as an afterthought.
When URLs change, old addresses should be mapped deliberately to relevant new destinations. Google recommends permanent server-side redirects such as 301 or 308 when a page has permanently moved.
Before launch, inventory the current URLs, identify pages that already attract search traffic or links, decide which URLs can stay unchanged, and create a redirect map for those that genuinely need to move. After launch, test redirects, canonicals, internal links, the sitemap, forms and analytics.
Source: Google Search Central guidance on redirects.
A simple decision table
| Situation | Repair | Redesign | Rebuild |
|---|---|---|---|
| One form or integration is broken | Best first option | Usually unnecessary | Usually unnecessary |
| Site works but looks dated | Possible small refresh | Strong fit | Only if deeper problems exist |
| Traffic comes but enquiries are weak | Diagnose first | Often appropriate | Only if architecture blocks the fix |
| Mobile UX is poor across the site | Sometimes | Often | If the platform cannot be corrected cleanly |
| Platform cannot support required features | Temporary only | Insufficient | Strong fit |
| Codebase is unsafe or effectively unmaintainable | Temporary only | Insufficient | Strong fit |
| Major platform migration is required | No | Part of project | Usually |
What I would audit before quoting the project
A useful website quote should follow diagnosis, not replace it.
Before deciding scope, I would want to know which pages generate traffic or enquiries, which customer journeys matter most, what is failing today, which URLs already have search value, what systems are connected, who owns the domain and source code, what the team needs to edit, and what must be measured after launch.
Those answers usually make the repair-versus-redesign-versus-rebuild decision much clearer.
The expensive mistake is solving the wrong layer
A business can waste money in both directions.
You can rebuild a site whose real problem was unclear positioning and a weak enquiry journey. Or you can keep paying for patches on a system that should have been replaced a year ago.
The goal is not to buy the biggest project. It is to make the smallest structural change that solves the actual business problem without leaving the same constraint waiting underneath it.
If you are unsure which layer your current site is failing at, send me the website and the problem you are seeing. I can help separate what needs repair from what genuinely deserves a redesign or rebuild before you commit to the wrong scope.
