Google Tag Manager will stop waiting for gtag('config'): what to check

Google's 8 October 2026 Tag Manager release note says that all gtm.js container snippets will initialize on container load "regardless of any gtag('config') commands," and that config commands will now surface in the dataLayer as visible gtag.config events. Two groups need to act: sites that load a G-, AW- or DC- tag ID through the gtm.js snippet path, or pair a GTM snippet with a standalone gtag('config') line and no gtag.js loader, and any container that fires tags on a wildcard .* custom event trigger.

What Google announced on 8 October 2026

The entry in the Google Tag Manager release notes is titled "Standardizing gtag('config') command behavior for Google Tag Manager" and runs to three short paragraphs. Google says it is standardizing the behavior of tagging snippets "to ensure consistency, reliability, and high performance across all websites that use the Google tag."

The note makes three statements. First, all Tag Manager (gtm.js) container snippets will initialize when the container loads, regardless of any gtag('config') command. Second, config commands will now surface in the dataLayer as visible gtag.config events, and Google warns that containers using wildcard custom event triggers may fire those tags on that event. Third, sites that want to keep using gtag configuration code must make sure every page runs the Google tag (gtag.js) snippet.

The release note points to a Google help page, "Set up your Google tag installation correctly for gtag.js," which carries the practical detail: which installations Google supports, a four-step migration procedure and two ways to verify the result.

Two snippets, two kinds of ID

Google ships two loaders that look similar in page source, and the change only makes sense once they are separated. The Tag Manager container snippet loads a file called gtm.js and is identified by an ID that starts with GTM-. The Google tag snippet loads gtag.js from googletagmanager.com/gtag/js and uses product IDs: G- for Google Analytics 4, AW- for Google Ads and DC- for Floodlight.

The gtag.js snippet defines a small gtag() function, then calls gtag('js', new Date()) and gtag('config', 'TAG_ID'). That function does one thing: it pushes its arguments onto the dataLayer array, the same array Tag Manager reads. A config call has always landed in that array. Under the 8 October release note, a gtm.js container will initialize without regard to that call, and Tag Manager will expose it as a named gtag.config event that triggers can see.

Who is affected by the gtag.config change

Group 1: the unsupported hybrid install

Google's help page describes the unsupported setup in two ways. It names a non-GTM tag ID, such as one starting with G-, AW- or DC, deployed through the Tag Manager snippet path (gtm.js). Its "incorrect implementation" example is a standard GTM container snippet, loaded with a GTM-XXXXXX ID, followed by a separate script block that contains only gtag('config', 'TAG_ID'), with no gtag.js loader on the page. The help page's warning covers any page that uses a GTM snippet but relies on gtag('config') to pass parameters or configure a tag. Google says sites using this pattern "may experience unexpected changes to their tag behavior."

Google also says users on containers with the unsupported implementation received an email notification. It does not say how many containers that covered. If the container's admin email belongs to a former employee or a previous web developer, the warning may never have reached whoever manages the site today, so a manual check is safer than waiting for a message.

PPC Land, which analysed the change on 9 October, describes the advertiser risk in plain terms: Google Ads conversion tags or Analytics configuration that relied on the loose config line may no longer pick up the parameters that line was passing.

Group 2: containers with .* custom event triggers

The second group is wider and harder to spot. Google's custom event trigger documentation already warned that "the .* regex means that your trigger will execute on all detected events, including events that Google Tag Manager and Google tag emit automatically," and it recommends a more restricted regex. The new gtag.config event is one of those automatically emitted events.

PPC Land points out that this half of the change can reach installations Google considers correct, because the supported gtag.js snippet itself contains a config call. On a page that runs gtag.js next to a GTM container, a tag on a .* trigger will have one more event to fire on. How much that matters depends on the tag. A debugging logger gains an extra row. A conversion tag, a remarketing tag or a custom HTML tag that forwards every dataLayer event to another platform could send an extra hit.

Who is not affected

A site that runs only the standard gtag.js snippet and has no wildcard triggers, or only a GTM- container with the Google tag configured inside Tag Manager and no .* triggers, already matches what Google documents as correct. The help page does not ask those sites to change anything.

Supported and unsupported installs at a glance

Google's release note and help page describe four installation patterns. This table summarises what Google says about each one.

How to migrate off the unsupported pattern

Google's help page sets out four steps for moving a hybrid install to the supported gtag.js snippet.

1. Copy your Google tag ID. In Google Ads, open Data manager from the Tools menu, find the Google tag under "Google tag", click Manage, select the Google tag on the left of the diagram and copy the ID under "Tag details". In Google Analytics, go to Admin, then "Data collection and modification", Data streams, choose the stream, click "Configure tag settings", select the Google tag and copy the ID under "Tag details".
2. Insert the ID into Google's gtag.js template, replacing TAG_ID.
3. Remove the gtm.js snippet and any standalone gtag('config') commands associated with it from your pages.
4. Paste the gtag.js snippet immediately after the opening head tag on every page of the site.

Removing Tag Manager is not the only route, and for many marketing sites it is the wrong one. Google says that if you use Tag Manager to manage other third-party tags or custom configurations, you should keep the main Tag Manager snippet, replace the G-, AW- or DC- ID in the gtm.js snippet with your GTM-XXXXXX ID, deploy the Google tag within the container and apply any configuration in the Tag Manager interface. A site that runs Meta, TikTok or LINE tags through Tag Manager would normally take this path.

