How to Tell If Your WordPress Site Is Beyond Repair, and What to Do Next

Your developer has disappeared. Your site breaks after every WordPress update. You’ve spent more on fixes in the last six months than you did building it in the first place.

Sound familiar?

If it does, you’ve probably already Googled “how to fix a slow WordPress site” and worked your way through a dozen articles telling you to install a caching plugin, optimise your images, and upgrade your hosting. You’ve tried some of that. It hasn’t fixed the problem.

That’s because the advice is aimed at the wrong problem. Caching plugins fix slow sites. They don’t fix broken ones. And there’s an important difference between a site that needs tuning and a site that needs rescuing.

After 18 years of building and fixing WordPress, Drupal and Laravel sites — and having delivered for organisations including Pfizer, the NHS and Specsavers — I’ve seen both. Here’s how to tell which one you’re dealing with.

Signs your site is salvageable

Not every struggling WordPress site is beyond repair. Some are genuinely fixable with targeted work, and a rebuild would be unnecessary expense. Here’s what a salvageable site usually looks like:

The core codebase is sound. If the theme is well-built and the site’s fundamental architecture is logical, most performance and stability issues can be resolved without starting over. A well-structured site with a plugin conflict is a very different problem to a site built on a deprecated framework with no documentation.

The issues are isolated and plugin-related. Plugin conflicts are common and fixable. If your site works reliably except when a specific plugin updates, the problem is contained. Removing or replacing that plugin — and auditing the rest of the stack — is usually straightforward.

The hosting is adequate for the site’s complexity. Shared hosting that was fine for a five-page brochure site will struggle with a WooCommerce store processing hundreds of orders. Sometimes the fix is simply moving to better infrastructure.

The original developer is contactable and left documentation. Not ideal, but if there’s a handover document, a Git history, or someone who can explain what was built and why, you’re starting from a much stronger position than if the site is a black box.

Signs you need a rebuild

These are the indicators I look for that suggest patching is going to cost more in the long run than starting fresh:

The site breaks after every WordPress core update. WordPress releases core updates regularly. A well-built site should survive them without incident. If yours doesn’t, the theme or plugin code is not following WordPress standards — and that problem compounds with every update cycle. You’re not fixing a bug; you’re managing a structural deficiency indefinitely.

You have more than 30 active plugins. Plugin bloat is the single most common cause of slow, unstable WordPress sites I encounter. Each plugin adds code that executes on every page load. More than 30 active plugins almost always indicates a site that has been patched incrementally over years, with each fix adding another layer rather than addressing the underlying issue. The plugin stack becomes its own problem.

The theme is built on a deprecated or abandoned framework. Builder frameworks like older versions of Divi, Avada, or Visual Composer become liabilities when they stop receiving security updates. If your site is built on a framework that is no longer actively maintained, extending or modifying it becomes increasingly difficult and risky. Every change is a gamble.

The original developer left no documentation. This is one of the most common rescue scenarios I deal with. A site with no documentation, no Git history, and no handover notes is essentially a black box. Every change carries risk because nobody knows what else it might affect. I’ve inherited sites where making a minor content change broke the checkout — because undocumented custom code connected things that had no obvious relationship.

You’re spending more on fixes than the site cost to build. If the cumulative cost of patches, emergency fixes, and recovery work over the past twelve months exceeds the original build cost, you are on a treadmill. The fixes are managing symptoms of a structural problem, not resolving it. At some point — and usually that point has already passed — a rebuild becomes the more cost-effective option.

Database errors are recurring. Occasional database errors can be a hosting issue. Recurring ones, especially after updates or periods of high traffic, usually indicate deeper problems with how the database was structured or how the site writes to it. This is rarely a quick fix.

The audit-first approach

Here’s the honest answer: in most cases, you can’t tell definitively whether to fix or rebuild without a technical audit first. The symptoms are often the same — slowness, instability, breakage after updates — but the causes can be very different, and the causes determine the right response.

A technical audit covers:

Hosting and infrastructure — Is the server adequate for the site’s requirements? Are there configuration issues at the hosting level contributing to performance problems?

Theme and plugin stack — Is the theme well-built and actively maintained? Which plugins are necessary, which are redundant, and which are security liabilities?

Code quality — Is the custom code following WordPress standards? Are there obvious red flags — unescaped inputs, deprecated functions, hardcoded credentials?

Database health — Is the database bloated with post revisions, transients, or orphaned data? Are there structural issues?

Security posture — Is the site hardened against common attack vectors? Are there signs of past or current compromise?

At the end of an audit, you get a clear answer: here’s what’s wrong, here’s what it would cost to fix it, and here’s whether a rebuild makes more sense. That answer is usually available within a few hours of looking at the site properly.