How to Audit and Clean Up a Bloated GTM Container
A bloated GTM container slows your site and corrupts your data. An audit has three phases: inventory what’s actually firing, categorise what stays vs. what goes, then clean and validate. Most containers shrink by 60-80% after a proper audit without losing a single tracking event that matters.
Here’s the full process.
What “bloated” actually means
GTM has no built-in size warning. Containers can grow for years before anyone notices something is wrong.
The warning signs:
- Your container JSON export file is over 200kb (a clean container sits under 50kb)
- Tags regularly fire in the wrong order, or at the wrong time
- You have events in GA4 that nobody on your team deliberately created
- Developers complain about site speed, and tag manager comes up
- You’ve inherited the container from someone who left the company
The real problem isn’t just file size. It’s what all those extra tags are doing to your data. Dead tags that still fire. Duplicate scripts loading the same tool twice. All-page triggers that were meant to be temporary. Every one of these is actively writing incorrect data into your analytics properties right now.
Before you start: what you need
Before touching anything, get these in front of you:
- Publishing access to the container — read-only access won’t let you make changes; viewer access won’t let you test
- The current production GA4 property — you’ll be validating against it
- A list of every tool that’s supposed to be running on the site — Google Ads, GA4, a/b testing, heatmaps, chat widgets, whatever is intentional. If you don’t know what’s supposed to be there, you can’t identify what shouldn’t be.
- A browser with GTM Preview Mode and browser devtools — you’ll need both; they catch different things
- The site’s consent configuration — if you’re cleaning up in a consent-mode environment, you need to know which tags are gated by consent and which aren’t
If you’re auditing a container you’ve inherited and you don’t have a list of what’s supposed to be running, ask the client or the previous implementer before you start. Deleting something that turns out to be tracking a business-critical conversion is a very avoidable mistake.
Phase 1: The inventory
Open the container. Go to Tags > All Tags. Sort by Last Edited (oldest first).
You’re doing three things:
1. Check firing status. Tags that haven’t fired in 30+ days in Preview Mode are candidates for removal, not automatic removals. Some tags only fire on specific user flows (checkout confirmations, error states, form submissions) that you might not hit in a preview session.
2. Check trigger assignment. Tags with no triggers assigned fire nothing, but they’re still in the container definition and bloating the JSON. These are clean, safe to remove.
3. Check for duplicates. Look for multiple tags loading the same script. Common patterns: a GA4 config tag added twice under different names, both a GTM-loaded version and a hardcoded script on the site itself loading the same tool, a deprecated Universal Analytics tag that nobody deleted when they set up GA4.
At the end of Phase 1, you should have a spreadsheet with every tag, its trigger(s), its last edit date, and a column for your verdict: Keep / Investigate / Remove / Unclear.
Don’t start deleting in Phase 1. This is inventory only.
Phase 2: The audit
Dead tags
A dead tag is one that’s attached to a trigger but the trigger condition is never true in practice. This happens when a site restructures its URL scheme and nobody updates the trigger, or when a campaign ends but the tags stay.
How to identify them: fire up Preview Mode, walk through the main user flows (homepage, category, product, checkout, confirmation), and watch the Tags Fired panel. Any tag that never fires across a realistic session is a candidate. Cross-reference against your GA4 DebugView if the tag is supposed to send events.
Duplicate scripts
Pull up the Network tab in browser devtools on the live site (not Preview Mode). Filter by the tool name: Facebook, Google, TikTok, whatever. If you see the same script loading twice from two different sources, you have a duplicate.
The fix is straightforward: pick one source (GTM-loaded is usually preferable for consent management) and remove the other. But verify with the client or dev team that the non-GTM version isn’t serving another purpose before you delete anything.
All-page triggers firing where they shouldn't
Sort your tags by trigger type. Find every tag using All Pages or Page View as a trigger. For each one, ask: should this really fire on every single page?
Most tools don’t need to fire on every page. GA4 configuration tag, yes. Remarketing pixels, sometimes. Event-specific tracking tags, almost never. An all-page trigger on a conversion event tag is a common bug that silently inflates conversion counts.
Tags with undefined variables
A tag that references a variable (like {{Event}}, {{Page URL}}, or a custom dataLayer variable) that doesn’t exist or has been renamed will throw an error silently. It won’t break your site, but it won’t track anything useful either. Check the Variables panel and cross-reference which variables are actually still active.
Phase 3: The cleanup
You have your verdict column. Work through it in this order:
1. Remove tags with no triggers first. Zero risk. They were doing nothing.
2. Remove confirmed duplicates. One at a time. After each removal, publish to a staging environment and verify in Preview Mode and devtools that the intended tag still fires correctly.
3. Remove dead tags. If you’re not 100% certain a tag is dead, archive it instead: put it in a folder called “Archived [month/year]”, pause it rather than delete it, and add a note. Check again in 30 days. If no one has asked about it and nothing has broken, delete it.
4. Fix all-page triggers. For each event tag incorrectly using an all-page trigger, build the correct scoped trigger (specific URL match, dataLayer event, custom event) and replace it. Test in Preview Mode before publishing.
5. Consolidate and rename. After cleanup, rename what’s left with a consistent naming convention. GA4 – [Event Name] – [Trigger] is a common and readable format. A container where you can understand what every tag does just by reading its name is a container that won’t get bloated again in 6 months.
Validating the cleanup (and what Preview Mode doesn't catch)
GTM Preview Mode is a good first check. It’s not enough on its own.
What Preview Mode catches: whether tags fired, what triggered them, the dataLayer state at the time of firing.
What it doesn’t catch:
- Tags that fire in production but not preview because of Content Security Policy headers, adblocker rules, or cookie consent states that differ between preview sessions and real user sessions
- Server-side tag failures — Preview Mode is client-side only; if you’re running a server-side container, sGTM has its own debug panel
- Duplicate GA4 events from a simultaneous gtag snippet on the same page — Preview shows the GTM-side firing but won’t surface a parallel gtag.js script loading outside GTM
- Consent-mode specific errors — a tag that fires correctly when consent is granted but also fires when it shouldn’t when consent is denied
After Preview Mode, do a live check in GA4 DebugView on your own device. Walk through the critical paths with a clean browser profile (no extensions, fresh session). Watch for event duplication and unexpected events.
Then check your GA4 events report 48-72 hours after publishing the cleaned container. The event count for any event that was being duplicated should visibly drop. That’s your confirmation the cleanup worked.
Keeping it clean
A container that gets re-bloated within six months has a governance problem, not a technical one.
Three rules that prevent it:
1. Every new tag gets a corresponding note. The GTM tag description field exists for a reason. Who added it, when, what campaign or implementation it supports. Without this, the next auditor (or your future self) has to guess.
2. Tags tied to campaigns get an expiry date. Name them explicitly: Facebook Ads – [Campaign Name] – Remove after [date]. Anything with an expiry date gets reviewed at that date, not left to silently run forever.
3. Container changes go through version control. GTM has versions. Use them. Every workspace publish should have a name and a note about what changed. A version history you can read in plain language means rollback is safe and fast if something breaks post-publish.
A clean container audit takes 4-8 hours depending on the size and history of the container. A proactively maintained container takes 30 minutes every quarter. The math is straightforward.
FAQ
What is a bloated GTM container?
A bloated GTM container is one that has accumulated dead, duplicate, or improperly scoped tags over time. Typical signs: container JSON over 200kb, tags firing on every page that should only fire on specific events, duplicate scripts loading the same tool twice, and tags with no active triggers that are never cleaned up.
How do I know if my GTM container is too big?
Export the container JSON (Admin > Export Container) and check the file size. A healthy container is under 50kb. Over 100kb is a red flag. Over 200kb usually means significant cleanup is needed. File size alone isn’t the only metric — a small container can still have broken logic — but size is the fastest first signal.
How long does a GTM audit take?
For a container with 30-60 tags and reasonable documentation, a full audit takes 4-6 hours. Inherited containers with no documentation, 100+ tags, and years of legacy additions can take 8-12 hours. Factor in time for client questions about what various tags are supposed to be doing.
What should I delete from GTM?
Tags with no triggers attached (they fire nothing and only bloat the container definition). Confirmed dead tags that haven’t fired in 90+ days and aren’t tied to any active tool or campaign. Duplicate tags loading the same third-party script that is also loaded outside GTM. Always archive before deleting if you’re uncertain — pause the tag, add it to an “Archived” folder with the date, and remove it after 30 days with no issues.
How do I validate GTM changes without breaking live tracking?
Use GTM Preview Mode for the initial check, but also run a parallel check in GA4 DebugView on the live site (not just in preview). For server-side containers, use the sGTM debug panel separately — Preview Mode does not cover server-side tag failures. After publishing, monitor GA4 event counts for 48-72 hours. A drop in event counts for previously-duplicated events confirms the cleanup worked correctly.
Posted by Metric Vibes. We audit and fix analytics implementations for data-serious teams. Get in touch if you’re working through a GTM cleanup.
