Why does my GTM tag work in preview mode but not live?

Kilian Müller
Kilian MüllerOwner of 1hold.de · Google PartnerUpdated
Google Tag ManagerGoogle Certified Specialist

When a GTM tag works in preview but not on the live site, the live site is loading something other than what you tested: an older version because your change was never published, a published version that lacks it, an outdated copy of the container, or the right version blocked by consent. Preview runs your workspace draft in your own browser; your visitors get the published version, with their own cookie choice.

So the question is never “is the tag broken?” but “what does the visitor’s browser actually load?”. If the problem started with your cookie banner, also read why the GTM container stops working after the consent banner.

Preview vs. live siteWhich container does the browser run?Preview (Tag Assistant)• your unpublished workspace draft• only in your own browser• your own consent choice• tags fired shown in Tag AssistantLive site• the last published version• for every visitor• each visitor's consent choice• may come from a cache or copySource: Tag Manager Help, preview and environments (October 2026)

Why does a GTM tag work in preview but not live?

According to Google’s help on preview and debug, preview shows your site as if the current container draft were deployed, and only in the browser where you started it. Nothing changes for visitors until you click Submit, keep Publish and Create Version selected and click Publish. If you work with environments, note that publishing to a custom environment does not send the changes to the live version.

Which five causes do we find in client accounts?

  1. Saved, but not published. The change sits in the workspace. The Versions tab shows which version is live and when it was published.
  2. Published, but not what you planned. A new version proves that something was published, not that it contains your change. At a B2B client, version 8 showed as published, yet five of six planned tag pauses were missing because a script had stopped after the first one. Version 9 fixed it the same day, and we now compare the live version with the plan after every publish.
  3. The site serves an old copy. Some cookie and performance plugins host a local copy of gtm.js or cache it on a CDN. Then your publish never reaches the visitor.
  4. Consent. In basic consent mode Google tags stay blocked until the visitor interacts with the banner. In preview you usually accepted long ago, so you never see the blocked state.
  5. Your own browser. When we checked in October 2026, Google served gtm.js with Cache-Control: private, max-age=900, so a browser may reuse an older file for up to 15 minutes. Our own test browser once held on to version 22 after a newer version had gone live. Ad blockers can also block googletagmanager.com on the live site.

Which two traps did one shop run into?

An online shop published GTM versions 24 and 25 on 6 July 2026 to repair its contact-form conversion. The live site kept running version 23. The consent plugin loaded the container from a local copy on the shop’s own server, and the job that should refresh this copy had stopped on 1 July. On 10 July we replaced the copy with the current file, cleared the CDN cache and checked the live file: version 25. On 11 July a rebuild of the plugin settings switched the loader to googletagmanager.com, so the copy is no longer used.

The second trap came after a switch to basic consent mode in August. GTM now started only after consent, late in the page. The shop system wrote purchase and checkout events into the page head before that, and in this setup GTM did not pick them up – purchases went missing. Tests that push an event after the page has loaded do not show this. We added a small script that re-sends those early events once when the container starts, with a check on the order ID to avoid double counting. One order in early October was still counted twice, and the cause is not yet confirmed, so we keep watching it.

Treat “published” as the start of the test, not the end. After every publish, open the live site in a clean browser profile, confirm which container version it loads and run the real conversion once – as a first-time visitor who accepts cookies and as one who declines.

How do you check what your visitors actually load?

  1. In GTM, open Versions and note the version marked as published. Compare it with your workspace changes.
  2. Open the live site in a private window without extensions. In DevTools → Network, filter for gtm.js and check where the file comes from: googletagmanager.com or a path on your own domain or plugin folder.
  3. Open the response and search for "version". The number must match the published version in GTM.
  4. Test the consent states: decline, then accept in a fresh session, and watch whether your tag fires after consent.
  5. Run the real flow – form, order or call click – instead of only pushing a test event into the dataLayer.

Sources

Your tags behave differently live than in preview? We trace which container your visitors really load and fix publishing, consent and cache issues. Book a free initial call or see how we handle Google Ads and conversion tracking for our clients.

Need personal advice?

Our Google-certified experts are happy to help – free and without obligation.

Book a meeting