Magento Open Source and Adobe Commerce allow merchants to manage several websites, stores and store views from one Commerce installation. Depending on the deployment, those storefronts might appear as different paths on one hostname, as subdomains, or as entirely separate registrable domains. Adobe's website, store and store-view hierarchy supports all of these kinds of multi-storefront structures.
The browser, however, does not care that two storefronts belong to the same Commerce backend. A consent preference that is available on example.com/en/ may behave very differently when the visitor moves to shop.example.com or example.de.
A workable consent architecture therefore has to follow the hostnames visitors actually encounter, as well as the trackers running on them, their purposes and vendors, regional requirements, and browser behaviour.
Multi-storefront does not automatically mean multi-domain, and multi-domain does not automatically mean shared consent.
Why Multi-Storefront Consent Gets Complicated
Adobe Commerce uses a hierarchy of websites, stores and store views. Websites sit at the upper Commerce level; stores commonly define catalogue structures through root categories; store views are often used for language, currency or regional presentation. Different views and websites can also have different base URLs.
That hierarchy does not map neatly onto browser boundaries.
Consider three deployments:
example.com/en/
example.com/de/
versus:
uk.example.com
de.example.com
versus:
example.co.uk
example.de
The first uses paths on one hostname. The second uses subdomains under a shared registrable domain. The third uses separate registrable domains.
Commerce can manage all three patterns, but the browser does not treat them as equivalent. Consent configuration therefore needs to follow both the Commerce hierarchy and the browser-facing hostname structure.
Same Hostname, Subdomain Or Separate Registrable Domain?
For:
example.com/en/
example.com/de/
the visitor remains on example.com. Subject to cookie path and other attributes, browser-side state can normally remain available while the user moves between those paths.
Now compare:
shop.example.com
outlet.example.com
These are different hosts, although both sit beneath the registrable domain example.com. Cookies can sometimes be deliberately scoped so that matching subdomains receive them.
example.com and example.de are different registrable domains. A normal first-party cookie created for example.com cannot simply be made readable by example.de.
The currently published cookie model is defined in RFC 6265. Without a Domain attribute, a cookie is host-only. Where a valid Domain attribute is supplied, the cookie can be returned to matching subdomains. A site cannot use that attribute to grant itself cookie access to an unrelated registrable domain.
A leading dot such as .example.com is commonly shown in configuration interfaces, including Adobe's, but modern cookie matching does not depend on that dot itself.
The useful architectural distinction is therefore not simply “different domains”. It is:
- same hostname;
- subdomains of one registrable domain;
- separate registrable domains.
Those cases require different consent decisions.
How Cookie Scope Affects Consent
Adobe Commerce exposes cookie-related settings under Stores > Settings > Configuration > General > Web > Default Cookie Settings. Adobe's Cookie Domain documentation explains that the setting can affect the availability of applicable Commerce cookies across subdomains. Cookie Path controls the relevant path scope.
That can matter when Commerce itself operates across hosts such as:
shop.example.com
checkout.example.com
It does not make a cookie from example.com readable on example.de.
There is another boundary worth making explicit: Adobe's Cookie Domain field controls applicable Adobe Commerce cookies. It does not configure CookieScript's consent storage or automatically enable CookieScript consent sharing between storefronts.
Commerce cookie scope and CMP consent sharing are separate configuration layers.
The same caution applies to consent cookies generally. A cookie set only for shop.example.com does not automatically become available to outlet.example.com. If the implementation deliberately uses parent-domain scope and browser rules permit it, subdomain availability may be possible.
When Should Consent Actually Be Shared?
Technical capability is only half the question. The other half is whether the preference collected on Store A accurately describes the processing on Store B.
Suppose Store A uses:
- essential ecommerce functionality;
- analytics;
- basic conversion measurement.
Store B additionally uses advertising, personalisation and several extra third-party vendors.
A choice collected on Store A may not contain enough information to represent what the visitor is being asked to permit on Store B. Reusing it automatically could therefore create a misleading consent state.
Before grouping storefronts, compare:
- controller or business context;
- tracking technologies;
- processing purposes;
- vendors;
- cookie categories;
- regional rules and configuration.
CookieScript's current cross-domain consent guidance says participating websites should use the same cookies or other tracking technologies where consent is to be shared.
Ownership is not enough. In some architectures, separate consent states are cleaner and more accurate than forcing one preference across every storefront.
For EU-facing stores, Article 5(3) of the ePrivacy Directive remains central to storage or access on terminal equipment, subject to its exceptions. UK rules apply more broadly than HTTP cookies as well.
The ICO's current guidance on storage and access technologies covers technologies including cookies, web storage, tracking pixels, scripts and tags, and reflects the additional exceptions introduced by the Data (Use and Access) Act 2025. All of the Act's data-protection provisions were in force by 19 June 2026.
One universal consent configuration may therefore be inappropriate for every regional storefront.
Cross-Domain Consent In CookieScript
CookieScript documents a dedicated subdomain-sharing option as well as a broader cross-domain grouping feature, which can include subdomains or separate domains where the tracking environment is compatible.
Its subdomain consent configuration includes Remember Consent for Subdomains. CookieScript also recommends using separate banners where the cookies used on the subdomains differ.
For broader cross-domain sharing, CookieScript's cross-domain cookie consent guidance allows participating sites to be placed into a group so that compatible websites can share banner settings and consent. Current documentation states that cross-domain consent sharing requires the Plus plan.
Visual consistency should not be confused with shared consent state. Several storefronts can display banners that look identical without sharing the same stored preference, and centrally managed banners do not prove that each storefront has an identical tracking environment.
Browser Limitations And Cross-Domain Consent
Cross-domain consent is not purely an administration setting. The browser still matters.
CookieScript currently documents several user-side prerequisites for its cross-domain sharing feature. Third-party cookies must be permitted, Do Not Track must not be enabled, and the visitor must accept the Preferences category because CookieScript classifies its cross-domain-sharing storage item within that category.
Browser restrictions can still prevent sharing even when the websites have been grouped correctly. CookieScript's current cross-domain consent setup guidance documents limitations involving Safari, Firefox and many iOS/WebKit environments.
Those constraints are consistent with broader browser privacy changes. Safari's tracking prevention restricts Third-Party Cookies, while Firefox's Total Cookie Protection partitions cross-site cookie state.
A merchant may therefore configure the CMP correctly and still find that another storefront cannot automatically recognise the earlier preference in some browsers.
Consent Mode v2 And Tag Behaviour Across Storefronts
Google Consent Mode solves a different problem from cross-domain consent.
Cross-domain consent attempts to make an existing user preference available or recognisable across storefronts. Consent Mode communicates consent state to Google tags so that those tags can adapt their behaviour.
The four Consent Mode parameters most relevant to Google Ads and Analytics in this setup are:
analytics_storage
ad_storage
ad_user_data
ad_personalization
Google also defines other storage-related consent types, but those four are the core Ads/Analytics signals usually discussed in Consent Mode v2 implementations.
Every storefront where Google tags execute must handle its consent state correctly. A visitor's preference being recognised on example.de does not prove that the Google tag on that storefront received the corresponding Consent Mode state.
Google distinguishes Basic and Advanced Consent Mode. In Basic Consent Mode, Google tags are blocked before the visitor interacts with the consent mechanism; Google says no data is sent before that interaction, and if the visitor does not grant consent the tags remain blocked.
In Advanced Consent Mode, Google tags load with default consent states and adjust their behaviour after the visitor makes a choice. Under denied storage states, consent-aware tags can send measurements without cookies.
Consent Mode does not synchronise a preference between domains, and it does not replace the CMP.
Google Tag Manager Requires Its Own Verification
CookieScript's current Consent Mode v2 and Google Tag Manager instructions recommend its GTM template and specify Consent Initialization – All Pages for the CookieScript tag.
For the broader implementation context, Google Tag Manager and cookie consent need to be considered together: GTM controls tag deployment, while the consent setup determines whether those tags are permitted to run.
Enable Consent Mode v2 in the CookieScript banner settings, then configure the GTM implementation as Basic or Advanced as appropriate.
CookieScript also instructs merchants to use only one CookieScript installation method. If moving to a GTM-based installation, remove the manually installed CookieScript code rather than running both implementations in parallel.
This GTM installation route does not apply to geo-targeted CookieScript code. CookieScript requires geo-targeted installation code to be placed directly in the site's <head>, as discussed below.
Tags outside GTM need attention too: advertising pixels, ecommerce tracking, custom scripts and embedded marketing technology can bypass a correctly configured GTM container.
Recognising consent is one problem. Enforcing it is another.
Script Blocking Is Part Of The Architecture
CookieScript's third-party cookie and script blocking documentation highlights several implementation points that are easy to miss.
Automatic third-party cookie blocking is not something to assume is active merely because the banner appears. Where automatic blocking is used, CookieScript needs to load early enough to intercept the relevant browser-side scripts. The same third-party script should not be managed simultaneously through conflicting CookieScript and GTM blocking logic.
There is also a technical boundary: JavaScript running in the page cannot automatically prevent every cookie created by an HTTP response header. Server-set state may require controlling the request or service that produces it rather than relying on browser-side script blocking.
This matters in Commerce deployments where analytics, personalisation or marketing technologies are mixed across frontend JavaScript, tag managers and server-assisted services.
Self-Hosting The CMP Script In A Multi-Storefront Commerce Deployment
Where the CMP script is served from can matter in a Magento or Adobe Commerce setup. CookieScript allows paid-plan customers to download and self-host the cookie banner JavaScript file on their own server instead of relying on the standard externally hosted script.
When Self-Hosting Can Help
For multi-storefront merchants, self-hosting can be useful when:
- JavaScript assets need to remain under the organisation's infrastructure control;
- teams want greater control over deployment and caching;
- reducing dependence on third-party-hosted resources is desirable.
Self-hosting can therefore fit naturally into an Adobe Commerce deployment where storefront assets are already managed through a controlled release process.
What Self-Hosting Does Not Change
Self-hosting does not change browser domain boundaries or replace cross-domain consent sharing. Script delivery, cookie scope and consent sharing remain separate parts of the architecture.
Two Operational Limitations
1. Updates become part of release management.
A self-hosted CookieScript file does not receive automatic updates. Merchants need to download and redeploy updated code when the banner configuration or relevant functionality changes. In a multi-storefront deployment, keeping the CMP version consistent across participating storefronts should therefore be part of the release process.
2. geo-targeting requires the hosted implementation.
CookieScript geo-targeting does not work with the self-hosted JavaScript file because geographic detection relies on CookieScript's service. Merchants that need geo-targeted consent behaviour should use the hosted implementation documented for that feature.
Edge Cases: Headless Storefronts, Checkout Domains And Regional Stores
Headless Adobe Commerce, PWAs and custom JavaScript frontends change where browser-side code actually executes. A checkout can also move users to another hostname, while a payment provider may move them to a domain the merchant does not control.
Keep asking:
On which hostname does browser-side tracking execute, and where must the consent state be available?
A CMP installed on the merchant storefront cannot directly control arbitrary scripts running on a third-party page where its code is absent.
Moving measurement server-side does not automatically remove privacy obligations either. If browser-side code still stores or accesses information on the user's device, Article 5(3) of the ePrivacy Directive or Regulation 6 of PECR can still apply. Personal-data processing can also remain subject to GDPR or UK GDPR independently of where a server component runs.
Likewise, cookieless does not automatically mean consent-free. Current ICO guidance covers storage and access technologies beyond HTTP cookies, including web storage, pixels, scripts and tags.
Regional Storefronts
Regional stores may require different consent behaviour even when their branding and Commerce backend are shared.
CookieScript documents geo-targeted consent configuration. Its current guidance contains an important implementation restriction: geo-targeted CookieScript code should be installed directly in the site's <head> rather than through Google Tag Manager, because GTM deployment can interfere with location detection and banner selection.
For applicable US storefronts, browser-level privacy signals belong in the architecture as well. The California Attorney General states that covered businesses must treat Global Privacy Control as a valid request to opt out of sale or sharing where the law requires it. CookieScript provides a corresponding GPC configuration option.
Managing The Wider Consent Setup With CookieScript
CookieScript operates in the consent-management layer rather than the Adobe Commerce architecture itself. In this setup, CookieScript can support the banner, consent handling, tracker controls, regional configuration and consent recording described throughout this guide.
Visitor consent recording should remain conceptually separate from browser-side preference sharing. A storefront recognising the same preference is not, by itself, proof that an adequate consent audit record exists.
CookieScript's Help Centre currently documents a 14-day Plus trial without requiring a credit card.
Other Useful CookieScript Capabilities
Self-hosting is one part of the wider Consent Management Platform (CMP) setup. Multi-storefront deployments can also use:
- Google Consent Mode v2 for communicating consent states to Google services.
- Google Tag Manager integration for managing consent-aware tag deployment.
- The Cookie Scanner for identifying cookies and other tracking technologies across storefronts.
- Consent recording for maintaining records of visitor consent choices.
- Third-party cookie and script blocking for controlling non-essential technologies according to consent.
- Global Privacy Control for responding to supported browser privacy signals.
- Cross-domain cookie consent for compatible storefronts that need to recognise consent across domains.
- IAB TCF 2.3 integration for advertising environments using the IAB Transparency & Consent Framework.
- The CookieScript API for programmatic consent-management workflows.
CookieScript is listed by Google as a certified CMP and also describes itself as holding Gold-tier status.
Magento / Adobe Commerce Implementation Workflow
A practical implementation sequence is:
- Map the Commerce hierarchy. Record every website, store and store view together with its base URL.
- List the real hostnames. Include storefronts, checkout hosts, headless frontends and other browser-facing endpoints.
- Classify each boundary. Separate same-host paths, subdomains and separate registrable domains.
- Inventory tracking by storefront. A Cookie Scanner can support discovery, but also inspect local storage, network requests, pixels and scripts manually.
- Compare purposes, vendors and categories. Decide where an existing preference genuinely describes the same processing.
- Configure banner grouping and consent sharing accordingly. Use subdomain functionality for suitable subdomain cases and documented cross-domain sharing where broader sharing is appropriate.
- Verify blocking on every storefront.
- Validate Consent Mode and GTM independently.
- Test browsers, regions, consent changes and withdrawal.
- Verify consent-recording requirements where relevant.
A merchant might run:
shop.example.com
outlet.example.com
example.de
The first two share the registrable domain example.com and may be candidates for appropriate subdomain consent configuration if their tracking environments are compatible.
example.de crosses a registrable-domain boundary, so any shared preference requires the documented cross-domain mechanism described above, together with the relevant browser, regional, vendor and purpose checks.
Testing The Complete Consent Journey
Test actual browser behaviour, not merely CMP dashboard settings.
Cover:
- first visit with no stored preference;
- accept all;
- reject non-essential processing;
- category-level selections where supported;
- navigation between same-domain paths;
- movement between subdomains;
- movement between separate registrable domains;
- changing consent on one storefront and returning to another;
- withdrawing consent;
- private/incognito browsing;
- Chrome, Safari, Firefox and iOS/WebKit;
- regional banner behaviour;
- GTM's current consent state;
- all relevant Consent Mode signals;
- whether blocked scripts remain blocked;
- whether permitted tags fire only when allowed;
- checkout and post-purchase pages on other hostnames.
Google's Tag Assistant consent debugging guidance can help verify Google tags. Also inspect cookies in the browser, browser storage and network requests directly.
A passing test in one browser does not prove the consent journey works everywhere.
Conclusion
A coherent Magento or Adobe Commerce CMP setup starts by mapping Commerce hierarchy, hostname boundaries, tracking behaviour and consent context together.
Paths on one host, subdomains and separate registrable domains are not interchangeable. Neither are banner appearance, shared consent preferences, Consent Mode signals and consent records.
Configure each layer deliberately, then test the complete journey in real browsers.
Frequently Asked Questions
Can one Cookie Banner cover multiple Magento storefronts?
That depends on the deployment and the tracking environment. Storefronts can share centrally managed settings, and CookieScript documents cross-domain banner and consent grouping for compatible websites. A common banner design does not automatically mean that one consent state is appropriate everywhere.
Can consent be shared between Magento subdomains?
For suitable subdomains, yes. shop.example.com and checkout.example.com share a registrable parent domain, and CookieScript provides subdomain consent configuration. If the trackers or cookies differ materially, separate consent configurations may be more accurate.
Can one domain read another domain's consent cookie?
Not across unrelated registrable domains. A normal First-party cookie for example.com cannot simply be read by example.de. If the preference should be recognised across those domains, use a documented cross-domain consent mechanism.
Does Adobe Commerce's Cookie Domain setting enable cross-domain consent?
No. Adobe's Cookie Domain configuration controls the scope of applicable Commerce cookies. It does not make cookies from example.com readable by example.de, nor does it configure a CMP's separate cross-domain consent feature.
Does Google Consent Mode v2 share consent between domains?
No. Google Consent Mode communicates consent state to Google tags. The preference has to be collected and, where appropriate, recognised on the second storefront through the consent architecture itself.
Does CookieScript support cross-domain consent?
CookieScript currently documents cross-domain consent sharing for compatible websites grouped across separate domains. Its current documentation states that the feature requires the Plus plan and is subject to browser restrictions and user-side prerequisites.
Why can cross-domain consent behave differently in Safari or Firefox?
Cross-site state is increasingly restricted or partitioned by browsers. CookieScript's cross-domain setup guidance documents limitations involving Safari, Firefox and many iOS/WebKit environments. A configuration working in Chrome therefore does not prove that the second storefront can recognise the same preference everywhere.
Should consent be shared between regional storefronts?
Only when the underlying consent contexts are sufficiently compatible. A regional store may use different vendors, purposes or privacy frameworks. CookieScript geo-targeting can support region-specific banner behaviour, but the merchant still needs to decide what consent model accurately reflects each storefront.