Consent State Should Survive the Subdomain Hop
A visitor accepts your banner on the main site, clicks through to the help centre, the booking flow, or the shop, and gets bannered again. Then again on the blog. Each prompt is legal in isolation and maddening in sequence, and the cause is almost never policy. It is cookie scope: the consent cookie was set on one host, or with a path or domain attribute that the next subdomain cannot read, so every property in the family treats a known visitor as a stranger.
Consent fatigue is usually described as a design problem. Half the time it is a scoping bug. People do not hate making the choice. They hate making the same choice four times in one session because four subdomains could not share one record of it.
Set the cookie where the family can read it
A consent cookie intended to cover subdomains must be set with the registrable domain as its Domain attribute, so www, help, shop, and blog all read the same value. A host only cookie, set by default when no Domain attribute is given, belongs to the exact host that set it. That default is the single most common reason multi subdomain sites re-prompt, and it survives code review because the banner works perfectly in testing on the one host the tester used.
Path and expiry matter too. A consent record scoped to a subpath, or expiring at session end while the banner promises to remember the choice for six months, produces the same re-prompt complaint with a different root cause. Test the record, not the banner: set a choice, then read the cookie from each subdomain and confirm value, scope, and expiry all match the promise the interface made.
One record, or genuinely separate choices?
There is an honest design question underneath the bug. A single shared record assumes the visitor's choice means the same thing on the blog and the checkout, which holds when the same trackers run everywhere. Where a subdomain runs materially different processing, a separate, explained choice can be right. The difference is intent. A deliberate second prompt that says why it is asking again is a consent flow. An accidental one caused by a missing Domain attribute is a defect wearing the same clothes.
Whatever you decide, withdrawal must travel the same distance as consent. If one record covers four subdomains, the reject and the later opt out must be honoured on all four. A shared accept with a per site reject is the asymmetry regulators notice first, and it is hard to explain as anything other than what it is.
Test the journey a visitor actually takes
Banner testing usually stops at the homepage. Test the cross subdomain journey instead: land on a blog post from search, choose, follow a link to the shop, complete a purchase, visit the help centre. Count the prompts. The count should be one, or a number you chose on purpose and can defend in a sentence.
Log the consent cookie's attributes in the test evidence, not just screenshots of banners. When the re-prompt complaint arrives, and it will, the difference between a team that can show scope and sync behaviour in an afternoon and a team starting from the banner code is the difference between a fix and an investigation.
Related reading: Consent for Chat Widgets: The Conversation Starts After Permission, Consent for A/B Testing Tools: The Experiment Starts After the Opt-In, Consent on Newsletter Signup Forms Is Not the Cookie Banner.
Frequently asked questions
Why do visitors get the cookie banner again on every subdomain?
Usually cookie scope. If the consent cookie is host only, which is the default without a Domain attribute, subdomains cannot read it, so each one prompts as if the visitor were new. The banner works, the record does not travel.
How should a shared consent cookie be scoped?
Set it on the registrable domain so all subdomains read the same value, with a path of the whole site and an expiry matching what the banner promises. Then verify by reading the cookie from each subdomain, not just the one that set it.
Should one consent choice really cover every subdomain?
When the same processing runs everywhere, yes. Where a subdomain does materially different processing, a separate choice can be justified, but it should be deliberate and explained in the prompt, not an accidental repeat.
Does an opt out need to apply across subdomains too?
Yes. Withdrawal must travel as far as consent did. A shared accept paired with per site rejection is an asymmetry that is difficult to defend, and trivially visible to anyone testing the journey.