Normally your visitors’ browsers fetch the Google tag from www.googletagmanager.com. Ad blockers and browser tracking restrictions treat requests to that domain differently from requests to your own, so some of them never arrive, and the measurement they carried is lost.
The Google tag gateway changes where the tag comes from. With it switched on, the browser fetches the tag from your own domain, and the measurement the tag sends afterwards travels through your domain as well before GTM Kit passes it on to Google. Nothing about your container changes: the same tags fire, with the same data.
It is off by default. You will find it under GTM Kit → Setup → Google tag gateway.
What you need
Two things have to be true, and both are properties of your hosting rather than of your settings. Your server has to be able to open outgoing connections to Google, which some hosts block for security reasons. And the address GTM Kit serves the tag from has to be reachable: GTM Kit serves it from a small file inside its own plugin folder, and some hardened hosts refuse to run files like that directly.
GTM Kit checks both before letting you switch the gateway on, and then once a day. You will find each check under Tools → Site Health, in the Status list.
If your host blocks either one, the gateway is not available to you. That is a hosting limitation rather than something a setting can work around, so the check tells you which of the two failed and what to ask your host for.
If something stops working later
Hosting changes. If either check starts failing after you switched the gateway on, GTM Kit does not stop tracking. It goes back to loading your container the standard way and shows you a notice saying so, and Site Health tells you which check is failing.
This matters because the failure is otherwise invisible: your pages would look the same, your setting would still read as on, and your measurement would quietly stop. The fallback keeps your tracking running while you sort the hosting out. Once the gateway works again, GTM Kit goes back to using it on its own.
Page caching
The address GTM Kit serves the tag from must not be served from your page cache. It is not a page: it carries each visitor’s own measurement, so a cached copy would hand one visitor’s response to another and break your data. The path is /wp-content/plugins/gtm-kit/gtg/measurement.php.
In practice this is usually a check rather than a change, because caching plugins generally leave PHP files inside plugin folders alone. WP Rocket, for example, does not cache it. If you do need to exclude it, these are the settings to look for:
- WP Rocket — Settings → Advanced Rules → Never Cache URL(s)
- LiteSpeed Cache — Cache → Excludes → Do Not Cache URIs
- W3 Total Cache — Performance → Page Cache → Advanced → Never cache the following pages
- WP Super Cache — Settings → Advanced → Accepted Filenames & Rejected URIs
- A CDN or a host-level cache — exclude the same path in your caching rules
If your tracking works but only for the first visitor after a cache purge, this is the first thing to look at. Your firewall or security plugin may need to allow the same path as well.
An alternative to an sGTM container domain
If you already use your own server-side tagging container on a custom domain, you are serving the tag from a domain you control, and the gateway has nothing to add. The two are alternatives rather than additions, so GTM Kit lets you use one or the other. Set an sGTM Container Domain and the gateway option is unavailable; switch the gateway on and the sGTM domain, the sGTM container identifier and the Cookie Keeper are unavailable.
Switch off the one you are not using if you want to change over.
Visitors without JavaScript
The fallback for visitors with JavaScript turned off still loads from www.googletagmanager.com. The gateway does not cover it, and a visitor with JavaScript turned off has neither of the problems the gateway solves, so leaving the fallback where it works costs you nothing.
Google Tag Manager environments
If you use a Tag Manager environment, your environment settings still reach your container through the gateway, and Tag Assistant preview works as it did before. Nothing extra is needed.
Checking that it works
Open your site with the developer tools Network tab showing, and reload the page. Look for the request that loads your container: with the gateway on it comes from your own domain, and there is no request to www.googletagmanager.com for it. Then open your container in Tag Manager’s Preview mode and confirm your tags still fire as they did before.
One thing that can look wrong but is not: while Tag Assistant preview is connected, the page does make some requests to www.googletagmanager.com, because the debug session loads its own resources from there. A normal visit, without preview connected, does not.
Credits
The measurement requests are forwarded by Google’s own Google tag gateway proxy file, bundled under the Apache License 2.0.