Troubleshooting · part of GTM not workingHow to check if Google Tag Manager is actually working
Preview mode is the answer everyone gives, and it answers a different question from the one you are asking.
Preview tells you what the container you are editing does, in your browser, with your consent choices and your extensions. The question that matters is what the published container does for everyone else, and that is a question you can answer from outside, on any site, including ones you have no access to. Here are five checks in order, each with what it proves and, more usefully, what it does not.
Why Preview mode cannot answer this
It only ever describes your session
Preview runs in your browser, with your consent choices already made, your ad blocker, your extensions and your IP address. A tag that fires perfectly for you can be blocked for a third of your real audience, and Preview will never show you that.
It shows the workspace you are editing, not what is published
This is the single most common cause of a container that looks fine and does nothing. Preview deliberately includes your unpublished changes, which is what makes it useful while building and misleading while diagnosing.
You cannot use it on a site you do not control
Which is most audits. If you are looking at a prospect's site, an acquired brand, or a client whose previous agency still holds the GTM account, Preview is not available to you at all.
None of that makes Preview bad. It is the right tool while you are building. It is the wrong tool for establishing whether a live site is tracking correctly, which is what the checks below are for.
The five checks
- 1
Is the snippet on the page at all
How: View source on the live page, not the rendered DOM, and search for googletagmanager.com/gtm.js. Note the GTM- ID you find, then check a second page type as well: a product page, a checkout step, a thank-you page. Snippets go missing on exactly the templates that matter.
What it proves: The markup is present on the pages you checked.
What it does not: That it loaded, that it is the container you think it is, or that it is on the other 400 templates. Also check for the noscript iframe, and for the same ID appearing twice, which loads the container twice.
- 2
Did the container actually load
How: Open the console on the live page and type google_tag_manager, then look at its keys. A loaded container appears there by ID.
What it proves: The container executed in this browser.
What it does not: People often check dataLayer instead, which proves less than it appears to. Any script can create a dataLayer array, and the GTM snippet itself creates one before the container loads, so dataLayer existing tells you almost nothing. The google_tag_manager object is the one that only exists once the container has run.
- 3
Does the container contain anything
How: Request the container directly: googletagmanager.com/gtm.js?id=GTM-XXXXXXX, and search the response for "tags":[]. An empty array means the container has no tags in its published version.
What it proves: Whether there is anything inside to fire. This is the check almost nobody does, and it is the one that catches a whole class of problem in seconds.
What it does not: Be careful what you conclude from the network tab alone. A request for a container ID that does not exist returns HTTP 200, not a 404, along with roughly 244KB of GTM runtime wrapped around an empty configuration. More awkwardly, a container that does exist but has nothing published in it returns the same thing, so from outside you cannot tell "no such container" apart from "container with no tags". Either way the answer is the same: open the payload and look.
- 4
Is anything actually being sent
How: In the network tab, filter to collect and reload. GA4 sends to a /g/collect endpoint, Google Ads conversions to their own. Then confirm independently in GA4 Realtime, which is the only view that proves the hit arrived rather than merely left.
What it proves: Tags are firing and data is reaching Google.
What it does not: That the right data is arriving. A purchase event that fires twice, or carries no revenue, looks identical here to one that is correct. That is a separate question, and the one an audit answers.
- 5
What happens for someone who declines consent
How: Open a private window, decline the cookie banner, then repeat check four. Compare what fires against the accepted session.
What it proves: What the majority of your real traffic experiences, as opposed to what you experience after clicking accept months ago.
What it does not: Nothing further, but this is the check that most often changes the answer. Setups that pass every other test on this page routinely fail here, in both directions: tags firing that should be gated, and tags gated that did not need to be.
The 200 that means nothing
It is worth isolating the trap in check three, because it quietly invalidates the most common verification anyone does. On 19 October 2026 we requested three container IDs that do not exist, including GTM-ZZZ9999. Every one returned HTTP 200 and about 244KB of script, each containing "tags":[]. That 244KB is the GTM runtime, which Google serves whether or not there is anything to run. A real populated container requested the same way came back at 854KB with its tags in the payload, so the size does differ, but nothing in the network tab labels which you are looking at.
The more awkward part: a container that genuinely exists but has never been published, or has had everything removed from it, returns the same roughly 244KB empty response as one that does not exist at all. From outside you cannot tell those two apart. So a green gtm.js request tells you only that Google answered. Open the payload, look for an empty tags array, and if you find one, the next question is whether the container was ever published.
If every check passes and it still does nothing
The usual answer is that the work exists but was never published, which no external check can see, because an unpublished workspace is invisible to everyone but the person editing it. That cause and six others, including consent configurations that block every tag rather than the intended ones, and Content Security Policies that stop the container loading at all, are covered in Google Tag Manager not working.
Checks one and two take a few seconds with the free checker, no sign-in needed, and GTM Inspector reads what is actually inside any public container, which is check three. The full audit covers what none of them can: whether the data arriving is correct.
Check a site free →FAQs
How do I check if Google Tag Manager is working on my site?
Work from outside the container rather than from Preview mode. Confirm the snippet is in the page source, confirm the container loaded by checking the google_tag_manager object in the console, confirm the container actually contains tags by requesting gtm.js directly and looking for an empty tags array, then watch the network tab for outbound collect requests and verify in GA4 Realtime. Finally, repeat the last step in a private window having declined consent.
Why does gtm.js return 200 for a container that does not exist?
Google serves the GTM runtime regardless, with an empty configuration inside it. We checked three container IDs that do not exist on 19 October 2026: each returned HTTP 200 and about 244KB of script containing "tags":[], while a real populated container came back at 854KB with its tags present. A container that exists but has nothing published returns the same empty response as one that does not exist, so a successful gtm.js request proves only that Google answered.
Is checking dataLayer enough to confirm GTM is running?
No. The GTM snippet creates the dataLayer array before the container loads, and any other script on the page can create one too, so its presence proves very little. Check the google_tag_manager object instead, which only exists once the container has actually executed.
Why not just use Preview mode?
Preview answers a different question. It tells you what the container you are editing does in your browser, with your consent state and your extensions. It cannot tell you what the published container does for a visitor who declined the banner or runs an ad blocker, and it is unavailable entirely on a site you do not control.
Can I check a GTM container on a site I do not have access to?
Yes, for the parts that are public. The page source shows the container ID and the gtm.js payload shows what the published container contains, because both are served to every visitor. What you cannot see from outside is the workspace, the change history, or anything that has not been published.