Repair or Rebuild? How to Decide What to Do With an Ageing Website

The site works, mostly. It looks dated, breaks occasionally, and every change takes longer than it should. Someone suggests a rebuild. Someone else points out the quote and asks whether it can just be fixed.

The repair or rebuild decision gets made on gut feeling far more often than it should, usually by whoever argues most persuasively. It deserves better, because both answers are right in different circumstances.

Start with the honest question

Not "is it old?" — age alone means nothing. A well-built site from four years ago can be perfectly serviceable.

The question is: is the cost of keeping this working rising faster than its value?

That reframes it usefully. A site that needs occasional attention and does its job is fine. A site where every small change requires a developer, every update risks breakage, and nobody can safely touch the theme is costing you more each year regardless of what the invoice says.

Signals pointing to repair

• The problems are specific and identifiable. Slow pages, a broken form, an outdated plugin. Known problems with known fixes
• The underlying build is sound — a standard theme, mainstream plugins, no exotic custom code
• It converts acceptably. If the site generates enquiries at a reasonable rate, the fundamentals are working
• The design is dated but not embarrassing. Visual refreshes are much cheaper than rebuilds
• You can still update it without things breaking

Most sites that feel like they need rebuilding actually need maintenance that has been deferred for two years. That is a much cheaper problem.

Signals pointing to rebuild

• Updates break things routinely. Usually means heavy modification of theme or plugin code, so every update fights your customisations
• It depends on abandoned software — a theme or critical plugin no longer maintained. There is no patch coming when a vulnerability is found
• Nobody understands how it works. Custom code from a developer long gone, undocumented
• It cannot be made fast. Some builds have a performance ceiling no optimisation clears
• It is not properly responsive. Retrofitting mobile onto a desktop-first build often costs more than starting again
• You cannot edit it yourself. If every text change needs a developer, you are paying rent on your own content
• It has been compromised repeatedly despite good hygiene

The clearest signal is when the cost of a change no longer relates to the size of the change. If moving a button costs the same as adding a page, the build is fighting you.

The trap in the middle

The most expensive outcome is neither. It is repeated partial repair on a site that needed rebuilding — a fix here, a plugin there, a patch on top of a patch, for three years.

Each individual decision was rational. Cumulatively you spent more than a rebuild and still have the original problem.

If you are on your third significant fix in eighteen months for related issues, that pattern is the answer.

Doing the arithmetic properly

Compare over three years, not today.

Repair path: immediate fixes, plus ongoing maintenance, plus the fixes you will need in years two and three, plus the cost of every change taking longer than it should, plus the risk of a compromise through unmaintained components.

Rebuild path: the build cost, plus content migration, plus a period of disruption — against much lower maintenance and change costs afterwards.

Rebuilds usually look expensive because the cost is visible and arrives at once. Repair costs are spread out and mostly invisible until you total them.

What a rebuild genuinely risks

Being fair to the repair argument, because rebuilds are frequently oversold.

SEO. A rebuild that changes URLs without proper redirects can lose rankings built over years. This is recoverable with care and genuinely damaging without it.

Content loss. Migration is tedious, and things get missed.

Regression. The old site had features nobody documented. They surface as complaints after launch.

Timeline. Rebuilds overrun. The old site still needs maintaining while it happens.

Rebuilding the same mistakes. If the new site is built without a maintenance plan, you are back here in three years.

The middle option people forget

It is not binary. A staged approach often works better than either extreme.

Keep the platform and rebuild the theme. Replace the worst components one at a time. Fix performance and security now, redesign later on your own timeline.

This spreads cost, keeps the site working, and lets you stop at any point if the improvement is sufficient.

The one thing to do first, either way

If the site may be compromised, resolve that before anything else. Rebuilding a site while an attacker has access to the hosting account achieves nothing — the new site inherits the problem.

The same applies to a repair programme. Our guide to auditing a website you did not build covers establishing what you actually have before deciding what to do with it.

The question that usually settles it

If this site were working perfectly tomorrow — fast, secure, easy to edit — would it be the right site for the business?

If yes, repair. The problems are technical and technical problems are fixable.

If no — if the structure is wrong, the content does not reflect what you do now, or it was built for a different business — then repairing produces a well-maintained version of the wrong thing.

If you want an honest assessment

We do not build websites from scratch, which means we have no particular interest in telling you to rebuild. What we can tell you is what state the current one is actually in.

Our WordPress security and error fixing service includes an audit covering what it is built from, what is abandoned, whether it has been compromised, and what could realistically be fixed.

If it is worth keeping, our managed website plans keep it that way. Send us your web address and we will tell you plainly which situation you are in.