Introduction
Tools like Cookiebot, CookieYes, OneTrust assessments, and NGO scanners crawl your site in a clean session, catalog cookies and trackers, and compare results to your banner and policy declarations. Customers, agencies, and regulators use them as quick objective tests.
Passing does not require their product—you need the underlying behaviors scanners measure: no non-essential cookies before consent, accurate cookie lists, working reject paths, and policies linked prominently.
This guide explains typical scan criteria, why sites with banners still fail, and how to validate fixes with GDPRChecker and manual tests before you send a URL to a prospect.
What it means
Pre-consent crawl: scanner loads homepage and sometimes linked pages without clicking Accept. Any analytics, marketing, or unknown cookie set in that window is flagged. Duration and domain are recorded—_ga with two years is a common fail.
Declaration match: if you use a CMP cookie declaration, scanned cookies must appear in the table with correct category. Extra undeclared cookies fail; declared but never set cookies raise accuracy questions.
Banner interaction tests: some scans simulate Accept and Reject to see if new cookies appear appropriately. Reject should not spawn ad cookies; Accept may set them after update.
Policy linkage: scanners check for privacy and cookie policy URLs reachable from the page. Broken links or generic placeholders fail transparency checks.
Consent UI requirements: increasing number of scans verify Reject all presence and whether non-essential scripts load before choice—mirroring CNIL and ICO guidance rather than old implied-consent models.
Consent Mode v2 evaluation: scanners increasingly check whether Google Consent Mode v2 defaults are set to denied before tags load. If analytics_storage and ad_storage are granted by default, the scan interprets this as pre-consent tracking regardless of what the banner UI looks like. The scanner evaluates the technical signal, not the CMP vendor's dashboard self-assessment. Align your Consent Mode defaults, blocking order, and cookie declaration before running any third-party audit.
Why it matters
Agencies often send Cookiebot PDFs before renewals. Failures delay campaigns and embarrass marketing teams who believed the banner was enough.
Scanners are adversarial in a useful way—they ignore internal assumptions and measure behavior. Treat them as continuous integration for privacy.
Passing scans reduces complaint risk from privacy activists who automate submissions to authorities with scan attachments.
Enterprise vendor due diligence increasingly relies on automated scan results. Security and procurement teams run Cookiebot or similar scans on vendor domains before approving contracts. A failing scan — even from a site that 'has a cookie banner' — can block a deal before the sales team gets a meeting. Treat scanner results as part of your company's public compliance posture, not an internal QA metric.
Common mistakes
- Cookiebot banner installed but GTM still loads tags outside CMP control.
- Declaration auto-scan not rerun after adding TikTok or LinkedIn pixels.
- Staging domain scanned while production still leaky—or vice versa.
- Reject button present but Consent Mode defaults remain granted.
- Policy lists Cookiebot cookies but not vendor tags firing through GTM.
- Scanning only after personally clicking Accept in the same browser.
- Using async script order that lets GA4 win the race before blocking.
Practical checklist
- Run scanner in private window; save full cookie report.
- Fix every pre-consent non-necessary cookie on first visit.
- Update cookie declaration or policy table to match scan output.
- Confirm Reject all blocks marketing and analytics categories.
- Verify policy links return 200 from footer on scanned URL.
- Rescan until pre-consent section is clean or only necessary cookies remain.
- Cross-check with GDPRChecker public scan for second opinion.
- Add rescan to marketing launch checklist.
How GDPRChecker helps
GDPRChecker public scanner independently tests pre-consent network behavior and consent UI markers—useful to validate fixes before rerunning Cookiebot or sharing results with clients.
When you manage a site with GDPRChecker, runtime blocking addresses the same pre-consent failures Cookiebot reports, with dashboard verification that guard and banner are live.
Compliance reports document which controls are active at scan time, giving you a shareable artifact alongside third-party scanner PDFs for enterprise due diligence.
If a third-party scanner still flags cookies after you have fixed pre-consent blocking, the most common causes are: CDN caching serving old HTML with the incorrect script order, a staging domain or campaign landing page using a different template without the CMP integration, or a tag management container that was published after your fix and reintroduced the All Pages trigger. Run GDPRChecker on the exact URL the third-party scanner tested, not your homepage, to isolate template-specific gaps.