Free scan
Google Tag Manager · troubleshooting

Google Tag Manager fires tags before consent

Because that is what a container does by default. GTM loads, evaluates every trigger, and fires every tag whose trigger matches — consent is an extra check you have to switch on, tag by tag, and it does not exist until you add it.

The short answer

There are two separate switches, and most containers have neither. The first is a consent default: a small snippet that runs before gtm.js and tells Google's tags that storage is denied until told otherwise. Without it, tags behave as though consent were granted. The second is the per-tag consent setting: inside each tag's Advanced Settings, Tag Manager asks whether additional consent is required, and the default answer is no.

So a container can sit behind a perfectly good consent banner and still fire everything on page load. The banner talks to its own cookie; the container never hears about it. Fixing this is configuration work in GTM plus one snippet on the page — no re-platforming, usually under an hour.

Last reviewed: September 1, 2026Diagnostic + fix checklistGeneral information, not legal advice

What it looks like

The signature is a burst of third-party requests that all begin within a few hundred milliseconds of gtm.js. Open a fresh incognito window with DevTools → Network, load the site, and do not touch the banner. You will see the container load, then the tags it fired: an analytics beacon, an ad pixel, maybe a recorder — each one a tag, each one firing because its trigger matched and nothing asked about consent.

The other tell is in Tag Manager itself. Open Preview / Tag Assistant and look at the Consent tab: if no on-page default consent state is reported, nothing on the page ever told Google's tags to wait.

DevTools → Network — fresh incognito, banner untouched:
GET googletagmanager.com/gtm.js?id=GTM-XXXXXX ← container loads with the page
POST google-analytics.com/g/collect?v=2&tid=G-XXXX ← tag fires ~200ms later, banner untouched
GET www.facebook.com/tr/?id=…&ev=PageView ← second tag, same load, same page

Verify it yourself in five minutes

You do not need a tool to answer this. Two passes — one in the browser, one in Tag Manager — tell you whether your container is gated.

  1. Open a clean session. New incognito window, DevTools → Network tab, tick Preserve log and Disable cache. Load your homepage. Do not click the banner, do not scroll, do not close anything.
  2. Find the container. Filter the request list for gtm.js and note its time. That is time zero — everything after it that goes to a third party is a tag your container fired.
  3. Clear the filter and read down the list. Sort by time. Any request to a vendor domain (google-analytics.com, facebook.com, analytics.tiktok.com, clarity.ms, snap.licdn.com) that appears before you interacted with the banner is a pre-consent tag fire. Write down the domains — that list is your work queue.
  4. Check the consent state in Tag Assistant. In Tag Manager, click Preview, enter your URL, and when Tag Assistant opens look for the Consent tab or the on-page consent state. "No consent state" or everything granted at page load means no default was ever set.
  5. Check one tag's settings. Back in GTM, open any marketing tag → Advanced Settings → Consent Settings. If it reads "No additional consent required", that tag fires no matter what the visitor chooses. Repeat for two or three more — the answer is usually the same for all of them.

What a healthy result looks like: If the container request and the vendor requests share the same one-second window and you never clicked anything, the tags are ungated. That is a fact about your page load, and it is the fact everything else on this page is about.

Why it happens

1. No consent default runs before the container

Google's consent framework only works if a gtag('consent','default',…) call executes before gtm.js. If the snippet is missing — or was pasted after the container, or lives in a GTM tag rather than in the page source — the tags start with no instruction to wait.

2. Every tag defaults to "no additional consent required"

Tag Manager does not infer consent requirements. Each tag has its own Consent Settings field, and a tag created without touching it fires whenever its trigger matches. A container with forty tags typically has forty of these.

3. Triggers fire at container load

All Pages and Initialization – All Pages both fire the instant the container is ready. That is correct behavior for a trigger; it just means the timing question has to be answered by consent settings, not by the trigger.

4. Custom HTML tags carry raw vendor snippets

A vendor snippet pasted into a Custom HTML tag executes exactly as written. If that snippet initializes the vendor's SDK on load, the SDK starts working the moment the tag runs — the tag's own consent setting is the only thing standing in front of it.

The risk context

