Consent State Across Subdomains: Why Your Banner Keeps Coming Back
The complaint is always the same. A returning visitor accepted cookies last week and the banner greets them again on the store, again on the help center, and again on the app subdomain, so they start clicking Accept blindly just to make it stop.
Banner fatigue is a compliance problem, not just an annoyance. A user trained to accept instantly is not making a considered choice, and the cause is usually a cookie scoped wrong by one attribute.
The Domain attribute decides everything
Set a cookie without a Domain attribute and it is host only: the browser returns it solely to the exact host that set it. The consent platform on www.example.com stores the choice, shop.example.com never sees it, and the banner renders fresh. Setting Domain=example.com makes the cookie readable across subdomains, and one choice follows the user.
Check the path too, though it rarely bites: consent cookies belong at path=/ so every route can read them. Then check for the opposite bug, two platforms writing competing consent cookies on different scopes, so the state flips depending on which subdomain the user entered through.
When separate consent per subdomain is actually right
Subdomains that are genuinely different services, a customer portal with its own privacy notice, a separately branded product, a regional entity acting as its own controller, deserve their own consent capture. The legal object is the notice the user saw and the controller they agreed with, not the cookie mechanics.
The failure mode to avoid is accidental separation: the same site, same notice, same controller, re prompting purely because of cookie scope. That is the case to unify. One more wrinkle worth checking while you are in the configuration: single sign on and chat widgets often set their own cross subdomain cookies independently, and a consent state that covers the main site but not the support widget produces the same re prompting complaint from a different door. Deliberate separation should be documented in the consent configuration, with each subdomain listed and its controller named.
What breaks when you unify
Merging consent across subdomains merges the purposes too. If the store runs advertising trackers the help center never had, a single shared consent means help center visitors agreed to a purposes list written for the store. Rebuild the category list as the union of what fires across the unified scope, disclose all of it, and re prompt once at launch. One more prompt now is cheaper than a disclosure that was never true.
Related reading
These earlier guides cover connected questions in more depth: Consent State Across Subdomains: Why Your Banner Keeps Coming Back, Consent Logs in a Data Breach: What Your Banner Records Expose, and Testing Consent Banners Across Browsers and Devices: A Working Checklist.
Frequently asked questions
Why does the banner reappear on our shop subdomain?
Almost always a host only consent cookie. If the cookie was set without Domain=example.com, the shop subdomain cannot read it. Set the domain attribute, use path=/, and clear the old host only cookie to avoid conflicts.
Does one consent legally cover all subdomains?
It covers the scope of the notice shown: same controller, same purposes, same disclosure. Distinct services or controllers on other subdomains need their own capture even if the cookie could technically be shared.
Should consent be stored in local storage instead?
No. Consent records belong server side with the cookie or storage on the client acting as the state flag. Local storage also falls under the same ePrivacy storage rules in Europe, so it changes nothing legally.
How do we handle users who accepted before we unified subdomains?
Honor the existing choices where they can be read, and re prompt only the users whose recorded purposes do not cover the unified category list. Log the migration date and the notice version change.