Elementor sites can show a cookie banner while Google tags receive the wrong consent default, a late update, or no update at all. Basic mode and advanced mode also produce different expected network behavior before the visitor responds.
Use this after changing an Elementor banner, GTM container, Google tag, form redirect, regional rule, caching layer, or Consent Mode integration.
Quick answer
Elementor Consent Mode v2 Tag Assistant Verification should be handled with a narrow evidence-first workflow: start a clean tag assistant session, verify consent default, test choice updates, then verify the result before making broader changes.
What to check first
- Open Tag Assistant in a clean browser profile and record the region, page, container version, and test time.
- Verify the default consent state fires before Google measurement tags evaluate consent.
- Test reject, accept all, and category-level choices, then confirm the matching consent update event.
- Submit one Elementor form after consent and confirm the conversion event uses the intended consent state.
- Repeat with cached and uncached pages, mobile width, and a returning visitor choice.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Start a clean Tag Assistant session | Open Tag Assistant in a clean browser profile and record the region, page, container version, and test time. | The default event precedes Google tags and matches the intended regional mode. |
| Verify consent default | Verify the default consent state fires before Google measurement tags evaluate consent. | Each visitor choice produces the expected consent update values. |
| Test choice updates | Test reject, accept all, and category-level choices, then confirm the matching consent update event. | The Elementor form conversion fires after the update and carries the intended state. |
| Submit one form | Submit one Elementor form after consent and confirm the conversion event uses the intended consent state. | Cached pages and returning visits reproduce the same policy without duplicate events. |
Why this usually happens
- The consent update can fire after a conversion event already ran.
- A cached banner script can use an old category or region configuration.
- Basic mode correctly sends no Google request before consent, which can be misread as a failure.
- A thank-you redirect can lose the consent cookie or data-layer state.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('consent', 'default', {
ad_storage: 'denied',
analytics_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied'
});
// The banner must send a consent update after the visitor choice.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Start a clean Tag Assistant session
- Verify consent default
- Test choice updates
- Submit one form
- Repeat cache and return paths
What to tell the client or owner
Share the page, region, container version, Tag Assistant event order, consent values, form event, cache state, and screenshots of each test choice.
Production verification checklist
- The default event precedes Google tags and matches the intended regional mode.
- Each visitor choice produces the expected consent update values.
- The Elementor form conversion fires after the update and carries the intended state.
- Cached pages and returning visits reproduce the same policy without duplicate events.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, verify Elementor consent and conversion tracking.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references
Measure form success and consent updates in order
If Tag Assistant shows the right values but leads still go missing or duplicate, run the Elementor submit-success and consent-update order test to compare millisecond timestamps, event IDs, network requests, and retries.