California's Invasion of Privacy Act (CIPA), Penal Code § 631, prohibits intercepting a communication without the consent of all parties. Since 2022, plaintiff firms have applied that decades-old wiretapping statute to websites — arguing that tags in your container transmitting visitor page views and events to their vendors before the visitor consents is an intercepted communication. Statutory damages under § 637.2 run up to $5,000 per violation, and plaintiffs argue each affected visitor session is a separate count, which is why even small sites receive demand letters. Similar all-party-consent statutes in Pennsylvania (WESCA), Florida (FSCA), and Massachusetts have produced parallel filings.

To be precise about what a network log can tell you: a tracker firing before consent is a technical finding — it establishes when a script transmitted data, not whether any law was broken. But timing is exactly what these claims are built on, which is why fixing the timing is the practical response.

How to fix it

Consent-gating snippet

<!-- Place BEFORE the GTM/gtag snippet. Defaults all storage to "denied"
     so no tags fire until your CMP updates consent after the user opts in. -->
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('consent', 'default', {
    ad_storage: 'denied',
    analytics_storage: 'denied',
    functionality_storage: 'denied',
    personalization_storage: 'denied',
    security_storage: 'granted',
    wait_for_update: 500
  });
</script>

Your CMP (Cookiebot, OneTrust, Termly, etc.) calls gtag('consent','update',{...:'granted'}) only after the visitor accepts. Until then, tags stay blocked.

What this is called

Terminology bridge

The setting you are looking for is called consent mode, and the per-tag switch is additional consent checks. When people talk about "the tags need to wait for the CMP" they mean tag firing order or tag sequencing. The pattern where a tag transmits data before the visitor answers has a name too — a consent gap — and it is what an automated pre-consent scan measures.

Knowing the vocabulary matters mainly because it unlocks the documentation: Google's docs index everything under "consent mode", not under "stop my tags firing early".

What a scan can and can't tell you

Two honest limits. A network log shows what loaded and when — it does not show whether a court would call any of it a violation, and nothing on this page is legal advice. And Tag Assistant only knows about tags in your container: a pixel hardcoded in your theme, injected by a plugin, or added by a platform integration is invisible to it. That is exactly the gap a real-browser scan of the rendered page closes, because it records every request regardless of who put the script there.

Sources

  1. Google: Tag Manager consent mode supportsupport.google.com
  2. Google: About triggers (Tag Manager)support.google.com
  3. Google: Set up consent mode on websitesdevelopers.google.com
  4. Google: Troubleshoot consent mode with Tag Assistantdevelopers.google.com
  5. California Penal Code § 631 (leginfo.legislature.ca.gov)leginfo.legislature.ca.gov

Check your own site

RegSentry loads your site in a real browser, records when each third-party tracker first contacts its server, and flags everything that fires before consent — with the fix for each one. Continuous monitoring re-runs it and emails you when something new appears.

Free real-browser scan

See every pre-consent tracker on your site — free, 30 seconds, no signup.

Real browser scan, no signup to run it. You see a summary of the findings; the full report with every tracker unlocks with your email.

Common questions

Why does Google Tag Manager fire tags before my consent banner?
Because GTM fires every tag whose trigger matches as soon as the container loads, and consent is an optional per-tag check that is off by default. Unless a consent default snippet runs before gtm.js and each tag is set to require consent, the container has no reason to wait for the banner.
Does blocking GTM itself solve the problem?
It stops the tags in the container, but it is a blunt instrument: it also blocks tags you may consider strictly necessary, and it does nothing about trackers hardcoded in your theme or injected by plugins. The maintainable fix is consent defaults plus per-tag consent requirements, so each tag waits for the consent type it actually needs.
How do I see which GTM tags fire before consent?
Load your site in a fresh incognito window with the DevTools network tab open, note the time of the gtm.js request, and list every third-party request that follows before you touch the banner. Then check the same tags in Tag Manager's Preview mode and in each tag's Consent Settings. A free real-browser scan produces the same list automatically, including trackers that are not in your container.

Keep reading

Guide: Google Consent Mode v2 setupConsent Mode is on but tags still fireGoogle Analytics loads before consentReport: the state of website trackingFree cookie consent checker