Rescue or rebuild: auditing a WordPress site you have just inherited

An agency sends us a WordPress site it has just inherited and asks the same question every time: is this worth fixing, or do we start again?

It is a commercial question wearing technical clothes. Rebuilding is easier to quote and easier to deliver, so there is a pull toward recommending it. But a rebuild the client did not need is money they will resent spending, and an agency that recommends one every time stops being believed. Here is the audit we run before answering, and the four findings that actually decide it.

The short version:

• A page builder holding the content is the finding that forces a rebuild
• Over 40 plugins, or plugins unmaintained for years, signal an unowned site
• Concentrated traffic is low migration risk; long-tail traffic is the hidden cost
• About a third of “rebuild” requests are two or three specific faults

WordPress audit step 1: read the plugin list, not the theme#

Open the plugins screen and count. Under twenty is normal. Between twenty and thirty-five, look closely. Above forty, something has gone wrong that a redesign will not solve.

What matters is not the number itself but what the number is doing. Sort by last updated. Anything untouched by its author for more than two years is a liability, and anything untouched for more than four is a security incident waiting for a slow week. Then look for overlap: two caching plugins, two SEO plugins, a slider plugin and a page builder that also does sliders. Overlap means nobody has owned this site for a while, and it usually means the person who added the second one could not work out how to configure the first.

The specific thing that decides a rebuild: a page builder holding the content. If every page is a nest of builder shortcodes, the content is not portable. You are not looking at a site you can improve. You are looking at a site that has to be retyped, and once that is true the cost gap between fixing and rebuilding mostly disappears.

Step 2: check whether a content model exists#

This is the finding that changes quotes most and gets checked least.

Look at a few key pages in the database, not in the admin. If a case study is a title, a featured image and one enormous block of markup, there is no content model. Every page is bespoke, nothing can be filtered or listed programmatically, and the client’s team has been building pages by copying an older one and typing over it.

If instead there are custom fields, custom post types and taxonomies doing real work, someone thought about this. That site can be restyled without touching its content, which is a completely different project. A restyle on a well-modelled site is often a third of the cost of a rebuild and delivers most of the visible benefit.

The test question: could you produce a list of every product released after a given date, sorted by category, without a human reading the pages? If yes, the model exists. If no, it does not.

Step 3: map the organic traffic before changing anything#

Pull twelve months of search data and sort landing pages by organic traffic. You are looking for how concentrated it is.

A site earning most of its traffic through ten or fifteen pages is low risk. Those pages get preserved, reworked and redirected carefully, and everything else can change freely. A site earning traffic across four hundred long-tail pages is a different proposition. Every one of those URLs has to be mapped, and the rebuild has to reproduce content that someone, at some point, wrote for a reason nobody currently remembers.

That second scenario is not an argument against rebuilding. It is an argument for pricing the migration properly and saying so out loud, because that work is usually the largest hidden line in the estimate.

Step 4: test forms and performance before declaring the site bad#

Before agreeing that the site is bad, test whether it works. In our experience about a third of sites described as needing a full rebuild have two or three specific faults, and the frustration is coming from those rather than from the site as a whole.

Submit every form and confirm the email arrives. Not that the success message shows, that the message arrives, in an inbox someone reads. Silent form failures are the single most common serious fault we find, and they can run for months because nothing visibly breaks.

Then run the site through a performance check on mobile, look at what is loading before first paint, and check whether the largest image on the homepage is being served at its natural size. A three megabyte hero image is not a reason to rebuild a site. It is a reason to fix an image.

Fix or rebuild a WordPress site: how the decision falls#

Fix it when the content model is sound, the traffic is concentrated, and the complaints trace to specific faults. Budget goes to performance, conversion paths and a visual refresh. The client gets most of the benefit for a fraction of the cost, and you look like the agency that did not upsell them.

Rebuild it when the content is trapped in a page builder, the plugin count is out of control, or the information architecture no longer matches what the business sells. All three are structural. No amount of careful surgery fixes a site whose organising idea is wrong.

The uncomfortable third answer is that sometimes the site is fine and the problem is elsewhere. The traffic is unqualified, or the offer is not landing, or sales is not following up. Saying so costs you a project and buys you a client who believes the next thing you tell them.

Deliver the audit as a prioritised list, not a verdict#

Whatever the recommendation, send it as a prioritised list with an estimated impact and effort against each item, not as a verdict. Clients accept expensive recommendations far more readily when they can see the cheap ones were considered first.

It also gives them something real if they decide not to proceed. An audit they can hand to their own developer is a deliverable. A sales document dressed as an audit is not, and clients can tell the difference faster than most agencies expect.

Frequently asked questions#

How many plugins are too many on a WordPress site?#

There is no magic number, but under twenty is normal, and above forty almost always indicates a site nobody has owned for a while. What matters more is overlap between plugins doing the same job and anything unmaintained by its author for more than two years.

Is it cheaper to fix or rebuild a WordPress website?#

Fixing is usually a third of the cost of rebuilding, if the content model is sound. Once the content is trapped inside a page builder, the gap mostly disappears, because the content has to be re-entered either way.

What should a WordPress site audit include?#

A plugin and maintenance review, a content model check, twelve months of search and conversion data mapped to URLs, and functional testing of every form. Delivered as a prioritised list with impact and effort against each finding.