# Cookie consent across subdomains and multiple domains > Can one cookie choice cover www, shop and blog subdomains or other domains? How cookie scope works, when to share consent or ask again, and how to test it. Source: https://cookiequiet.com/guides/cookie-consent-across-subdomains Published: 2026-10-21 Publisher: Cookiequiet ## Steps 1. **Check who controls each subdomain** Share consent only between subdomains run by the same organization for the same purposes. Give partner or franchise subdomains their own banner. 2. **Align categories and tools** Use the same categories on every subdomain and list the trackers of all of them in the cookie policy. 3. **Set the consent cookie domain** Configure the consent tool to store its cookie with Domain set to the parent domain, so every subdomain can read it. 4. **Tell visitors the scope** Say in the banner and the cookie policy which sites the choice applies to, and that withdrawing on one withdraws on all. 5. **Remove old host-only cookies** Delete or rename the previous consent cookie so browsers do not send two values with the same name. 6. **Test choice and withdrawal** Reject on one subdomain, visit the others, then withdraw and check that every subdomain follows. A consent choice is stored in a cookie or in local storage, and where it can be read depends on how it was stored. A cookie set with `Domain=example.com` is readable on every subdomain (www, shop, blog), so one choice can cover all of them. A cookie set without a Domain attribute is host-only and stays on the exact host that set it, and local storage is always limited to one origin. Separate domains (example.com and example.de) can never share a cookie. Whether you should share the choice is a separate question: it makes sense when the same organization runs the subdomains for the same purposes and the banner says the choice covers them. ## How does cookie scope work? MDN's reference for the Set-Cookie header sums up the rule: - **Domain set:** the cookie is available to that domain and all its subdomains. A response from shop.example.com can set `Domain=example.com`, and the cookie is then sent to www.example.com and blog.example.com too. - **Domain omitted:** the cookie is host-only, returned only to the host that set it, not to its subdomains. - **Limits:** the value must be the server's own domain or a parent of it, never a sibling (shop cannot set a cookie for blog) and never a public suffix such as `com`, `co.uk` or `github.io`. Local storage, which some consent tools use as well, belongs to an origin: scheme, host and port. https://www.example.com and https://shop.example.com have separate storage, and so do http and https versions of the same host. ## When does sharing make sense? Sharing one choice across subdomains is reasonable when: - the same company is the controller on every subdomain; - the subdomains use the same categories and roughly the same tools; - the banner tells visitors that the choice applies to the listed sites; - withdrawal on one subdomain withdraws everywhere. Asking again is better when a subdomain is run by a different company (a franchisee, a partner shop on your domain), when it uses very different trackers (a marketing-heavy shop under a quiet documentation site), or when it targets a different audience. Consent under the [GDPR](/laws/gdpr) must be specific and informed; a choice made on docs.example.com does not inform anyone about advertising on shop.example.com if the banner never mentioned it. ## How do you share consent across subdomains? If your consent tool lets you set the cookie domain, set it to the parent domain on every subdomain, use the same configuration and categories everywhere, and make sure the banner text names the scope ("Your choice applies to example.com, shop.example.com and blog.example.com"). The numbered steps below the article walk through it. Two technical traps: 1. **Duplicate cookies.** If the tool used to store a host-only cookie and now stores a domain cookie with the same name, the browser sends both. Clear the old one on deployment or rename the cookie, otherwise visitors may see a stale choice. 2. **Different versions.** If one subdomain runs a newer banner version with an extra category, a shared choice made under the older version does not cover the new category. Ask again for the new purposes. ## What about separate domains? Cookies cannot cross registrable domains. example.com cannot set or read a cookie for example.de or example-shop.com. Approaches that used to work, like a hidden iframe from a central domain, rely on third-party cookies, which Safari and Firefox restrict and which privacy settings often block. Two workable options: - **Ask on each domain.** The simplest and most transparent. Each domain has its own banner, log and policy. - **Pass the choice in a link.** When you link from one domain to another, the destination can read a parameter in the URL and store the same choice locally, if the visitor followed your own link. This is more work and must not carry identifiers that track the visitor. For most businesses, asking once per domain is the right trade: visitors rarely move between country domains, and the consent record stays simple. ## How do you test it? Clear all site data for the parent domain, open www, choose Reject all, then open each subdomain in the same browser. With sharing, no banner should appear and the trackers should stay off. Check in the Application panel that the consent cookie has the parent domain in its Domain column. Then withdraw on one subdomain and check the others. [Checking cookies before consent](/guides/check-cookies-before-consent) has the full DevTools routine. ## What goes in the consent log? Record which host the choice was made on and which hosts it covers. If you keep [consent records](/guides/how-long-to-keep-consent-records) per site, make sure a choice made on one subdomain can be traced when an authority asks about another. ## How Cookiequiet handles subdomains Cookiequiet stores the choice in a first-party cookie on the exact host, plus local storage, so each subdomain and each domain asks once, which is the conservative default. Paid plans let extra domains (www, staging, country domains) sit under one website, with one configuration and one consent log: 1 on Starter, at €3 per website per month, and up to 5 on Pro, at €9. Setup is one script tag on each host, before your other scripts; see [pricing](/pricing) for what each plan includes. ## Questions ### Does consent on www.example.com apply to shop.example.com? Only if the consent cookie was set for the parent domain and the banner told visitors the choice covers the shop. A host-only cookie stays on www, so the shop asks again, which is also the safer default when the subdomains use different tools. ### Can I share consent between example.com and example.de? Not with a cookie. Browsers never let one registrable domain set or read cookies for another. Ask on each domain, or pass the choice through your own links and store it again on arrival. ### Is local storage shared between subdomains? No. Local storage belongs to one origin, meaning one scheme, host and port. Each subdomain has its own, so a choice saved only in local storage is not visible on other subdomains. ### Do I need one consent log per subdomain? Not necessarily, but each record should show the host where the choice was made and the hosts it covers. That lets you prove consent for any subdomain an authority asks about. ## Sources - [MDN Web Docs, Set-Cookie header: the Domain attribute](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie) - [MDN Web Docs, Window: localStorage property](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) - [MDN Web Docs, Same-origin policy (definition of an origin)](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) - [Regulation (EU) 2016/679 (GDPR), articles 4(11) and 7](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - [WebKit, Full third-party cookie blocking and more](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/)