Most WordPress audit guides check whether plugins are up to date and call it finished. That misses the three things that actually predict how the engagement goes: plugins doing the same job twice, a theme edited directly instead of through a child theme, and whether the honest answer is to repair the site or rebuild it.
This is the audit we run before taking on a maintenance retainer for a site we did not build, and before quoting any work on one. Do it before you commit to either.
Find the plugins doing the same job twice
A plugin count on its own tells you little. Two SEO plugins, three form builders installed at different points and never cleaned up, or a caching plugin fighting the one the host already runs are the pattern that actually predicts maintenance pain.
List every active plugin with what it is actually used for, not what its name suggests. WordPress's built-in Site Health screen shows active and inactive plugins with their versions in one place, no separate tool needed.
| Finding | What it usually means |
|---|---|
| Two plugins doing the same job | Pick one, confirm nothing depends on the other, then remove it rather than just deactivating it |
| A plugin with no recent update | Check whether it is abandoned, not just old. An abandoned plugin is a standing security risk |
| Inactive plugins still installed | Dead weight and a larger attack surface for no benefit. Remove, do not just deactivate |
| A plugin doing something core or the theme already does | Redundant functionality. Usually removable once you confirm what actually depends on it |
Check whether the theme was edited directly
This is the single most common way a site quietly loses custom work. A direct edit to a parent theme's files survives right up until the next theme update, which silently overwrites it with no warning.
The Site Health Info screen shows the active theme's parent theme field. It reads "None" if there is no child theme, which is your answer.
If it is "None" and the theme has clearly been customised, the customisation lives in the parent theme's own files. Confirm this before promising any update, because applying one can delete work nobody remembers doing.
Check the PHP version against what the plugins actually need
The Site Health Info screen's Server section shows the PHP version running. Compare it against PHP's own supported-versions page rather than assuming whatever the host defaults to is current.
A site on a PHP version past security support is not a future problem to schedule. It is a present one, because a security fix for the underlying language will not come.
The reverse also matters: a plugin that requires a newer PHP version than the site runs will fail in ways that look unrelated, which is why this check happens before anything else gets touched.
Confirm backups exist, and that they actually restore
A backup nobody has restored is a hope, not a backup. Confirm three things: backups are running on a schedule, they are stored somewhere other than the same server, and at least one has actually been restored to prove the file is not corrupted.
This one is easy to skip because a missing or broken backup causes no visible symptom until the day it is needed, which is also the worst possible day to discover it.
The question every audit should actually answer
Repair or rebuild is the decision the client is really paying for, and it is the one most audit checklists never make explicit. Three findings push the answer toward rebuild rather than repair.
- Core, theme and several plugins are multiple major versions behind, so bringing everything current is itself a project, not a patch
- The customisation lives in directly edited parent theme files rather than a child theme, so there is no safe path to update the theme without redoing the work
- Duplicate and abandoned plugins outnumber the ones actually doing something, so untangling dependencies costs more than starting the relevant pages over
None of these alone means rebuild. Together, they mean the hours spent patching would have been better spent on a WordPress rebuild, and the audit is what lets you say so with evidence instead of a guess.
What the report itself should contain
Not a wall of findings. A short, prioritised list, because that is what actually gets acted on.
- Critical: security exposure or something actively broken for a visitor. Fix before anything else
- Important: the plugin, theme and PHP findings above, prioritised by risk rather than listed alphabetically
- Optional: everything real but not urgent, so it does not compete with the critical items for attention
Keep the report. The next audit, whenever it happens, starts by checking what from this list actually got fixed.
How long should an audit like this take?
A few hours for a typical brochure site, longer for one with custom functionality or an unclear plugin inventory. It should always be faster than the work it is scoping.
What if the audit finds nothing seriously wrong?
That is a legitimate outcome, not a wasted exercise. Confirming a site is in reasonable shape before committing to it is worth exactly as much as catching a real problem, because both replace a guess with evidence.
