By Marc Alexander

Google changed how Tag Manager containers start on 8 October 2026, and the change leaves a footprint: every gtag('config') call on your pages now appears in the dataLayer as an event called gtag.config. For most sites that's a free diagnostic; for a container with a catch-all trigger, it's extra tag firings since yesterday. Here's what to check.

What Google changed.

The release note says three things. All Tag Manager container snippets now initialise when the container loads, regardless of any gtag('config') commands on the page.

Those config commands now surface in the dataLayer as visible gtag.config events. And a site that wants to keep using gtag configuration code should run the Google tag snippet, gtag.js, on every page rather than relying on the Tag Manager snippet to pick it up.

It's the latest step in a series. In July, Google fixed how containers behave when loaded from unsupported paths; in August, it began turning Google tags into full Tag Manager containers. The direction is one tagging system with one set of rules, and the stray config call is one of the last irregularities being tidied away.

Why there are stray config calls.

A gtag('config', 'G-XXXXXXX') line is how the Google tag is told which GA4 property or Ads account to send to.

Sites that use Tag Manager shouldn't need one, because the GA4 tag inside the container does that job. They have them anyway: a theme that bundles Google Analytics, a plugin with its own GA4 field, a developer who followed the GA4 setup wizard, a consent tool that adds one, or a leftover from the migration from Universal Analytics.

Marc finds one on a large share of the containers he audits, and they're a common cause of double-counted page views and conversions.

Until this week they were invisible unless you read the page source. Now each one announces itself in the dataLayer, which is the useful half of the change.

What to check.

  1. Catch-all triggers. Any Custom Event trigger that matches every event, by regex such as .* or by matching on a variable, now also fires on gtag.config. Open each one and add an exception, or a condition that the event name doesn't equal gtag.config. Monitoring tags that count events, and tags that forward the whole dataLayer to a warehouse, are the usual suspects.
  2. Look for the event. Open Tag Manager's preview on a few page types. A gtag.config entry in the timeline means the page has a config call outside the container. Note which property or account ID it names.
  3. Decide whether each one should exist. If the container already sends to that property, the call is a duplicate: remove it from the theme or plugin, or stop the plugin's own tracking. If it's the only thing sending to that property, move the tag into the container, where it can respect consent and be versioned.
  4. Hybrid setups. A site that deliberately runs both the Tag Manager snippet and gtag configuration code should follow Google's advice and install the gtag.js snippet on every page, so the config commands have the tag they expect.
  5. Annotations and logs. Event counts in anything that reads the dataLayer went up on 8 October. Note it, so nobody chases a phantom traffic spike in a month's time.

What it doesn't change.

Tags with ordinary triggers, page views, clicks, form submissions and named custom events, are unaffected. GA4 data isn't changed by the event itself; it only changes if a catch-all trigger sends something extra, which is why the triggers are the first thing to look at.

Consent Mode is unaffected, though a config call outside the container was always a way to leak a hit before consent, and now you can see it.

A quick way to find them.

The free tracking checker shows which Google tags a page loads before anyone agrees to anything, including ones that arrive outside Tag Manager.

For the container itself, a first look at the triggers and the stray calls is part of the GA4 mini audit, and a container that has collected years of them is what the Tag Manager rebuild is for.