Why does a consent banner reappear on a subdomain?

Usually because the consent cookie was set as host only, so other subdomains cannot read it, or because the CMP is configured differently on that host. Each subdomain looks correct alone, which is why a cross domain test with one browser session is needed to find it.

What cookie scope lets subdomains share consent state?

The consent cookie generally needs its domain attribute set to the registrable domain, with appropriate path and security flags, so sibling subdomains can read it. Exact configuration depends on your CMP and security policy, and should be tested in production.

Should every subdomain show the same banner?

The experience should be consistent, but the key requirement is shared state, not identical pixels. A visitor's recorded choice and preferences must be readable and honoured on every host they reach in a session.

How often should cross subdomain consent be audited?

After any CMP, checkout, or domain change, and on a recurring automated check. Deployments on a single host are the common trigger for a break that only appears when a visitor crosses between subdomains.

Consent Banners on Error Pages, Search Results, and Pages Nobody Designed

November 3, 2026

The banner was configured on the homepage template and behaves differently, or not at all, on 404s, search results, and legacy pages. Testing consent where the design system does not reach.

A visitor who lands on a broken link meets a 404 page, a search box, and, if the configuration only covered the main templates, either no consent banner at all while trackers load, or a banner in a style the site retired two redesigns ago. Error pages, internal search results, and old campaign pages are the parts of a site that inherit code rather than receive design, and consent inherits with everything else.

That neglect matters for a simple reason. A 404 is often an entry page, not an exit. Paid and organic links rot, old URLs circulate, and a meaningful share of first visits can begin on an error page. A visitor whose first page loads trackers before any choice has been offered has had their consent handled worst at exactly the moment it was first required.

Find the templates the design forgot

Inventory the odd templates directly: the 404, the 500, internal search results, the empty search results variant, password reset, unsubscribe confirmation, print views, and any legacy landing pages still receiving traffic. For each one, load it fresh, with no prior consent state, and record whether the banner appears, whether it works, and which tags fire before a choice is made.

Legacy landing pages are the highest risk in the set. They were built for a campaign, often with their own hard coded tags outside the tag manager, and they stay live and indexed long after the campaign ends. A consent platform cannot block a tag it does not manage, so those pages need their hard coded tags found and dealt with individually, not assumed into compliance.

Search results pages carry query data

An internal search results page puts the visitor's query in the URL and usually in the page title. Loading advertising and analytics tags there sends that query to third parties. Most of the time the query is a product name and the exposure is minor. Sometimes a visitor searches a site for something personal, a health product, a legal topic, a debt service, and the calculus changes entirely.

Check what the consent state on results pages actually permits, and whether query strings are stripped or retained in what is shared. Site owners are often surprised to learn their analytics has been collecting a verbatim list of everything visitors searched for, including searches that found nothing, which is a second useful dataset and a first order privacy question at the same time.

A banner that appears but does not work is worse

On inherited templates the most deceptive failure is a banner that renders but whose buttons do nothing, because the script it depends on is not loaded on that template, or a consent mode integration is missing so choices are recorded and ignored. Test the buttons on every odd template, refuse, accept, and open preferences, then reload and check both the banner behaviour and the tags.

Finding this on a 404 is almost a favour. It reveals that banner testing has only ever happened on the pages the team visits themselves, and the fix is to add the odd templates to the standard consent test list permanently. Every site has a long tail of forgotten pages. The consent system has to work there too, or the honest statement is that it works on the pages someone remembered.

Frequently asked questions

Why do error pages have consent problems?

Because they inherit code rather than receiving design attention, so the banner may be missing, out of date, or present but non functional, while trackers still load. Since broken links make 404s a common entry point, the failure hits first visits.

What pages should a consent audit include besides main templates?

The 404 and 500 pages, internal search and empty results pages, password reset, unsubscribe confirmations, print views, and any legacy campaign landing pages still receiving traffic.

Why are internal search results pages a privacy concern?

Because the visitor's search query is usually in the URL and title, and third party tags on the page can send it onward. Queries can be personal even on a retail site, and analytics may be retaining them verbatim.

Can a banner appear but still fail?

Yes. On inherited templates the buttons may not work or choices may be recorded without being honored, if the scripts the banner depends on are absent. Testing has to exercise refuse and accept on each template and verify tag behaviour afterwards.