How the score is calculated

Each category starts at 100. Every failing or warning check subtracts its rule's published deduction, scaled by how sure we are and by how many times the same fault repeats, and bounded by a ceiling on the family of related faults it belongs to. The overall score is the weighted mean of the categories we were able to measure, with a handful of faults severe enough to cap it outright.

categoryScore = min(max(0, 100 − Σ_families min(familyCap, Σ_findings
                  deduction × statusMultiplier × confidenceMultiplier × repeatMultiplier)),
                  gateCap, verificationCeiling(verifiedShare))

verifiedShare = Σ_modules (1 − priced gaps)  /  Σ_modules (1 − unpriced gaps)
                  each module's gaps sized and classified by the module itself

overall       = min( Σ weight × categoryScore  /  Σ weight , gateCap )
                      over the categories that were actually measured

Nothing is hidden behind that. Open any finding on a report and it shows the rule, the deduction, the multipliers that were applied and the cap it landed under; the numbers in the drawer add up to the number printed next to it, and a test proves they do.

The weights are a product judgement about what matters to a domain owner — explicit, versioned, and written down here so you can disagree with a specific number rather than with a black box. They are not derived from a risk calculation, and we do not claim they are. Internet.nl, the only comparable tool covering more than one domain of risk, avoids the question by keeping its web and mail scores separate rather than blending them; we blend them, and the weights below are where that choice is visible.

A rule declares a deduction — how much it removes from its category's 100. Three multipliers stand between that number and the score.

Status: did the check fail, or merely warn?

Confidence: how sure are we?

Repeats: the same fault, several times

When one rule fires more than once — the same weak cipher on four ports, the same missing attribute on six cookies — the instances are ordered heaviest first and tapered.

Ordering by weight rather than by the order modules happened to report in is what makes the score independent of scan timing, and what makes "adding a failing check can never raise the score" true.

Related rules share a ceiling. Without one, a single underlying problem that produces many findings would outweigh everything else on the report: a host with MySQL, PostgreSQL and Redis all answering the internet has one problem — no firewall — and must not be scored as though it had three, and six SOA timer complaints are one piece of DNS hygiene, not six outages.

Each cap is sized on one rule and one heuristic. The rule: no single family may take its category to zero on its own. The heuristic: the cap sits at or a little above the family's heaviest single rule, so the fault that matters most still lands at its full published weight, and at or below the family's summed deductions, so the cap can actually bind. Both bounds are asserted by a test, and the columns below let you check them yourself.

A rule that declares no family stands alone and is bounded only by the category's default ceiling of 100. That is reserved for rules that cap a category outright anyway — the gates below.

A weighted mean cannot express "this one thing is so wrong that nothing else matters". TLS is 15.8% of the scope, so a domain serving an expired certificate would still score in the eighties on the strength of its DNS and its mail. Gates are the override that makes the mean safe: a small set of faults that cap the score outright, whatever else is right.

Each gate caps its own category as well as the overall score, so a category panel can never show a comfortable number while the summary it belongs to is gated — the drill-down would otherwise contradict the headline. And a gate never fires on a guess: the confidence floor is on every one of them, because capping somebody's score at 30 on an inference is not something we could defend to them.

These bands are reasoning rather than measurement, and that is worth saying plainly. Comparing them to Observatory's or SSL Labs' bands directly would be misleading — a threshold means nothing without the aggregation function under it, and ours is a weighted mean of fourteen categories, which regresses toward the middle where a running penalty total does not. Once there is a large enough body of real scans, we intend to plot the distribution and move the boundaries if they do not separate meaningfully. We would not move the weights to fix a distribution.

A+ needs the score, and no finding at high severity or worse, and every applicable item below demonstrated affirmatively. The old rule was two absences — a high enough score and no serious complaints — which meant a domain that did everything adequately and nothing well could reach the top grade. Both comparable tools that award a top grade require an affirmative extra, and so do we.

Each is decided by the check you can already see on the report — DMARC is enforcing, so spoofed mail is quarantined or rejected, The HSTS instruction lasts six months or more, The server supports TLS 1.3 — rather than by a second, invisible test. The grade and the finding can therefore never disagree.

Missing an A+ prerequisite withholds A+ and nothing else: the domain gets an A. These decide whether the top grade is awarded; they never deduct. And within a category we did scan, silence is not credit — if the HSTS check did not produce a pass, for any reason including an error, the achievement was not demonstrated. A category that was never in the scan at all is simply not applicable: a mail-only scan has no opinion about HSTS, and denying A+ for evidence nobody asked us to gather would make the grade depend on which tool page you arrived through rather than on the domain.

The most important part of a scoring model is what it does when it does not know. A methodology page that lists weights without describing the denominator is describing a different engine.

A category we could not test is excluded, never assumed to pass

