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 full-weight 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, snoozed, blocked, and verified issues are excluded (see "What does not change the score" below).

The score has a protective floor at 35 unless a full-weight critical or a cap-eligible finding is active; the hard floor is 5. Any active issue also keeps the score below 100, even when its rounded deduction would be zero. Historical scan artifacts use 0 for missing check coverage; that is not a verdict that every check failed.

Why diminishing returns

The deduction model gives the first few serious findings the largest effect:

• The first serious issue really matters. One full-weight critical without a security cap lands you at 85. One high lands at 91.
• Large backlogs have diminishing deductions. Fifty findings do not cost fifty full deductions. Removing a finding reduces the underlying deduction, but rounding, saturation, a floor, or the security cap can leave the displayed integer unchanged.
• Severity alone does not impose a cap. Two full-weight criticals without a security cap land at 72; clearing one moves the score to 85.

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 use Block after establishing 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 weighs severity first, but confidence matters in three places:

• A needs review finding contributes 0.5 to its severity's effective issue count before diminishing returns are applied. Other confidence levels contribute 1.
• 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.

This halves its contribution to the count, not exactly its final points deduction: one needs-review critical produces a score of 92, before any other findings. It also ranks lower and cannot trigger the security cap. The separate ranking weights are in Understanding findings.

What this means in practice

A few patterns you'll see. These examples use full-weight findings without a security cap unless stated otherwise:

• 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. Its effective count is 0.5 (92 on an otherwise clean site) while you review, fix, or block it if it does not apply.

Risk categories

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

• Security
• Performance
• SEO
• Accessibility
• Privacy & Policies
• 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 until the next scan; if it detects them again, they return and count again.
• Snoozed issues stay out of the score until the snooze runs out.
• Blocked issues (for example, a finding that does not apply or work blocked by an external dependency) stay out across future scans until you reopen them.
• 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.
4. The underlying deduction fell without crossing the next integer, or the score remains at a floor. Use the issue's verification result to confirm the fix independently of the headline number.