A visitor accepts cookies on the shop, clicks through to the support portal, and is asked again. She declines on the blog, visits the main store, and finds analytics already running. Multi subdomain estates quietly produce both experiences at once, because each property implemented consent as a local feature instead of a shared state.
The fix is architectural: one consent record, written once, readable everywhere it lawfully applies, with the boundaries of that application thought through rather than assumed.
Set the consent cookie at the registrable domain
A cookie scoped to the parent domain is readable by all subdomains, which makes it the natural transport for consent state. The consent platform writes it on any property where the visitor makes a choice, and every other property reads it on arrival and applies the decision before tags fire.
Host only cookies are the usual bug. A banner that stores its answer on shop dot example dot com has said nothing to support dot example dot com, so the second banner is not being rude; it is genuinely ignorant. Scoping is a one line configuration with estate wide consequences.
One writer, many readers, no URL passing
Designate the consent platform as the single writer of consent state. Properties that invent their own storage, local storage here, a server flag there, create competing versions of the truth that surface in audits as inconsistent firing: analytics running on one subdomain for a visitor who declined on another.
Never pass consent in URLs or redirect parameters. It leaks the state into logs, emails, and third party referrers, breaks when links are shared, and cannot be trusted because anyone can edit it. Shared first party cookies and, for signed in users, server side account records are the sound transports.
Respect the boundaries of the estate
Shared state should span properties the visitor would understand as one service. It should not silently span separate brands, white label stores, or country properties with different legal duties, even where the same company owns them all. Consent given to one brand is not consent to its siblings, and regulators read quiet expansion as deception.
Where properties genuinely differ, say so at the point of choice: this decision applies across our store and support site. Naming the scope inside the banner turns an architectural convenience into informed consent.
Signed in users need a server record
Cookies are cleared, devices multiply, and consent given on a phone should govern the same person's laptop session when they sign in. Store consent against the account server side, merge it with the device state carefully, and let the most recent explicit choice win, with the history retained for audit.
The merge rules matter. A decline on any device must not be silently upgraded by an older acceptance elsewhere. When states conflict, applying the more restrictive one until the visitor chooses again is the defensible default.
Related reading
These earlier guides go deeper on connected questions: Consent in Single Page Applications: Why Route Changes Break Your Banner Logic Single page apps load tools as visitors move between views without page reloads, which quietly defeats consent code written for classic sites. How to fix the sequence., Multilingual Consent Banners: When Translation Is a Legal Requirement, Not a Courtesy Serving visitors in their language is often part of valid consent. Which languages a banner needs, and how translation quality affects whether consent counts., and Consent Records: What to Keep When Someone Asks What You Collected and Why Consent logs feel like plumbing until a regulator, a platform, or an angry visitor asks for proof. What a useful consent record contains, how long to keep it, and how to find one person's record without a week of archaeology..
Frequently asked questions
Why does a visitor get asked for consent on every subdomain?
Because the consent cookie was scoped to a single host, so other subdomains cannot read the answer. Setting the cookie at the registrable domain level makes the choice visible across the estate.
Should consent span all of a company's brands?
No. Shared state should cover properties a visitor understands as one service. Separate brands or legally distinct country properties need their own choices, or explicit wording that names the wider scope.
How should consent work for signed in users across devices?
Store consent server side against the account, merge it with per device state, let the most recent explicit choice win, and default to the more restrictive state when records conflict.
Why not pass consent state in links between properties?
URL parameters leak into logs and third party referrers and can be edited by anyone, so they are neither private nor trustworthy. Shared first party cookies and account records are the reliable routes.