Open a dashboard with 60 client sites and every one of them is generating signals: pending updates, PHP version, certificate expiry, last backup, uptime, failed logins, vulnerability findings, disk usage, cron health. Call it forty per site if you count honestly. That is 2,400 data points, and you have a Tuesday morning to decide which site needs you first. A health score exists to answer that question, and its usefulness comes from a single design decision: sort worst first.
Why forty signals do not help you
Every one of those signals is individually reasonable to track. The trouble is that a wall of them has no order. A site with a pending minor plugin update and a site with a certificate expiring tomorrow both show an amber flag. A site that has not backed up in nine days looks identical, on a list of badges, to one running an old PHP version.
Humans handle this badly. We scan for red, fix the first red thing, get interrupted, and never return to the second. Meanwhile the one quiet, unglamorous problem, such as a backup job that stopped running in August, sits in the middle of the list until the day you need it.
The job of a health score is triage. It does not need to be a perfect measure of site quality. It needs to put the site most likely to hurt you at the top of the list.
What a good score should do
A useful score has four properties, and it is worth checking any tool's score against them.
It is a single number you can sort by. If you cannot sort 60 sites by it in one click, it is a report, not a score.
It weights signals by consequence, not by count. Ten trivial warnings must not outrank one critical finding. An active vulnerability or an unreachable site should drag a score down far more than a stale readme file. If your score averages everything equally, a site with one serious problem and thirty perfect signals will look healthy, and that is the exact failure you were trying to avoid.
It explains itself. A score of 62 is useless without a reason. You need to click and see: backup is eight days old, two plugins have known vulnerabilities, PHP is two versions behind. The number gets you to the site, the breakdown tells you what to do.
It moves when you fix things. If you apply the updates and the number does not change, you will stop trusting it within a week.
Why worst-first beats alphabetical
Most agencies keep their site lists in whatever order they were added, or alphabetically by client. Both are orderings that have nothing to do with risk.
Here is some arithmetic. Suppose you manage 60 sites and can give each site check three minutes if you review them all. That is three hours, which you will not spend, so in practice you skim and stop. Now suppose that in any given week five of the sites have something that deserves action. If you review alphabetically and give up after 20 sites, the chance you have seen all five is low. If you review worst-first and give up after 20, you have seen all five by definition, because they were at the top.
The exact numbers are illustrative, but the mechanism is not: sorting turns partial attention into full coverage of what matters. It is the same reason hospitals triage instead of seeing patients in the order they arrived.
The signals that should pull hardest
Different agencies will weight things differently, but a sensible ordering of consequence looks like this:
- Site down or unreachable. Nothing else matters until this is fixed.
- Active known vulnerabilities, especially in plugins that are publicly exposed.
- No recent successful backup. Not a failed update, but the absence of any restore path.
- Expiring certificate or domain. Low likelihood, total impact.
- Outdated PHP or core versions. Slow-burning risk, rarely urgent on a given day.
- Performance regressions and minor pending updates. Real, but they can wait for the weekly window.
You can argue about placement, and you should tune it to your clients. A membership site that takes payments deserves a heavier weight on uptime and security than a five-page brochure site. The principle is that the ordering exists on purpose, in writing, and not by accident of what your dashboard happened to show first.
Using the score without being ruled by it
A score is a filter. It is not a verdict on the site or on your work.
Two habits keep it honest. First, review the top of the list daily and the whole list weekly. The top ten is your triage; the weekly pass catches sites that are quietly sliding. Second, look at trends, not just levels. A site that has drifted from 91 to 78 over a month is more interesting than a site that has sat at 70 for a year because the client refuses to let you update their theme. That one needs a conversation, not a daily glance.
Watch out for the opposite failure too. A score of 100 does not mean nothing can go wrong. It means the signals being measured are fine. Something not measured can still be broken, which is why you keep a human look at checkout flows and forms.
Clients can read it too
There is a side benefit that agencies underuse. A single number with a plain-English reason behind it is easy to put in a client report. "Your site is at 94; the one open item is a plugin update we are holding back for testing" is a fine sentence for a monthly email. It shows attention without a jargon lecture.
It also makes the awkward conversations easier. If a client has declined a PHP upgrade for a year, "the score has been held at 70 by this one item, and here is the risk" is less personal than "I told you so."
Where this leaves you
Decide what hurts most, weight it accordingly, and view your portfolio worst-first so that your limited attention lands on the sites that need it. Look at the breakdown before the number, and track the trend more than the level. WPClientHub computes a health score per site and lets you sort your portfolio by it, and it is free for 3 sites if you want to try this on a real client site: sign up free.