A Consent Management Platform (CMP) May Be Blocking Tags: What It Means and How to Fix It

If Google Tag Assistant is showing you the message "A Consent Management Platform (CMP) may be blocking tags," the first thing to know is that it is usually not an error. It means Tag Assistant found a consent banner on your site that is stopping Google tags from firing until a visitor makes a choice. That is exactly what a consent tool is supposed to do. The real question is not "how do I make the warning disappear," it is "are my tags behaving correctly, and am I staying compliant while they do."

What does "a consent management platform (CMP) may be blocking tags" mean?

It is an informational warning from Google Tag Assistant, the tool you use to debug Google Tag Manager, Google Analytics, and Google Ads tags. It appears when Tag Assistant detects a consent management platform (a cookie banner) that is preventing one or more Google tags from firing. Google's own documentation is explicit that this is often expected behavior, not a fault. Your CMP is blocking tags before consent because, in most of the world, it is legally required to.

Is the warning actually a problem?

Usually, no. There are two situations, and only one of them is a bug. In the first, the warning is expected: your tags are blocked before consent and then fire normally once the visitor accepts. Nothing is broken. Tag Assistant flags the CMP so you are aware of it, but consent is working. In the second, the warning points to a real issue: your tags stay blocked even after the visitor consents. That almost always means your CMP is not sending a consent update to Google, so the tags never get the signal that they are now allowed to run. That is the case worth fixing.

Why your CMP blocks Google tags before consent

Under the GDPR, the ePrivacy Directive, and a growing list of US state laws, analytics and advertising tags that read or write cookies need a legal basis before they run. For most sites that basis is consent. A consent management platform enforces this by holding those tags until the visitor chooses. Google describes three ways a CMP can do this: automatic script blocking, consent checks inside Google Tag Manager, and manual blocking. All three produce the same Tag Assistant warning.

The wrong fix: letting tags fire before consent

Most CMPs offer a setting with a name like "Allow Google tags to fire before consent." Turning it on makes the warning go away, because the tags are no longer blocked. It also fires tracking before the visitor has agreed to anything, which is the exact behavior that regulators fine and that pixel-tracking and wiretap lawsuits are built on. Clearing the warning this way trades a harmless diagnostic message for real legal exposure.

The right fix: Google Consent Mode v2

The correct fix keeps tags blocked before consent but still gives Google the data it can legally collect. That is what Google Consent Mode v2 does. Instead of hard-blocking Google tags, you let them load in a "cookieless" state: they run, but they do not set cookies or send identifiers until the visitor consents. Google can still model conversions from this anonymous signal, so your Ads and Analytics reporting does not fall off a cliff. When the visitor accepts, you send a consent update and the tags switch to full mode.

1. Set your consent defaults to denied for ad_storage, ad_user_data, ad_personalization, and analytics_storage before any Google tag loads.
2. Keep functionality and security storage granted so the site itself works.
3. Send a consent update the moment the visitor accepts, switching the granted signals on.
4. Do not also hard-block the Google tags themselves. Let consent mode gate them, so the cookieless pings still go out.
5. Reload in Tag Assistant and confirm the consent state moves from denied to granted after you accept.

// Before any Google tag loads: deny by default
gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  functionality_storage: 'granted',
  security_storage: 'granted',
  wait_for_update: 500,
});

// When the visitor accepts your banner: grant what they allowed
gtag('consent', 'update', {
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted',
  analytics_storage: 'granted',
});

How ConsentStack handles this

ConsentStack ships this configuration by default. Its Google integration sets Consent Mode v2 to deny ad_storage, ad_user_data, ad_personalization, and analytics_storage until consent, keeps functionality and security storage on, and uses Google's own recommended privacy settings (ads_data_redaction and url_passthrough). Google tags are allowed to load in cookieless mode rather than being killed, so you keep conversion modeling. The moment a visitor accepts, ConsentStack sends the consent update and the tags switch to full measurement.

You still decide which tags belong in which category, and correct setup always matters, but the consent-mode plumbing that trips up most sites is handled for you. That is the difference between a banner that looks compliant and one that actually behaves correctly: blocked before consent, firing the instant it is given, and never leaking in between.

How do I know if my tags are actually leaking?

The Tag Assistant warning tells you a CMP is present. It does not tell you whether tags fire before consent. The only way to know is to load your site, refuse consent, and watch what still runs. ConsentStack's free compliance scanner does exactly that: it visits your site, rejects the banner, and reports which trackers and cookies fired anyway. If Google Analytics or an ads tag shows up in that report, your tags are leaking, no matter what the banner looks like.