Before deleting anything, record what the old config line was doing. Google's help page frames the problem as pages that "rely on gtag('config') to pass parameters or configure your tag." Whatever settings that line carried have to exist somewhere after the migration, either in the new gtag.js snippet or in the Google tag configuration inside Tag Manager. Removing the line without moving its settings would swap one tracking gap for another.

How to deal with .* triggers

Google's general advice is to use a more restricted regex. In practice that means listing the event names a tag should respond to instead of matching every event. If a tag genuinely needs to see almost everything, add a condition so it ignores the gtag.config event, or make sure your logs and reports account for the extra firing.

A container audit for this takes four passes:

• Open each custom event trigger and look for "Use regex matching" combined with .* or any pattern broad enough to match gtag.config.
• List the tags each of those triggers fires.
• Leave pure logging or debugging tags alone if an extra row does no harm.
• Narrow the trigger, or add an event-name exclusion, for every tag that sends conversions, remarketing audiences or events to a third-party platform.

How to verify the fix

Google documents two checks on its help page.

• Tag Assistant: go to Google Tag Assistant, click Add domain, enter your site URL and click Connect. Under the "Google tags found" header, confirm your tag ID appears with a green or blue status icon.
• Chrome Developer Tools: open the site in Chrome, open Developer Tools from View, Developer, Developer Tools, open the Network tab and refresh. Requests should go to googletagmanager.com/gtag/js instead of /gtm.js. Google Ads traffic shows as requests to googleadservices.com, and Google Analytics traffic as requests to analytics.google.com.

One clarification: the /gtag/js check is written for sites that moved to the gtag.js snippet. If you kept Tag Manager and switched the snippet to your GTM- ID, a gtm.js request carrying that GTM- ID is the expected result. For the trigger side, run Tag Manager's preview on a page that executes a config command, find gtag.config in the event list and check which tags fired on it.

What Google has not said

Several open questions remain after the 8 October entry, and it is worth knowing them before planning work around the change:

• Google has not said how many containers use the unsupported pattern or how many owners received its email.
• PPC Land notes that the help page says gtm.js snippets "will soon be updated." The release note is dated 8 October but also uses "will", so neither confirms the rollout date.
• Neither document says whether Tag Manager's diagnostics will flag the hybrid pattern or wildcard triggers catching the new event.
• Google gives no estimate of how much measurement could shift for affected sites.

How this fits Google's recent tag changes

The release notes show a steady tightening of how Google's tag code may be installed. On 9 July 2026, Google changed how Tag Manager handles containers loaded through unsupported paths such as /gtag/js or /gtag/destination. From then on, the ID used to load the container, not the path, decides what may run: containers loaded with a GTM- ID are not restricted, while product IDs such as G- or AW- only permit tags and variables provided by Google. The 8 October change handles the mirror case, gtag config commands placed beside a GTM loader.

PPC Land links both changes to Google's May 2026 plan to merge Tag Manager and the Google tag, and quotes Google saying new deployment snippets "will not have the gtag config command." Relevant Audience covered that unification on 25 August 2026, and Tag Manager's guided Google Ads purchase tracking setup on 21 July 2026. Read together, the direction is one loading rule per ID, with config handled inside the tag or container rather than in loose page code.

What this means for Thai marketers

If your tracking code was added in layers (a Google Ads snippet from one setup screen, a GA4 snippet from another, a Tag Manager container added later), a hybrid install can happen without anyone choosing it.

Two checks cover most of the risk. View your page source and look for a gtm.js snippet whose ID starts with G- or AW-, or a gtag('config') line with no gtag/js loader above it. Then open your container and review any tag on a .* trigger, especially LINE Tag, TikTok pixel and Meta pixel tags, since an extra firing per page can inflate the event counts those platforms report. If your GA4 implementation or your Google Ads conversion tracking depends on either pattern, fix it before the numbers drift into next month's reports.

FAQ: gtag.config and Google Tag Manager

Do I need to change anything if my site only uses a GTM- container?

Not for the loading change, as long as no standalone gtag('config') line sits beside the GTM snippet without a gtag.js loader. Google's own unsupported example is a GTM- snippet plus a loose config line. The gtag.config event still appears on any page that runs a config command, so check wildcard triggers either way.

What is the gtag.config event?

It is a dataLayer event that, according to Google's 8 October 2026 release note, will surface whenever a gtag('config') command runs. The config call always went into the dataLayer; it will be surfaced as a visible, named event that triggers can match.

How do I know if my site uses the unsupported setup?

Your site uses it if a G-, AW- or DC- ID is loaded through the gtm.js snippet, or if a GTM snippet sits beside a standalone gtag('config') line with no gtag.js loader. Google says it emailed users on containers with that pattern, but checking the page source directly is more reliable than relying on the email.

Is this change live in Thailand?

Google's release note does not mention any country or regional limit. What Google has not stated is whether rollout is immediate for every container or phased.

Will this break my Google Ads conversion tracking?

It can, if your conversion setup depends on the hybrid pattern or if conversion tags fire on .* triggers. Google does not quantify the effect, so the safe move is to audit both patterns and verify with Tag Assistant and the Network tab.

The 8 October change is small in code and easy to miss in practice, because nothing visibly breaks on the page. If you are not sure which pattern your site uses, Relevant Audience can review your Tag Manager container and Google tag installation and tell you exactly what needs to move.