How the scanner works, and what it cannot see

The scanner fetches your page over HTTP, parses the HTML it receives, and runs five independent rule sets against it.

What it checks

• SEO — titles, meta descriptions, heading hierarchy, canonicals, robots directives, Open Graph, structured data, internal linking and anchor text.
• Accessibility — alt text, form labels, landmarks, language declaration, link names, focus order hazards, iframe titles, viewport zoom, and contrast where it can be computed.
• Security — HTTPS, mixed content, HSTS, CSP, frame protection, MIME sniffing, referrer policy, cookie flags, insecure form targets and version disclosure.
• Performance — server response time, document size, render-blocking resources, image dimensions, lazy loading, redirect chains and compression.
• Content — text volume, calls to action, placeholder text, duplicate headings and page structure.

How scores are calculated

Each finding carries a severity weight: critical 12, serious 6, moderate 3, minor 1. Those are summed per category, and the score is 100 - 8 × √penalty.

The square root is deliberate. With a linear scale, any real site bottoms out at zero and the number stops being useful for tracking progress. This way your first critical issue costs about 28 points and your twentieth minor one costs almost nothing, which matches how much each actually matters.

The overall figure is a weighted roll-up: SEO 30%, accessibility 30%, security 20%, content 12%, performance 8%.

What it cannot see

This is the important part.

The scanner reads server-rendered HTML. That is exactly what search crawlers index, so it is the right lens for SEO. But it means:

• Content rendered by JavaScript after page load is invisible to it — and, notably, often invisible to crawlers too, which is itself worth knowing.
• Contrast can only be computed where colours are resolvable from the markup. If your styles live in a stylesheet, the report says contrast needs a manual check rather than guessing.
• Performance findings are structural. They are not Core Web Vitals, which need a real browser and ideally field data from actual visitors.

The honest headline

Automated accessibility testing of any kind catches roughly a third to a half of real WCAG problems. Keyboard traps, focus order, whether your alt text is accurate rather than merely present, and whether your error messages make sense all need a person.

A clean report is a floor, not a certificate.