Why do two audit tools give different scores?

Coverage differs enormously. One tool may run a few dozen checks, another several hundred, and the overlap is smaller than the names suggest.

Scope differs too: some audit one page, some crawl the site, some include DNS, mail authentication and TLS, and some stop at the HTML.

A tool that does not check something cannot penalise it, so a narrow tool can return a higher score for the same site simply by looking at less.

Comparing two scores therefore compares two different questions. The overlap in findings is the only part where the comparison means anything.

Every score assigns a cost per finding, and those costs are a product decision rather than a property of the web.

VeriFixScan weights by impact, on a published scale: a critical finding weighs 10, high 6, medium 3, low 1.5.

It also distinguishes severity: a failing check loses its full weight, a warning loses 0.35 of it, and informational or unverifiable results cost nothing.

Duplicate findings on one subject are damped — the first counts fully, the second at half, the third at a third — so a single misconfiguration producing four related findings does not get charged four times.

Another tool making different choices on any of those three dimensions produces a different number from identical observations.

Plenty of things cannot be verified from outside: what happens behind authentication, whether a header is set on routes the crawl did not reach, whether a detected technology is current.

One tool may treat an unverifiable item as a pass, another as a failure, and a third may exclude it from the score entirely.

VeriFixScan excludes it and reports coverage separately — the share of applicable checks it could actually verify — so a high score with low coverage is visibly different from a high score with high coverage.

It also discounts by confidence: something observed directly counts fully, something inferred counts at 0.75, and something not publicly verifiable at 0.4.

A tool that silently treats unknowns as passes will always score higher, and the difference says nothing about the site.

Crawl limits differ, so one tool may have seen 50 pages and another 500 of the same site.

Rendering differs: a tool that executes JavaScript sees a different document from one that reads the served HTML.

Bot filtering affects tools unequally — one is served the real site and another receives 403 on half the URLs.

Geography and caching mean two tools can genuinely receive different responses at the same moment.

Before comparing anything, check how many pages each tool actually reached. That single number explains a surprising share of disagreements.

Individual findings, not scores. "Both tools report missing HSTS" is a fact; "one says 62 and one says 91" is two opinions.

The evidence behind a finding. A report that names the URL, the header and the observed value can be verified by hand in a minute.

The same tool over time. A score is most useful as a trend against itself, where the weighting is held constant and only the site changes.

Coverage alongside the score, where a tool reports it. A score built on half the checks is a different claim from one built on all of them.

Treat it as a summary for people who will not read 300 findings, not as a measurement of quality.

Never chase the number itself. Fixing the findings moves it; optimising for the score optimises for one tool's weighting.

Expect a large jump when one critical finding is resolved, and small movements afterwards. That is the impact weighting working, not a scale problem.

VeriFixScan's score carries a version number precisely because the weighting can change, and a score from one version is not comparable to another.