What the scanner actually does

The requests it makes

A scan is a handful of real HTTP requests made the moment you press Scan. In order:

1. The document itself, over HTTPS, following redirects up to eight hops. Each hop is recorded, and socket events are timed separately so DNS, TCP, TLS handshake and time-to-first-byte are measured rather than estimated.
2. A TLS handshake on port 443, offering ALPN, to read the certificate chain, expiry, SAN list, negotiated protocol and cipher — and to find out whether HTTP/2 is advertised.
3. DNS queries for A, AAAA, MX, TXT, NS, SOA, CAA and _dmarc.
4. /robots.txt, parsed for the user-agent groups, Disallow rules and Sitemap directives.
5. The sitemap, from robots.txt if declared, otherwise /sitemap.xml and /sitemap_index.xml.
6. A deliberately nonexistent URL, to see whether a missing page returns 404 or a soft 200.
7. Port 80, to check the HTTP → HTTPS redirect and whether it is permanent.
8. The other hostname — www if you gave the apex, apex if you gave www — to check they do not both serve content.
9. Up to twelve subresources, for real sizes, compression and cache headers. Each is a GET whose socket is closed as soon as the headers arrive, so almost nothing is actually transferred — a HEAD would be cheaper still, but servers omit Content-Encoding when there is no body, which makes every compressed asset look uncompressed.

That is roughly 20 to 25 requests. It takes a few seconds and puts no meaningful load on the target.

How the score is built

Each check carries a weight reflecting how much it matters in practice, not how easy it is to detect. A pass earns the full weight, a warning earns half, a failure earns none. Findings marked informational are reported but never scored, so a site is not penalised for something the scanner cannot judge — the presence of a CDN, for instance.

The overall figure is the weighted total across every scored check. It is a triage number: useful for deciding what to look at first, and not a substitute for Search Console, real-user data, or reading your own logs.

What it cannot see

Being honest about this matters more than the score does.

• It does not execute JavaScript. The HTML it analyses is what the server sent. On a client-rendered site the word count, headings and links will look thin — which is itself worth knowing, because that is close to what a crawler sees on its first pass.
• It measures one request from one location. Your visitors are elsewhere, on worse connections. For real numbers use field data from the Chrome UX Report or your own instrumentation.
• It cannot produce Core Web Vitals. LCP, INP and CLS require a rendering browser and, properly, real users. Nothing that makes a single HTTP request can report them, and tools that claim to are modelling, not measuring.
• It scans one URL. Site-wide problems — orphaned pages, duplicate clusters, internal link structure — need a crawl.
• Headers may belong to a CDN, not your server. If a proxy is detected it is reported, because that changes who owns each finding.

Privacy

No account, no stored scans, no third-party scripts on any page of this site, and no analytics tag in the scanner. The domain you type is used to make the requests described above and is not written to a database. Server access logs record requests as any web server does.

If you are scanning someone else's site

Everything here is a request any browser could make — publicly served pages, public DNS, a public TLS handshake. It is not a vulnerability scan, it does not probe for software flaws, and it sends nothing a visitor would not send. Scanning a site you do not run is fine, and competitive comparison is a legitimate use.