How to Check if Google Consent Mode Is Working

Google Consent Mode is not a cookie banner. It is a small API between your consent banner and Google's own tags: the Google tag, GA4, Google Ads and Floodlight. The banner tells Google four things about the visitor's choice, and Google's tags change how they behave accordingly.

The four signals in Consent Mode v2 are ad_storage, analytics_storage, ad_user_data and ad_personalization. The last two arrived with v2 and have been required for advertising in the EEA and UK since March 2024. A site that only sets the first two is running v1, and Google Ads treats its EEA traffic as unconsented.

Two things follow from this. First, Consent Mode governs Google's tags only: a Meta Pixel, a TikTok pixel or a Hotjar script never read those signals, and gating them is a separate job. Second, the default state has to be set before the Google tag loads. Set it afterwards and the tag has already decided, whatever your configuration says.

1. Open your site in a fresh incognito window. Consent is remembered per browser, so a normal window shows you what a returning visitor gets, not a new one.
2. Open DevTools (F12), go to the Network tab, and filter by google-analytics.com, googletagmanager.com and doubleclick.net. Reload the page and do not touch the banner.
3. Click any request to /g/collect or /pagead/ and look at its query string for gcs=. gcs=G100 means both storage signals were denied at that moment: correct before consent. G111 means granted. If you see G111 before you clicked anything, the default is wrong or is being set too late.
4. In the Console tab, type dataLayer and expand it. Look for an entry whose first element is "consent" and second is "default". It has to appear before the config entry of your Google tag. If it appears after, or not at all, the tags loaded without a default.
5. Now click Accept on the banner and look for a new dataLayer entry with "consent", "update" and all four v2 keys set to granted. The next request to Google should carry gcs=G111.

If every step matches, Consent Mode is working for a first-time visitor on your machine. That sentence has two limits, and they are why a manual check is a starting point rather than a proof.

Your browser is not a clean browser. Extensions, cached consent from an earlier visit, a logged-in Google account and a saved preference in the CMP all change what fires. Incognito helps but does not remove extensions or your IP-based region.

You cannot see timing by eye. The failure that matters most is a default set a few hundred milliseconds after the Google tag loaded. In the Network tab both requests look simultaneous; only the millisecond timestamps tell them apart.

Banners are often geo-targeted. Many consent platforms only show the banner to EU or UK visitors and set no default elsewhere, so a check from the US can pass while an EU visitor gets tags firing before consent. See why cookie banners differ by country.

Consent Mode says nothing about non-Google tags. A page can pass every step above and still load Meta, LinkedIn or Hotjar before consent. That is the most common pattern we see on sites that "have Consent Mode set up".

The Google Consent Mode checker runs the same steps from a browser that has never seen your site: it records the default state before any interaction, the consent-state parameter on every Google request with its timestamp, the banner click, and the update that should follow. It also lists every non-Google host contacted before consent, which the manual method never shows.

You can run it from the US, from California or from Germany, so a geo-targeted banner is checked from where it actually appears. The first scan is free and needs no signup.

• Default set after the tag. The CMP snippet sits below the Google tag in the page head, or the CMP is loaded through GTM on a trigger that fires after the tag. Fix: move the consent default above every Google script, or in GTM put the CMP template on the Consent Initialization trigger.
• Still on v1. Only ad_storage and analytics_storage are set. Fix: enable Consent Mode v2 in the CMP (most platforms have a switch) so ad_user_data and ad_personalization are included.
• No update after the click. The banner records the choice in its own cookie but never calls gtag('consent', 'update', …). Symptom: gcs=G100 forever, even for visitors who accepted, and empty GA4 reports. Fix: enable the Google Consent Mode integration in the CMP or map its categories to the four signals.
• A second Google tag outside the CMP's control. A theme or plugin loads its own gtag.js with no default. Fix: remove the duplicate or route it through the same container.
• Advanced mode misunderstood as blocking. In advanced mode Google's tags load before consent and send cookieless pings with consent denied (gcs=G100). Google treats that as compliant for its products, but the ping still carries the page URL, device details and a per-page id, and under the EDPB's 2024 guidelines on ePrivacy Article 5(3) a script that sends device information can still require consent. It is not "nothing fires". If your policy promises nothing fires, or you want no grey area, use basic mode, where the tags do not load until consent.

A failed check has a cause you can name: which tag, which trigger, which missing signal. On Pro and Agency plans every scan comes with a How to fix guide that reads your public Google Tag Manager container and says, tag by tag, what fires before consent and which consent type to require on it, plus the banner settings to change. It also comes as a Markdown brief you can hand to an AI coding agent.

After the change, re-run the check. Consent Mode is a configuration that a deploy can break silently, so the sites that keep it working are the ones that check on a schedule.