gtag('config') Stops Working in GTM on October 2, 2026

If Google emailed you about an “unsupported implementation” on your container, do not archive it unread: starting October 2, 2026, gtm.js snippets will stop recognizing and waiting for your gtag('config') commands. In plain terms, the gtag config + gtm.js combo that many sites run without realizing it is about to change behavior overnight, and some tags will either fire too early or stop receiving their parameters. The good news: diagnosing your case takes 60 seconds, and the fix is often a copy-paste job. This guide tells you whether you are affected, which of the three scenarios you fall into, and what to do before the deadline.

What Google is changing for gtag(‘config’) on October 2, 2026

Today, a gtm.js snippet can “listen” for the gtag('config', 'G-XXXX') commands on the page and wait for their parameters before initializing. That waiting behavior is what goes away. From October 2, 2026, every gtm.js snippet initializes on container load, regardless of any gtag('config') commands present on the page. Google’s help page puts it bluntly: Tag Manager snippets will no longer recognize, or wait for, any gtag('config') command.

The problem case is the one Google calls an “unsupported implementation”: a G- (GA4), AW- (Google Ads) or DC- (Floodlight) ID loaded through a gtm.js path instead of the proper gtag.js snippet. These setups worked so far as a side effect. They will stop working as intended, with no warning beyond the email you may already have received. This change is part of the broader shift where GTM is becoming Google Tag: same unification logic, but here with a breaking, dated consequence.

Are you affected? The 60-second test

Before touching anything, check. Open your site, launch Chrome DevTools (F12), go to the Network tab, filter on js, then reload the page. Look at what the browser downloads:

• a request to gtm.js (https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXX): you are loading a Tag Manager container.
• a request to gtag/js (https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX): you are loading the real Google tag.

Now, in the Console tab or in the page source, look for a gtag('config', 'G-...'), gtag('config', 'AW-...') or gtag('config', 'DC-...') line. Cross-referencing the two gives you your diagnosis. If you load only gtm.js but you find a gtag('config') with a G-, AW- or DC- ID, you are running an unsupported implementation. Double-check with Tag Assistant (Google): start a debug session, look at which tags fire and with which ID. Tag Assistant shows you in black and white which snippet actually serves your tags.

The three scenarios and their fixes

Once you have your diagnosis, you fall into exactly one of these three cases. The table below sums up the action; details follow.

Case A: GTM only, nothing to do

You load a clean GTM-XXXXXX container, all your tags (GA4, Ads, others) are configured inside the Tag Manager interface, and there is no hard-coded gtag('config') in the page. This is the clean, recommended implementation. The October 2 change does not touch you. Still, run the 60-second test anyway, because a stray gtag('config') left in an old template or a plugin happens more often than you would think.

Case B: Google ID loaded via gtm.js, the real fix

This is the notified sites’ case. You load a G-, AW- or DC- ID through a gtm.js snippet, and you rely on gtag('config') to pass parameters. The official fix is clear: switch back to the real gtag.js snippet. Here are the two blocks, the wrong one and the right one, side by side.

Incorrect snippet (Google ID served by gtm.js):

<script async src="https://www.googletagmanager.com/gtm.js?id=G-XXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');
</script>

Correct snippet (real gtag.js):

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');
</script>

The difference is one word in the URL: gtag/js instead of gtm.js. The rest of the code stays put. Once you make the switch, your gtag('config') is read and awaited again as intended, because you are finally loading the script that is meant to handle it.

Case C: legitimate GTM plus a gtag config, move it into the UI

You genuinely use Tag Manager to drive several tags (triggers, variables, other platforms) and you have a gtag('config') on the page for a GA4 or Ads ID. Do not break your container: keep the GTM-XXXXXX snippet, but move the configuration that lived in gtag('config') into the GTM interface, as a Google tag configured cleanly with its parameters. This is the moment to audit your dataLayer and make sure the values your config parameters depended on are actually pushed on the container side; the complete GTM dataLayer guide walks through how to structure that without breaking your GA4 events.

The gtm init trigger: what it actually does

Google introduces a new trigger, gtm init, to take back control of the initialization behavior that gtag('config') handled implicitly. It fires at container bootstrap and acts as an anchor point for everything that must go first. Key point for legacy setups: gtm init can be configured to wait for the config command before letting tags fire, which gives you a safety net if your historical implementation relied on that wait. In other words, if you cannot migrate cleanly by October 2, this trigger is your spare wheel, not your target solution.

The consent trap: the order that breaks everything

This is where most setups will fail silently. Three initialization moments now coexist, and their order decides whether a tag fires before or after consent: Consent Initialization (gtm.init_consent), then Initialization (gtm.init), then your gtm init. A consent-dependent tag wired to the wrong trigger will fire before the CMP has returned its signal, and you will either collect data with no legal basis, or lose conversions because the tag fires too late.

The rule: anything advertising-related or consent-dependent must sit after Consent Initialization, never before. If you have already wrestled with Consent Mode v2 in GA4, you know that ad_storage now governs the flow to Google Ads on its own: a tag that wakes up before the consent signal is exactly the scenario that empties your conversions. Check the trigger order before you consider the migration done.

Post-migration verification

An unverified migration is not a migration. After applying your fix, run through this check:

1. Tag Assistant: start a fresh session, confirm your tags fire with the right ID and through the right snippet.
2. DevTools, Network tab: verify the request goes to gtag/js (case B) and that GA4 hits (/g/collect) and Ads hits fire with the right parameters.
3. GA4 real-time: check that events come through and that the expected parameters are present.
4. Google Ads conversions over 48 hours: this is the real judge. Watch conversion volume across two days to catch a tag that no longer fires, or fires too early.

If you want a broader frame for that check, the GA4 configuration audit covers the issues that most often distort data after a tagging change.

Checklist before October 2, 2026

So nothing slips through, here is the short list to tick before the date:

• 60-second test done (Network gtm.js vs gtag/js + search for gtag('config')).
• Case identified (A, B or C) and fix chosen.
• Snippet corrected (case B) or config moved into the GTM UI (case C).
• Trigger order verified: consent before advertising tags.
• Tag Assistant + DevTools + GA4 real-time check.
• Google Ads conversions monitored for 48 hours after the switch.

One last useful point: this change only affects the client-side. If your tags already run through server-side GTM, or if you serve your snippet first-party via Google Tag Gateway, the server-side initialization logic is not impacted by this shift. What is left is your client layer, and doing it before October 2 beats doing it on October 3.