WordPress Site Audit: Patch Backlog, Exposure and Load Timings

What a score out of 100 cannot tell you

Automated site graders are useful and they answer a question nobody actually has. They tell you how a page compares against a general standard. What an owner needs to know is which of these things will cost me money, and in what order.

A grader cannot rank findings because it cannot see value. It does not know that the page it flagged is your highest-converting one, or that the plugin it called critical is deactivated, or that the two-second response it measured happens only on the pages where people buy. It marks a missing image dimension and a publicly exposed admin endpoint with the same shade of red, and it has no way to tell you that fixing the first takes ten minutes while the second changes who can reach your site.

The instant check on this page is honest about being that kind of tool. It reads the outside of a site quickly and tells you what it found, which is genuinely useful and is where most people should start. What it cannot do is weigh anything, and weighing is the part that turns a list into a decision.

The findings that repeat

Across sites arriving from elsewhere, the same handful accounts for most of the risk, and almost none of it is exotic.

• Update debt measured in years, not weeks. The site was left alone because updating felt risky, which made updating riskier, which is the loop. Breaking it is what a staged update cycle is for.
• Backups that have never been restored. Present, scheduled, and unproven – often failing quietly for months into an inbox nobody reads. The test, not the schedule, is the thing that matters, and it is why off-site backups are quoted with a quarterly restore.
• Plugins doing nothing. A typical inventory carries several installed for a single feature, one duplicate of something the theme already does, and at least one paid licence that lapsed.
• Customisation in the theme. Functionality written into a theme that will be replaced one day, so replacing it silently removes features nobody documented.
• Administrator accounts belonging to nobody. A developer from two agencies ago, a plugin’s support login, a shared account with a password sitting in a breach list.

None of these is difficult on its own. What makes them dangerous is that each one hides the next, and a site carrying all five has no safe place to start. Establishing that order is most of what you are paying for.

Reading the report as a decision

The report is written to be acted on by someone who is not going to do the work personally. Every finding states the observation, the evidence behind it, the consequence of leaving it, the effort to resolve it, and what it depends on.

That shape means it works as a brief. Hand it to your existing developer and it is a scope of work with the arguing already done. Hand it to a second supplier and it is a like-for-like quote request, which is the only honest way to compare two of them. Keep it in-house and it is a backlog already in priority order. It is also the document to read before deciding whether this belongs with your host or with a specialist at all – host support against a maintenance specialist sets out where the line usually falls.

Where the answer is that the site needs ongoing attention rather than a project, the work continues as WordPress maintenance and the report becomes the first month’s plan; plans and pricing sets out what each cadence covers. Where one finding dominates, it goes to whichever service owns it – security hardening or Core Web Vitals work. And where the finding is that a compromise is already present, the audit stops and malware removal starts, because assessing a site while somebody else still has access to it produces a report about their work rather than yours.