By following this guide you will complete a full Google Tag Manager container audit, identify broken and duplicate tags, and establish a repeatable review process. Most teams can complete the core audit in three to four hours using only GTM, a spreadsheet, and Google Analytics 4.

What You'll Build

  • A complete inventory of every tag, trigger, and variable in your GTM container
  • A prioritised list of tags to remove, fix, or consolidate
  • A firing-rule map that shows which tags fire on which pages and events
  • A documented naming convention your team can follow going forward
  • A scheduled review cadence so the container stays clean after the audit

Prerequisites

Before you start, make sure you have the following in place.

  • Publish access to the GTM container you want to audit
  • A Google Analytics 4 property linked to the container
  • Google Chrome with the Tag Assistant Companion extension installed (free from the Chrome Web Store)
  • A blank spreadsheet in Google Sheets or Notion for the audit log
  • 30 minutes of uninterrupted time for the initial export step

Step 1: Export Your Container and Build the Audit Log

Start with a complete export so you have a static snapshot of the container before you change anything.

In GTM, open your workspace and go to Admin > Export Container. Choose the current workspace and export as JSON. Save the file with today's date in the filename, for example gtm-audit-2026-09-17.json.

Open your spreadsheet and create four tabs: Tags, Triggers, Variables, and Issues. Paste the following column headers into the Tags tab.

Tag Name | Tag Type | Trigger(s) | Status | Last Modified | Notes

Go back to GTM and open the Tags overview. For each tag, fill in one row. Status should be one of: Active, Paused, or Unknown. Unknown means the tag has no clear owner or documentation.

Common pitfall: teams skip paused tags entirely. Include them. A paused tag can be reactivated accidentally during a future change.

Step 2: Flag Tag Bloat and Duplicates

Most containers accumulate tags that were created for a single campaign and never removed. These slow page load and corrupt event counts in GA4.

What counts as tag bloat?

A tag is bloat if it meets any of these conditions.

  • It fires on All Pages but sends data to a platform you no longer use
  • It has not been modified in over 12 months and no team member can explain its purpose
  • It duplicates an event already sent by another tag or by the GA4 configuration tag
  • It belongs to a vendor whose contract ended

In your Tags tab, add a Bloat flag column. Mark each row Y or N. Aim to make a decision on every single row before moving to the next step.

How do you spot duplicate events?

Open Tag Assistant in Chrome and load your site's homepage. Click through to a product or service page, then check the event stream in the Tag Assistant panel. If you see the same event name fired twice within the same page session, you have a duplicate. Common offenders are page_view sent by both a legacy Universal Analytics tag and a GA4 tag, and purchase sent by both a custom HTML tag and a GA4 e-commerce tag.

Record each duplicate pair in your Issues tab with a recommended action: keep one, delete the other.

Step 3: Audit Triggers for Over-Firing and Under-Firing

A tag can be technically valid but fire at the wrong time. This is the most common cause of inflated session counts and misleading conversion data.

For each trigger in your Triggers tab, answer these three questions and note the answers in the spreadsheet.

  1. Does the trigger use All Pages when it should use a page path filter?
  2. Does a Click trigger target a CSS selector that no longer exists in the current site HTML?
  3. Does a Form Submission trigger fire before the form actually submits, catching abandoned fills?

To check CSS selectors quickly, open Chrome DevTools on the relevant page and run this in the console.

document.querySelectorAll('.your-selector-here').length

If the result is 0, the selector is broken. Mark the trigger as a priority fix in your Issues tab.

Pro tip: If you are auditing a Shopify store, check whether the checkout triggers target window.location.pathname correctly. Shopify's checkout uses a subdomain path structure that breaks generic URL-match triggers more often than people expect.

Step 4: Review Variables for Stale or Insecure Values

Variables store values like Measurement IDs, pixel IDs, and API keys. Stale variables point at old properties. Insecure variables expose credentials in the browser.

Open the Variables tab in GTM and review each user-defined variable. Check for these issues.

  • Constant variables that hold a GA4 Measurement ID for a property that was deleted or renamed
  • JavaScript variables that read document.cookie or localStorage without validation, which can break silently across browsers
  • Lookup Table variables with stale key-value pairs left over from old A/B tests

Cross-reference each Measurement ID against your active GA4 properties in Google Analytics. If the property does not exist, flag the variable for deletion.

Do not store API keys or secret tokens as GTM constants. They are visible in the browser. Move any sensitive values to server-side GTM or to your application's environment variables.

Step 5: Build the Firing-Rule Map

A firing-rule map shows you which tags fire on which URLs and under which conditions. It is the single most useful document you will produce in this audit.

In your Tags tab, add three new columns: Fires On (URL pattern), Fires On (event), and Priority. Fill in these columns for every active tag.

Then switch to a new sheet called Firing Map. Set up rows as URL patterns and columns as tag names. Put a tick in each cell where a tag fires on that URL. Your spreadsheet will look like this.

