Webclat logoWebclat . | OneTrust Solutions
Consent persistence

How do I make a visitor's cookie-consent choice persist across subdomains instead of re-prompting?

Short answer

The consent choice needs to be stored in a cookie explicitly scoped to the parent domain rather than left at its default host-only scope, so every subdomain can read the same value - if your CMP stores its choice in localStorage instead of a cookie, that storage is origin-scoped by the browser and cannot be shared across subdomains at all without a dedicated cross-domain bridge.

Why this happens

A cookie set without an explicit domain attribute defaults to host-only scope - readable only on the exact hostname that set it, not its subdomains or siblings. Setting domain explicitly to the registrable parent domain makes the cookie visible to every subdomain under it, which is the mechanism that makes cross-subdomain persistence possible at all.

localStorage has no equivalent domain-scoping option - it's strictly origin-scoped (scheme + host + port) by browser design, with no attribute that widens that scope. A CMP that persists its choice there is architecturally unable to share it across subdomains without an out-of-band mechanism, no matter how it's configured.

Fix it

  1. 1

    Determine where your CMP actually persists its choice

    Check the CMP's documentation and inspect Application > Cookies / Local Storage in DevTools after making a choice - the fix differs entirely depending on whether it's a cookie or localStorage.

  2. 2

    If cookie-based, set the domain attribute explicitly to the parent domain

    Configure the CMP (or the cookie-setting call, if you control it directly) to set domain=webclat.com rather than leaving it unset, so ot.webclat.com, ampl.webclat.com, and any other subdomain under the same parent all read the identical cookie.

  3. 3

    If localStorage-based, either switch storage mode or build a bridge

    Check whether the CMP supports a cookie-based storage mode as a configuration option first, since that's the simpler fix. If it doesn't, the alternative is a cross-domain sync pattern - a shared hidden iframe hosted on a common domain that each subdomain communicates with via postMessage - which is meaningfully more engineering effort than a configuration change.

  4. 4

    Check Secure and SameSite attributes don't undermine the domain scoping

    SameSite=Lax is generally fine for cross-subdomain reads under the same registrable domain; SameSite=Strict combined with certain cross-subdomain navigation flows can still block the cookie from being sent even when the domain attribute is correct, so verify the actual attribute combination in use.

  5. 5

    Confirm the subdomains involved genuinely share a parent domain

    Domain-scoped cookies only bridge subdomains of the same registrable domain - this pattern cannot extend consent state to a completely different domain, however related the two properties are in branding.

How to verify it worked

Accept consent on one subdomain, then navigate directly to a different subdomain in the same browser session (not incognito) and confirm the banner does not reappear.

In DevTools > Application > Cookies, check the consent cookie's Domain column - a passing result shows the parent domain, not the specific subdomain that set it.

If a cross-domain bridge was built instead, test it the same way and additionally confirm it degrades gracefully (re-prompts rather than errors) if the bridge iframe fails to load for any reason.

Related

Why is window.__tcfapi undefined, or how do I decode the euconsent-v2 TCF string client-side?What's the correct pattern to block GA/GTM/AdSense from loading until the visitor accepts cookies?Why doesn't Google Consent Mode v2's ad_personalization/analytics_storage signal update the way I expect?

Still stuck, or want this checked against your specific setup?

We scope every engagement in discovery, before implementation - no assumptions about your stack.

Request a Free OneTrust Audit