If the TLS checks did not run, TLS does not score 100 and it does not score 0. It leaves the calculation, and the weighted mean is taken over the categories that remain. Scoring it 100 is a false pass; scoring it 0 penalises a domain for our probe being down; keeping it in the denominator at 0 points is arithmetically the same as scoring it 0. Excluding it is the only honest answer, and it is why a report will tell you "TLS was not tested" instead of showing you a green panel.

A score built on part of the assessment is labelled as one

Renormalising gives the surviving categories more influence than they would otherwise have, so a partial score is not comparable to a complete one and is never presented as though it were. Any scan with an untested or partly verified category is markedpartial, and its grade is capped according to why the gap is there — the same principle as the A+ prerequisites, extended downward: a top grade is awarded for a demonstrated positive, and a check nobody ran is precisely an absence of evidence.

When the missing part is a limit on our side — the Chrome UX Report publishes no data for your site, a test only a verified owner can run, a sample we deliberately stop at, such as the number of addresses a port check connects to — the scan cannot be graded above A. A+ needs a complete assessment, and your site did nothing to lose A. When the site caused the gap — a timeout, a refused connection, an error or challenge page, an address we may not connect to — the scan cannot be graded above B, and the report says what failed. So can a gap our own run left, such as our probe host being unreachable, or a source we read — a domain registry, the Chrome UX Report — not answering at all: it is not a limit we chose, another scan may close it, and a grade that rose because of our outage would be the false pass this rule exists to prevent. The report says which it was and never blames your site for ours. Where there is more than one gap, the strictest cap wins.

The report names each test that is missing because of a limit on our side, and says that waiting or running the same scan again will not fill it. Where the missing test is one only a verified owner can run — the in-browser speed test — it offers the verification, and says plainly that verifying adds that test without lifting the cap by itself while any other test is still missing.

A report scored before 2026-10-12 recorded no cause and keeps the cap it had: no higher than B for a category not tested at all, and no higher than A for one that left a gap inside a category it did test.

A check we could not run puts a ceiling on its category's score

This is the part most scoring models get wrong, including ours until 2026-09-21. Every other lever above scales a deduction — and a check that passed, or that never ran at all, deducts nothing. Multiplying zero by any confidence is still zero, so a category whose port scan half-finished, or whose blocklist question could not lawfully be asked, went on reporting 100 / A+. The correction never reached the number.

So verification is applied as a ceiling on the score rather than as a deduction from it. Each check that ran reports, itself, what it could not verify and how much of its subject that was — a network of yours nothing connected to, two protocol versions of six never offered, one question of two with nowhere to ask it. Those shares are what the ceiling is priced from. The module knows the size of the hole it left; a scoring layer that charged every incomplete check the same flat fraction did not, and until 2026-09-21 ours charged a category by how many checks it happened to contain rather than by how much of it went unseen. Where the verified share is short of complete, the category's score may not exceed 94, falling a further 40 points in proportion to how much is missing, and never below 80 — a gap in the evidence costs a band or two, never a collapse. A category whose checks produced no result for less than 60% of them is withheld rather than capped.

A ceiling, not a deduction, because the two say different things. A deduction would appear in your breakdown as a fault of your domain, and our probe host being unreachable is not one. A ceiling says the true thing: what we saw is fine as far as it goes, and it does not go all the way. Every capped category names the gap in the module's own words — which address, which version, which file — so it is something you can read rather than something you have to infer from a number.

What we did not connect to is measured, not assumed

The port check connects to every address your domain publishes, up to eight IPv4 and eight IPv6, because two addresses of one name can be two machines with two firewalls, and the IPv6 one is the firewall most often forgotten. Each address gets the same five connections at a time it always did. It stops at eight in a family rather than connecting to every address you could publish, because a name can publish dozens and knocking on all of them is a great deal of traffic to send at one estate for one report. Where a family has more than eight, the eight are picked at random for each scan, so there is no address every scan skips. That stopping point is a limit of ours, so on its own it never holds the overall grade below A. It is still a gap in what we saw, though: the addresses it leaves out can lower the Network score, as the next paragraph explains.

On a domain publishing more than that, it leaves the rest of a family, and we will not tell you they are fine because they are probably the same machine. We check instead: if an address we did not connect to is in the same routed network as one we did — the same /24 or /48, reached through the same routing announcement — we say so and name the network, and it costs your score nothing, because the evidence is there for you to judge. If it is in a network nothing reached, that is a real gap, it is charged, and we name it. If we cannot place it at all, we say that too rather than rounding it into either answer. It is worth knowing which way we err: two machines of yours in two different networks are treated as two, so you may see a gap reported for addresses that are in practice identical. We would rather understate what we covered than overstate it.

Three kinds of gap are stated but not charged

