GTM Tags Work in Preview but Not on the Live Site
Updated
Preview runs your unpublished workspace, while visitors get the published version, so the two are running different code. Check that the change is in the live version and the live page loads the same container ID, then rule out environment snippets, caching, hostname conditions and consent.
Preview proves the workspace can work. Confirm that the same logic is published, loaded and allowed to run for real visitors.
Google Tag Manager Preview mode loads your current workspace, including unpublished changes, into a debug session. The live site loads whichever container version is published to the environment that page uses. When a tag fires in Preview but not for real visitors, the two are running different code or under different conditions. Work through what differs: the version, the snippet on the page, the environment, caching, consent and the browser itself.
What to check
1. Confirm the change is actually published
Open the Versions list in GTM and check which version is marked as live and when it was published. Compare it with the workspace you tested in Preview. A frequent cause is a change that was previewed and approved but never submitted, or submitted from a different workspace. If the tag is missing from the live version, publish the reviewed change and retest instead of debugging further.
2. Check the container ID on the live page
View the page source or Network panel on the production URL and find the gtm.js request. Confirm the container ID matches the one you edited. Sites with a staging and production container, or a leftover snippet from an old agency container, can load a different ID from the one you are working in. If the expected ID is not requested, the problem is in the site code, not in GTM.
3. Check environments and snippet parameters
If you use GTM environments, the snippet on each site can include extra parameters that point it at a specific environment rather than Live. Compare the snippet on production with the environment snippet you expect. A production site accidentally carrying a staging environment snippet will keep serving the staging version no matter what you publish to Live.
4. Rule out page and CDN caching
A cached HTML page can keep an old snippet, an outdated data layer or old site code for some visitors. Test with a hard reload and in a fresh private window, then check response headers for cache status. If the site recently changed how it pushes data layer events, confirm every cached variant has the new code. Purge the relevant cache through the normal deployment path rather than repeatedly republishing GTM.
5. Compare hostname and page conditions
Preview often runs on a staging hostname, a URL with debug parameters or a page reached through a different route. Triggers with hostname, page path or query conditions can match there and fail in production. Review every condition on the tag’s triggers and the variables they depend on. Test with the exact production URL the campaign sends visitors to, including the redirect chain.
6. Test the consent state real visitors have
In Preview you may already have accepted cookies, while a new visitor starts in the default consent state. Tags that require consent will wait or not fire until the visitor makes a choice, which is correct behaviour. Repeat the test in a fresh window and record the banner choice. Treat a tag that respects a refusal as working, and review the consent configuration with its owner rather than bypassing it.
7. Check data layer timing on the live site
Preview can mask timing problems because the debug session changes when you interact with the page. If a trigger depends on a data layer event or value, confirm in production that it is pushed before or at the moment the tag needs it. Variables that read page elements may return empty if the element renders later. Ask the site to push a clear event with the needed values once they exist.
8. Account for blockers and browser privacy
Ad blockers, privacy extensions and some browser protections block gtm.js or specific vendor requests. Your own browser may differ from a typical visitor’s. Test in at least one clean browser profile with no extensions. Blocked requests from some real visitors are expected and cannot be fixed with a GTM change, so do not judge implementation health from a single blocked session.
9. Confirm the vendor received the hit
A tag firing in GTM is not the same as the destination accepting the data. Check the outgoing request in the Network panel and the vendor’s own diagnostics, such as GA4 DebugView or Meta event diagnostics. Look for wrong measurement IDs, rejected parameters or requests that never complete. Fix the configuration at the point where the evidence stops.
10. Retest production and save the evidence
After the fix, run a clean production test without Preview: fresh window, real campaign URL, default consent state and then the permitted state. Save the live version number, container ID, consent state, request evidence and date. Re-run the check after every publish that touches the same tags, since a later version can quietly undo the fix.
Before you call it fixed
- Change present in the live container version
- Expected container ID loads on production
- Environment parameters match production
- Page and CDN caching ruled out
- Trigger hostname and path conditions match production
- Default and permitted consent states tested
- Data layer timing verified on the live page
- Clean browser profile tested
- Vendor diagnostics confirm the hit
- Live version and evidence recorded
Check the production URL
A correct configuration on paper can still fail after redirects, deployment or consent logic. Use the exact URL your campaign will send traffic to.
Check a campaign URLVerify the signal directly
Related troubleshooting guides
Scan the full campaign route.
See where the click lands, what survives the redirect chain and which supported tracking signals are visible on the final page.