Rebuilding a website is the most expensive available answer to almost any website problem, and it is the one most often proposed — partly because it is easier to quote for than a diagnosis, and partly because it is genuinely more enjoyable to build something new than to understand something old.

Sometimes it is the right answer. Here is how to work out whether yours is one of those times, before committing the budget.

Is the content still right?

If the pages say the wrong things about the wrong services to the wrong audience, no amount of rebuilding fixes that, and you will pay to have the same wrong content re-typed into a new system. Content problems are content projects. They are cheaper, faster, and they can be done on the site you already have.

A useful test: if you rewrote every page tomorrow and changed nothing else, would the site do its job? If the answer is yes, you do not need a rebuild.

Can you change anything without paying someone?

This is the question that most often does justify significant work. If updating a phone number requires an invoice, the site has failed at something structural, and that failure compounds every month. It is not always a rebuild — sometimes an editable content layer can be added to what exists — but it is a real problem with a real cost.

How old is the code underneath?

Ask whoever maintains the site for two things: the version of the framework or platform it runs on, and whether that version still receives security updates. An unsupported major version is a genuine risk rather than an aesthetic complaint, because vulnerabilities found after end-of-life are never patched.

  • Still supported, a version or two behind: upgrade in place. This is maintenance, not a rebuild.
  • Out of support but upgradeable: a migration project, usually far cheaper than starting again.
  • Out of support with no upgrade path, or a platform that no longer exists: this is where rebuilds are genuinely justified.

Is the structure wrong, or just the surface?

A dated visual design is a surface problem. Ten years of accumulated pages with no coherent hierarchy, half of them orphaned and none of them linked to each other, is a structural problem. The first is a redesign, which is affordable. The second is an information architecture project, which a rebuild does not automatically solve — plenty of new sites launch with the same tangle carried over.

What are you currently getting from search?

This is the question people forget, and it is the one that costs most when they do. If the site has years of accumulated search visibility, a rebuild puts that at risk. It is recoverable — with a complete URL inventory, redirects for every old address, and preserved metadata — but only if it is planned for from the start rather than discovered afterwards.

Before any rebuild begins, export the list of every page that currently receives search traffic. If nobody produces that list, the project is not ready to start.

Is it actually slow, or does it feel slow?

Performance is the most common stated reason for a rebuild and the least often the real one. Most slow sites are slow because of oversized images, unaudited third-party scripts, and page generation that should have been cached — none of which are properties of the underlying framework, and all of which will happily follow you into a new build if nobody addresses the cause.

A reasonable rule

Rebuild when the platform is unsupported with no upgrade path, when the structure is genuinely broken rather than merely dated, or when you cannot change your own content and no editable layer can sensibly be added. Repair in every other case.

And whichever way you go, get the reasoning in writing first. A quote that says "new website" with a number after it is not a plan — it is an invoice with an unstated set of assumptions attached.