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.

Auditing Consent After a Site Migration: What Breaks When the Platform Changes

October 30, 2026

Migrations reset consent cookies, reorder tag firing, and drop the consent record integration, while everyone is watching design and redirects. A post migration consent audit checklist.

Nobody migrates a store planning to break consent. It breaks anyway, by side effect. Consent choices are commonly stored in a cookie or local storage under the old platforms keys, so after migration every returning customer looks like a stranger and gets re prompted, or worse, the new setup defaults to firing tags while it waits for a choice the customer already made last year.

Meanwhile the teams attention is on redirects, design parity, and checkout. Consent is a paragraph in the go live checklist, signed off because the banner appears. Appearing is not the test.

What migrations typically break

Firing order is the big one. The tag manager container on the new platform is often rebuilt quickly, and consent mode defaults or the sequencing between the banner tool and the container get inverted: tags load first, consent state applied afterwards. On the old site the order was tuned over years. On the new site nobody tuned it at all, because nobody knew it had been.

Records are second. The integration that wrote consent events into the stores record system was frequently custom code on the old platform. If it was not on the migration spec, it did not move, and the store discovers months later that it has banner interactions it cannot evidence for the entire post migration period.

The audit, in order

First, with a clean browser profile, load key templates and record what fires before a choice. Second, make each choice in turn, accept, reject, partial, and verify both the firing behaviour and the record written, including timestamp and the disclosure version. Third, return as a previous customer would: check whether a choice made before migration, where it can be carried over, is honoured or at least handled deliberately, with re prompting that explains nothing is broken on the customers side.

Fourth, test withdrawal and the preference centre on the new platform, and confirm suppression reaches email and ads tooling, not just the banner. Fifth, repeat the firing check in the checkout and any third party hosted steps, which migrations frequently replatform without telling the consent owner.

Put consent on the migration spec next time

The lasting fix is procedural. Consent belongs in the migration requirements as its own workstream: banner configuration, firing order, record integration, historical record retention, and an audit slot two weeks after go live, when real traffic patterns show the problems a staging site could not.

Old consent records must be retained through the migration, not archived into a system nobody can query. A complaint about a send from before the move still needs its evidence after the move.

Frequently asked questions

Why do customers get re prompted after a migration?

Consent choices are often stored under platform specific cookies or keys that do not transfer. Treat re prompting as expected, plan the messaging, and never treat the absence of a stored choice as consent to fire tags.

What is the most serious migration consent failure?

Tags firing before consent is applied, usually because firing order or consent defaults changed when the tag manager was rebuilt. It can affect every visitor from go live until it is caught.

What should a post migration consent audit check?

Pre choice tag firing, the behaviour and record for each consent choice, returning customer handling, withdrawal end to end, and hosted checkout steps.

Should old consent records be kept after migrating?

Yes, in a queryable form. Complaints and regulator questions can concern sends and consent given before the migration, and that evidence must survive it.