Method
Where the data comes from, and how the score is computed.
Nothing in a report is inferred or generated. Each value is either what a named source returned or an explicit statement that the source could not be reached.
Where the data comes from
A scan makes requests from your browser to the public services below. None of them requires an API key, and none of them is operated by this site. The report shows the source next to each check, so a value can always be traced back to the service that supplied it.
Every DNS answer: A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, SRV, DS, DNSKEY, TLSA and HTTPS records.
The same DNS answers, used as the fallback when Google does not respond.
Certificates issued for the domain, their issuers, validity windows, and the hostnames they name.
The registration record: when the domain was registered, when it expires, the registrar, the registry status flags and the nameservers.
The earliest and most recent capture of the address, which bounds how long the site has existed in public.
The domain's daily rank in a research list built from four providers, used as context rather than as a verdict.
Whether the product named in the response appears in the catalogue of vulnerabilities with confirmed exploitation in the wild.
The estimated probability that a matched CVE is exploited in the next 30 days, with its percentile.
The raw response headers of the target, including every redirect hop, as a status line and header block.
Open ports observed on the address, the hostnames and CPEs linked to it, and the CVEs associated with those services.
Geolocation and the autonomous system announcing the address.
Threat pulses that name the domain or the address, and the passive DNS record of which hostnames have resolved to the address.
The document exactly as the site sends it, used whenever the site permits a cross-origin read. This is the preferred route because the bytes and the element tree are the site's own.
The target document as HTML, when the site does not permit a direct read. Used by the content, privacy and SEO checks. Also used to retrieve robots.txt and sitemap.xml.
Title, description, language and Open Graph fields. A fallback used only when the reader fails, and never treated as a full document.
Whether Google holds a malware or phishing verdict for the URL, read from the keyless transparency report rather than the API that requires a key.
Whether the domain appears in a feed of compromised sites, now or historically, matched through parent domains.
Whether a hostname appears in a live list of phishing URLs.
The autonomous system announcing each nameserver's address and the website's own address, so the report can say whether DNS is hosted separately from the site.
An estimate of the carbon dioxide emitted by one page view, with the percentile that places the page among those the model has measured.
Headings, alternative text, form labels, language, duplicate identifiers, canonical and robots directives, script and iframe sources.
How the score is computed
Each of the 30 checks carries a weight of 1, 2 or 3. A status maps to a fixed fraction of that weight. The score is the sum of the fractions earned divided by the sum of the weights that were actually scored, multiplied by 100 and rounded to the nearest integer.
A check whose status is unavailable or skipped is removed from both the numerator and the denominator. It contributes nothing and costs nothing. If no check produced a verdict, the score is 0 and the grade is F, and the report says that nothing could be measured.
- pass1.0
The rule was met.
- info0.85
An observation, not a judgement. Scored just below a pass.
- warn0.55
Worth fixing, not severe alone.
- fail0.1
The rule was broken. Not zero, because the check did run.
- unavailableremoved
Dropped from numerator and denominator.
- skippedremoved
Dropped from numerator and denominator.
The resulting score maps to a grade by fixed bands. There are no curves, no per-site adjustments and no hidden bonuses.
- A90 and above
- B78 to 89
- C64 to 77
- D50 to 63
- E32 to 49
- Fbelow 32
Why unavailable is not a pass
A pass is a claim that a source answered and the answer was correct. If the source did not answer, there is nothing to claim. Counting an unreachable source as a pass would mean a site behind a strict firewall, or one that rate limits the proxy, scores better than a site that answers honestly and has a weak header. It would also make the score rise as the scan learned less. So an unavailable check is removed from the arithmetic entirely, the report prints the count of checks that could not run, and the score is described as being computed over the checks that did. A scan where four checks answered and the rest could not run is an A on four checks, not an A on the full set.
The limits
CORS. A static page can only read a cross-origin response that sends an Access-Control-Allow-Origin header. Most sites do not, which is why the document is read through a proxy that does. Where a source omits the header, the check reports unavailable rather than guessing at the body.
Bot walls. A Cloudflare interstitial, a consent wall or a CAPTCHA is not the page. The document layer recognises the common markers and flags the document as an interstitial instead of analysing it, because analysing a challenge page and reporting on it would be a silent lie about the site.
Rate limits. Several sources limit by IP. The header proxy and crt.sh are the two that fail most often under load. A rate-limited response is reported as unavailable with a note, and re-running the scan usually succeeds.
Staleness. Shodan InternetDB and crt.sh are indexes, not live probes. Shodan reports ports it observed at some earlier crawl; a port opened or closed since then will not be reflected. crt.sh reports certificates that were logged, which can lag issuance by minutes to hours. Neither is a port scan or a live TLS handshake.
One document, one moment. The content checks read a single fetched document. A page that varies by user agent, by geography or after JavaScript runs is read as the proxy saw it. Nothing is rendered, so no value that requires layout, computed style or script execution is claimed.
What a finding is judged against
Every finding can carry a reference. These are the specifications the checks cite, and the part of each that a finding is measured against.
SPF record syntax, lookup limits and the all mechanism.
DMARC policy, alignment and reporting addresses.
The apex HTTPS record that tells a client which protocols and endpoints the origin supports.
The _smtp._tls record that reports failed TLS negotiation to mail hosts.
The registration record format used in place of WHOIS.
Selector records and key material published in DNS.
HSTS max-age, includeSubDomains and preload.
Which certificate authorities may issue for the domain.
The format and location of a security contact file.
robots.txt directives and how a crawler must read them.
Success criteria for names, roles, language, headings and alternative text.
Certificate lifetime, key strength and issuance rules.
Where no specification covers a check, the report says so and the finding stands on the measured value alone. The catalogue of 30 checks in 11 groups is on the checks page. The scoring code itself is in the repository at the source.