Google Consent Mode Checker

The Google Consent Mode Checker verifies that your gtag configuration respects consent signals and only fires marketing tags with the correct mode applied.

It tracks how consent state flows to Google services so you know whether gtag.js, analytics, and ads respect user choices.

By hand: open the site in a clean incognito window with DevTools on the Network tab, filter for google-analytics.com and googletagmanager.com, and reload before touching the banner. Anything that fires there is pre-consent. Then run dataLayer in the console and look for the consent default entry — it has to appear before the gtag library loads, not after.

That method works but only shows your own session, on your own machine, with whatever extensions and cached consent you already carry. It also misses the timing question that matters most: whether the default was set early enough, measured in milliseconds rather than by eye.

Paste a URL above and the checker does the same passes from a clean browser with no history: the default state before any interaction, the banner click, and the update that should follow it.

Consent Mode v2 (required by Google since 2024) adds two signals on top of the originals: ad_user_data and ad_personalization, alongside ad_storage and analytics_storage.

The checker confirms all four signals are present and flip to the correct state after the banner — the most common gap is sites still running v1 without the two new v2 signals.

Being configured isn't the same as working. We load your site as a fresh visitor and check the real default state, the banner interaction, and the post-consent update.

Typical failures we surface: the consent default set after tags load, no consent update event from the CMP, or tags firing before consent regardless of the chosen mode.

Google penalizes sites that claim to honor Consent Mode but still leak user identifiers or preload tags without honoring the chosen mode.

Broken Consent Mode v2 also degrades EEA/UK remarketing and conversion modeling — a direct revenue hit, not just a compliance one.

Basic blocks Google tags entirely until consent; Advanced loads them in a cookieless, consent-aware state and sends pinged signals. Each behaves differently before consent.

The checker shows which model your site is running and whether its pre-consent behavior matches that model — so you're not silently sending data you think you're withholding.

Four signals present, not two. Consent Mode v1 sites pass ad_storage and analytics_storage and stop there; v2 requires ad_user_data and ad_personalization alongside them. Missing the latter two is the single most common failure we see.

The default denied and set first. The consent default has to be registered before the Google tag loads. Set it afterwards and the tag has already made its decision — the configuration reads correctly in your source and still does nothing.

An update that actually arrives. After the visitor accepts, a consent update should carry the granted signals. A banner that stores a preference locally without telling Google leaves measurement stuck in the denied state, which looks like a traffic collapse in GA4 rather than a consent bug.

Every major consent platform ships Consent Mode support, and every one of them can be installed in a way that quietly disables it. The usual culprits are a template that loads the Google tag outside the platform's control, a category mapping that never reaches ad_user_data, or a script left in the head that runs before the platform initialises.

The checker identifies which platform is running and evaluates the signals it actually emits, so the answer is about your installation rather than the vendor's documentation.

Tag Assistant and DebugView are built for debugging your own visit. They assume you are logged in, they inherit whatever consent you granted earlier, and they answer the question “is the tag firing?” rather than “is it firing before this person agreed?”

This checker starts from a visitor who has never been to your site, which is the state that regulators and your real traffic share. The output is a timeline of what left the browser and when, relative to the moment consent was recorded.

We capture the gtag initialization, consent updates, and resulting network hits to Google endpoints, correlating them with the consent banner decisions.

Signals such as gtag('consent', 'update') payloads, cookies, and measurement_id hits are evaluated to ensure the right mode remains in effect — and you can schedule the check so a deploy that breaks it pages you.