How the Site Health score works

Model pdf-health-v3 · updated 29 October 2026 · Prime Dev Force

The Site Health score is Prime Dev Force's own model. It is not an industry standard and it can't be compared with other vendors' scores. It is deterministic: the same findings always produce the same score, and you can recompute it from any JSON report. Every report names the model it was scored with.

1. Deductions

The score starts at 100. Each finding deducts a fixed number of points by severity, and the score never goes below 0.

SeverityPoints deductedTypical example
Critical40Reserved for direct, severe exposure (none of the current checks produce this level).
High20No HTTPS; expired or self-signed certificate; certificate that doesn't cover the hostname; listed on Google's Safe Browsing lists (checked through Web Risk); SPF that allows any sender (+all)
Medium8No HSTS; no Content Security Policy; no DMARC; certificate expiring within 14 days; missing intermediate certificate; TLS 1.0/1.1 still accepted
Low3No CAA; DMARC at p=none; version numbers in headers; certificate expiring within 30 days; past URLhaus reports
Info0No MTA-STS; no TLS reporting; no Permissions-Policy

2. Coverage

Coverage is the share of applicable checks that produced a definite result (no issue detected, or issue detected). Every check result is one of six outcomes:

  • No issue detected and Issue detected: definite results. They count as covered.
  • Could not complete: the check tried and failed, for example a timeout or a Cloudflare challenge page instead of the site.
  • Inconclusive: the property can't be established from outside.
  • Not performed: we didn't run it, for example no DKIM selector was given or a blocklist source isn't configured on our side.
  • Not applicable: it doesn't apply, for example MTA-STS for a domain that receives no email, or header checks when the domain has no website.

Only "not applicable" checks are left out. The other three count against coverage and are never treated as passed.

Each finding also says how sure we are: confirmed (we observed the condition itself), likely (inferred, for example a certificate taken from Certificate Transparency logs, or headers of an error page), or possible (a pattern match you should confirm, such as a malware indicator). Confidence is shown next to severity and doesn't change the arithmetic.

If coverage is below 60%, we don't show a score at all. The report says "Not enough data" and lists what we could observe.

For example, the certificate checks can't read the certificate of a site served through Cloudflare, so those three checks are "could not complete" and lower coverage a little. They don't lower the score unless a finding is raised.

3. Bands

  • Good: 90–100
  • Fair: 70–89
  • Poor: 40–69
  • Critical: below 40, or any critical finding regardless of score

4. Task priority

Findings become tasks with a priority from P1 (do first) to P4 (optional):

  • P1: critical findings, and high findings in malware indicators, blocklist reputation, exposed files, HTTPS and certificates, or email authentication, which directly harm visitors, leak secrets or expose your domain to spoofing.
  • P2: other high findings, and medium findings in those same areas.
  • P3: other medium and all low findings.
  • P4: informational suggestions.

Within a priority, tasks are ordered by severity, then area (malware, reputation, exposed files, HTTPS and certificates, email, headers, DNS, page content, CDN, security contact), then finding code.

Subdomains and pages

The weekly subdomain and page checks for verified owners are shown per host and don't change the score. The score is always the score of the homepage report, so it stays comparable over time.

Model changes

Any change to the checks, deductions, coverage rule or priority rules gets a new model version. Stored history keeps the model each score was produced with, and the dashboard's trend chart marks the point where the model changed.

pdf-health-v3 (26 October 2026)

  • Coverage: checks that weren't performed (no DKIM selector, a source not configured) now count against coverage instead of being left out. Only "not applicable" checks are left out. A free scan without a DKIM selector therefore shows slightly lower coverage than under v2.
  • A Cloudflare bot challenge or a Cloudflare 520–530 error in place of the homepage makes the web checks "could not complete", instead of judging the challenge page's headers.
  • Findings carry a confidence (confirmed, likely, possible).
  • New checks: content.third_party_scripts and disclosure.security_txt for every scan, and exposure.files for verified owners. See what we check.
  • Exposed files join the areas whose high and medium findings rank up a priority level. Deductions, the 60% threshold and the bands are unchanged.

pdf-health-v2 (26 October 2026)

  • New checks: tls.cert_expiry, tls.cert_chain, tls.protocols and reputation.blocklist, with nine new certificate findings and three reputation findings.
  • Blocklist reputation joins the areas that rank high and medium findings up a priority level.
  • Deductions, the coverage threshold and the bands are unchanged. Because more is checked, the same site can score lower under v2 than under v1 (for example if its certificate expires soon). That's a change in what we measure, not necessarily in the site. Monitoring reports the model change instead of a score-drop alert.

pdf-health-v1 (24 October 2026)

The first published model: 23 checks of HTTPS, headers, page content, CDN, DNS and email for the public scan, plus two homepage malware checks for verified owners.

What the score does not mean

A score of 100 means none of our checks found a problem. It does not mean the site is secure, malware-free or compliant with any standard. The score covers only the configuration we can observe from outside; see what we check.