Since 8 October 2026, every Google Tag Manager snippet initialises its container as soon as it loads, “regardless of any gtag(‘config’) commands”, and those config calls now appear in the dataLayer as gtag.config events. Google warns that containers with wildcard custom event triggers may fire tags on them. If your site loads a GTM- snippet but configures GA4 or Google Ads with hand-written gtag('config', 'G-…') lines, Google now calls that an unsupported implementation. Three checks: your consent default still runs before the snippet, no consent-sensitive tag fires on gtag.config, and your G-/AW- IDs use the real gtag.js snippet.
What Google changed
The Tag Manager release notes for 8 October 2026 are short:
“all Google Tag Manager (gtm.js) container snippets will initialize on container load, regardless of any gtag(‘config’) commands. These changes to the gtag mean that config commands will now surface in the dataLayer as visible gtag.config events. If your Google Tag Manager containers use wildcard custom event triggers, this change may cause those tags to fire.”
A related help article adds that “all new deployment snippets will be the same. Additionally, they will not have the gtag config command.” Instead, Google recommends controlling initialisation with the gtm init trigger, which “can also configure the tag to wait for the config command if you want to preserve legacy setup”.
Who is affected
The setup Google is targeting is a hybrid that many CMP install guides and agency templates produce: a gtm.js container snippet on the page, and alongside it gtag('config', 'G-XXXX') or gtag('config', 'AW-XXXX') lines added by hand. Google’s supported-implementations page is now explicit: loading a G-, AW- or DC ID “using a Google Tag Manager snippet path (gtm.js)” is “an unsupported implementation, and sites using them may experience unexpected changes to their tag behavior”. Google says owners of affected containers “received an email notification” — if someone on your team got one, this is what it was about.
Sites that load GA4 with the standard gtag.js snippet, or that configure everything inside a GTM container, are not the target.
Why it matters for consent
1. Wildcard triggers can fire on a new event. A trigger set to “Custom Event” with the event name .* (regex) fires on every dataLayer event — and there is now one more, gtag.config, early in the page. If such a trigger feeds a non-Google tag that has no consent check of its own — a pixel, a chat widget, a session-replay script — it can now fire at a moment it did not before, possibly before your CMP has read the visitor’s choice. Google tags respect Consent Mode; most third-party tags do not.
2. The consent default must still come first. Google’s consent guide requires the default to run “before any commands that send measurement data (such as config or event)”. If your default is a gtag('consent', 'default', …) call in the page, keep it above the GTM snippet. If your CMP sets the default from inside the container, check that its tag fires on the Consent Initialization trigger, not on an event that now arrives later than the container start. We covered the ordering rules in default vs update: execution order, and a related failure in why gtag consent can be silently ignored.
3. Initialisation is no longer tied to your config line. Code that relied on “nothing happens until gtag('config') runs” — some consent setups deliberately delayed the config call until after a choice — no longer holds for gtm.js. Use the gtm init trigger, or Consent Mode, to control what fires.
How to check your site
- Look at the snippet. View source and search for
gtm.js?id=GTM-and forgtag('config'. Both on the same page, with aG-orAW-ID in the config call, is the unsupported pattern. Move those IDs to the standardgtag.jssnippet, or configure them as Google tags inside the container. - Look at the dataLayer. In the browser console, run
dataLayer.map(e => e.event || (e[0] + ':' + e[1]))on a fresh load. Confirm the consent default appears beforegtm.js, and note where anygtag.configevent appears. - Look at your triggers. In GTM, search triggers for Custom Event with regex matching (
.*or similar). For each tag using one, ask whether it should fire ongtag.config. If not, add an exception or make the event name explicit. - Look at the network. With a fresh profile and no consent given, the first GA4 or Ads hit should carry a denied
gcs(G100) and no cookies should be written. Our network-tab guide shows how to read it.
We have not measured this on a production container: the outcome depends on each container’s triggers. The checks above are what tells you whether your site is affected. For the container-side setup, see the Consent Mode v2 GTM setup guide.
A tag that starts firing on a new event is easy to miss. Check what your Google and third-party tags send before consent with CookieInspector.