Google announced a set of updates to Google tag and Google Tag Manager on 20 August 2026, and the interface changes everyone noticed first are the smaller part of it. The Overview page is condensed into one table with workspace changes, a data flow map and container diagnostics, and there is a new Settings tab for container-wide configuration. Triggers, Variables, Templates and Folders now sit behind a collapsible Advanced tab, which is a strange definition of advanced for anyone who has built a tag in the last decade, though the choice persists once you expand it.
The real change is that Google tags are being upgraded into full Tag Manager containers, so sites that only ever had a gtag snippet get the GTM interface, preview mode, and version control. New deployment snippets will be identical across products and will not include the gtag config command, so initialization moves to the gtm init trigger, and you can configure that trigger to wait for config if you need the old behavior. Optimizing an existing container lets it send data straight to Google destinations instead of loading gtag.js on top, which removes a layer of JavaScript that was costing you latency for no benefit.
My recommendation is to keep everything in a real GTM container that you created yourself, and if you are still running a Google tag-only setup, use this as the moment to switch rather than waiting for the upgrade to arrive. A container you built has a workspace history you understand, permissions you set, and a naming convention that matches the rest of your stack, while an auto-upgraded one inherits whatever the gtag snippet happened to be doing on the page. The features are converging anyway, so you lose nothing by moving first, and you keep control of how the container is structured.
One detail worth reading twice during optimization: the flow creates account links between your container and your Google destination accounts automatically, with Read access granted by default. Check who that exposes before you publish.
Visual tagging is the part I would be careful with, since it is in beta for Google Ads purchase conversions and works by letting you click elements on your receipt page while it writes the CSS selectors for you. Simo Ahava made the same point in his review, and I agree with him. A dynamic receipt page or a theme update will quietly break that conversion, and purchase data is the last place you want page scraping. Ask the developers for a dataLayer push instead, which is the boring version of this work we do for clients at SmartMetrics and the reason those conversions survive redesigns.
