What automated compliance scanners can and cannot check

Automated scanners have become the default first step for website compliance. They are fast, cheap compared with a manual audit, and repeatable. They are also easy to over-trust. This guide explains what they actually do, so you can read a report correctly and choose a service that fits.

How a scanner works

Most services load your pages in a real, automated browser, often from an EU location and with a clean profile. They record cookies, storage, network requests and the page’s HTML, then interact with the consent banner: accepting, rejecting, or both. Rules map what they observe to legal requirements, for example “a request to an advertising host before consent” to Article 5(3) of the ePrivacy Directive. Better services keep screenshots, request logs and timestamps as evidence.

Where scanners are strong

• Pre-consent tracking. Detecting cookies and third-party requests before any choice is the core strength, and the most common real-world violation.
• Banner behaviour. Whether “reject” exists, whether it works, and whether trackers return after navigation.
• Inventory. A list of every cookie, storage key and third-party host, which is useful for your privacy notice and records.
• Presence checks. Whether an imprint, a privacy notice and terms are linked from every page.
• Accessibility basics. Contrast, missing alternative text, unlabelled fields and similar machine-testable WCAG criteria.
• Regression. Re-running after every release catches the tag someone added on Friday.

Where they reach their limits

• Documents and contracts. Records of processing (GDPR Article 30), processor agreements (Article 28), transfer safeguards and impact assessments (Article 35) are not on the website.
• Server-side processing. Server-side tagging, CRM synchronisation and what happens to form submissions are invisible from the browser.
• Logged-in areas and checkouts. Unless you give the scanner credentials or test accounts, account pages and payment flows are not covered.
• Meaning. A tool can find that a privacy notice mentions “retention”; it cannot confirm that the stated period is what your systems do.
• Legal judgment. Whether a legitimate interest outweighs the visitor’s rights, or whether a cookie is strictly necessary for your service, is a judgment call.
• Manual accessibility. Keyboard journeys, screen-reader flow and cognitive load under the European Accessibility Act need a human.

How to choose a service

The services we rate differ less in whether they find cookies than in what they do with the result. Questions worth asking:

1. Scope. Only cookies and consent, or also privacy notice, imprint, consumer law and accessibility?
2. Consent interaction. Does it test the reject path, or only list cookies?
3. Evidence. Does the report record when, from where and how the site was tested, with screenshots or request logs you could show an authority?
4. EU depth. Does it know national specifics, such as imprint rules, languages and authority guidance in the countries you sell to?
5. Fixes. Does each finding come with concrete guidance your developer can act on?
6. Price transparency. Are prices and limits published, or only available on request?

These questions are, in weighted form, the criteria on our methodology page. A longer findings list is not automatically better: false positives cost developer time, and a report that cannot tell a strictly necessary cookie from an advertising one teaches teams to ignore it.

Consent platform or scanner?

A consent management platform (CMP) runs your banner; a scanner checks whether the banner and everything else on the site behave as they should. Some vendors offer both, and many CMPs include a cookie scan to populate their cookie list. If you already use a CMP, a separate test of the reject path from outside the CMP is still worth having, because the most common failure is a correctly installed CMP with tags that bypass it.