Google on October 8, 2026 changed how Google Tag Manager container snippets treat gtag('config') commands. According to the Tag Manager release notes, every gtm.js container snippet now initializes on container load "regardless of any gtag('config') commands," and those commands now appear in the dataLayer as visible gtag.config events - a new entry that can trigger tags built on wildcard custom event rules.

In Short

Google changed its Tag Manager code so that it no longer pauses to wait for a separate setup instruction called gtag('config'), and that instruction now shows up as its own event in the list of things Tag Manager watches. If you built a rule that fires a tag on every event, that rule now has one more event to fire on. Sites that relied on the old pause-and-wait behavior need to switch to Google's other snippet, gtag.js, to keep their configuration working.

What changed on October 8

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

The substantive change sits in one sentence. "With this update, all Google Tag Manager (gtm.js) container snippets will initialize on container load, regardless of any gtag('config') commands," according to the release note.

That matters because two distinct pieces of Google code are involved, and the distinction is not always obvious from the page source. The first is the Tag Manager container snippet, which loads a file called gtm.js and is identified by an ID beginning with GTM-. The second is the Google tag, which loads gtag.js and is identified by product-specific IDs such as G- for Google Analytics, AW- for Google Ads or DC- for Floodlight. The gtag.js snippet is the site tag that most Google Ads and Analytics setup screens hand to advertisers, and it carries its own command queue: gtag('js', ...) to start, gtag('config', ...) to configure a destination.

Until October 8, a gtm.js container could recognize and wait for a gtag('config') call placed elsewhere on the page. Some sites came to depend on that, pairing a GTM snippet with a stray config line rather than installing the matching gtag.js loader. Google has now removed that dependency. The container initializes when it loads, full stop.

The second consequence is the one practitioners noticed first. "These changes to the gtag mean that config commands will now surface in the dataLayer as visible gtag.config events," according to Google. "If your Google Tag Manager containers use wildcard custom event triggers, this change may cause those tags to fire."

The release note closes with a single instruction: to continue using gtag configuration code, all pages need to run the Google tag (gtag.js) snippet.

The gtag.config event and wildcard triggers

Tag Manager reads instructions from the dataLayer, a JavaScript array that pages push named events into. A custom event trigger watches that array and fires tags when an event name matches. Google's help documentation for the trigger type describes its most common use as tracking form submissions where "the default behavior for the form has been altered."

Custom event triggers accept regular expressions when the "use regex matching" option is selected. The pattern .* matches any string at all. Google's own documentation for the trigger already carried a warning about this before October 8. "The .* regex means that your trigger will execute on all detected events, including events that Google Tag Manager and Google tag emit automatically," the help page states, adding that "it's recommended that you use a more restricted regex when using regex matching."

The new gtag.config event falls squarely into that category of automatically emitted events. A container whose tags fire on .* will now see one more firing on every page where a gtag('config') command runs. Whether that is harmless depends on the tag. A logging or debugging tag that records every dataLayer push gains an extra row. A conversion tag, a remarketing pixel or a custom HTML tag that forwards events to a third party could send an extra hit.

Simo Ahava, co-founder at Simmer and a long-standing Tag Manager specialist, flagged this point in a LinkedIn post that linked to the October 8 entry. He framed the container-loading fix as a narrow one. "They started with making GTM work even when loaded through the Google Tag CDN, and now they're fixing container loading issues when stray gtag('config', ...) calls are combined with just the GTM snippet (and not a gtag loader)," Ahava wrote.

The broader exposure, in his reading, is the event. "The thing you need to watch for is that there's a new Data Layer event in the timeline: gtag.config," he wrote. "If you use .* event name triggers, this will be an additional firing for them, so make sure to either filter this event out in the trigger level or to account for it in your annotations and logs."

There is a distinction worth drawing between the two halves of the change. The container-initialization fix affects only sites with what Google classifies as an unsupported implementation. The new event affects any container with wildcard triggers on a page that also runs gtag('config') - including sites whose installation Google considers entirely correct, since the supported gtag.js snippet itself contains a config call.

Supported and unsupported implementations

Google's help page titled "Set up your Google tag installation correctly for gtag.js" lays out which setups the company accepts. It opens with a warning box: "Google Tag Manager (gtm.js) snippets will soon be updated to no longer recognize or wait for any gtag('config') commands. If your pages use a GTM snippet, but rely on gtag('config') to pass parameters or configure your tag, you must update your website code to use the correct Google tag (gtag.js) snippet."

