Running a Compliance Check

Two ways to run the regulatory evidence check: a free single-page version that needs no account, and the full version inside the dashboard. This page covers both, and what to do when a result is not what you expected.

Read Regulatory Evidence: Overview first if you have not — particularly the part about what "No issue detected" does and does not mean.

The free check

No account required. Available from the header menu under free tools, and from the scan box on the homepage by choosing the EU or California option.

1. Enter a URL.
2. Pick a market — Germany, other EU / EEA, or California. The California page is pinned to that market and skips the selector.
3. Confirm you own or manage the site. The check will not run without this.
4. Read the result.

Limits, so the result is not misread. It reviews one representative page, plus any legal pages linked from it. Results are cached for 24 hours, so re-running the same URL returns the same result rather than re-scanning. There are three checks per IP per day.

The free result shows what needs action. When there is nothing to act on, it shows one item worth reviewing. Any remaining checks are counted but not itemised — the full check is where the complete evidence record lives.

The confirmation in step 3 is not a formality. A compliance finding names a domain, names a statute, and carries a timestamp and a citation. In Germany that is the shape of an Abmahnung exhibit, and generating one against a domain you do not control, on our infrastructure, is not something we will do.

The full check

Inside the dashboard, on a site's Compliance tab. Three prerequisites:

• The feature is enabled for your plan. It is in Beta and rolled out per-plan; if the tab is not there, it has not reached your plan yet.
• The site is verified. Same reasoning as above, and this one is not optional — see Domain Verification.
• At least one market is declared. No market, no findings.

Declaring markets

A market is a jurisdiction plus the URL where that market's pages start.

Most sites have one market and one root — the site URL itself, which costs you nothing to set. A site that serves different regions from different paths declares one row each: Germany at /de, California at /us. Each root is validated against the site's own domain.

Choose markets by where you actually do business. Declaring extra markets does not make a site safer; it adds checks whose failures may not apply to you.

Running it

The Compliance tab has a run control. Collection happens on a separate worker, and the run continues if you navigate away or close the tab — progress and the result are read back from the server rather than held in the browser.

A run reviews up to five pages, chosen to spread across the site's sections rather than five variations of one template, plus the legal pages it finds linked.

After the first run

Verified sites are re-checked weekly, automatically. The cadence is deliberate: a legal surface changes when somebody edits it, which is rare, while an accessibility surface changes with every content update. Daily re-checks would re-read the same legal notice seven times to learn nothing.

If something that previously passed starts failing, you get an email. That is the actual product — the first run tells you where you stand, the weekly re-check tells you when a deploy quietly changed it.

Reading a finding

Each finding carries four things:

• A status. Action needed, Needs review, No issue detected, or Not evaluated.
• The pages it was seen on, so you know whether it is site-wide or one template.
• An evidence line — the specific observation behind the verdict. The cookie name, the third-party host, the missing field.
• A citation, for anything that is not a pass. Required, and enforced by the database rather than by convention.

"Needs review" is not a soft failure

It has two distinct causes, and they call for different responses.

Sometimes the observation was genuinely ambiguous — banner detection is heuristic, because there is no standard markup for a cookie banner. If the checker is not confident it found one, it will not assert a violation against something that might not be a banner.

Sometimes the observation was clear but the legal weight is not. Germany has a judgment awarding damages for remotely-loaded Google Fonts; other member states have the same underlying argument and no comparable precedent. Same observation, same evidence — but reporting both as a violation would overstate the second. The weaker binding caps the result at "Needs review" rather than inventing confidence.

So: read the evidence line. If it describes something real on your site, the observation stands whatever the status says.

When a run does not come back clean

The site could not be read. Bot protection is the usual cause. Interstitials from providers like Imperva are served with HTTP 200, so a status code alone cannot distinguish a challenge page from a real one — the checker reads enough of the page to tell. Allowlist the checker, or run against a staging environment that is not behind the challenge.

A legal page was not found. The checker follows links first. If nothing links to your privacy policy, it tries well-known paths — which proves the page exists but says nothing about whether a visitor could find it, so reachability is reported separately from contents. If a page exists but was not found, check that something on the site actually links to it.

An email address was reported missing that is on the page. This was a real bug and is fixed: addresses published as mailto: links whose visible text is a person's name are read from the link, not just the page text. If you still see this, the address is neither in the text nor in a mailto: — check how it is rendered.

A check says "Not evaluated". It has no binding in your declared markets, or the observation it needs was not available. This is not a pass, and not a failure.

Getting the evidence out

Findings live with the site and stay after the run, so a later question about what the site looked like in August has an answer. The client-facing report carries a compliance section whenever the feature is enabled for your plan — that is the shareable form, see Sharing & Reports. The report is public to anyone holding the link, so the same rollout gate is re-checked when it renders rather than trusted from the dashboard.

One thing to keep in mind

Every result carries a disclaimer, and it means what it says. These are automated checks for specific, named conditions. They are general information, not legal advice, and passing them does not mean your site is compliant. For your own situation, consult a lawyer.