A WordPress consent banner can record a choice in its own cookie while Google tags still see the old default during an immediate page transition, Elementor form redirect, checkout navigation, or single-page application route change. The result is a timing bug, not necessarily a banner configuration bug.
Use this for WordPress sites with Google Tag Manager, GA4, Google Ads, Elementor forms, WooCommerce, consent platforms, AJAX navigation, or regional consent defaults.
Quick answer
Set the approved default before measurement commands and apply consent updates on the page where the choice occurs, before navigation. Verify the actual consent state in Tag Assistant and the next relevant request, rather than relying on a custom queue marker. Test accept, reject, partial choices and withdrawal, including immediate form redirects.
What to check first
- Record the initial consent default by region before GTM or gtag-dependent configuration runs.
- Timestamp the banner action, consent update, dataLayer event, tag request, form success, and navigation start.
- Test accept, reject, partial choices, change preferences, expired choice, and returning visitor paths.
- Repeat on normal links, Elementor redirects, WooCommerce checkout, AJAX navigation, and browser back or forward.
- Verify both consent state and request parameters in the network trace, not the banner UI alone.
Why this usually happens
- Cookie persistence and the Google consent command queue are separate operations.
- A form or router can start navigation in the same task as the banner callback.
- Consent defaults loaded after a tag cannot retroactively change the request already sent.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
A queued marker is not an acknowledgement. A dataLayer event named consent_updated proves only that your code pushed that message. It does not prove that a Google tag processed the new consent state. Do not use that marker as the sole permission to navigate.
For a GTM custom consent template, use its supported setDefaultConsentState and updateConsentState APIs. For a direct gtag.js integration, follow the Google tag consent command guidance. Keep these implementation paths separate and use the CMP integration supported for your setup.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Move the default before tags | Record the initial consent default by region before GTM or gtag-dependent configuration runs. | The consent default runs before Google tag configuration. |
| Instrument the timeline | Timestamp the banner action, consent update, dataLayer event, tag request, form success, and navigation start. | Accept, reject, and preference changes update request behavior as intended. |
| Sequence update before navigation | Test accept, reject, partial choices, change preferences, expired choice, and returning visitor paths. | Form and route transitions preserve the updated state. |
| Test every transition type | Repeat on normal links, Elementor redirects, WooCommerce checkout, AJAX navigation, and browser back or forward. | Network evidence and Tag Assistant agree with the stored consent choice. |
Decision rule
Hold tracking changes when any eligible request leaves before the intended default or update, navigation occurs before the update path completes, returning choices reset unexpectedly, or a regional fixture receives the wrong default.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| First visit accept | Cold profile in a consent-required region | Default denied precedes tags, then update granted precedes eligible requests |
| First visit reject | Cold profile rejects optional storage | Denied state remains in requests and after navigation |
| Form redirect | Elementor success redirects immediately | Consent update is processed before the destination tags run |
| Preference change | Returning user revokes an earlier grant | New state applies to later requests and survives route changes |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Move the default before tags
- Instrument the timeline
- Sequence update before navigation
- Test every transition type
- Monitor consent-state regressions
Production verification checklist
- The consent default runs before Google tag configuration.
- Accept, reject, and preference changes update request behavior as intended.
- Form and route transitions preserve the updated state.
- Network evidence and Tag Assistant agree with the stored consent choice.
What to tell the client or owner
Provide the region, consent platform, default command timestamp, user action, update timestamp, dataLayer events, request timestamp and parameters, transition type, destination result, and sanitized HAR.
Mistakes to avoid
- Do not verify consent from the banner cookie alone.
- Do not add an arbitrary long delay instead of sequencing the actual events.
- Do not test only a returning visitor with an existing cookie.
- Do not include personal values in shared HAR or debug files.
Questions teams ask during testing
Is a setTimeout the right fix?
A fixed delay can hide the race on one device. Sequence the consent update and navigation through the integration's supported callback or event path.
Why preserve the network log?
The page transition otherwise clears the evidence needed to compare tag requests and timestamps.
Do all regions need the same default?
No. Use the legal and platform configuration approved for each region, then test those exact branches.
When HandL WP should help
HandL WP can instrument consent timing, trace GTM and gtag requests, correct form and router sequencing, test regional and returning-user paths, and verify Google Ads and GA4 behavior.
If this is active on a production site, fix WordPress consent timing.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references
Verification note: October 17, 2026
Keep a synthetic test trace for the consent choice, observed state and destination page. Remove personal data from shared HAR files. A technically ordered consent implementation does not itself establish legal compliance. Compare the approved policy with the actual behavior in each tested region.