Severity: HighOwner: DevTime to fix: 1-2 h
Cookies still set after Reject
Fix flows where optional cookies or requests continue after the visitor explicitly rejects tracking.
Covers: cookies_after_reject, reject_not_enforced
Why this matters
A Reject button that does not actually block optional processing is one of the clearest signs that the consent mechanism is not being enforced correctly.
How to verify manually
- Reject optional processing in a clean session and reload the page.
- Inspect cookies and network requests after Reject.
- Compare behavior before and after Reject to confirm whether optional storage truly stops.
Typical root causes
- Reject updates banner state but does not propagate a denied consent state.
- Optional tags re-fire on reload despite a denied choice.
- Stored consent values are misread or ignored after navigation.
GTM fix
- Ensure denied consent state is read before tags can run after reload.
- Attach consent checks to all optional tags, not just first-load events.
- Verify Reject persists through reload in GTM preview.
WordPress fix
- Check plugin integrations that keep loading optional tags after Reject.
- Verify the CMP plugin stores and enforces denied state across page loads.
- Remove overlapping tracking plugins that ignore CMP state.
Generic fix
- Treat Reject as an enforceable runtime state, not just a UI action.
- Block optional loaders on every page when the stored consent state is denied.
- Test reload, revisit, and cross-page flows instead of only first-load behavior.
How to confirm the fix worked
- Reject and reload: confirm optional cookies remain absent.
- Reject and reload: confirm optional requests stay blocked.
- Run a fresh scan and verify reject-flow findings disappear.
Next step
Re-scan after deployment to confirm that the runtime behavior changed, not just the banner copy.