SecureSpells
Website Cookie Scanner Guide: How to Scan Sites Correctly
Website Cookie Scanner Guide: How to Scan Sites Correctly
To scan a website for cookie compliance correctly, use a clean browser state, decide what “accept” vs “reject” means for your test, then review three proofs: what fires before consent, which third-party domains receive data, and whether rejection actually stops non-essential tags. A cookie inventory alone is not proof—pair scans with runtime checks when stakes are high.
Website cookie scanners range from simple inventory tools to full runtime compliance auditors. Getting useful results depends on how you set up the scan, not just which tool you use. This guide explains how to scan correctly and what to do with the results. Scope: EU/EEA GDPR and ePrivacy Directive. UK GDPR applies equivalent requirements.
This article is for educational purposes and does not constitute legal advice. For compliance decisions, consult a qualified legal or privacy professional.
- Website cookie scanner
A tool that visits your site and records cookies, tracking scripts, and network requests, producing a report that shows what data is collected and what compliance risks are present.
- Pre-consent state
The state of your site before a visitor interacts with the consent banner — i.e. first load with no prior consent given. Scanning in this state reveals which cookies and trackers fire without consent, which is the highest compliance risk.
- Remediation
The set of technical changes that fix identified compliance issues — for example, blocking a tracker in GTM until consent is granted, or updating CMP configuration to gate a script.
For a structured runtime pass on the same URL (cookies, third-party requests, pre-consent behaviour), use the free cookie audit tool—especially if your scanner only outputs a cookie list.
Pre-scan setup and consent-state testing
Most scan errors come from scanning in the wrong state. Before running a cookie scan:
- Clear all cookies and consent records. Use a private/incognito browser window. If testing manually, delete cookies for your domain in DevTools → Application → Storage.
- Do not accept the consent banner. If you accept cookies before scanning, you will see the post-consent cookie set — which misses the most important question: what fires before consent.
- Scan in rejected state too. Run a second scan after explicitly rejecting all cookies. Any trackers that still fire in this state represent a consent bypass.
- Test multiple pages. Compliance risks often appear on specific pages (checkout, blog, landing pages) — not just the homepage. Scan your highest-traffic URLs.
- Use a tool that supports consent-state simulation. Runtime scanners (e.g. SecureSpells) automate consent rejection and report pre-consent behavior; static scanners do not.
Interpreting scanner results
A scanner report typically contains:
| Report section | What to look for |
|---|---|
| Cookies list | Categories (necessary vs non-essential); which are set pre-consent |
| Third-party domains | External domains that receive requests on page load — check for analytics, ad networks, pixels |
| Pre-consent requests | Any non-necessary request before consent = compliance risk |
| CMP behavior | Does the scan confirm that rejecting cookies stops tracking? |
| Risk score / priority | Which issues are highest severity (usually pre-consent analytics and ad tracking) |
Focus first on pre-consent non-essential tracking — this is the primary enforcement target under GDPR and ePrivacy. See Cookies loading before consent for examples.
Turning findings into remediation tasks
For each finding, map it to a specific fix:
| Finding | Remediation |
|---|---|
| Analytics fires before consent | Move GA tag / GTM trigger to fire only after consent is granted; use Consent Mode v2 |
| Ad pixel fires pre-consent | Gate pixel in GTM or CMP tag blocking; verify with re-scan |
| CMP does not block on reject | Check CMP configuration; verify tag blocking mode is enabled |
| Undisclosed third party found | Add to cookie/privacy policy; gate or remove if no lawful basis |
| Same cookie/tracker on multiple pages | Fix at tag manager level, not page by page |
After each fix, re-scan to confirm the issue is resolved. Sites change with every release; scheduled or recurring scans reduce the risk of new violations going undetected.
Scan your site now. See what cookies and trackers fire before consent.
Scanner setup that won't lie to you
The most common reason scans produce misleading results is a bad setup, not a bad tool. Before running any scan:
| Setup step | Why it matters |
|---|---|
| Incognito / private window | Clears prior consent records; prevents cached consent state from skipping the banner |
| Geography match | Some CMPs serve different banners by region; test from the target jurisdiction (or with a VPN) |
| Disable ad blockers | Ad blockers may block tracking pre-scan, making your site look more compliant than it is under real visitor conditions |
| Do not pre-accept consent | Run the scan before clicking Accept; the pre-consent state is what regulators care about most |
| Scan more than the homepage | Checkout, blog, signup—different pages load different tags |
If your scanner does not let you control consent state, pair it with a manual DevTools check in the steps above.
How to record "Reject all" as a first-class test
Most compliance failures are not "trackers load before consent"—they are "trackers load even after rejection." To test this:
- Open an incognito window; load your site.
- Click "Reject all" (or the most restrictive option your banner offers).
- Open DevTools → Network; filter for
analytics,pixel,gtag,googletagmanager,facebook.com. - Any request to those domains after rejection = consent bypass. That is a GDPR violation regardless of what your settings screens say.
- Re-run this test after every CMP configuration change.
For an automated version of this test, use the free cookie audit tool—it simulates both consent states and returns a structured report.
Methodology and sources
- EDPB Cookie Banner Taskforce report on pre-consent behavior expectations.
- ePrivacy Directive and GDPR Art. 5(3) requirements for consent before non-essential storage.
- Last updated: 2026-03-26.
Related Articles
