One Brand, Several Domains: Keeping Consent State Coherent Across Subdomains
Consent does not travel between domains on its own. A choice made on the shop subdomain is invisible to the support subdomain unless the consent tool is deliberately configured to share it, and trackers on the second domain will treat the visitor as undecided, banner them again, or worse, default to firing.
Why the second domain behaves like a stranger
Browsers scope cookies to the domain that set them. A consent cookie written for the shop host does not automatically exist on the help centre host, and a consent platform installed separately on each property keeps separate records for the same person on the same visit. From the visitor's side it reads as incompetence: they answered once and the brand asks again at every door.
The legal problem is sharper than the annoyance. If the second property defaults to loading marketing tags while it waits to ask again, it collects under no consent at all, because the consent that exists lives in a record it never checked. The person's earlier refusal, in particular, must follow them: re-asking after a refusal until the answer changes is a pattern regulators have named in decisions.
The shared consent options, honestly priced
On subdomains of one registrable domain, a consent cookie set at the parent domain level can be read by each subdomain, and most consent platforms support that configuration. Across separate registrable domains there is no silent mechanism: the options are a consent bridge during navigation, where the choice travels in the handoff between properties, or accepting separate choices per domain and recording them as such.
Single sign on changes the picture for logged in users, because the account can carry the consent state server side and every property can ask the account. Anonymous visitors get no such carry. Design for the anonymous case and let login improve it, rather than designing for members and leaving most traffic in the broken path. Our guide to Consent State Across Subdomains: Where the Shop, Blog, and Support Site Disagree covers the vendor side of making one platform behave across properties.
An audit pass for multi domain consent
Walk the real journey in a fresh browser: land on the shop, refuse consent, follow the support link, open the account pages, and watch what fires and what re asks at each step. Then repeat accepting. The two recordings, refused and accepted, are the audit. Any property that fires marketing tags on the refused walk, or demands a fresh answer with no way to see the old one, goes on the fix list with the recording attached.
Fix order matters. Stop collection without consent first, because that is live exposure. Share the refusal state second. Unify the asking experience last, because it is the most visible item and the least legally urgent, which is exactly why teams tend to do it first.
Keep reading: Consent State Across Subdomains: Where the Shop, Blog, and Support Site Disagree Reading a TCF Consent String When a Partner Says You Sent the Wrong One Top Cookiebot Alternatives Worth Switching To.
Frequently asked questions
Does consent on one subdomain apply to another?
Technically only if it is configured to. A consent cookie set at the parent domain can be read across subdomains. Without that configuration each subdomain keeps its own state, asks again, and may fire tags in the gap. The legal duty to honour a refusal does not reset at the subdomain boundary.
Can consent be shared across different registrable domains?
Not silently. Browsers will not carry a cookie between separate domains. Brands use a navigation handoff that passes the choice when a visitor moves between properties, or they record separate choices per domain. What they cannot do is assume one domain's consent covers another's tracking.
Why do visitors get asked again after refusing?
Usually because the second property never received the refusal, or because the banner is configured to re prompt after a set interval regardless of the answer. Re prompting after refusal on a short cycle is a known dark pattern concern. Store the refusal with the same care as a grant and respect its duration.
Should logged in consent be stored on the account?
Yes, where an account exists. Server side consent on the account survives device and subdomain changes and gives the cleanest record. It supplements rather than replaces the browser level consent for anonymous traffic, which is where most collection happens.