Cookiebot: Reject Path Leaks Trackers
Your site uses Cookiebot. The banner is in place. Yet the dsgvochecker.de reject-path test shows trackers still firing after "Reject all". That is a GDPR violation under Art. 6 + 7 GDPR and the ECJ ruling C-673/17 Planet49. This page lists the four most common Cookiebot-specific causes with concrete fixes — every recommendation sourced from the official Cookiebot docs.
TL;DR: The four most common reject-path leaks on Cookiebot: (1) script not loaded first, (2) data-cookieconsent="ignore" mis-applied, (3) GTM without Consent Mode, (4) server-side-tagging endpoints outside the auto-block list.
How does the reject-path test work?
Three phases, each in a fresh browser. We record tracking behaviour separately and compare.
We load your page in a fepo-owned browser, automatically click your Cookiebot banner's "Reject" button, and compare which tracker domains still send requests after the click. Properly configured: none. If any fire, that is non-compliant consent — see also the CNIL fines against Google (€150M) and Facebook (€60M) for exactly this case.
Cause 1: Is the Cookiebot script loaded first?
By far the most common mistake. If a tracker loads before Cookiebot is ready, auto-blocking cannot intercept it.
By far the most common cause. Cookiebot's auto-blocking works by modifying DOM elements before they load. If a tracker script loads before the Cookiebot script is fully initialised, Cookiebot cannot intercept it.
Fix: The Cookiebot tag must literally be the first entry in <head> — before Google Analytics, before GTM, before any marketing pixel. Even async or defer on the Cookiebot tag is dangerous, because other scripts may then finish faster.
Source: Cookiebot Support — How does auto-blocking work? ("The Cookiebot script must be the first script to load and be fully loaded before other scripts start loading.")
Cause 2: Was data-cookieconsent="ignore" accidentally applied to a tracker?
Scripts with this marker bypass Cookiebot's auto-blocker. On trackers, that's a reject-path leak.
Cookiebot's auto-blocker respects manual markup. Putting data-cookieconsent="ignore" on a script tells the auto-blocker: "I'm in charge of this element, always run." Legitimate for technically required scripts (e.g. the banner itself), but if someone accidentally puts it on a tracker script, that script runs both before and after reject.
Fix: Search your site's source code for data-cookieconsent="ignore" and verify each occurrence is really a strictly necessary script. When in doubt, remove ignore and either drop the script or steer it via Cookiebot's Categories.
Source: Cookiebot Support — Disable automatic cookie blocking for a specific script
Cause 3: Do GTM tags fire without checking Consent Mode?
Cookiebot only blocks its own routing. GTM tags without a Consent Mode trigger run before that.
If you have Google Tag Manager on the page and dispatch tags via GTM, Cookiebot blocks the Cookiebot-side script routing — but GTM can fire its own tags without Cookiebot's auto-block in the loop. Classic case: marketing pixel in GTM, trigger "Page View" without a consent condition — fires immediately, no matter what the user clicks.
Fix: In GTM under Admin → Container Settings → Consent Settings, enable Consent Mode and mark all marketing/statistics tags with analytics_storage resp. ad_storage as required. Then GTM only fires those tags when Cookiebot signals granted for those storage types.
Source: Cookiebot Support — Google Tag Manager and Automatic cookie blocking + Google Consent Mode v2 docs
Cause 4: Is server-side tagging routing trackers via your own subdomain?
SST endpoints look like first-party subdomains. Cookiebot's auto-blocker does not recognise them as trackers.
Some sites route tracker calls through a first-party subdomain (e.g. gtm.your-domain.com or analytics.your-domain.com) — so-called server-side tagging. Upside for the site owner: first-party cookies, no ad-blocker issues. Problem for Cookiebot's auto-blocker: it does not recognise the first-party subdomain as a known tracker endpoint and lets it through.
Fix: SST endpoints must be wrapped explicitly via Cookiebot's manual markup (type="text/plain" + data-cookieconsent="marketing"), or the triggering code (typically inside the server-side GTM container) must itself check the Cookiebot consent API Cookiebot.consent.marketing.
Source: Cookiebot Support — Manual cookie blocking
How do I verify the fix worked?
Clear all caches, then re-scan. If the test reports "Reject path clean", you are GDPR-compliant.
After every change: redeploy the site, clear caches (CDN + browser), and start another reject-path scan at dsgvochecker.de. The scan is free. If it reports "Reject path clean", your Cookiebot configuration is now GDPR-compliant.
For the full three-phase comparison (Pre-Consent / Reject / Accept incl. detailed report), the one-time audit is $4.95 — no subscription, with a Markdown report by email.
As of: 2026-04-29 · Sources from support.cookiebot.com are linked at each point.