URL Pattern          | GA4 Base | Meta Pixel | LinkedIn | HotJar |
---------------------|----------|------------|----------|--------|
/ (homepage)         |    ✓     |     ✓      |    ✓     |   ✓    |
/checkout            |    ✓     |     ✓      |          |        |
/thank-you           |    ✓     |     ✓      |    ✓     |        |

This map makes it immediately obvious when too many tags fire on high-traffic pages. Every tag adds a network request. On a typical SMB site, reducing tag count on the homepage from 18 to 9 can cut total page weight by 15 to 25 percent, depending on the vendors involved.

Step 6: Implement a Naming Convention

A clean container is only useful if your team can maintain it. Without a naming convention, the container reverts to chaos within six months.

Use this structure for tag names, based on the convention recommended in the GTM community and used by agencies including Lenka Studio.

[Platform] - [Type] - [Description] - [Trigger Scope]

Examples:
GA4 - Event - Form Submit - Contact Page
Meta - Pixel - PageView - All Pages
LinkedIn - Insight - Conversion - Checkout Confirm

Apply the same pattern to triggers and variables. For triggers, use this structure.

[Trigger Type] - [Page or Element] - [Condition]

Examples:
Click - CTA Button - Homepage
Form - Contact Form - Submit Success
Page View - Checkout - URL Contains /checkout

Rename every tag, trigger, and variable in your current workspace before publishing. This takes time but prevents confusion for the next person who opens the container.

Step 7: Publish and Validate

Before you publish, use GTM's built-in Preview mode to validate your changes against the live site.

  1. Click Preview in the top-right of the GTM workspace.
  2. Enter your site URL and connect Tag Assistant.
  3. Navigate through the pages you identified in Step 5.
  4. For each active tag, confirm it fires exactly once per expected interaction.
  5. Check the GA4 DebugView in real time by opening Google Analytics, going to Admin > DebugView, and watching events arrive as you click through the site.

If a tag that should fire does not appear in DebugView, check the trigger conditions first. The most common cause is a regex pattern that does not account for a trailing slash in the URL.

Once you are confident the container is clean, publish the version and add a descriptive version note, for example: Audit 2026-09-17: removed 11 stale tags, standardised naming, fixed checkout trigger.

Step 8: Schedule a Quarterly Review

An audit is not a one-time task. Set a recurring calendar event for every 90 days. During each review, run through a short checklist.

  • Were any new tags added without following the naming convention?
  • Are there any paused tags older than 90 days that can be deleted?
  • Do all vendor pixels still correspond to active vendor contracts?
  • Has the site structure changed in a way that breaks existing URL-match triggers?

If your team manages multiple client containers, this workflow scales well. Build the audit log as a template and reuse it for each container. If you work with an external team, consider asking them to provide a completed audit log as part of their onboarding. It is a clear signal of how organised their tracking practice is.

Accurate tracking data also feeds into broader brand performance measurement. If you have not assessed how your tracking gaps affect your overall digital health, the free brand health score from Lenka Studio gives you a structured starting point across traffic, conversion, and brand visibility.

Frequently Asked Questions

How many tags is too many in a GTM container?

There is no hard limit, but containers with more than 50 active tags almost always contain redundant or broken tags. A well-maintained container for a typical SMB site runs between 10 and 25 active tags. Anything above that warrants a review.

Will deleting a tag break my GA4 data?

Deleting a tag stops future data collection for that specific event. It does not affect historical data already recorded in GA4. Always preview and validate before publishing deletions, and check whether any GA4 reports or audiences depend on the event the tag fires.

How is this different from just using Tag Assistant?

Tag Assistant shows you what fires during a session. This audit workflow goes further by cataloguing every tag in the container, including paused ones, and documenting naming, firing logic, and ownership. Tag Assistant is one tool within the audit, not a replacement for it.

Does this process work for server-side GTM containers?

The export, naming convention, and review cadence steps apply directly to server-side containers. The browser-based Tag Assistant steps do not apply because server-side tags fire outside the browser. Use your server container's built-in preview server and check your server logs to validate firing behaviour instead.

What if I inherited a container and have no idea what half the tags do?

Start with the Issues tab and mark everything you cannot explain as Unknown. Contact whoever managed tracking before you and ask for a handover document. If no one is available, use the GTM version history to see who created each tag and when. Tags with no activity in GA4 DebugView across five different page sessions can usually be safely paused for 30 days before deletion.

Next Steps

With a clean container, your GA4 data becomes reliable enough to act on. The natural next step is building a reporting layer on top of it, whether that is a Looker Studio dashboard, a GA4 exploration report, or an automated email summary for your team.

If you are managing tracking across multiple properties or want a second pair of eyes on your audit output, the team at Lenka Studio works with SMBs across Australia, Singapore, Canada, and the United States on analytics audits and marketing stack reviews. Get in touch to talk through what a clean tracking setup could look like for your business.