Tag Manager is in place

GTM lets you change tags without a developer. It also creates its own failure mode: installed but unused, or firing twice.

Why this matters

GTM lets you change tags without a developer. It also creates its own failure mode: installed but unused, or firing twice.

How this tool detects it

The tool looks for a container ID (GTM- prefix) and the URL that loads it. A container ID being present counts as deployed.

It then checks whether dataLayer is initialised, recognising four common forms: window.dataLayer=window.dataLayer||[], window['dataLayer']=…, the GTM inline snippet, and a gtag('js') call.

Both need to be present for the setup to be healthy. A container without dataLayer is a common and quiet half-finished state: the container loads, but triggers read no variables, so tags fire in ways you did not design.

Where this check can mislead you

Static analysis has limits. These are the cases where this particular check will report a result that does not match reality — worth knowing before you act on it.

A container existing does not mean it is working. The tool confirms a GTM ID is present but cannot confirm that the tags inside are configured correctly or firing at all. An empty container and a well-configured one look identical in source.
Differences between the workspace and the published version are not detected. If someone changed the GTM workspace without publishing, production still runs the old version. The tool reads the live version, which is usually what you want, but the gap exists.
Trigger execution order is not checked. The firing order of tag A and tag B affects data correctness in some cases, and that is runtime behaviour.

Examples

CorrectCorrect: GTM and dataLayer both present

<script>window.dataLayer=window.dataLayer||[];</script>
<script async src="https://www.googletagmanager.com/gtm.js?id=GTM-ABC123"></script>

dataLayer must be declared before the GTM container script.

WrongWrong: GTM is present but dataLayer is not

<script async src="https://www.googletagmanager.com/gtm.js?id=GTM-ABC123"></script>

Triggers cannot read variables such as form fields, so they can only fire on default events like a pageview.

How to fix it

Put window.dataLayer=window.dataLayer||[]; at the top of <body> or inside <head>, before the GTM container.
If there is no <noscript> version, add it — without it, users with JavaScript disabled are counted for nothing at all.
In GTM Preview, confirm your triggers fire when you expect them to.
While you are in there, check how many tags the container actually holds. An empty container usually means the migration never got configured — GTM was installed and nothing else.

Verify it worked

After making changes, confirm delivery rather than assuming. These steps require your Google login, which is exactly why this tool stops short of them.

Open Preview mode in the GTM interface, connect the site, then trigger page interactions one at a time and observe which tags fire.
Check each tag and its triggers in the GTM Tags list, and delete any tag not referenced by a trigger.
Confirm the container is published rather than only present in the workspace — workspace changes do not affect production.
Use this tool to check the bottom of the page for both hard-coded gtag and GTM. Having both is usually migration leftover.

Related checks

One thing static analysis cannot tell you: this page reads published code, so it shows what is installed, never what actually fires. To confirm delivery, use GTM Preview and GA4 DebugView — both require your Google login.

Check whether your site has this problem — no login required.