Names do not tell you what a tag does
A tag called GA4 - main can send a page view, an event, or a conversion to an account nobody remembers. Deleting by name is guessing. The first job in an inherited container is a table with one row per tag, trigger and variable that says what it sends, to which account, from which trigger, and who last edited it.
Fill the table from three places: the tag configuration, the version history for who and when, and the consent overview if you enable it, which lists tags with no consent settings configured. Leave a column for a decision with four values: keep, pause, remove or ask.
- Record the account or measurement ID each tag sends to.
- List triggers that match nothing separately; they are a symptom, not a fix.
- Mark any tag whose owner you cannot name as ask.
Let the preview tell you what fires
Open Tag Manager preview on the pages that matter and perform the actions that matter: submit the form, add to cart, reach the confirmation. Google describes the debug view as showing which tags fired, in what order and what triggered them. Keep a screenshot for each action as the baseline.
A tag that never fires on any key page is a candidate for review, but not proof it is unused: it may serve a page you did not visit. Pause before you delete, and keep the table up to date as you learn.
- Preview is visible only in your own browser unless you share it.
- If the debug parameter breaks a page, untick the option to include it in the URL.
Change in a workspace and keep a way back
Make removals in a workspace, not on the published container. Save the workspace as a named version with a note of what was removed and why. Google documents that you can publish an earlier version directly, or set it as the latest version to continue from it, so a missed dependency is a republish and not a rebuild.
Run the same actions in preview after the change and compare with the baseline before anyone publishes. The test events must fire the same tags with the same event names, except where the change was meant to alter them.
- Write version names a stranger could follow a year from now.
- Publish only after the before and after screenshots match.
What does not fit, and how the paid outcome is accepted
A container with more than about fifty tags, several sites on one container, or unknown advertising accounts needs a different scope. Clean-up does not add events or write a measurement plan, and it does not promise faster pages.
For one site and one container up to 50 tags, the fixed outcome Clean up one GTM container is quoted at £395 as an untested proposal, with payment only after sign-off. Acceptance is the before and after comparison of up to ten agreed events, an inventory with a purpose and owner for every remaining tag, and the live site sending each event once after you publish. Send the tag count and the five events you must not lose. Do not send container exports or logins.
Sources and limits
- Tag Manager Help: Publish a container and manage versions Checked 2026-10-11.
- A version is a snapshot of the container configuration; each publish records a version.
- An earlier version can be published directly or set as the latest version to become the working draft.
- Users need Approve access or higher to create versions.
- Tag Manager Help: Preview and debug containers Checked 2026-10-11.
- Preview lists which tags fired, in what order and what triggered them.
- The debug view is visible only in the browser that started preview, or to people you share it with.
- If the added debug signal breaks a page, it can be left out of the URL.
- Tag Manager Help: Consent mode in Tag Manager Checked 2026-10-11.
- A consent overview can be enabled in container settings and splits tags into Consent Not Configured and Consent Configured.