Understanding Google Consent Mode v2 requirements
Before diving into implementation, it's important to understand what Google Consent Mode v2 actually requires.
Google now expects websites to define four consent signals:
- ad_storage – controls cookies for advertising
- analytics_storage – controls cookies for analytics
- ad_user_data – controls whether user data can be sent to Google for ads
- ad_personalization – controls personalized advertising
These signals determine whether Google Ads, GA4, Enhanced Conversions, remarketing, and cross-site tracking can run on your site.
If these signals aren't configured correctly, your tags will either fire when they shouldn't, fail to fire when they should, or get rejected entirely by Google Ads. You'll also see "Consent Not Configured" warnings inside GTM's Consent Overview panel.
That's why getting this setup right matters for both compliance and accurate tracking.
Setting consent defaults to "denied" in Webflow
For GDPR compliance, your page must load with all consent signals denied by default. No tracking should occur until the user explicitly grants permission.
I built a fully custom cookie banner in Webflow. To ensure compliance, I added the following script at the very top of the Webflow <head> section, before the GTM container loads:
This ensures no Google tags fire prematurely and no cookies are dropped before consent is given.
Restoring returning user consent before GTM loads
One discovery that saved me hours of debugging:
GTM will only respect user consent if it's restored before GTM loads.
If a returning visitor has already accepted cookies, you need to restore their preferences before the GTM container initializes. Otherwise, the site loads in "denied" mode every time, causing broken analytics and lost conversions.
I solved this by reading the user's previous settings from localStorage and updating Consent Mode before injecting GTM:
This ensures repeat visitors load the site with their previous consent signals already active, so tags fire correctly from the first pageview.
Fixing the biggest problem: tags not firing after consent changes
Everything looked correct in my setup until I discovered something frustrating:
When a user updates their cookie settings, GTM does not automatically re-fire tags.
This creates a serious tracking gap:
- User accepts cookies → tags don't fire
- User changes preferences → tags don't fire
- User allows analytics → GA4 doesn't start
- User allows ads → Google Ads conversions don't send
- Enhanced conversion events silently fail
The reason? GTM evaluates tag firing conditions once, on page load. It doesn't re-evaluate when consent state changes mid-session.
The solution: push a custom event when consent changes
Inside my cookie banner's "Save Preferences" function, I added this line:
Then, in GTM, I created a new trigger:
- Trigger type: Custom Event
- Event name: consent_refresh
I added this trigger to every tag that depends on consent:
- GA4 Configuration tag
- GA4 Event tags
- Google Ads Conversion tags
- Enhanced Conversions (User-Provided Data Event)
- HubSpot tracking script
- Meta Pixel
- Any tag requiring analytics_storage or ad_storage
Now all tags fire instantly when consent is granted, without requiring a page reload.
This was one of the biggest breakthroughs in getting the system to work properly.
Why GTM's built-in consent settings aren't enough
GTM automatically recognizes consent requirements for most Google tag types. For example:
- GA4 requires: analytics_storage, ad_user_data, ad_personalization
- Google Ads Conversion requires: ad_storage, ad_user_data
These appear in GTM's Consent Overview as "Built-in consent."
But here's what tripped me up:
Even if a tag has built-in consent rules, GTM still blocks it unless you explicitly configure what happens when consent is missing.
That's where "Additional Consent" settings come in.
For every marketing and analytics tag, I had to manually enable:
- "Require additional consent" = ON
- Select the exact consent signals that tag depends on
Here's how I configured my main tags:
Google Ads Conversion tag
- Additional consent required: ad_storage, ad_user_data
GA4 Configuration tag
- Additional consent required: analytics_storage
Meta Pixel (Custom HTML)
- Additional consent required: ad_user_data, ad_personalization
If you skip this step, GTM won't evaluate your tags correctly under Consent Mode v2. They'll appear in the dashboard as "Consent Not Configured" even if they seem to work during testing.
This was another major source of confusion during my first implementation attempt.
Validating your setup with GTM's Consent Overview
GTM's Consent Overview panel is essential for verifying your configuration.
It categorizes your tags into two groups:
Consent not configured
Tags that are missing additional consent requirements, have mismatched consent signals, or have triggers that aren't aligned with consent state.
Consent configured
Tags where built-in consent requirements are satisfied, additional consent rules are defined, and triggers only fire after consent is granted.
I used this panel to verify that each tag:
- Had correct built-in consent recognition
- Had correct additional consent requirements set
- Included the custom consent_refresh trigger
- Was not firing early or without permission
Only once every tag moved into the "Consent Configured" section was the setup fully compliant and reliable.
Why I didn't use Cookiebot (and when you should)
For many Webflow users, Cookiebot is the easier route:
- Automatically detects and categorizes cookies
- Integrates directly with GTM
- Sends consent states to Google automatically
- Blocks scripts until user approval
- GTM offers a Cookiebot tag template for quick setup
I chose not to use Cookiebot because I wanted:
- Fully custom banner design
- A lightweight script footprint
- Complete control over consent logic
- A Webflow-native implementation
- No recurring monthly cost
But building your own banner has real downsides:
- You're responsible for compliance. If regulations change or you miss a requirement, there's no automatic update. You need to stay informed and maintain the code yourself.
- No automatic cookie scanning. You have to manually audit which cookies your site drops and categorize them correctly.
- More debugging. When something breaks, you're on your own. Tools like Cookiebot have support teams and community forums.
- Initial time investment. Getting everything working correctly took me significantly longer than a plug-and-play solution would have.
If you want a simpler, lower-maintenance solution and don't need custom styling, Cookiebot is a solid choice that handles most of the complexity for you.
Final result: a fully compliant Consent Mode v2 setup
After all the troubleshooting, my Webflow site now:
- Loads with all consent signals denied by default
- Restores previous user consent before GTM initializes
- Updates Consent Mode instantly when users change their preferences
- Fires tracking tags immediately using the consent_refresh custom event
- Uses proper additional consent rules for each tag type
- Passes GTM's Consent Overview validation
- Works seamlessly with Webflow forms and HubSpot integration
It took significant debugging to get everything working correctly, but the end result is clean, predictable, and fully GDPR-compliant.
.png)
.png)
.png)
.png)
.png)
