Server-side GTM consent issues

Why this matters

Server-side GTM can reduce client-side leakage, but it can also hide consent failures if events are proxied without respecting denied states.

How to verify manually

1. Inspect whether client-side requests still proxy analytics or ad events to the server container before consent.
2. Check how consent state is forwarded into server-side GTM requests.
3. Compare Accept and Reject flows to confirm denied states suppress server-side dispatch too.

Typical root causes

• Server-side GTM receives events without consent context.
• Client-side code forwards page-view events to the server endpoint before consent.
• Consent checks exist in the browser container but not in the server container.

GTM fix

1. Pass explicit consent state into events forwarded to server-side GTM.
2. Mirror consent checks in the server-side container instead of trusting client defaults.
3. Audit tags in both browser and server containers for duplicate or bypassed dispatch.

WordPress fix

1. Review whether plugins or theme snippets send events to a server-side GTM endpoint automatically.
2. Disable server-side analytics forwarding until consent state is wired correctly.
3. Retest both browser and network behavior after updates.

Generic fix

1. Treat server-side GTM as another enforcement layer, not an exemption from consent logic.
2. Forward denied states explicitly and suppress optional event proxying before consent.
3. Document how browser and server tagging share the same consent source of truth.

How to confirm the fix worked

• Confirm no optional events are proxied to server-side GTM before consent.
• Confirm Accept enables the intended event flow and Reject keeps it denied.
• Run a fresh scan and verify consent issues around server-side GTM are resolved.