Your Banner Keeps Coming Back Because the Consent Cookie Died
A reject control fails review on three measurable things: it takes more steps than accept, it is visually demoted to a link or a low contrast grey while accept is a filled button, or its wording obscures what it does. All three are checkable from a screenshot, which is why regulators check them first.
When a banner reappears for returning visitors, check three things first: the consent cookie's lifetime, whether the browser blocked it, and whether its domain scope covers the subdomain being visited. A consent cookie set for 30 days on the main domain will not be read on a shop subdomain, and the banner will ask again on every visit to that subdomain.
The three causes, in order of frequency
Expiry first. Consent cookies are often set with a short lifetime by default, sometimes 30 days, sometimes a session. A session cookie dies when the browser closes, so the banner returns every morning. The consent record says the visitor chose; the browser no longer carries the proof, so the site asks again.
Scope second. A cookie set without an explicit domain attribute belongs only to the host that set it. A visitor who consents on the main site and then visits the shop, the support portal, or the blog on a different subdomain gets asked again, because the consent cookie is not shared. Blocking third: some browsers and extensions block the consent cookie itself, and some visitors clear cookies on exit by choice, in which case the banner returning is correct behavior, not a bug.
Setting lifetime and scope deliberately
Set the consent cookie lifetime to match your stated renewal interval. If the policy says consent is renewed after 12 months, the cookie should live 12 months, not 30 days. A mismatch between the policy and the cookie lifetime means the site re asks sooner than it promised, which trains visitors to click anything to clear the interruption.
Set the domain scope to the parent domain when subdomains share the same consent. Then test it: consent on the main site, visit each subdomain, and confirm the banner does not reappear and the consent state is the same. Test in a browser with tracking protection on, because that is the browser your most privacy conscious visitors use.
When reappearing is the right answer
A banner that returns after consent expires, after purposes change materially, or after a visitor clears their cookies is doing its job. The failure is a banner that returns on every visit for a visitor who consented last week on the same device. Telling those two apart is the diagnostic: check the cookie's presence and scope before touching the banner code.
Log the consent cookie's name, lifetime, and scope in the consent platform documentation. The next person to debug a reappearing banner will thank you, because the answer will be in the record instead of in a guessing session with the network panel.
Keep reading: The Reject Button Audit: Placement, Wording, and Colour Traps That Fail Review, Consent Renewal Intervals: When Asking Again Is Required and When It Is Just Nagging, and Banner Fatigue: Repeat Prompts Train Visitors to Consent to Anything cover the nearby cases in this series.
Frequently asked questions
How long should a consent cookie last?
As long as your stated renewal interval, commonly 6 to 12 months. The cookie lifetime and the policy statement should match; a 30 day cookie with a 12 month renewal policy re asks far too often.
Why does the banner appear on the shop but not the main site?
Scope. The consent cookie was set for the main domain only, so the shop subdomain cannot read it. Set the cookie domain to the parent domain and retest across every subdomain.
Can a browser block the consent cookie itself?
Yes. Tracking protection and cookie settings in some browsers block or clear cookies, including consent cookies. For those visitors the banner returning is correct, because the site has no record of their choice on that device.
Should withdrawing consent delete the consent cookie?
Withdrawing should record the new choice and update the cookie to the withdrawn state, not delete the evidence. The record needs the withdrawal timestamp, and the cookie needs to carry the new state so the banner does not re ask on the next page.