The page then defines the problem precisely. "Some websites currently deploy a non-Google Tag Manager prefixed Google tag ID, such as those starting with G-, AW-, or DC, using a Google Tag Manager snippet path (gtm.js)," according to Google. "This is an unsupported implementation, and sites using them may experience unexpected changes to their tag behavior."

Google says it has already contacted some of those affected. "Users on containers with the unsupported implementation received an email notification," the help page states. It gives no count of those notified.

The incorrect pattern

Google's example of an unsupported setup is the standard GTM container snippet - the self-executing function that pushes a gtm.start timestamp and an event named gtm.js into the dataLayer before injecting the script from googletagmanager.com/gtm.js - followed by a separate script block containing only:

gtag('config', 'TAG_ID');

There is no gtag.js loader in this pattern, and Google's example defines no gtag() function either. The config line worked only because the container had been designed to recognize it.

The correct pattern

The supported alternative is the full Google tag snippet:

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

Google's note under the example specifies that TAG_ID is replaced with the actual Google tag ID, "for example, G-XXXXXX, AW-XXXXXX, or DC-XXXXX."

The snippet also explains where the new event comes from. The gtag() function is nothing more than a wrapper that pushes its arguments onto the same dataLayer array that Tag Manager reads. A config call has always landed in that array. What changed on October 8 is that Tag Manager now surfaces it as a named, visible gtag.config event.

The migration Google describes

The help page sets out four steps for moving off the unsupported pattern. The first is retrieving the Google tag ID: in Google Ads, through the Data manager section of the Tools menu, under "Google tag" and then "Manage"; in Google Analytics, through Admin, "Data collection and modification," Data streams and "Configure tag settings." In both products the ID sits under "Tag details."

The second step is inserting that ID into the correct gtag.js template. The third is removing the gtm.js snippet and any standalone gtag('config') commands associated with it. The fourth is pasting the gtag.js snippet immediately after the opening head tag on every page.

Removing the Tag Manager snippet entirely is not the only path. "If you're using Google Tag Manager to manage other third-party tags or custom configurations, you should keep your main Google Tag Manager snippet on your site, and replace the existing G-, AW-, or DC- IDs with your GTM-XXXXXX ID, on the gtm.js snippet," according to Google. In that case the Google tag is deployed inside the container and configured in the Tag Manager interface rather than in page code.

Two verification routes are documented. Through Tag Assistant, the "Google tags found" header confirms whether the correct ID appears with a green or blue status icon. Through Chrome Developer Tools, the Network tab shows whether requests go to googletagmanager.com/gtag/js instead of /gtm.js, with Google Ads traffic visible as requests to googleadservices.com and Google Analytics traffic as requests to analytics.google.com.

Where the documents leave gaps

The release note and the help page do not quite line up on timing. The help page, which displayed a "last updated 2 mo. ago" marker in the copy reviewed for this article, describes the change in the future tense: gtm.js snippets "will soon be updated." The October 8 release note describes the behavior as current. Neither document states whether the change rolled out to all containers on October 8 or is being phased in, and neither gives a figure for how many containers carried the unsupported pattern.

Google's custom event trigger documentation also contains a small inconsistency in its worked example. The code sample pushes an event named 'button1click', while the trigger configuration that follows is set to match 'button1-click', the version used in the rest of the page. Under exact matching, the two would not match. The discrepancy predates the October 8 change and does not affect it, but it is a reminder that event-name matching in Tag Manager is literal unless regex is switched on, and as broad as possible when the regex is .*.

How this fits Google's tagging consolidation

The October 8 change is the latest in a sequence of moves that narrow the ways Google's tagging code can be installed. On July 9, 2026, Google changed how Tag Manager handles containers loaded through unsupported paths such as /gtag/js and /gtag/destination. From that point, the ID used to load a container - rather than the URL path - determined whether third-party and custom tags could run. That is the change Ahava referred to as making GTM work "even when loaded through the Google Tag CDN." Containers loaded with a GTM- ID run without restriction; G- and AW- IDs remain limited to Google-provided tags and variables.

October's update addresses the mirror image of that problem. July dealt with a GTM container loaded through the gtag path. October deals with gtag configuration commands placed alongside a GTM loader. In both cases, the effect is that one predictable rule now governs what the code does, whatever the installation.

