Consent Mode Debugging: How to Check If Google Tags Respect User Choices
June 25, 2026
•
4 min read
Table of contents
back
to the top
Consent Mode Debugging: How to Check If Google Tags Respect User Choices
Google Consent Mode is now a major part of cookie compliance for websites that use Google Analytics, Google Ads, or Google Tag Manager. It helps Google tags adjust their behaviour based on a visitor's consent choices.
But there is one important problem: Consent Mode can look installed while still being configured incorrectly.
A cookie banner may appear. The accept and reject buttons may work visually. Google Analytics may still collect data. Google Ads conversions may still appear. But that does not prove your tags are respecting user choices.
Consent Mode debugging helps you check what is actually happening behind the scenes. It shows whether your website sends the right consent signals before and after a user accepts, rejects, or customises cookie preferences.
If your website depends on analytics or advertising data, this is not something to ignore. A broken consent setup can affect GDPR compliance, ad measurement, conversion tracking, reporting accuracy, and user trust.
In this guide, we cover:
- What Google Consent Mode is
- Why debugging it matters
- The basic consent flow
- How to use Google Tag Assistant
- Step-by-step testing for default consent, reject, accept, and category-level choices
- Common problems and how to identify them
What is Google Consent Mode?
Google Consent Mode is a way for your website to communicate a user's consent status to Google tags.
Google's official guide explains that Consent Mode lets you adjust how Google tags behave based on consent choices. The system allows you to set default consent states and update them dynamically based on user actions.
The most important consent signals are ad_storage, which controls whether ads can use storage; analytics_storage, which controls whether analytics can use storage; ad_user_data, which controls whether user data can be used for advertising; and ad_personalization, which controls whether ads can be personalized.
These signals tell Google tags whether they can use storage, process advertising user data, or support ad personalisation.
For example, if a visitor rejects analytics cookies, your setup should not behave the same way as it does after the visitor accepts analytics cookies.
Consent Mode does not replace your cookie banner or CMP. Your CMP collects the user's choice. Consent Mode passes that choice to Google tags. That is why your CMP and Google tags need to work together properly.
Why Debugging Consent Mode Matters
Consent Mode is not only a checkbox in Google Tag Manager. It depends on timing, defaults, tag settings, banner behaviour, and user actions.
A small mistake can cause a large problem.
For example, Google tags may fire before default consent is set, the reject button may not update consent correctly, consent may work on the homepage but fail on landing pages, Google Ads may receive advertising signals too early, GA4 may fire even when analytics consent is denied, server-side tags may not receive the same consent state, old hardcoded Google tags may bypass the CMP, or the banner may save the choice while the tags fail to read it.
This is why visual testing is not enough. You need to inspect the actual consent state and tag behaviour.
The Basic Consent Mode Flow
A healthy Consent Mode setup usually follows this order:
- The page starts loading
- Default consent is set before Google tags fire
- Non-essential storage is denied by default where consent is required
- The cookie banner appears
- The visitor accepts, rejects, or customises consent
- The CMP updates the consent state
- Google tags adjust their behaviour based on that choice
- The user can later change their preference
The order matters. If Google tags fire before default consent is set, they may act before the user has been given a real choice. If the CMP updates consent too late, your first page view may be wrong. If the reject action is not passed properly, users may be tracked in a way they did not agree to.
Tool 1: Google Tag Assistant
The main tool for checking Consent Mode is Google Tag Assistant.
Tag Assistant can help you check which Google tags are installed, which tags fired, when the tags fired, whether default consent was set, whether consent was updated after the user action, which consent checks applied to each tag, and whether a tag fired with granted or denied consent.
This is much better than only checking whether the cookie banner appears.
Step 1: Start With a Clean Test
Before testing, use a clean browser session. You can use an incognito window, but a fresh browser profile is better because it avoids old cookies and stored consent choices.
Then open Google Tag Assistant and connect it to your website. Start recording the session before accepting or rejecting anything. This lets you see the first page load, which is where many Consent Mode problems happen.
You want to test the website as a new visitor, not as someone who already has a saved consent preference.
Step 2: Check Default Consent
The first thing to check is the default consent state.
Before the user clicks anything, your website should send default consent settings. In regions where prior consent is needed, non-essential consent types should usually start as denied. Common default values may include ad_storage, analytics_storage, ad_user_data, and ad_personalization all set to denied.
The exact setup depends on your region, legal basis, and CMP configuration. But the key point is that default consent should be set before Google tags run. If Tag Assistant shows that Google tags fired before consent was set, that is a warning sign.
Step 3: Test "Reject All"
The reject path is often where broken setups appear.
Click "reject all" on your cookie banner, then check what happens in Tag Assistant. You want to confirm that consent updates after the click, that analytics and advertising storage stay denied, that advertising user data and ad personalisation remain denied, and that Google tags do not behave as if consent was granted.
Also check browser storage. If new marketing or analytics cookies appear after reject, something is wrong. A good CMP should make this path clear and reliable.
Step 4: Test "Accept All"
Next, clear the session and repeat the test.
This time, click "accept all" on the banner. In Tag Assistant, check whether consent changes from denied to granted for the relevant categories. Analytics consent should become granted if the user accepted analytics. Advertising signals should become granted if the user accepted marketing cookies and advertising processing.
Then confirm that the expected Google tags fire after consent is granted. This helps you check that the system is not only blocking correctly, but also enabling tags correctly when the user gives permission.
Step 5: Test Category-Level Consent
Many banners allow users to accept some categories and reject others.
For example, a user might accept analytics but reject marketing. This is an important test because analytics and marketing should not be treated as the same thing. In that case, you would expect analytics-related consent to be granted while advertising-related consent remains denied.
Test combinations such as accept analytics and reject marketing, reject analytics and accept marketing, accept functional cookies only, and reject all optional categories. If every category choice produces the same tag behaviour, the CMP may not be mapped properly to Google consent signals.
Step 6: Check Every Important Page Type
Do not test only the homepage.
Consent Mode can work on one page and fail on another if templates, plugins, or hardcoded scripts differ. Check pages such as the homepage, pricing page, product or service pages, blog posts, contact forms, demo booking pages, checkout pages, thank-you pages, and paid ad landing pages.
Testing across different page types helps ensure your setup is consistent across your entire website.
Common Consent Mode Debugging Problems
Default Consent is Set Too Late. This happens when Google tags load before the CMP or consent script. The result is that tags may fire before the correct default state exists.
Reject Does Not Really Reject. The user clicks reject, but analytics or marketing tags still fire as if consent was granted. This often happens when the banner UI is not properly connected to GTM or Google tags.
Old Hardcoded Tags Bypass the CMP. Some Google tags may be installed directly in the website code, while newer tags are controlled through Google Tag Manager. The hardcoded tags may ignore the CMP.
Consent Works Only on Some Pages. This can happen when a landing page uses a different template, page builder, checkout tool, or script manager.
Categories are Mapped Incorrectly. Analytics consent may accidentally trigger marketing tags, or marketing consent may be treated as analytics consent. This creates both compliance and reporting problems.
How CookiePal.io Helps
CookiePal.io is designed to support proper Consent Mode implementation and debugging:
- Google Consent Mode v2 Support - Full integration with Google's latest consent framework
- Cookie Auto-Blocking - Prevent non-essential tags from firing until consent is granted
- Cookie Scanning - Detect all cookies and tracking technologies on your site
- Auto-Categorisation - Intelligently map cookies to consent categories
- Scheduled Scanning - Monitor your site for new tags and cookies
- Consent State Tracking - Monitor and log user consent choices
- Integration with GTM - Seamless connection between your CMP and Google Tag Manager
What to Document After Debugging
After testing, keep a simple record of the results.
Document the date of the test, pages tested, CMP used, Google tags found, consent states before choice, behaviour after reject, behaviour after accept, category-level test results, issues found, and fixes made.
This is useful for developers, marketers, and future audits. It also helps avoid the same mistakes after a website update.
Consent Mode Debugging Checklist
Before you call Consent Mode "done," check that:
- Default consent is set before Google tags fire
- Reject all keeps non-essential consent denied
- Accept all grants the right consent types
- Category-level choices work correctly
- Google Tag Assistant shows expected consent updates
- Old hardcoded tags are removed or controlled
- Important page types have been tested
- Your CMP and Google Tag Manager setup are aligned
- Consent choices can be changed later
- Your cookie policy matches the real setup
- All consent signals are being sent correctly
- No tags fire before consent is set
Final takeaway
Consent Mode is powerful, but it is not automatic compliance. It only works if your CMP, Google tags, default settings, and user choices are connected properly.
The safest approach is to test the full journey. Check the first page load, reject all, accept all, and category-level choices. Use Google Tag Assistant to inspect what is happening behind the banner.
A cookie banner should not only look right. It should control the tracking behind it. Consent Mode debugging helps you prove that it does.
Explore further

How to Audit Your Website Tags Before Installing a Cookie Banner
Audit your tags, pixels, and third-party scripts before you add a banner so you know what needs consent, what should be blocked, and what should be removed.
June 24, 2026
4 min

Google Signals Is Changing on June 15, 2026: What It Means for Your Consent Setup
On June 15, 2026, Google decouples Google Signals from Consent Mode ad_storage. Here’s what’s actually changing, who it affects, and why a correctly configured CookiePal banner already handles it.
June 13, 2026
4 min
Why Your CookiePal Page Views Differ from Google Analytics
CookiePal counts every page load, while Google Analytics only counts consented visits — so the numbers rarely match. Here’s how page views are counted and why that’s expected.
June 8, 2026
2 min
