Introduction
Third-party compliance 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 third-party scan reports before renewals. Failures delay campaigns and expose implementations where teams believed the banner alone 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 independent 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
- Consent 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 CMP 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 for validating fixes before rerunning an external audit or sharing results with clients.
When you manage a site with GDPRChecker, runtime blocking addresses common pre-consent failures, with dashboard verification that the 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.