Most of the sites I am asked to look at are between five and eight years old. They were built by someone competent, they did the job for a long time, and now they are slow, awkward to edit and starting to look like the year they were made. The owner usually asks the same question, which is whether it can be tidied up or whether the whole thing needs doing again.
There is a real answer to that, and it is not always the expensive one. Plenty of sites that feel finished are structurally fine and need a few days of work rather than a new build. Others have reached the point where every fix costs more than the last one and buys less. Here is how I work out which is which.
Separate what is broken from what is dated
The first job is to write two lists, because these problems get talked about as though they are one problem and they are not.
Things that are broken behave badly. Forms that fail silently, a checkout that drops orders on mobile, layouts that collapse on a phone, PHP warnings in the error log, a plugin that stopped being updated in 2021, load times that put the site in the red on Core Web Vitals. These are defects, and defects have causes you can find and fix.
Things that are dated simply look and feel like their era. Small type, a stock photo carousel, a contact page with a map nobody uses, copy written for a business that has since changed shape. Nothing here is failing. It is just that the site no longer represents the company, and no amount of maintenance will change that, because it was never a maintenance problem.
The lists matter because they point at different work. A defect list is a fixes and repairs job, billed by the hour, usually finished in days. A dated site is a design and content project, and a rebuild is the only honest way to deliver it.
Look under the site before deciding anything
Whatever the two lists say, the decision turns on the foundations, so this is the part I spend the most time on.
I want to know what the theme is and whether it is still supported. I want to know how many plugins are doing work the theme should be doing, whether anything has been edited directly in core or in a theme that will overwrite those edits on update, and whether the hosting is the reason the site is slow. I want to see the database, because a decade of form entries, revisions and abandoned plugin tables is a common cause of a site that has quietly become sluggish.
A site with sound foundations can carry another five years with sensible upkeep. A site with a nulled premium theme, a page builder that has been abandoned by its developer, custom code in files that get replaced on every update, and a plugin count in the fifties is not going to get better with attention. Every fix on that site sits on top of something unstable, which is why the fixes keep coming back.
When the builder or the theme is the problem
This is the most common single cause of a site that cannot be economically repaired.
A site built on a page builder that is no longer developed, or on a multipurpose theme with its own bundled builder that only works with that theme, is a site with a ceiling. The plugin still runs, and one day it will not, and until then everything you want to do has to be done its way. I have seen sites where adding a section to a page meant working around the builder rather than with it, and the work took three times as long as it should because of it.
Themes bought from a marketplace and then customised by editing the theme files directly cause the same trouble from the other direction. The customisation is real work and it is gone the moment the theme updates, so the site sits unupdated for years, which is how sites end up insecure.
I use Elementor daily and have no argument with page builders as a category. The question is whether the specific one on your site is current, supported, and still capable of doing what the business now needs. When the answer is no, that is usually the moment a rebuild stops being optional.
The arithmetic of patching against replacing
Now the money, which is where most of these conversations end up anyway.
Repairs are billed by the hour, and individually they are small. Two hours here, half a day there, a morning to get a plugin conflict sorted out. The trouble is that on an unstable site they recur, and they recur at an increasing rate as the gap widens between the site and the platform it runs on. It is worth adding up what you spent on the site over the last two years before comparing anything, because that number is often higher than people expect and it bought no new capability at all.
A rebuild is one larger figure. Websites start at £2,000 with design included, and the range above that depends on size and complexity. Against that you get a site that will not need the same repairs, that your team can edit without asking anyone, and that starts a fresh five-year clock.
Comparing a single repair bill against the build cost misses the point, because the two are not buying the same thing. The useful comparison is the repair bill plus another two or three years of the same, plus the enquiries a dated site is not winning, set against the build cost spread over the life of the new site. Put that way the sums usually decide themselves, in one direction or the other.
Repair or rebuild, side by side
A repair is the right call when the design still represents the business, the theme and builder are current and supported, the foundations are sound, and the fault list is a list of specific defects rather than a general feeling that the site is tired. That combination is more common than the industry likes to admit, and it is one of my favourite kinds of job: a few focused days, a site that behaves again, and no need to spend anything else.
A rebuild is the right call when the site fights you every time you try to change it, when the design no longer matches what the business has become, when the platform underneath is unsupported, or when the fixes have started repeating. It is also the right call when the site needs to do something it was never built for, which is the usual reason a perfectly healthy five-year-old site gets replaced.
There is a middle path worth knowing about. Sometimes the right answer is to repair now and rebuild in twelve months, because the site is unsafe today and the business is not ready for a build project this quarter. Stabilising a site to buy planning time is a legitimate piece of work, so long as everybody understands that is what it is.
What is worth keeping
A rebuild does not mean starting from nothing, and the things worth carrying across are worth naming before anyone touches the site.
The content comes first. Years of pages, posts and product descriptions represent real work and real rankings, and they migrate cleanly if the migration is planned. Rewriting is a decision to take deliberately, page by page, rather than a side effect of a new build.
Then the search equity, which is the part that gets damaged most often. A site that has been ranking for eight years has accumulated links, authority and history against specific URLs. Keep the URL structure where you sensibly can, and where you cannot, map every old URL to its new home with a proper 301 redirect before launch rather than after. Skipping the redirect map is the single most expensive mistake in a rebuild, and the damage shows up six weeks later when the traffic has already gone.
Beyond that: form submissions and any customer data held in the site, tracking and analytics history, integrations with a CRM or a booking system, and anything the business quietly depends on that nobody thinks to mention until it stops working. I ask about those in the discovery call, because they are always easier to keep than to recover.
How the decision gets made in practice
When someone sends me a site to look at, I go through the foundations, the plugin and theme situation, the error logs and the speed data, then come back with a plain recommendation and a reason. Sometimes that recommendation is a day of repairs and nothing else, which is a perfectly good outcome for both of us.
If it turns out to be a rebuild, the process is a discovery call, a written scope and fixed price, then your home page designed for real in the browser so you can click through it before the rest of the site is built. A standard business site runs roughly three to six weeks from there, and the two things that stretch that timeline are content arriving late and feedback rounds taking longer than planned. Both are worth thinking about at the start, because they are the parts a developer cannot speed up alone.
If you have a site you are unsure about, send it over and I will tell you which of the two it is.
Common questions
How long should a WordPress site last before it needs rebuilding?
Five to seven years is typical for a business site that has been looked after. Sites on a maintained platform with regular upkeep last longer, and sites left unupdated for years tend to need replacing sooner, often because the security position leaves no other choice.
Will a rebuild damage my search rankings?
Not if the redirects are done properly. Every old URL needs mapping to its new equivalent with a 301 before launch, and the content that was ranking needs to survive the move. Rankings usually wobble for a few weeks after any launch and settle back. The lasting damage comes from unmapped URLs and content quietly dropped in the redesign.
Is it cheaper to fix an old site than to rebuild it?
Per job, always. Over two or three years on an unstable site, frequently not, because the repairs repeat and none of them improve the site. Adding up the last two years of invoices before deciding is the quickest way to see which situation you are in.
Can you rebuild a site without taking the old one down?
Yes. The new site is built on a staging environment while the existing one carries on serving customers, and the switch happens in one planned step once everything has been tested and signed off. Downtime on a well-run launch is measured in minutes.
What stops a new site ageing the same way?
Regular upkeep and a supported platform, mostly. Core, theme and plugin updates applied and tested, backups that have actually been restored at least once, and someone keeping an eye on performance and security. That is what the Infinity care plans are for, at £49 a month for Standard and £120 for Plus, both including managed hosting. The plan matters less than the fact that somebody is doing it.
