The SiteCMD Score

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. In the current lifecycle, New and Regressed are active. Ignored, blocked, and verified issues are excluded (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: the security cap

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 deliberately narrow security cap. An active finding caps the score at 49 (or leaves it lower if the ordinary deductions already put it there) only when all three conditions are true:

1. Its normalized severity is Critical.
2. Its check ID belongs to the small, audited cap-candidate list.
3. Its producer supplied explicit High or Confirmed confidence.

Membership in the candidate list is not itself an exploit verdict. It only says that this class of finding is serious enough to cap the score when the concrete evidence also clears the severity and confidence gates.

Today the live-site case that can automatically clear all three gates is a public /.env response whose sampled body matches env-file structure and includes a substantive secret-looking assignment. The source scanner keeps direct request-to-SQL, command, code-execution, file-inclusion, unsafe-deserialization, and template-injection patterns in the candidate class, but its static matches are emitted as Needs review because validation, control flow, reachability, and deployed configuration are unresolved. Those initial static findings do not cap the score.

Credential-shaped strings in ordinary page JavaScript, committed-secret patterns, CORS heuristics, SSRF heuristics, and other review-only matches do not automatically qualify. They still deduct points at their assigned severity; they simply cannot invoke the hard cap from pattern evidence alone.

The cap lifts as soon as no cap-eligible finding remains active. Fix and verify the finding, or mark it not applicable only after you have established that the evidence does not represent the claimed condition. There is currently no control for manually changing a finding’s confidence label.

If your score is exactly 49, a cap may be active, although ordinary deductions can also land on the same number. Review the active Critical findings and their evidence before assuming which case applies.

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 security 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.
• A content-validated public /.env finding at Critical/High confidence, nothing else. Capped at 49 while it remains active. Remove public access, rotate any real credentials, and verify the finding; the underlying score then returns to 100.
• A Critical candidate at needs review confidence. No cap. It deducts like any Critical (85 on an otherwise clean site) while you review, fix, or mark it not applicable.

Risk categories

SiteCMD groups findings by risk category for filtering and triage. Live-site findings use the web categories:

• Security
• Performance
• SEO
• Accessibility
• Compliance
• Config
• Polish

Source-audit findings use the code-scan categories:

• Security
• Database Analysis
• AI Safety
• Architecture
• Operations
• Dependencies
• AI Setup

The category bucket is metadata supplied by the engine that produced the finding: live-site security checks land in Security, source-audit dependency findings land in Dependencies, and operational source findings land in Operations. Categories help explain and filter the evidence; they are not separately weighted inputs that are averaged into the headline. The SiteCMD Score is computed once from the deduplicated active findings across all sources.

Some historical scan views also retain engine-specific category scores. Those are diagnostics for that scan artifact, not additional SiteCMD Scores and not inputs that are averaged on the frontend.

What does not change the score

• Ignored issues are removed from active counts and the score entirely.
• Blocked issues (waiting on a vendor, a pending design decision) 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 moves to Regressed and counts again.

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:

1. A new check shipped in a SiteCMD update and found a real issue that was already there.
2. 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:

1. The fix is in source but hasn’t shipped. The live-site engine still sees the broken version.
2. 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.
3. The security cap is in effect. While a cap-eligible finding remains active and the ordinary score is above 49, other fixes will not move the displayed headline above 49. Clear or correctly disposition that finding first.