Website Tag Audit: Scripts, Triggers and Consent Checks

A website tag audit inventories scripts and tracking integrations, then checks what each one sends, when it runs and who owns it. The output is a verified map of tags, triggers, destinations, consent behaviour and proposed corrections.

What is included in a tag audit?

Include tag-manager containers, hardcoded scripts, CMS integrations, embedded widgets and relevant server-side destinations. Page source alone may miss tags loaded after interaction or through another script.

The analytics audit checks how collected data is interpreted. A tag audit establishes the implementation that produced it.

Why do unnecessary or duplicate tags appear?

Tags can survive agency changes, tool trials and migrations when ownership is unclear. A CMS plugin and a tag manager may both send the same event, but the number of installed scripts alone does not prove duplicate measurement.

For each integration, record its purpose, owner and removal dependencies. A script that looks unused in one session may be required for a different consent choice or customer journey.

Which tag problems should you investigate?

Unexpected collection: data sent before the intended consent state or to an unapproved destination.
Duplicate events: the same business action emitted more than once through overlapping implementations.
Missing events: a trigger that fails on a particular template, navigation path or error state.
Performance cost: repeated requests, long tasks or resource loading that interferes with the customer journey.
Ownership gaps: scripts with no accountable owner or documented purpose.

How do you audit website tags?

Agree the pages, journeys, devices and consent states to inspect.
Export the current container version where authorised and inventory hardcoded or CMS-managed integrations.
Open a fresh browser session and inspect network requests before consent, after rejection and after acceptance.
Exercise relevant actions using labelled test data. Record trigger, event, destination and timestamp.
Compare actual requests with the intended specification and investigate discrepancies.
Prepare a small correction, preserve a rollback version and retest every affected journey.

Google's Consent Mode overview explains built-in consent checks and the distinction between basic and advanced implementations. Advanced mode can send measurements without cookies; a denied state does not mean that no request is sent. Third-party tags need their own assessment.

How should tags be governed after the audit?

Require an owner, purpose, permitted data, consent behaviour and acceptance test for each integration. Review changes before publication and retain a recoverable configuration.

A tag manager can centralise management, but moving every script into one container is not a universal requirement. Choose the implementation that supports the site's performance, security and maintenance needs.

Server-side tagging changes where processing occurs. It does not automatically remove browser work, restore missing data or exempt collection from privacy obligations. Measure its actual effect before describing it as an improvement.

Which tools help verify a tag inventory?

Use browser network tools for actual requests and storage inspection. Use the provider's debugging interface for its own events and a crawler to find selected script patterns across templates.

Google Tag Assistant supports debugging Google-tag implementations. A technology detector can suggest integrations to investigate, but it is not a complete inventory or a privacy-compliance certificate.

Record confirmed corrections in the implementation tracker. Use the cookie audit workflow for storage purposes, jurisdiction and consent evidence.