Reading your report

A report lives at /r/<id>. The link is public, so it can be pasted into a ticket or forwarded to a colleague without anyone needing to sign in. This page walks through the report from top to bottom.

While the scan runs

The report page opens as soon as the scan is queued and refreshes itself every ten seconds. The status line moves through three states: "Queued", "Loading the site in a real browser", and "Evaluating against the rules". A scan takes about two minutes. A URL that is not publicly reachable is refused on the scan page before a scan starts. A scan that cannot be completed shows "Scan failed" on the report page and can be run again.

Header

The header shows the URL that was scanned, the time of the scan, the rules version and the tracker blocklist version that produced the result, and a link to the site's privacy policy where one was found. The versions matter when comparing two reports: a different score under a different rules version is not necessarily a change in the site.

GDPR / ePrivacy panel

The panel shows the score ring, from 0 to 100, and a one-line verdict: how many issues need attention, how many items are worth reviewing, or that no issues were found. Beneath it a bar shows the split between failed, warning, passed and not applicable checks.

The score is computed from the weighted results of the checks; each rule has a weight. What we check explains the severities.

Headline tiles

Four numbers, all taken from the pre-consent phase:

• Pre-consent trackers: third-party requests fired before any consent was given.
• Cookies set on load: cookies present after the page loaded and before any interaction.
• Third-party domains: the number of distinct external domains contacted.
• Likely violations: the number of checks with status fail.

Issues to fix and Warnings

"Issues to fix" lists every finding with status fail, ordered by severity from critical down. "Warnings" lists findings with status warn in the same order. Each finding card shows:

• the status, severity and category chips;
• the title of the check;
• a remediation note describing what to change;
• the legal citation the check is based on;
• an expandable "Raw evidence" block with the observation itself, such as cookie names, request domains, or the DOM selectors that matched.

The raw evidence is the part to keep. It lets a finding be verified independently and lets an engineer see exactly which script or cookie is being referred to.

Passing checks and Not applicable

Both sections are collapsed by default and can be expanded. Passing checks are worth reading when preparing a record of compliance, since they document what the site already does correctly. Not applicable covers rules that had nothing to evaluate on this page, along with any check the scan could not decide.

Technical evidence

Four panels summarise the underlying observations:

• Consent platform: whether a CMP was detected and which vendor, and whether TCF, USP or GPP signals were present.
• Banner: whether it is present, whether a reject-all button exists, and whether any boxes were pre-ticked.
• Phase summary: the cookie count before consent, whether reject and accept were effective, and whether Global Privacy Control was respected.
• Site profile: the technologies detected on the site (for example WordPress on Apache), its DNS provider and its domain registrar.

How a scan works describes how each of these was captured.

Screenshots

A desktop and a mobile screenshot of the page in its pre-consent state, exactly as the browser saw it before any interaction. They are useful when a finding refers to banner geometry or button labels.

Disclaimer

Every report ends with the same sentence: "Automated compliance indicators, not legal advice." The checks are automated indicators of common GDPR and ePrivacy requirements, not a legal assessment of a specific site. See Limits and retention for how long the report stays available.