Severity: HighOwner: DevTime to fix: 1-2 h
GTM tags firing before consent
Audit and gate GTM triggers so optional tags do not fire on page load before a valid consent state exists.
Covers: gtm_tags_before_consent, pre_consent_gtm_fire
Why this matters
Even a well-configured CMP fails if GTM keeps firing tags on page view without consent conditions. This is a common root cause behind multiple findings at once.
How to verify manually
- Open GTM preview mode and review which tags fire on first load before any consent action.
- Compare GTM firing events with the banner timeline and consent state changes.
- Identify custom HTML tags and legacy triggers that ignore consent requirements.
Typical root causes
- Tags still use generic page-view triggers with no consent conditions.
- Custom HTML tags load external scripts immediately.
- Multiple GTM workspaces or containers duplicate tag behavior.
GTM fix
- Move non-essential tags behind consent-aware triggers.
- Use Consent Initialization and explicit consent checks instead of late blocking.
- Review every custom HTML tag for manual script injection.
WordPress fix
- Ensure the site uses one GTM container and no overlapping plugin-injected tags.
- Disable plugin features that add tracking outside GTM.
- Retest after publish and cache invalidation.
Generic fix
- Treat GTM as an execution layer, not a consent source of truth.
- Centralize consent state and require it before optional tags can run.
- Remove redundant tag paths that bypass your intended GTM flow.
How to confirm the fix worked
- In preview mode, confirm optional GTM tags do not fire pre-consent.
- Confirm only essential tags remain on first load.
- Run a fresh scan and verify related pre-consent findings drop.
Next step
Re-scan after deployment to confirm that the runtime behavior changed, not just the banner copy.