GTM Changes How gtag('config') Works: Check Your Wildcard Triggers

Google quietly changed when your container starts working, and the side effect can set off tags you never meant to fire. The change landed in the Tag Manager release notes on 8 October 2026 under the title "Standardizing gtag('config') command behavior for Google Tag Manager." It is three sentences long, which is exactly why most teams will not read it.

The first half of the note is housekeeping. The second half is an operational risk that sits inside your container right now, waiting for the release to reach your site.

What Google changed

Google says it is standardising the behaviour of tagging snippets "to ensure consistency, reliability, and high performance across all websites that use the Google tag." In plain terms, every Google Tag Manager snippet, the gtm.js one, will now initialise on container load. It no longer waits for a gtag('config') command before it starts working.

For a site that installed Tag Manager the normal way, this is close to invisible. Your container already started on load. Google is removing a dependency that only a subset of sites ever created.

The second sentence is the one to read twice. Because the container no longer waits for a config command, Google has to decide what to do with config commands that are still on the page. Its answer is to make them visible: config commands will now surface in the dataLayer as gtag.config events.

Why a dataLayer event matters

A gtag.config entry is a real push into the dataLayer with an event name attached. Tag Manager fires triggers when dataLayer events arrive. Standard triggers watch for gtm.js, gtm.dom, gtm.load and page views, so they ignore it. Custom event triggers are a different matter.

The release note does not hide the consequence. "If your Google Tag Manager containers use wildcard custom event triggers, this change may cause those tags to fire."

Read that against Google's own documentation for the custom event trigger, which has warned about the wildcard for years. When you enable regex matching, be careful with the .* pattern, because it "means that your trigger will execute on all detected events, including events that Google Tag Manager and Google tag emit automatically." Google recommends a narrower regex. The advice was easy to ignore while the automatic event stream was short. As of this release, gtag.config is part of that stream.

What a misfire actually costs

The damage depends entirely on what the wildcard trigger is attached to, and that is why a flat container-wide answer is wrong. Look at the tags, not the trigger.

• A GA4 event tag fires an extra hit every time a gtag.config event reaches the dataLayer. Your event counts and conversions inflate.
• A Google Ads conversion tag sends a conversion ping with no user behind it. Bid signals read data that never happened.
• A remarketing tag builds an audience from an event the visitor did not generate.
• A third-party pixel, Meta or TikTok or anything else, receives a call it was not designed to receive.

None of these break a page. No error appears in the console, no tag turns red in Preview, and no report tells you a number moved. The events simply accumulate, and the gap between your dashboard and your bank account widens one gtag.config at a time.

The unsupported setup Google is closing off

Behind the release note sits a Help Centre page, "Set up your Google tag installation correctly for gtag.js," and its opening warning is blunter than anything in the release notes. Google Tag Manager snippets "will soon be updated to no longer recognize or wait for any gtag('config') commands."

The page names the implementation Google treats as invalid. Some sites deploy a non-GTM tag ID, one that starts with G-, AW- or DC-, through a gtm.js snippet path, and then call gtag('config') in a separate script block underneath. Google calls that unsupported and says sites using it "may experience unexpected changes to tag behavior."

Google has emailed the administrators of the containers it considers significantly affected. If you look after Tag Manager for clients, asking which of them received that mail is the fastest way to find the sites that need work.

The correct shape depends on what you were trying to do. If you want gtag config commands to deploy Google Ads or Analytics, the standard gtag.js snippet is the supported path: load https://www.googletagmanager.com/gtag/js?id=YOUR_TAG_ID, then declare the dataLayer, define gtag, and call gtag('js', new Date()) followed by gtag('config', 'YOUR_TAG_ID').

If you use Tag Manager for other tags and custom setups, keep the main GTM snippet and put your Google tag inside it. Google's instruction is to replace the G-, AW- or DC- ID on the gtm.js snippet with your GTM-XXXXXX ID, deploy the Google tag from the Tag Manager interface, and apply the configuration there.

How to find the triggers at risk

Open each container and walk the Triggers list. You are looking for custom event triggers whose matching condition is wider than the events you actually send. Three patterns account for most of the exposure.

