SiteScanReport

Methodology

How the scan works

Every scan checks the same things, the same way, on your live site, and reads up to 50 of your pages. This page covers what we check, what automated testing can and cannot determine, and what we do when part of your site is out of reach. If a finding is in your report, we saw it on your real pages.

What we check

Accessibility

We test each page against the Web Content Accessibility Guidelines (WCAG 2.0, 2.1, and 2.2, Levels A and AA), the recognized standard for web accessibility. Every rule is checked per page and counted once across all the pages we scan, sorted into what passed, what failed, and what needs a person to review.

Security headers

We run the ten checks that make up the reference web-security header methodology, and grade the result on its scale, using that methodology’s own scoring.

SSL and TLS

We report the industry-standard TLS grade, A+ through F, whenever it is available. When it is not, we connect to your server directly, read the certificate and protocol, and report what we measured ourselves as strong, adequate, or weak, rather than invent a letter that might disagree with the standard tool.

Privacy

We check whether a privacy policy is present, whether a California “Do Not Sell or Share” opt-out link is present on your pages, and which third parties your pages contact, read from the actual network requests your site makes while we scan. We also screen your site against a major malware and phishing blocklist.

Each finding comes with what we saw, why it matters, and who usually fixes it, written in plain language by an AI model working only from your scan results, under terms that prohibit using your data to train it.

What automated testing can, and cannot, determine

Accessibility is only partly automatable, and we tell you how much.

Independent research spanning more than 13,000 pages and some 300,000 evaluated issues found that automated testing surfaces about 57% of the accessibility issues a full evaluation would catch. Measured another way, only 20 to 30% of WCAG success criteria can be tested by software at all; the other 70 to 80% need a person. So your accessibility result is a specific, verifiable starting point for a fuller review, not a stand-in for one. Where a check can run but the tool cannot decide it on its own, your report marks that specific rule for a person to confirm.

Privacy detection is presence, not legal adequacy.

We can tell you whether a privacy policy and an opt-out link exist, and which third parties load on your pages. We do not judge whether your policy is legally sufficient. Where a control is likely present but a single scan cannot confirm it, we say “couldn’t verify” instead of marking it missing.

Platform detection is best effort.

We identify common site platforms from public signals and say so plainly when nothing matches. We report what we detected; we never treat it as proof of anything more.

When we cannot see part of your site

Some sites sit behind bot protection that shows an automated scanner a challenge page instead of the real content. When that happens, we do not guess.

Your report tells you which pages we reached and marks the rest as not verified, on every area, rather than grade a page we never saw. A scan that could only read your homepage says exactly that; it does not report a clean result on the pages it could not open. If bot protection keeps us from enough of your site that the report isn’t worth what you paid, the 7-day refund window in the Refund Policy applies.

We scan from a single location in the United States, so a control shown only to visitors in another region, such as an EU-only cookie-consent banner, may not appear for us. When that is likely, we hedge rather than accuse. A scan is also a point-in-time reading of what your site served at that moment.

See it applied

A look inside the report shows what the finished deliverable looks like.