How should a consent banner handle subdomains and the Shopify checkout?
A consent choice made on the storefront should follow the visitor to the blog subdomain and into checkout, but it usually does not. Subdomains store consent separately, and the Shopify checkout is platform-controlled. The fix is a consent map of every domain and subdomain, shared consent state where the platform allows it, and a tested journey that proves the choice survives each hop.
Why subdomains break consent
Consent state typically lives in a cookie or local storage scoped to the domain that set it. A choice made on the store does not automatically exist on the blog subdomain or the help center subdomain. Each one shows its own banner, asks again, and may record a different answer.
That is more than an annoyance. If the visitor rejected optional cookies on the store but the subdomain loads analytics by default, the store is collecting data the visitor refused. The violation is real even though no one intended it. Subdomain consent has to be designed, not assumed.
The checkout hop is the hard one
On Shopify, checkout runs on a platform-controlled domain path. The store's consent banner does not run there, and the store cannot inject its consent logic into checkout. Whatever the visitor chose on the storefront, checkout behaves according to the platform's own rules and the store's checkout settings.
This is a document-and-configure situation, not a code situation. Review what the platform does with tracking in checkout, configure the available privacy settings, and write down exactly what happens to the visitor's choice at each step. The goal is a true statement of the journey, not a wish.
Share consent state where you can
Between subdomains the store controls, share the consent state. Set the consent cookie at the parent domain level so subdomains read the same choice, and make sure every subdomain's banner respects a choice already made instead of asking again. One choice, recorded once, honored everywhere.
Test the sharing in both directions. Set the choice on the store and check the subdomain; set it on the subdomain and check the store. Consent state that only syncs one way will eventually produce a subdomain running the opposite of what the visitor chose.
Draw the consent map
List every domain and subdomain the brand operates: store, blog, help center, landing pages, regional stores. For each, note which banner runs there, where its consent state is stored, and whether it shares state with the others. Gaps in the map are where violations hide.
Include the tools, not just the pages. Tag managers, analytics, ad pixels, and heatmaps each need to be gated by the same consent state. A map that covers pages but not tools is decoration. The map should be ugly and complete, not pretty and partial.
Test the full journey like a visitor
Walk the journey end to end in a fresh session: land on the store, reject optional cookies, visit the subdomain, proceed to checkout. At each step, check which cookies and storage entries exist and which network requests fire. The test is only as good as its freshness, so use a clean profile every time.
Run the journey twice, once accepting and once rejecting. The accept path confirms the tools load; the reject path confirms they do not. Most stores test the accept path and assume the reject path mirrors it. It often does not, especially across the subdomain boundary.
Recheck after every structural change
New subdomain, new landing page tool, new checkout setting: each one can silently break the consent journey. Tie a consent recheck to the same change process that governs deploys. If it touches a domain, it gets a consent walkthrough.
Keep the consent map with the site documentation, not in someone's head. When the map is written down, the next person to add a subdomain inherits the requirement instead of rediscovering the violation.