When to rebuild your site and when fixing it is enough: a diagnosis before the decision

The decision to rebuild a site often comes from fatigue: "it's old", "we don't like it any more". Those feelings are legitimate, but they are a poor spending criterion. A rebuild is the most expensive and risky web project there is, and before doing one it is worth understanding where the problem lies: in the content, the design or the architecture. The solutions are very different.

Three levels of problem

Content

Copy that does not explain what you do, services described badly, no trust signals, pages answering questions nobody asks. These are solved by rewriting and reorganising, without touching code. It is the most frequent case and the cheapest.

Design

A dated interface, confusing visual hierarchy, poor readability on phones, inconsistent components. These are solved with a restyle, if the technical base allows the look to change without rewriting everything.

Architecture

This is the deciding level. Signs of an architectural problem:

• every change costs more than it should, because the code is fragile or tied to a page builder;
• updates are frightening: an abandoned theme, incompatible plugins, unsupported PHP versions;
• performance does not improve despite caches and optimisers, because the weight is structural;
• content is trapped in proprietary shortcodes and fields that block any evolution;
• security is a recurring problem, with repeated compromises or vulnerabilities;
• new features cannot be added without yet another plugin that makes everything else worse.

When the problems are architectural, a restyle is money spent on foundations that will not hold.

Diagnosis before decision

Before any proposal I run a four-point diagnosis:

1. data: traffic and conversions per page, the searches visits come from, real-user Core Web Vitals;
2. content: what works, what is missing, what needs rewriting;
3. code and dependencies: theme, plugins, versions, customisations, update status;
4. current cost: what maintenance, fixes and recurring problems cost today.

From there the choice is between four routes, in order of effort: content refresh, restyle on the existing base, partial rebuild (for example a new theme or a rebuilt section), full rebuild. The rule: the lowest level that really solves the problem.

Reducing the risk of a rebuild

If a rebuild is the right path, there are three main risks, and they can be managed:

• loss of rankings: prevented by a designed migration, URL inventory and one-to-one redirects (I explain it in Rebuilding your site without losing rankings);
• loss of content: everything that brings traffic or enquiries is kept and improved, not cut to fit the design;
• a project that never ends: defined scope, a first publishable version early, improvements afterwards.

Rebuilding is also the moment to choose the platform

If the site has to be rebuilt anyway, the marginal cost of changing architecture is the lowest it will ever be. It is the moment to ask whether you really need a dynamic CMS with dozens of plugins, or whether a pre-generated site, with content in Markdown or a headless CMS, better solves speed, security and maintenance. Changing platform for fashion adds risk; changing it because it was the cause of the problem removes it.

Effort and timing for each route

Without invented figures, the order of magnitude is:

• content refresh: days, mostly work by people who know the business; code changes little or not at all;
• restyle on the existing base: a few weeks, provided the theme allows the look to change without rewriting templates;
• partial rebuild: depends on the part rebuilt, but keeps content, URLs and much of the SEO work;
• full rebuild: a new project, with design, development, content migration and a redirect map, organised in phases.

A practical decision criterion: add up the costs of the last twelve months (fixes, problems, maintenance, opportunities lost to features that could not be added) and compare them with the cost of rebuilding, spread over the expected years of life. If the first figure grows every year, technical debt is already costing more than the rebuild.

My take

I often advise against a rebuild: when the problem is the copy or a couple of page templates, rebuilding everything is a waste. But when the diagnosis says the problem is the architecture, I am just as direct. Many of the WordPress sites I receive do not have a look problem: they have a multipurpose theme, a builder and thirty plugins tied together, and every change costs three times what it should. A restyle makes no sense there.

In those cases I suggest rebuilding with fewer dependencies: a lean WordPress with a custom theme if a rich admin panel is needed, or a static site with Nuxt, GitHub and Netlify if it is not. It is the choice I made for this site, and I describe it in From WordPress to Nuxt, GitHub and Netlify.

And when a rebuild happens, I insist on one principle: the new site must be easier to change than the old one. Not just more attractive or faster on launch day, but with fewer dependencies, content separated from presentation and a publishing workflow with previews. That is what saves you from asking the same question again in five years.

Why work with me

I have been programming since 1999, delivered more than 300 projects and work as an external developer with about 30 agencies, from Rome and remotely. Before proposing a rebuild I run a diagnosis on data, content and code, and tell you frankly if fixing is enough.

If you are thinking of rebuilding your site, get in touch: in a call of about 20 minutes we find out where the problem really lies. The service is in Website development.