How a site is graded
The scoring is fixed: the same settings always produce the same grade. Here is exactly how, so a score can be checked rather than taken on trust.
A hundred points, minus what is wrong
Every site starts at 100. Each weakness deducts points sized to its risk, and a couple of good practices add a few back. The number is capped at 0 and 100 and mapped to a letter, A through F.
Content over presence
We read the rules the way a browser reads them. What costs points, above all: code written loose in the page, settings that allow everything, and shared platforms where anyone can drop harmful code. Modern, safe exceptions are not held against you, because the browser already ignores what it should.
The shape of the policy, not who is in it
We grade the policy's shape, not the parties it names. Every address the policy allows is another place code can load from, so a short, specific list permits less than a long one, and a wildcard that opens a whole domain is no limit at all. A policy that names a few addresses scores better than one packed with them, whoever those addresses belong to. Whether a named party can be trusted is a judgment this tool does not make.
A serious failure caps the grade
Some findings put a ceiling on the grade regardless of the points, because you cannot average your way out of them. A site that allows loose code in the page, or that answers over an unencrypted connection (http), holds the grade down no matter what else is right.
No rules count as the worst rules
Sending no security rules at all is not a neutral absence. It leaves the page exactly where wide-open rules leave it, so it is graded by running that wide-open equivalent through the same checks. The number is derived, not asserted, which means the tool can never tell you that removing a security setting improves your grade.
Not tested is never a failure
A check that timed out or could not run is reported as not tested, worth zero points, with the reason. A check that did not run tells you nothing about the site, and reporting it as a red cross would be inventing a result.
Who can fix it
Each finding names where a fix can live: your application, a web server, the CDN, the hosting provider, DNS or the network. Usually more than one. That is the difference between an afternoon of work and a phone call, and it turns a verdict into something you can act on.
What is deliberately not tested
The tool reads only the security settings a site sends with its response (its headers) and a few outside-in signals. It does not run a browser, so rules written into the page itself rather than sent with it are not read, and parts that load only while the page runs are not seen. It does not test the fine detail of the encryption, because that would mean offering weak encryption. When something is not measured, it is said plainly, and absence of a finding is never presented as proof that nothing is there.