⚠️ Important: This article explains common reasons why a scanner may report a finding that does not reflect how your site behaves for real visitors. It is not legal or compliance advice. Whether your setup meets your obligations depends on your specific configuration and applicable laws. If you're unsure, consult your legal or compliance team.
Below are some of the most common examples.
Example #1: Scanner IP location falls outside your banner's targeted region
Some sites intentionally show the consent banner only to visitors in certain regions — for example, only within the EU/EEA, where consent is legally required, while visitors elsewhere see the site without a banner.
What's actually happening
The Cookiebot scanner runs from its own IP address, which corresponds to a specific geographic location. If that location falls outside the region where your banner is configured to display, the scanner never sees the banner at all. Without a banner to interact with, it has no way to know which cookies are meant to be blocked pre-consent and which are exempt — so it may flag cookies as "not blocked before consent" simply because, from its vantage point, no consent mechanism appears to be running.
This isn't a case of cookies actually loading without consent for the visitors the banner is built for. It's that the scanner's location doesn't match the audience the banner is targeting, so it's evaluating the site as if no consent solution exists.
How to confirm this on your own site
Check where your banner's geo-targeting rules are set to display, and compare that to the region the scan is run from. If the scanner's IP falls outside your targeted region, that mismatch — rather than an actual compliance gap — is the likely explanation for the finding.
Your options
No action required. If the banner correctly displays for visitors in your actual target region, the finding may reflect a scanning blind spot rather than a live issue. However, whether geo-targeting your banner meets your compliance obligations depends on your specific setup and applicable requirements.
Broaden banner display, if appropriate. If it makes sense for your compliance strategy to show the banner globally rather than geo-restricted, doing so ensures the scanner (and all visitors) consistently see the same consent experience.
Example #2: GA4 (_ga) flagged as "not blocked before consent"
One of the more common specific cases is Google Analytics 4 (_ga) being flagged when Cookiebot is deployed via Google Tag Manager (GTM) in Advanced Consent Mode.
What's actually happening
When Cookiebot is deployed via GTM in Advanced Consent Mode, the GA4 tag isn't blocked outright before a user gives consent. Instead, it loads in a reduced-data state and may briefly write temporary data or send cookieless pings while the page initializes.
This is by design: Advanced Mode intentionally lets tags fire in a privacy-safe, consent-aware way rather than blocking them completely. The trade-off is a very small timing window, during page load, before Cookiebot's default consent state (analytics_storage: denied) is fully applied by GTM.
Why the scanner catches it but real visitors don't
The Cookiebot scanner crawls pages in a way that can expose this brief initialization window. A real browser session, by contrast, only evaluates cookies after the page — and the consent default — has fully loaded. That's why:
- The scanner sees a moment where GA4 is technically active before the "denied" default takes hold, and flags it.
- A real visitor's browser never observes this window, because by the time cookies are checked, the default is already in place.
In short: the scanner is measuring a millisecond-scale technical timing gap that doesn't translate into an actual privacy exposure for real users.
How to confirm this on your own site
You can verify there's no real-world issue by opening your live site in a fresh, unauthenticated browser session and checking that _ga and other analytics cookies are not present until after consent is given. If they aren't, this may indicate that there is no corresponding issue for real visitors, regardless of what the scan reports.
Your options
No action required. If confirmed compliant in a real browser, this is simply a known limitation of scanning GCM v2 Advanced Consent Mode. No fix is needed.
Switch to Basic Consent Mode. If you'd rather eliminate the finding entirely, configure your GA4 tag in GTM to fire only after a Cookiebot consent trigger. This blocks GA4 completely before consent (rather than running it in reduced-data mode), which removes the timing window altogether and clears the finding on your next scan.
Example #3: "Close on scroll" registering the scanner's own scrolling as consent
If your banner is configured with a close on scroll (or "implied consent on scroll") setting, a scan may show GA or other trackers as "not blocked before consent" — even though no real visitor interaction caused it.
What's actually happening
To check for trackers, the Cookiebot scanner performs a series of actions on the page, including scrolling. If your banner treats scrolling as a form of implied consent, the scanner's own scroll action can register as consent being given — which then allows trackers to fire. The report reflects that sequence: trackers appear as "not blocked before consent" not because a real user interacted with the banner, but because the scanner's probing behavior was interpreted as consent.
How to confirm this on your own site
Check whether close on scroll (or a similar implied-consent-on-scroll setting) is enabled in your banner configuration. If it is, that setting — rather than a GTM misconfiguration or a real pre-consent leak — is the likely explanation for the finding.
Your options
No action required.
This is expected behavior when close on scroll is combined with the scanner's page-probing process. it may not reflect a real compliance gap for visitors.Disable close on scroll, if you'd prefer stricter consent capture.
If you'd rather require an explicit click on the banner before any tracker can fire — and eliminate this kind of finding going forward — you can turn off the scroll-based implied consent option.
The bottom line
Not every scan finding reflects a real-world compliance gap. Before making changes to your setup, it's worth checking how the cookie or script actually behaves for a real visitor — the scan and the live experience don't always match, and understanding why can save unnecessary rework.
Comments
0 comments
Please sign in to leave a comment.