Serve the Google tag from your own domain

The Google tag gateway loads the Google tag from your own domain instead of from Google, so ad blockers and browser restrictions that target Google’s domain interfere less with loading it.

Last updated ·

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 GTM Kit fetches it from Google on the visitor’s behalf. 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 it does not do

The measurement the tag sends afterwards still goes to Google. Google routes that through your own domain only for sites behind a content delivery network or load balancer it integrates with, such as Cloudflare, Akamai, Fastly, Amazon CloudFront or Google Cloud Load Balancing, set up from the Google tag’s Admin tab in Tag Manager. Google decides that per site. A WordPress plugin cannot switch it on, and this setting does not try to.

That matters for what to expect. Loading the tag from your own domain helps against blocklists and restrictions that target www.googletagmanager.com. It does not change how the analytics cookie is set, so browser limits on cookies set by script, such as Safari’s seven-day cap, still apply. If that is the problem you are solving, the fix is Google’s tag gateway through your CDN or host, or a server-side tagging container, not this setting.

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 also checks that your container itself can be fetched through the gateway, so a container that has not been published is refused here too, and the message says so.

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 the two checks under Tools → Site Health show which one is failing. If both checks are passing and you are still seeing the notice, check whether an sGTM Container Domain has been set since you switched the gateway on. The two cannot both be active, and the domain takes precedence.

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, the Cookie Keeper and Get the loader from Stape 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. The collect requests to google-analytics.com or analytics.google.com still appear; that is the measurement, and it is expected to keep going to Google. Then open your container in Tag Manager’s Preview mode and confirm your tags still fire as they did before.

Two things that can look wrong but are not. A normal visit still makes one small request to www.googletagmanager.com, a health signal Google’s own script sends; it is not the container loading. And while Tag Assistant preview is connected, the page makes more requests there, because the debug session loads its own resources from Google.

Credits

The tag is served through Google’s own Google tag gateway proxy file, bundled under the Apache License 2.0.

Related articles

← Previous

Previous article

Next →

Next article