Your SiteCMD Score is a number out of 100. It’s the headline answer to “how is this site doing?” Everything on the Dashboard ladders up to it.

This page explains the math behind the number so you can read it accurately, predict how a fix will move it, and avoid the two common misreads.

Where the number comes from

The score starts at 100. Each active issue deducts points based on its severity. An issue is counted once, not once per location: a code issue that shows up in six files is one finding and one deduction.

The first issue of each severity costs the most:

Severity	First issue costs
Critical	15 points
High	9 points
Medium	4 points
Low	1.5 points

Each additional issue of the same severity costs slightly less than the one before. How fast that decays depends on the severity:

Criticals and highs decay slowly. One critical costs 15 points, two cost 28.5. One high costs 9, three cost 24. A pile of serious issues keeps mattering.
Mediums and lows saturate. A run of mediums tops out around 22 points no matter how many you have; lows top out at 6. Each one past the first costs less than the last, so a long tail pulls the score down without cratering it.

Only active issues count. Anything snoozed, ignored, blocked, or verified is out of the math entirely (see “What does not change the score” below).

Two boundary cases worth knowing: the score never displays below 5, so even a badly broken site has somewhere to climb from. And a score of 0 means no checks ran at all, not that the site failed everything.

Why diminishing returns

The deduction model is built so that fixing always moves the number:

The first serious issue really matters. One critical, nothing else, lands you at 85. One high lands at 91. The score reacts immediately to the things worth reacting to.
A backlog doesn’t pin you to the floor. Fifty findings don’t cost fifty full deductions, so fixing five of them visibly moves the score instead of being lost in saturation.
Identical work never reads the same as no work. Two criticals land at 72; fix one and you’re at 85. Under a hard “any critical means 49” rule, both states would read identically and fixing one would do nothing. Here every fix pays.

The one exception: exploitable security issues

There are no severity caps. A critical doesn’t lock your score to some fixed number, and neither does a high; they just cost the most points.

The one exception is a finding that is genuinely exploitable as shipped: an exposed secret or credential in source, SQL injection, server-side request forgery, a database reachable from client code, an attacker-controlled redirect, a checkout price taken from request input, and a short list of similar conditions. While one of those is active, the score is capped at 49 (lower, if other issues already put it there), no matter how clean everything else is.

The reasoning: an actively exploitable hole means the site is effectively compromised until it’s fixed. A 92 with an exposed API key buried in the breakdown would be a lie, so the cap keeps the headline from reading healthy over a live hole - the same way SSL Labs caps a grade on a named, exploitable condition instead of averaging it away. The list of conditions is short and audited; nothing lands on it unless shipping with it live is genuinely unsafe.

Two things keep the cap honest:

It only triggers for findings SiteCMD is confident about (confirmed or high confidence). A needs review finding never pins the score, so a possible false positive can’t slam the headline into the red.
It lifts the moment the issue is resolved. Fix it (or mark it not applicable, if it genuinely is), and the score returns to whatever the underlying math says.

If your score is exactly 49, look for the exploitable finding. The Dashboard flags it, and fixing anything else won’t move the headline until it’s gone.

Confidence and ranking

The headline number counts issues by severity alone, but confidence still matters in two places:

A needs review finding never triggers the exploitable cap, as above.
Each finding’s impact, the number the Issues list sorts by and the category breakdown sums, weights its severity by confidence, status, and how many places it shows up. A confirmed critical outranks a needs-review critical; an issue on five pages outranks the same issue on one.

So an uncertain finding still costs its severity’s deduction, but it sits lower in the list and can never be the thing that pins your score in the red. The exact weights are in Understanding findings.

What this means in practice

A few patterns you’ll see:

A single critical, nothing else. Score 85. It stings - it’s the single biggest deduction - but it doesn’t tank you. Fix it and you’re back at 100.
One high, nothing else. Score 91. Worth fixing, not worth panicking over.
Two criticals. Score 72. Fixing one moves you to 85: real, visible progress for real work.
A backlog of mediums. Ten mediums land you around 81. The first costs 4 points; the tenth costs well under one. Clearing the worst few barely moves the headline, so triage by what actually matters instead of chasing a clean medium list.
An exposed API key in a committed file, nothing else. Pinned at 49 until the key is removed and rotated. The moment it’s gone, the score jumps back to 100.
The same finding at needs review confidence. No cap. It deducts like any critical (85 on an otherwise clean site) and waits for you to confirm it, fix it, or dismiss it.

Risk categories

The Dashboard breaks the score down by risk category:

Security
Performance
SEO
Accessibility
Database
Dependencies
Reliability
Compliance
Polish
AI safety
Architecture

Categories are aggregated by total impact (the sum of per-issue impact), not by issue count. A category with one confirmed critical will appear at the top of the breakdown, ahead of a category with twenty lows.

The category bucket an issue lands in is determined by the engine that found it. Live-site security checks land in Security. Source-audit dependency findings land in Dependencies. Operational gaps from the source audit land in Reliability.

What does not change the score

Snoozed issues are paused until the snooze date and do not count toward your score in the meantime.
Ignored / not-applicable issues are removed from active counts and the score entirely.
Blocked issues are flagged with a reason (waiting on a vendor, a pending design decision) and stay out of the score while blocked.
Verified (fixed) issues are removed from active counts. If a later scan re-finds the same issue, it gets reopened.

See Working with issues for the full lifecycle.

The two common misreads

“The score is dropping but I haven’t changed anything.” Two real things can do this without code changes:

A new check shipped in a SiteCMD update and found a real issue that was already there.
An integration (uptime, analytics, search console) reported new evidence: a slowdown, a drop, an outage.

“I fixed an issue and the score didn’t move.” Usually one of:

The fix is in source but hasn’t shipped. The live-site engine still sees the broken version.
The issue is still in New. The score moves when the issue leaves the active list: use Verify on the issue to re-run the relevant check now, or wait for the next scan to confirm the fix.
The exploitable cap is in effect. While an actively exploitable finding is open, the headline stays pinned at 49 no matter what else you fix. Clear that finding first.