The first is an event name set to .* with regex matching switched on. It was probably a shortcut for "catch everything," and it now catches gtag.config as well.

The second is a regex that reads specific but is not, such as .*click or a bare _event. Anything short of an exact list is worth testing, not assuming.

The third is a trigger whose event name is narrow but whose "This trigger fires on" setting is left at All Custom Events, with the narrowing moved into a tag-level exception instead. Broad triggers with narrow exceptions behave fine until the event stream changes, which is precisely what happened.

Before you change anything, note what each trigger is attached to. A wildcard trigger on a tag that only reports to a testing tool is harmless. The same trigger on a conversion tag is the whole problem. The trigger is not the issue; the pairing is.

The fix is a tighter condition, not a deleted trigger

You have three options and they are not equal.

The clean fix is to narrow the regex to the events you actually push. If your site sends form_submit, quote_request and video_play, list those and drop the wildcard entirely. This is more work up front and it stops the class of problem for good.

The quick fix is to keep the broad pattern and add an exclusion so the trigger skips gtag.config. In the trigger's condition, exclude when the Event variable equals gtag.config. It takes a minute and it holds as long as nobody adds another automatic event, which is not a guarantee Google owes you.

The option to avoid is leaving it alone because the tag is only a test tag today. Tags get repurposed, and a container is not a document most teams reread before the next campaign.

One caution. Do not solve this by deleting the trigger. Traffic that depended on it stops firing and you will not notice until a client asks where their conversions went. Tighten the condition, publish a version, and leave a note in the version description so the next person understands why.

Test in Preview before you publish

Tag Manager's Preview mode is the tool for this, and it is the only place you will see the event before it reaches production. Load your site in a preview session, watch the event stream, and look for a gtag.config entry. Then check which tags fired on it. If your conversion tag or a pixel appears in that list, you have found the problem on a page that is not yet costing anyone money.

Google's guidance for verifying the installation points at Tag Assistant: add the domain, enter the URL, connect, and confirm the Google tag is detected and sending. That check tells you the tag loads. Preview tells you what else it drags along. Run both, because they answer different questions.

The consent angle

For UK properties this is a compliance question as much as a data-quality one. The ICO's guidance on storage and access technologies, finalised in April 2026, allows analytics used to improve your own service to sit inside the statistical purposes exception, provided you give clear information and a simple means of objecting free of charge. Advertising measurement does not need a consent of its own; it rides on the advertising consent the visitor already gave. What the guidance does insist on is that nothing beyond the strictly necessary runs before consent is captured.

A wildcard trigger firing an advertising tag on gtag.config cuts against that. The tag is firing on an event the visitor never generated. If consent mode is still in its default denied state the tag may be blocked, and you are leaning on that block rather than on a decision you made. If the visitor granted consent on an earlier visit, the tag fires and nobody sees it happen. Either way the trigger is doing something your consent design did not plan.

That is worth a look before your next audit, and it is worth writing down when you find it. The ICO cares less about a perfect setup than about being able to show you checked.

What to do this week

1. List every container you manage and the Google tag ID each one loads. Any G-, AW- or DC- ID sitting on a gtm.js snippet is the unsupported shape, and it is first in line.
2. Inside each container, open the Triggers list and filter your attention to custom event triggers with regex matching on.
3. For each one, read the condition literally as a machine would, not as you remember writing it. A dot and a star match more than they look like they match.
4. Note the tag each broad trigger drives. Conversion and pixel tags move to the top of the queue.
5. Run a preview session and confirm which tags fire on a gtag.config event. Evidence beats a guess.
6. Tighten the conditions, publish a version with a description that explains the change, and re-test in Preview.
7. Where a container still loads a non-GTM ID through a gtm.js snippet, plan the move to the supported shape rather than waiting for the behaviour to change underneath you.

This release is the latest in a run that has changed how Tag Manager handles containers without asking anyone to edit them. The July release that made the container ID, rather than the loading path, decide which tags are permitted was the same kind of change. The pattern is consistent: Google tightens the rules on the loading snippet, and containers that were never quite standard feel it first.

Check the triggers this week. A wildcard that was harmless in September is not harmless now.