Google Tag Manager has a preview mode. When you use it, the container script URL on your own browser carries extra parameters: gtm_auth, gtm_preview and gtm_cookies_win. Those parameters tell Google to serve you the unpublished workspace instead of the live container.
They are meant to exist only in your browser session. When they appear in the HTML that every visitor receives, every visitor is loading your debug workspace. The public audit flags this as a hard failure, and it is one of the few checks that is never a false alarm.
What goes wrong when it ships
- Visitors load whatever is in the workspace at that moment, published or not. A half-finished tag change goes live for everyone.
- Data is sent to wherever the workspace points, which during testing is often a test property.
- The parameters are visible to anyone who views the source, and gtm_auth is enough to read your container configuration.
- If the preview session is later ended, the URL can start serving nothing at all, and tracking disappears without an error.
How it gets there
Almost always by copying the wrong snippet. The container install snippet in the GTM admin is clean. The snippet visible in the browser's network panel during a preview session is not, and it is the one that gets pasted when someone grabs "the script that is working". It also arrives via:
- A staging site that was configured from a preview session, then promoted to production by copying the template.
- An environment snippet from GTM's Environments feature pasted into the wrong environment.
- A page builder's "custom code" field filled in from a colleague's browser.
How to check in a minute
View the page source on your production site and search for gtm_preview. If it is there, you have the problem. The free audit does the same check on every run.
How to fix it
Replace the container snippet with the one from the GTM admin's install dialog. It should contain only the GTM- ID. Then publish the workspace you were previewing, or discard it, so the state of the live container is deliberate.
If you use GTM Environments on purpose to point staging at a separate environment, keep the environment parameters in staging configuration only, and audit production after every deploy.
FAQ
What do gtm_preview and gtm_auth do?
They switch the container script into preview mode for a specific workspace. gtm_auth is the credential, gtm_preview selects the environment. Both belong only in a debugging session, never in a page served to the public.
Is it dangerous to have gtm_auth in my page source?
It exposes the container configuration to anyone who reads the source and ties every visitor to an unpublished workspace. It is not a credential for your Google account, but it should still be treated as a leak and rotated by ending the preview session.
Will the free audit catch this?
Yes. The GTM debug mode check reads the container script URL in your page and fails if it carries the preview parameters.
Check any URL at tageasy.io/check, no signup needed.