The larger architectural shift was set out earlier. On May 20, 2026, Google published plans in the Tag Manager Help Center under which Google Tag Manager and the Google tag would merge, with all Google tags upgraded to full Tag Manager containers. PPC Land's coverage of that announcement quoted Google stating that "all new deployment snippets will be the same. Additionally, they will not have the gtag config command." Google at the time pointed to an initialization trigger that could be configured to wait for the config command as a migration path for legacy setups.

Read against that plan, the October 8 standardization looks like groundwork. If future snippets carry no config command at all, a container that pauses for one becomes an anomaly. Removing that pause, and making the config command a visible dataLayer event instead, brings the existing gtm.js behavior closer to where Google has said the platform is heading.

The same period brought a run of changes to how Google's scripts are served. Google moved its Google tag gateway for advertisers to general availability on May 8, 2025, letting advertisers serve tags from their own domains. Integrations followed, including general availability on Google Cloud on June 1, 2026, and a May 2026 documentation update that lets advertisers hide GTM container IDs behind randomized serving paths. Each alternative serving route adds to the number of ways a page can end up loading Google code, which may explain why Google keeps tightening the rules about which ID and which snippet produce which behavior.

Why this matters for advertisers and analysts

For most sites the October 8 change will pass without visible effect. A site running only the standard gtag.js snippet, or only a GTM container with the Google tag configured inside it, already follows the pattern Google documents as correct.

The exposure is concentrated in two groups. The first is sites built on the unsupported hybrid: a gtm.js loader with a product ID such as G- or AW-, plus a loose config line. Those sites were the subject of Google's email notifications, and their tag behavior is the part Google warns "may experience unexpected changes." For an advertiser, that can mean Google Ads conversion tags or Analytics configuration that no longer pick up the parameters the config line was passing.

The second group is larger and less obvious: any container that uses .* on a custom event trigger. That pattern is common in debugging setups, in tags that mirror every dataLayer push to an external analytics tool, and in older containers where a broad trigger was used as a shortcut. Such containers are not affected by the initialization change at all. They are affected by the new event. On a page that runs a supported gtag.js snippet next to a GTM container - a configuration Google explicitly endorses - every wildcard-triggered tag now fires once more.

Tag Manager's complexity has grown well beyond what many marketing teams assume. PPC Land's mapping of the platform in 2026 documented the range of triggers, consent sequencing and data layer dependencies that sit inside a typical container, and recorded one case where a consent misconfiguration cut a client's Google Ads conversions by 90% overnight. A single extra event is a smaller change than that, but it lands in the part of the system - automated, high-volume event matching - where small changes compound across every page view.

Google has also given site owners tooling for spotting installation problems. Tag Manager's Tag Diagnostics expanded in October 2024 to flag tags that stop sending data for 48 hours and tags placed too low on a page. Whether those diagnostics will surface the hybrid gtm.js-plus-config pattern, or wildcard triggers catching the new gtag.config event, is not addressed in either of the October 8 documents.

What remains open is the pace. Google has described the change in the release notes as made and in the help center as coming "soon," has notified an undisclosed number of container owners, and has signaled through its May plans that the config command will eventually vanish from new snippets. The October 8 entry is unlikely to be the last adjustment to how gtag and gtm.js interact.

Timeline

Summary

Who: Google, which operates Google Tag Manager and the Google tag (gtag.js); website owners, advertisers and analysts running Tag Manager containers, particularly those pairing a gtm.js snippet with standalone gtag('config') commands or using .* wildcard custom event triggers. Simo Ahava, co-founder at Simmer, highlighted the new event's effect on wildcard triggers.

What: Google standardized gtm.js container snippets so they initialize on container load regardless of any gtag('config') commands, and made config commands surface in the dataLayer as visible gtag.config events. Sites relying on a GTM snippet plus a loose config line, which Google classifies as unsupported, need the gtag.js snippet to keep their configuration working. Tags on .* custom event triggers may fire an additional time.

When: The change appears in the Google Tag Manager release notes dated October 8, 2026. Google's help center had warned in the preceding months that the change was coming "soon," and Google emailed owners of affected containers in advance.

Where: Across all websites using Google Tag Manager web containers and the Google tag, documented in the Google Tag Manager Help Center release notes and the help page "Set up your Google tag installation correctly for gtag.js."

Why: According to Google, the change provides "consistency, reliability, and high performance across all websites that use the Google tag." It follows the July 2026 change to unsupported installation paths and fits Google's May 2026 plan to merge Tag Manager and the Google tag, under which new snippets will not carry a gtag config command.