Consent default fires after GTM? Fix the trigger order

Jul 23, 2026

If your consent default fires after GTM loads other tags — Google Analytics or Google Ads requests showing up in DevTools before Consent Mode's default has been set, even though you know you configured one — the cause is almost never a missing default. It's an ordering problem: the tag that sets the default is racing against the tags it's supposed to gate, and sometimes losing. This article is the deeper, GTM-specific version of failure mode #1 from why Google Consent Mode v2 isn't working — worth reading this one specifically if you've confirmed that the default is racing, and want the full trigger-level fix rather than the short version.

The fix: Consent Initialization - All Pages

GTM ships a trigger type built specifically to solve this: Consent Initialization - All Pages, available in the trigger type picker alongside Page View, DOM Ready, and the rest — not something you need to create or configure conditions for. Unlike every other trigger type, tags assigned to it are guaranteed to fire before any other tag in the container, on every page load, without exception. That guarantee is the entire fix.

How to check what you're currently using: in your GTM workspace, open the tag that sets your consent default (either a custom HTML tag calling gtag('consent', 'default', {...}), or GTM's built-in Consent Settings tag type). Check its trigger. If it's anything other than Consent Initialization - All Pages — Page View, DOM Ready, Window Loaded, a custom event, anything else — that's the bug, and it explains why the behavior can look intermittent: unordered triggers sometimes let the default win the race, sometimes not, which is exactly why a single manual check can miss it.

The fix: change the tag's trigger to Consent Initialization - All Pages. See Google's own documentation on setting up consent mode for the full reference this trigger type is part of.

Why tag priority and sequencing don't fix this the same way

It's a common next step to try raising the consent tag's priority number, or using Tag Sequencing (Setup/Cleanup tags) to force it earlier. Neither actually solves the root problem: priority only orders tags within the same trigger, and Tag Sequencing controls one tag firing relative to another specific tag, not the consent default relative to every tag in the container generally. Both can reduce how often the race is lost without eliminating it — which produces the worst version of this bug: rare enough to pass casual testing, common enough to still leak pre-consent data in production.

Confirming the fix actually worked

How to check: after switching the trigger, clear your cookies (or use a fresh incognito window) and run the same DevTools check covered in how to check if cookies fire before consent — the consent entry with "default" should be the first or among the very first dataLayer entries. Reload several times to confirm it's consistent, not just correct on one lucky run, since consistency across repeated loads is exactly what this fix is supposed to guarantee.

If your container has multiple consent-setting tags

Occasionally a container ends up with more than one tag trying to set the consent default — left over from a CMP migration, or a custom implementation added alongside a CMP's native one. If you have two tags both calling gtag('consent', 'default', ...), whichever fires last silently overwrites whichever fired first, and unordered triggers make this just as inconsistent as the single-tag version of this bug. Search your container for every tag referencing consent or gtag before assuming there's only one to fix.

If you'd rather not check this by hand every time

A pre-consent scan checks exactly this: whether the consent default is present before any other tracking tag fires, across a real first-time page load — the same race condition this article is about, checked automatically instead of manually reloading and inspecting dataLayer yourself.

— Petrus, ConsentCheck founder. This is the single most common GTM container issue I see when auditing a "should be working" Consent Mode setup — it's a trigger dropdown, not a rewrite.

FAQ

Why does my consent default fire after GTM instead of before it?

Almost always a trigger-type mistake: the tag that sets your consent default (whether a custom HTML gtag call or GTM's built-in Consent Settings feature) is set to fire on a regular trigger like Page View or DOM Ready, instead of Consent Initialization - All Pages. Regular triggers race against every other tag in the container -- sometimes the default wins, sometimes it doesn't, which is why this bug can look intermittent rather than consistently broken.

What is the Consent Initialization - All Pages trigger and why does it fix this?

It's a trigger type Google Tag Manager built specifically for consent defaults -- unlike every other trigger type, tags on this trigger are guaranteed to fire before any other tag in the container, including tags on Page View or DOM Ready triggers. That guarantee is the entire fix: it removes the race condition instead of trying to win it with trigger priority settings or tag sequencing workarounds.

I set tag priority/sequencing on my consent tag instead -- why didn't that fix it?

Tag priority and Tag Sequencing (Setup/Cleanup tags) control order *within the same trigger type*, not across different ones -- they don't override the fundamental unordered nature of most GTM triggers relative to each other. A high-priority tag on Page View can still lose to a tag on DOM Ready if DOM Ready happens to resolve first on a given page load. Consent Initialization - All Pages is a structurally different trigger type built to sidestep this entirely, which sequencing settings on a regular trigger can't replicate.

Does this affect GTM's built-in Consent Settings feature the same way as a custom gtag tag?

Yes -- GTM's Consent Settings feature (the built-in way to set consent defaults without a custom HTML tag) still needs a trigger assigned to it, and the same Consent Initialization - All Pages requirement applies. Using the built-in feature instead of a raw gtag call doesn't change the ordering requirement, it just changes how you configure the default values in the GTM UI.

Want to know if your own site does this?

Scan your site free