---
title: "Making Cookie Consent Persist Across Subdomains"
canonical_url: https://ot.webclat.com/qa/cookie-consent-persist-across-subdomains
description: "Scope the consent cookie explicitly to the parent domain - if your CMP stores its choice in localStorage instead, that storage is origin-scoped and can't be shared across subdomains without a bridge."
source: Webclat | OneTrust Solutions (OneTrust partner, independent consultancy)
---

# 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. **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. **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. **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. **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. **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?](https://ot.webclat.com/qa/tcfapi-undefined-decode-tcf-string)
- [What's the correct pattern to block GA/GTM/AdSense from loading until the visitor accepts cookies?](https://ot.webclat.com/qa/gate-ga-gtm-adsense-behind-cookie-consent)
- [Why doesn't Google Consent Mode v2's ad_personalization/analytics_storage signal update the way I expect?](https://ot.webclat.com/qa/consent-mode-v2-signal-not-updating)

Contact: ot@webclat.com | (813) 694-4451 | https://ot.webclat.com/#contact