How We Grade Website Health

Design goals

We built the check for three audiences that usually talk past each other: developers who need evidence, small-business owners who need priorities, and agencies who need a shareable handoff. That means:

• Live data — results come from probes at check time (DNS, TLS handshake, HTTP headers, public mail-related records), not a stale crawl archive.
• No vanity score as the product — a single number encourages gaming and hides whether the failure is “expired cert” or “missing Permissions-Policy.”
• Actionable language — each finding should answer: what broke, who feels it (visitors, mail, SEO bots), and what to change first.
• Honest limits — we are not a pentest, not a WAF, and not continuous monitoring from every continent.

Severity model

Findings are grouped into three practical buckets:

1. Priority / critical — something that breaks trust or delivery now: expired or hostname-mismatched TLS; MX missing or non-resolving when the domain is expected to receive mail; core DNS pointing at a dead end for the hostname users type.
2. Warning — elevated risk or impending failure: certificate nearing expiry, incomplete email authentication (e.g. SPF present but DMARC absent on a sending domain), contradictory answers across major resolvers, outdated TLS versions still offered.
3. Info / recommendation — hardening and clarity: additional security headers, robots.txt hygiene, performance headroom. These matter, but they should not drown out a dead certificate.

Context matters. A static brochure site with no outbound mail is not graded the same way as a store that sends order receipts. The report text calls out when a gap is catastrophic versus optional hardening — read the explanation, not only the color.

What each module is responsible for

TLS / SSL — We complete a handshake to the hostname on 443 and inspect the presented leaf certificate (validity window, name coverage, issuer, protocol). We care about what browsers will see on that name, including common apex vs www mismatches. Details: SSL Checker.

DNS — We query public DNS for the records that make a site and its mail reachable. Inconsistencies and missing essentials surface here; deep record browsing lives in DNS Lookup and DNS Propagation.

Email authentication — MX resolvability plus SPF (and related TXT signals) so “site moved, mail died” is visible in the same report as HTTPS. Deeper rollouts: MX Validator and SPF, DKIM & DMARC.

Security headers — Response headers that reduce clickjacking, mixed content fallout, and XSS blast radius (HSTS, CSP, frame options, and related). Absence is often a warning or info depending on platform constraints — many managed hosts set these at the edge. Use Security Headers / Header Inspector for raw evidence.

Crawl / ads signals — robots.txt (and ads.txt when relevant) so you do not accidentally block indexing or leave publisher files inconsistent after a redesign.

Performance snapshot — Time-to-first-byte and related timing from our vantage point. It is a signal, not a lab Lighthouse substitute from every city.

Full check extras — Path and common-port visibility from our infrastructure when you need to know whether a firewall change left SSH or a database port exposed. Authorization still applies — only test systems you own or may assess.

What we intentionally do not do

• Store your queried domains or report history in a user profile
• Claim malware / phishing “safety” scores from third-party blacklists as the core product
• Replace authenticated security testing, dependency scanning, or SOC monitoring
• Guarantee identical results from every network path (CDN anycast and DNS TTL make that impossible)

How to use the grade in practice

Fix priority items first, re-run after DNS TTL, then schedule warnings. Share the priority list with contractors as the acceptance criteria for a migration. For section-by-section reading tips, continue with How to Read a Website Health Report. For launch timing, use Pre-Launch Audit.