Most WordPress site audits produce a list. You run a tool, the tool finds ninety-one issues, and you are now the owner of ninety-one issues you did not have that morning. The list is accurate. It is also close to useless, because it does not tell you which of the ninety-one will cost you money and which will sit there harmlessly for another three years.
An audit is not a list of problems. An audit is a decision about what to do next.
We audit inherited sites constantly, because every site that comes to us arrives with a history somebody else wrote. This is the order we check things in, what each number actually means, and where the numbers mislead you.
A scan is not an audit
A scanner runs rules against your site and reports what matched. It has no idea what your site is for, how much a slow checkout costs you, or whether the plugin it just flagged is running your entire booking system. It cannot tell you what matters, because mattering is a business question and the scanner has never met your business.
An audit uses the scan as an input and then does the part the tool cannot: weighting. The same finding means different things on different sites. An out-of-date plugin on a brochure site is a maintenance task. The same plugin on a site taking payments is a Tuesday you will remember.
So the useful question is never “what did the scan find.” It is “what did the scan find that changes what I do this month.”
The five things worth auditing, in the order that matters
The order is not arbitrary. It runs from the things that fail loudly and cost immediately to the things that fail quietly and cost later.
1. Whether it is up, and whether you would know
Uptime first, because everything else is theoretical while the site is down. The audit question is not only “what is the uptime percentage.” It is “who finds out first when it goes down, you or a customer.” Plenty of sites with excellent uptime numbers have no monitoring at all. They have simply been lucky, and luck does not appear as a finding in any report.
2. Performance, on the pages that earn
Not the homepage. Almost every performance report leads with the homepage because it is the easiest URL to type, and the homepage is frequently the fastest page on the site. Audit the pages that carry the money: the product page, the booking page, the checkout, the top three organic landing pages. A homepage scoring 94 in front of a checkout scoring 31 is a site with a performance problem and a performance report that says otherwise.
3. Security posture, which is mostly access
Vulnerability scanning is the visible half. The invisible half is access: how many administrator accounts exist, who they belong to, whether any of them belong to a contractor from 2022, and whether anyone still holds the logins that sit above WordPress entirely. Most compromises we inherit did not come through a clever exploit. They came through an account nobody remembered to remove. Our guide to WordPress security services covers what that layer should include.
4. Update and dependency health
Count how many plugins you run, then check the more revealing number: how many of them have not had a release in over a year. An abandoned plugin is not an urgent problem on the day you notice it. It is a scheduled one. It will break at the next PHP version or the next core release, on a date somebody else chooses. This is the ongoing work that maintenance services exist to carry.
5. Backups, and specifically whether they restore
The only backup statistic that means anything is the date of the last successful restore test. A backup that has never been restored is a belief, not a backup. This is the single most common gap we find, and it is close to universal: the backups are running, nobody has ever tried to use one, and the first attempt happens on the worst possible day.
What the numbers actually mean
This is where most audits lose people. Here is the honest reading of the numbers you will be handed.
PageSpeed or Lighthouse score (0-100). A synthetic score from a simulated device on a simulated connection. It moves several points between runs on an unchanged site. It is useful as a rough band, not as a target. Chasing 100 is a well-known way to spend a great deal of money improving a number that no customer experiences. Treat anything above 90 as “not your problem right now” and look at the field data instead.
Largest Contentful Paint (LCP). How long until the main thing on the page appears. This one is worth caring about, because it correlates with what a visitor calls “slow.” Under 2.5 seconds is healthy. Over 4 seconds, people leave, and they leave before any of your content has had a chance to work.
Time to First Byte (TTFB). How long the server takes to start answering. This is the number that points most directly at hosting and at the database, because it is measured before your images, fonts, or scripts are involved at all. If LCP is bad and TTFB is fine, the problem is on the page. If TTFB is bad, the problem is underneath it, and no image optimization plugin will touch it.
Plugin count. A weak number on its own. Thirty well-maintained plugins are safer than eight abandoned ones. What the count is useful for is a conversation: every plugin is a dependency on a stranger’s release schedule, and thirty of them is thirty schedules you do not control.
Uptime percentage. Read the scope before the number. 99.9% sounds close to perfect and allows roughly forty-three minutes of downtime a month. More importantly, ask what is being measured: one URL checked every five minutes tells you the front page responded, not that checkout worked. A high uptime number with a narrow scope is a true statement about a small thing.
Vulnerability counts. Almost always inflated by severity-blind counting. Ten low-severity notices on components not exposed to the internet are not “ten vulnerabilities” in any sense you should act on. One authentication bypass in a plugin that touches user accounts is worth more of your attention than all ten of them together.
The pattern underneath all of these: a number without its scope and its method is not evidence. Any report that gives you the figure but not how it was measured has given you a mood.
The three questions that turn a finding into a decision
Once you have the list, run each finding through these. Most of the ninety-one will not survive the first question, which is the point.
One: if this stays broken for ninety days, what does it cost? Not “is it bad.” What does it cost, in money, in customers, or in the hours someone will spend fixing it later. A surprising number of findings cost nothing at all. Those are not urgent, and calling them urgent trains you to ignore the ones that are.
Two: who owns this? Not which tool would fix it. Which person is responsible for the outcome. If the answer is a plan, a subscription, or “the host handles that,” check whether the host has actually agreed to handle it or whether you have assumed it. Those two feel identical right up until the day they do not. This is the same distinction that separates the four levels of WordPress support services.
Three: does fixing this create the next problem? Updating an abandoned plugin can break the page it powers. Aggressive caching can break a cart. The right answer is often still to do it, but knowingly, with a restore point that has been tested, rather than at four in the afternoon on a whim.
If you want a straight read on where your own site currently sits, our free speed audit runs the performance half of this in about thirty seconds and reports what it measured rather than a score with no method attached. It will not tell you who owns your backups. Nothing automated can. But it will tell you honestly whether the pages that earn are fast, which is the half most reports get wrong by testing the homepage.
How often this is worth doing
Quarterly is the honest answer for most business sites, with two exceptions that matter more than the schedule.
Audit after any major change, because that is when things break: a redesign, a migration, a new payment or booking system, a WordPress major-version release. And audit before any season you depend on. If November and December carry your year, the audit belongs in September, when there is still time to act on it. An audit run during your busiest month is a report you will read in January.
Monthly audits on a stable site mostly generate the same list twelve times. That is not diligence. It is a subscription to a document.
Doing it yourself, or having it done
Doing it yourself is genuinely viable, and for a lot of sites it is the right call. The free tools cover performance well. Access review is tedious but it is not hard: list the administrators, remove the ones you cannot name, and note who holds the accounts above WordPress. Restore testing is the part people skip, and it is the part with the most value in it. If you only ever do one thing from this guide, restore a backup to somewhere harmless and confirm the site comes back.
Having it done makes sense when the site carries real revenue, when the findings need weighting against a business you would have to explain to a stranger, or when the honest answer to “who owns this” is currently nobody. That last one is not a tooling problem and no audit will fix it, which is exactly why it belongs in the audit. It is also the reason managed WordPress hosting exists as a category.
What we would push back on either way: an audit that ends in a list is an unfinished audit. The deliverable is a decision about the next thirty days, with the things that cost nothing explicitly marked as costing nothing. If the report you receive does not do that, ask for it. You paid for judgment, not for output.
Frequently asked questions
What is a WordPress site audit?
A structured review of a WordPress site’s uptime, performance, security posture, update health, and backups, weighted against what the site is actually for. It differs from a scan in that a scan reports what matched a rule, while an audit decides which findings change what you do next.
How long does a WordPress site audit take?
An automated performance check takes seconds. A useful full audit on a business site takes a few hours, and most of that time goes to the parts tools cannot do: access review, restore testing, and weighting findings against how the site earns.
What should a WordPress audit report include?
Findings with their measurement method, not just figures. A severity view that separates what costs money from what does not. A named owner for each action. And a recommendation for the next thirty days rather than an undifferentiated list.
How often should I audit my WordPress site?
Quarterly for most business sites, plus after any major change (redesign, migration, new checkout, a WordPress major release) and before any season the business depends on.
Is a free WordPress audit tool good enough?
For the performance half, often yes, provided you test the pages that earn rather than the homepage. No automated tool can review who holds your administrator accounts or confirm your backups restore, and those are usually where the real findings are.
