Google Tag Manager: what the 2026 update changes for your container

Until now there have been two routes for getting Google measurement onto a website: the Google tag placed straight in the source code, or a container in Google Tag Manager. Google is now merging the two. The details are set out in the help article “Updates to Google tag and Google Tag Manager”. The English version is dated 20 August 2026, the German one 20 May 2026.

The change has three parts:

• Simplified interface: the Overview page in Tag Manager has a new structure.
• Unification: Google tags become fully capable Tag Manager containers, and existing containers can be optimised.
• Visual tagging: conversions can be set up by selecting elements directly on the website.

The US English release notes show how this is arriving in stages: the redesigned Overview page on 1 July 2026 (the UK English version says 22 June), a change to how container IDs behave on 9 July, and an AI-suggested version name and description on 17 September 2026. In early October 2026 the UK English version did not yet list the last two entries.

One phrase from the help article matters most for planning: “no changes will be made automatically”. When you switch is up to you.

The first thing you notice when you open Tag Manager is the Overview page. According to Google nothing you already use has been removed, but new areas have been added, including:

• Settings: one central place for everything that applies to the whole container. The page is populated once you optimise your container or add a tag for a Google destination by hand. A Google destination is, for example, an Analytics property or a Google Ads account. The page then also shows a data flow map listing the destinations the settings apply to.
• Advanced: a collapsible tab that holds triggers, variables, templates and folders.

Triggers, variables, templates and folders now sit under “Advanced”.

Until now, Google says, Tag Manager loaded extra JavaScript, the gtag.js file, to send data to a Google destination. That could delay the transmission of measurement data. An optimised container sends the data to the Google destinations directly. According to Google, the optimisation only concerns existing Tag Manager users.

This is what happens to your container:

• Settings move: the settings of your Google tags are brought into the new “Settings” tab.
• Event tags stay: according to Google, your event tags and triggers are kept.
• Accounts are linked: the container is linked to the accounts of your Google destinations and becomes visible and manageable in the interfaces of those products. The links are created automatically during optimisation, with read access by default.

You start from a banner on the Overview page and need edit, approve or publish permission. If every Google tag in the container has the same settings, you confirm the consolidation via “Review details”. If the settings differ, “Get started” walks you through choosing which ones apply. Google describes the steps on the help page “Optimize your Google Tag Manager container”.

The changes land in your workspace first. Nothing goes live until you submit the version.

Since the release of 9 July 2026 the prefix of the ID has determined what a container may execute, even when it is loaded via an unsupported path such as /gtag/js. Google says installations using its own snippets are unaffected. Google says it has emailed the administrators of significantly affected containers. Google distinguishes two cases:

• The ID starts with GTM: all tag types are allowed, including third-party scripts and your own HTML and JavaScript tags.
• The ID starts with a product prefix such as G or AW: the container is limited to Google tags and sends data to Google services only.

A website that only carries the Google tag with a G or AW ID does, according to Google, gain the Tag Manager interface, debugging and version control. Tags from other vendors will not run in that mode, though. For those you need a container with a GTM ID. Google explains the rules under “Manage tagging behavior using the container ID”.

Installation changes as well. Google says all new deployment snippets will be the same and will no longer contain the gtag “config” command. Its recommendation is to control initialisation with the “gtm init” trigger. If you want to keep a legacy setup, that trigger can make the tag wait for the “config” command. According to Google, the upgrade does not alter how Google tags already installed on your pages behave. According to Google, each Google destination gets its own tag in the process.

The most recent addition dates from 17 September 2026. When you submit a version, an AI summarises the changes in the workspace and proposes a version name and a version description.

From a developer’s point of view this is useful, because a version without a description is hard to place later, for instance when you need the last working version after a measurement error. I would still read the suggestion and add to it before publishing. A summary tells you what was changed. Why it was changed is something only you know.

The third building block, visual tagging, runs through Tag Assistant. According to Google you need a Google Ads account with at least one conversion action, a sitewide Google tag and edit access to the container. You place a test order and then pick, on the order confirmation page, the elements to be passed with the conversion, such as transaction ID, order subtotal and currency. The system creates selectors and triggers in the background. The flow ends with publishing the changes. Google says the feature is in beta for purchase conversions in Google Ads, with further use cases to follow during the year. If the container already measures purchase conversions, the flow warns you about double counting.

1. Take stock: write down which IDs are loaded on the website, which prefix each one has and where it is installed: in the theme, in a plugin, in the consent tool or in the shop system.
2. Fix your starting point: note the currently published version. Google confirms that you can roll back to a prior version if something is wrong after publishing.
3. Start the optimisation in a workspace: open the banner on the Overview page. Where settings conflict, make a deliberate choice about which Google tag serves as the reference.
4. Review the changes: use “Preview changes” and compare the new “Settings” tab with your previous Google tags. Look for everything you had entered there before, for example a custom server URL for server-side tracking or cross-domain measurement.
5. Test in preview mode: check your key events and conversions, once with consent and once without.
6. Check access: according to Google, admins specify during the optimisation which level of access each destination gets to the container. See which account links have been created and whether read access is intended for every linked account. Google notes that permissions are not versioned, so a rollback will not reset them. They can be changed under “External Account Links” in the admin settings of the container.
7. Publish and monitor: submit the version with a meaningful description. Over the following days, compare event and conversion figures in Analytics and Google Ads with the weeks before.

Further reading: our article on custom JavaScript variables in Google Tag Manager explains how to build your own variables. A related service is our tracking switch in Google Tag Manager.

Google leaves some questions open for now:

• No figure for speed: Google lists faster website performance as a benefit but gives no measurement. Only your own before-and-after test will show whether, and by how much, your site gains.
• Staged introduction: the help page announces the optimisation as coming soon. If the banner is missing from your container, the feature has presumably not been enabled there yet. The extension of gtag.js for sites that only use the Google tag has likewise only been announced.
• Consent remains your job: the help pages reviewed for this article say nothing about changes to consent mode. Test behaviour without consent explicitly all the same. When initialisation changes, the order in which consent, settings and tags take effect deserves a fresh look.

My assessment: the changeover is not an emergency, but it is a fitting occasion to look through the container thoroughly. If a review of your web analytics is planned anyway, do both in one go. Basic terms are explained in our knowledge section.