Is Your Consent Banner Actually Blocking Anything?

We audit 10-15 websites a week. In more than half of them, the consent banner is there, the UI looks professional, and zero scripts are actually being gated.

The banner is decorative.

This is not a theoretical compliance risk. It is the most common technical failure we see across enterprise sites, and it is one regulatory complaint away from becoming a real problem.

What "blocking" actually means

When a user declines cookies or does not consent to tracking, the site should:

• Not load Google Analytics, Meta Pixel, TikTok, or any marketing scripts
• Not write any cookies (first-party or third-party)
• Not fire any network requests to ad platforms
• Not populate localStorage or sessionStorage with tracking identifiers

Most consent banners are configured to show a UI. That is the easy part. The hard part - actually preventing scripts from executing before consent - is where nearly every implementation fails.

Why it fails

Three common patterns we see in every audit:

1. Scripts load before the CMP initializes

The consent management platform loads asynchronously, but the marketing tags are already in the page HTML or fire from GTM before the CMP has had a chance to set consent state. By the time the banner appears, GA4, Meta, and a dozen other scripts have already executed.

This is the most common failure. The fix: use GTM's built-in consent mode or configure blocking triggers that wait for the CMP's consent signal before firing any tags.

2. Default consent state is wrong

Many CMPs default to "all accepted" for US visitors because GDPR only applies to the EU. But CCPA, Colorado, Virginia, Connecticut, and other US state privacy laws require opt-out mechanisms. If your default state is "all yes" and you are not checking whether the visitor is in a regulated state, you are non-compliant.

The fix: default to denied for analytics and advertising categories, then update based on the user's actual consent choice.

3. CMP categories are not mapped to tags

The CMP has categories (Strictly Necessary, Analytics, Advertising, Functional). GTM has tags. But nobody connected them. The CMP records the user's preference, but GTM fires everything regardless because there is no blocking trigger checking the consent state.

This is a configuration gap, not a platform limitation. Every major CMP supports integration with GTM. The wiring just has not been done.

How to check yours in 5 minutes

You do not need an audit tool. Open your site in a private/incognito browser and follow these steps:

1. Open Chrome DevTools (F12) before navigating to your site.
2. Go to the Network tab. Clear it.
3. Navigate to your homepage. DO NOT interact with the consent banner.
4. In the Network tab filter, search for: google-analytics, facebook, tiktok, doubleclick, ads
5. If you see requests to any of these domains BEFORE you have accepted the banner, your consent implementation is broken.

Also check:

• Application tab > Cookies: Are marketing cookies being set before consent?
• Application tab > Local Storage: Are tracking identifiers being stored?
• Console tab: Are there GA4 or gtag.js initialization messages?

What proper enforcement looks like

A correctly implemented consent flow:

1. Page loads. CMP script is the first thing that executes.
2. CMP checks for existing consent preferences (returning visitor) or displays the banner (new visitor).
3. GTM initializes with consent mode set to "denied" for analytics and advertising by default.
4. No marketing tags fire. No cookies are set. No tracking requests go out.
5. User interacts with the banner - accepts all, rejects all, or customizes.
6. CMP updates the consent state. GTM's consent mode flips to "granted" for the categories the user accepted.
7. Tags that match the granted categories now fire. Tags that do not, stay blocked.

This is how Google designed Consent Mode v2 to work. Most implementations skip steps 3 and 4.

The real-world impact

This is not just a compliance checkbox. Broken consent has measurable business impact:

• Data quality: If tags fire before consent, your analytics data includes users who did not consent. When consent is properly enforced, your data is cleaner but your numbers drop - which scares teams into leaving it broken.
• Platform compliance: Google requires Consent Mode v2 for EEA traffic. Meta's Limited Data Use requires consent signals. Running pixels without consent puts your ad accounts at risk.
• Legal exposure: US state privacy laws (California, Colorado, Virginia, Connecticut, and growing) have enforcement mechanisms. "We had a banner" is not a defense if the banner was not technically enforcing anything.

What to do about it

If your check revealed problems:

1. Do not panic. This is fixable, usually within a few hours of GTM work.
2. Audit your GTM container. Identify every tag that fires on page load without a consent-based blocking trigger.
3. Map CMP categories to GTM triggers. Each tag should have a blocking trigger tied to the appropriate consent category.
4. Implement Consent Mode v2 if you have not already. Google Tag Manager has built-in support.
5. Re-test in incognito after making changes. Verify that nothing fires before consent.
6. Monitor continuously. New tags get added. Developers make changes. What is compliant today may not be next month.