A gap that another scan could close — a timeout, a resolver that did not reply, a network our budget did not reach — is charged in full: your domain has a state there that we did not see. A gap that no scan of ours can close is different. SSL 2.0 and SSL 3.0 cannot be offered by the TLS library we handshake with; whether your domain is on a domain-level reputation list has no source we are licensed to ask. Charging those would cap every domain identically, forever, and a ceiling that binds on every scan measures the scanner rather than the domain and tells you nothing about yours. So they are excluded from the share above and stated beside the score instead, every time, in the check's own words — never folded into a pass, and never silently dropped.

The third is not a shortfall of ours at all: a question your domain does not pose. A domain that publishes no mail servers has no mail transport to secure and no mail reputation to look up, and until 2026-09-22 we marked it down for it — the reputation area was withheld for "low coverage", which pulled the whole scan's grade to no better than B. An area with no subject is now taken out of the score's scope rather than withheld inside it: it is not counted as passing, it is not counted as failing, it is not counted as untested, and it does not shrink the share of the assessment we say we measured. The page tells you which areas did not apply, so you can see that we looked and found nothing there to check.

Below half the scope, we state no score at all

When less than 50% of a scan's scoped weight was actually measured, no overall score is shown. A number derived from a fifth of the checks is a number about a fifth of the domain, and presenting it as the domain's score is the same false pass in a different place. Within a single category the same floor applies at 60% coverage: below it the category reports "incomplete" rather than a figure.

A score is comparable within one ruleset version, and not across two

Every scan stores the scoring configuration and ruleset version it was scored under — today 2026.10.1 and 2026.10.12.32. Changing a weight, a cap or a rule's text changes what a number means, so we bump the version rather than quietly re-baselining history. When you compare two scans of the same domain, the comparison tells you which differences are your configuration changing and which are ours — because a score that moved because we changed our mind is not an improvement, and reporting it as one would be the easiest lie on the whole report.

A rule page may carry one line under its heading — "23% of the domains we could check fail this" — and this section is where that number comes from: which domains, which checks, what was done with the domains that could not be checked, and why some rules show no figure at all.

The sample, and its licence

The domains are the first 1,000 of the Majestic Million by rank — Majestic's free, daily list of the domains with the most referring subnets on the web — published under CC BY 3.0, which permits commercial use with attribution. We chose it over the other public rankings because its licence is the only one of them without a non-commercial component. The list is not redistributed here: we record the day the file was downloaded and the SHA-256 of its bytes, and print both above once a sweep is published, so anyone can confirm which list a figure came from.

A domain on this list is not necessarily a website. The ranking is by how many networks link to a domain, so the top of it holds, beside the sites a reader would expect, the domains that infrastructure lives on: CDN and asset hostnames, API endpoints, link shorteners, mail and tracking domains. Every figure is a share of domains, and a rule about a web page is measured over the domains that served one.

Which checks run

The sweep is passive. It reads the records a domain publishes, and whether each of its mail servers' addresses has a reverse name, through public resolvers over DNS-over-HTTPS; makes one plain-HTTP and one HTTPS request to the home page to see where the site sends a visitor and what the landing page's headers say; and opens one TLS connection on port 443, with no request on it, to read the certificate. The checks are the product's own modules — the same code, the same verdicts a report shows — and nothing that probes a site more actively than a browser's first visit runs at all.

What "could not check" means, and where it goes

Every domain lands in exactly one of five buckets for every rule: pass, warn, fail, could not check or not applicable. A domain could not be checked when our egress guard refused it (a name resolving to a private or reserved address is never fetched), when a module failed or ran out of time, when the module itself reported the check as a gap, or when the request budget below stopped a check before it ran. A check is not applicable when it had nothing to judge — a mail check on a domain that publishes no mail servers. Neither is a failure. The percentage on a rule page is taken over the pass, warn and fail buckets only, and the number of domains it was taken over is printed in the sentence.

The floor

A figure is shown only when at least 200 of the sample could be checked for that rule. At that size the sampling error on a percentage is at most about seven points, which is the most a figure printed to the nearest whole percent can honestly carry; and a rule checkable on fewer than one domain in five would be a statistic about whichever fifth happened to be checkable. Below the floor the page says nothing rather than something small. A rule that cannot fail or warn — one that reports a fact — carries no figure either.

How politely it is done

One domain's checks send at most 1 plain-HTTP and 1 HTTPS request to each hostname they reach; a redirect to another hostname is followed under the same limit, and a chain that would need more is stopped and counted as not checked rather than guessed at. Every request carries the published User-Agent, whose URL is the page that says what this is and how to opt out. Mail-authentication and DNS records are read from public resolvers, never from a domain's own servers, and DKIM is not checked at all: a key is published under a selector the sweep has no way to know.

Attribution

Domain list: Majestic Million, published by Majestic, used under CC BY 3.0. The counts are ours; nothing about any individual domain is published, and the per-domain results of a sweep are kept only long enough to review the counts.

All 301 rules are published with their severity, deduction, family cap and the standards they cite.