← Back to changelog

GTM Kit 2.18: know when your tracking is broken, and keep staging out of your analytics

Free

GTM Kit now tells you when your tracking is broken

Until this release, the GTM Kit settings screen could only tell you what GTM Kit intended to do. If a caching plugin stripped your container out of the page, or a second plugin loaded it a second time, or a staging copy of your site was quietly reporting into your live analytics, nothing said so. The settings looked perfectly healthy while the measurement was wrong.

2.18 closes that gap. GTM Kit now checks your own pages the way a visitor receives them, reports on itself in WordPress’s Site Health screen, and stops your staging site from polluting your data. It also makes switching from another Google Tag Manager plugin a two-minute job instead of an afternoon of copying settings by hand.

A daily check on your own pages

GTM Kit now fetches one of your pages once a day, exactly as a visitor would receive it, and reads what actually arrived.

It tells you when nothing on your site is loading your container: the case where a caching or optimisation plugin has stripped the snippet and your site has been measuring nothing at all. And it tells you when your pages load tracking twice, whether that is two different containers, the same container loaded by two scripts, or a Google tag loading alongside your container. Duplicate tracking silently doubles your events and your purchases, which is worse than no tracking, because the numbers look plausible.

Where GTM Kit recognises the plugin or tool adding the second copy, it names it.

The check is deliberately careful about crying wolf. A server-side fetch cannot see a container that a consent platform injects later in the browser, so a “nothing found” result is never escalated to a warning while a consent platform is active. That configuration is a deliberate setup, not a fault.

GTM Kit reports on itself in Site Health

Two checks now appear in WordPress’s own Tools → Site Health: whether your container is set up and being added to your pages, and whether consent is configured, either through GTM Kit’s Consent Mode defaults or through a consent platform GTM Kit recognises. A container that is deliberately loaded by something else is described as such rather than reported as a fault, and a local or development site is never told off for an unfinished setup.

A GTM Kit section on the Info tab lists your whole configuration on one screen: container and consent settings, the add-ons in use, and the shop or form plugins found on the site. One click copies it into a support request, so a first reply can be an answer instead of a list of questions.

Your container’s environment authentication token and preview ID are shown on screen but deliberately left out of the copy.

Your staging site stops polluting your analytics

GTM Kit no longer loads your container on a site that WordPress reports as staging, development or local.

This one changes behaviour on existing sites, so it is worth reading. If you keep a copy of your site that declares itself in wp-config.php, and it has been tracking until now, it will stop after this update. That traffic was being counted alongside your real visitors and quietly distorting both your analytics and your advertising audiences.

Nothing else changes. The data layer is still built on those sites, so you can still see what a live site would send. The browser console says why the container is missing. And a notice on the GTM Kit dashboard explains it and links to a new “Load the container on staging and test sites” setting, for when you are measuring a staging site on purpose.

Separately, if your site’s address reads like a test or staging copy but WordPress has not been told what kind of site it is, GTM Kit now points that out and links to the WordPress documentation on declaring it. That one is a suggestion and nothing more: it never changes what GTM Kit loads, and it can be dismissed.

Switching from another GTM plugin

You can now import settings from another Google Tag Manager plugin at any time, from a new Import settings section on the Tools page. Previously the offer appeared only during the very first setup, so anyone who switched later had to copy every setting across by hand.

Before anything is written, you see exactly which of your settings will be replaced. Only settings the other plugin actually configured are touched.

The warning shown when a second Google Tag Manager plugin is active now links straight to the import, so you can copy that plugin’s configuration across before deactivating it. The link appears only when there is something to import.

Several things about importing got better in the process:

  • Importing during the setup wizard works again. Choosing a plugin and confirming did nothing at all, leaving the wizard stuck on the import question.
  • The wizard offers the import whenever another plugin’s settings are found, not only on a brand new install, and reloading no longer makes the offer disappear.
  • Importing from Google Tag Manager for WordPress now copies considerably more: your Consent Mode defaults, login and sign-up event tracking, excluded user roles, the post title data layer variable, and your container’s environment. Sites running a Dev or QA container environment previously lost that setting and silently fell back to production.
  • A site configured with more than one container no longer produces an unusable container ID. The first is imported, and the screen tells you how many were skipped.
  • The “Include customer data” option now reflects what the other plugin was actually set to.

The <noscript> fallback

The fallback for visitors who have JavaScript turned off was never actually added to your pages. It now is, immediately after the opening <body> tag, where Google recommends placing it. This is a small hidden element with no visible effect on your site, and nothing changes for visitors who have JavaScript, which is nearly all of them.

Because the fallback has to work without JavaScript, it cannot carry a consent signal. If you would rather your pages did not have it, the “Container code noscript implementation” setting can switch it off.

Choosing to place that fallback in the footer now actually places it there. The “Footer of the page” option has never worked on any site: it waited for a signal from your theme that WordPress does not send and no theme sends either. It was doing nothing for precisely the sites that needed it, since it is the option chosen by people whose theme does not support the standard position.

That fallback is now placed at the standard WordPress footer position. If you added a body_footer hook to your own theme to make this option work, the fallback moves from there to a point a little further down the same page. Same element, same page, no difference to what is measured. It is a change to your markup though, so worth knowing if you put that hook there deliberately.

Also in this release

Block themes: adding to the cart works properly again. On a block theme, adding a product to the cart from the product page went through a full page reload instead of updating in place. It now updates in place again.

A correction to what we told you about deduplication. The GTM Kit Premium information in the settings screen said that a shared event ID lets Google Analytics 4 merge a purchase arriving from both the browser and the server. Testing established that it does not: GA4 counts both copies, even when every identifier matches. The shared event ID is what stops Meta, TikTok and similar Conversions API destinations from counting a recovered purchase twice, and the screen now says so, along with the advice to send the purchase to Google Analytics 4 from one side only.

Preview controls. The setting that makes your live orders appear in your server container’s Preview panel is now shown with the rest of the Preview controls, next to the note explaining that it changes what your live site sends and that it switches itself off when the Preview token expires. Sending a test on its own has never made real orders appear in Preview, and the setting that does was easy to miss.

Dashboard notifications no longer lose part of their text or their links. Any link in a notification now appears as a button beside it, and messages offering two choices show both.

Requirements

GTM Kit now requires WordPress 6.9 or later. Sites running an older version keep the copy of GTM Kit they already have and carry on tracking, but they stop being offered updates from the dashboard until WordPress itself is updated. WooCommerce shops are already above this floor, since WooCommerce has required WordPress 6.9 since version 11.0.

GTM Kit is now tested with WordPress 7.1. The settings screens, the setup wizard, container loading and the data layer were all verified against it.

Developer notes

  • New extension point gtmkit_site_health_tests lets add-ons register their own Site Health tests, inheriting GTM Kit’s badge, severity vocabulary and link handling rather than re-implementing them.
  • Container output on non-production environments can be forced on with the GTMKIT_LOAD_ON_NON_PRODUCTION constant in wp-config.php, or with the existing gtmkit_container_active filter, which remains the escape hatch and is applied exactly once.
  • The admin JavaScript libraries have been brought up to date, including a security fix in the component that cleans up text before it is displayed. The settings screens look and behave exactly as before.