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.

Cookiebot Alternatives Compared Side by Side

November 2, 2026

A side by side way to judge consent platform alternatives: scanning, blocking, records, pricing shape, and the migration questions that decide whether a switch sticks.

Comparison tables for consent platforms all look the same because vendors supply the rows. Every box is ticked, every regulation is listed, and the tools appear identical until you run them on a real site and watch what they miss. A useful comparison has to be built from tests you ran yourself: the same heavy page scanned by each candidate, the same decline clicked in each banner, the same record exported and read. Anything less is comparing brochures.

Build the table around five rows that decide whether a switch succeeds: scanning depth, blocking behaviour before consent, consent record quality and export, pricing shape at your traffic, and migration handling of existing choices. Add a sixth row for the thing your team kept complaining about with the current tool, because a switch that does not fix the original complaint will be re-litigated within a year.

Run the same tests on every candidate

Use one test page per candidate: a product page carrying video, reviews, a chat widget, and payment elements, plus a checkout page if the platform supports it. Record what the scanner found, what it misclassified, and what it missed entirely, especially anything that loads after a click or a scroll. Scanners differ most exactly there, in the interaction loaded scripts, and a demo on a static homepage hides the difference completely.

Then do the decline test in each tool. Load the page fresh, decline everything you can decline, and watch the network and the tag manager. Which tags fired anyway? Which third parties were contacted before the choice? A platform that looks rigorous in its dashboard and still lets marketing tags fire on decline has failed the only test a regulator would care about, and your table should say so in plain words, not stars.

Records and pricing, the rows vendors soften

For records, export a single consent from each candidate and read it like an investigator. Timestamp, categories, banner version, mechanism, identifier. If the export needs a support ticket or arrives as an unreadable dump, score it down and write why. The day you need that record will be a bad day; a platform that makes it slow is choosing your bad day for you.

For pricing, model the same three traffic months in every tool: a normal month, your peak month, and the plan for next year. Pageview models, domain models, and feature tier models cross over each other as traffic changes, and the cheapest tool in a quiet month is regularly the most expensive in December. Write the annual figure at your real shape in the table, not the entry price from the pricing page.

Score migration before you sign anything

Ask each candidate, in writing, how existing consent choices are handled: import, honour through a cookie that carries the prior state, or a planned re-ask of all visitors. Any of the three can be right. What cannot be right is discovering the answer after launch, when declines from the old platform have been forgotten and shoppers who opted out are being tracked on a default they never chose.

Finish the comparison with a weighted call, not a tie. Weight blocking and records above banner design, because design can be restyled in a quarter and records cannot be rebuilt after the fact. Then keep the losing candidates' test notes. Consent tooling changes fast, and next year's review starts from your own evidence instead of from three fresh brochures.

Frequently asked questions

What is the fairest way to compare consent platforms?

Run identical tests on each: scan the same heavy page, perform the same decline and check which tags fire, export one consent record and read it, and model pricing at the same traffic months. Vendor feature tables are a starting list of questions, not evidence.

Which feature matters most in the comparison?

Blocking before consent, verified by watching tags and network calls after a decline, then record quality. A platform can have an excellent banner and still fail the core job if marketing tags load regardless of the shopper's choice.

How do alternatives differ on pricing?

Some charge by pageview, which scales with success and spikes; some charge by domain or a flat tier; key features like consent mode, APIs, or multiple languages often sit in higher tiers. Compare annual cost at your peak and at next year's expected traffic, not the entry month price.

What migration question decides a switch?

Whether existing consent choices are imported or honoured, or whether every visitor will be re-asked, and whether that outcome is deliberate and documented. A switch that silently forgets prior declines creates a compliance problem on day one, whatever the new banner looks like.