Consent state not persisted

Why this matters

If consent resets on reload or across pages, users may be repeatedly prompted or optional processing may restart without respecting their previous choice.

How to verify manually

1. Accept or reject on one page, then reload and navigate to other pages.
2. Confirm the same consent choice is still in effect across the site.
3. Inspect the persistence mechanism used for consent storage.

Typical root causes

• The consent cookie or local storage entry is not written consistently.
• Subdomain, path, or SameSite settings prevent persistence.
• SPA navigation resets state because consent is stored only in memory.

GTM fix

1. Ensure consent state is read from a persistent source on every page.
2. Do not rely on one-time runtime variables that disappear after navigation.
3. Validate consent persistence in GTM preview across reloads.

WordPress fix

1. Review CMP plugin storage settings, domain scope, and multilingual path handling.
2. Test whether caching or security plugins strip or reset consent storage.
3. Verify the plugin respects the same stored choice on every template.

Generic fix

1. Persist consent in a stable cookie or equivalent storage with correct domain and path scope.
2. Reload consent state before optional tags initialize on each page.
3. Keep consent storage logic centralized instead of duplicating it per route.

How to confirm the fix worked

• Confirm the same choice persists after reload and cross-page navigation.
• Confirm Reject remains denied after revisit.
• Run a fresh scan and verify persistence-related regressions no longer appear.