Cross-Domain Cookie Consent: How CookieTrust Syncs It Automatically

Introduction

You’re running multiple domains or subdomains: your main site at example.com, your shop at shop.example.com, and maybe a blog at blog.example.com. A visitor lands on your main site, accepts your cookie consent banner, then navigates to your shop. The banner appears again.

This happens because browsers restrict where data can be stored. The consent decision made on example.com isn’t accessible to shop.example.com by default, so your site shows the banner again. It’s a frustrating user experience that repeats across every domain boundary.

CookieTrust solves this automatically. When you add multiple domains to a single cookie configuration, we switch from origin-scoped storage to a first-party cookie that spans your entire domain network. Your user accepts consent once, and that decision follows them everywhere.

This guide explains why this problem exists, how CookieTrust fixes it, and how to set it up on your sites.

Why localStorage Fails Across Domains

The root cause is browser security. Browsers sandbox data storage by origin: each unique combination of protocol, domain, and port gets its own isolated storage space. This protects users from malicious scripts on one site accessing data from another.

When you store consent in localStorage on example.com, it’s locked to that exact origin. A visitor’s browser can’t read that same localStorage value from shop.example.com because they’re different origins, even though they’re both part of your business. The consent decision exists, but it’s invisible to your subdomain.

This design works perfectly for single-domain sites. You store consent once in localStorage, visitors see no banner on repeat visits, everyone’s happy. But it breaks immediately when you add subdomains:

• Root domain plus multiple subdomains (shop, blog, help, docs)
• Regional subdomains for different markets
• Separate applications running on different subdomains

The native browser solution exists: first-party cookies with a broad domain scope. A cookie set on .example.com can be read by example.com, shop.example.com, blog.example.com, and any other subdomain. The consent data is no longer locked to one origin; it travels with your user across your entire domain network.

How CookieTrust Handles Cross-Domain Consent

CookieTrust is context-aware about storage. When you configure a single domain, we store consent in localStorage because it’s simpler and faster. When you add a second domain to the same cookie configuration, we automatically switch to a first-party cookie with domain-zone scoping.

Here’s exactly what happens:

1. You configure example.com in your CookieTrust dashboard and deploy our script. Consent data is stored in localStorage.
2. You add shop.example.com to the same cookie configuration. CookieTrust detects multiple domains.
3. The next time consent is recorded (new visitor or existing visitor’s next interaction), our system switches from localStorage to a first-party cookie.
4. That cookie is scoped to the domain zone (.example.com), making it readable by all subdomains.
5. A visitor accepts consent on shop.example.com. That decision is written to the domain-zone cookie.
6. When the same visitor navigates to blog.example.com, your script reads the cookie, sees the consent decision, and suppresses the banner.

The consent data stored is identical whether you’re using localStorage or cookies. Only the storage mechanism changes. Your configuration, proof of consent, and audit logs remain the same.

What Gets Stored

CookieTrust stores minimal data: the visitor’s consent choices (accepted, rejected, or granular selections), a timestamp, and an optional visitor identifier. This data is the same whether it lives in localStorage or a cookie. The difference is scope. With localStorage, it’s locked to one origin. With a cookie, it flows across all subdomains in the same domain zone.

The data payload includes the consent state, the timestamp, and which domain triggered the action. This information displays the correct behavior on repeat visits and generates audit logs. All of this happens client-side.

Setting Up Cross-Domain Consent in CookieTrust

Setting up is straightforward because the storage switching happens automatically. You don’t need to change your implementation or toggle any special flags.

Step 1: Open your cookie configuration in the CookieTrust dashboard.

Navigate to your site settings and find the “Domains” section. This is where you’ll see your primary domain listed.

Step 2: Add additional domains.

Click “Add Domain” and enter your subdomain (for example, shop.example.com or blog.example.com). You can add as many subdomains as needed. CookieTrust will automatically detect that you have multiple domains and prepare to switch storage mechanisms.

Step 3: Deploy the same script on each domain.

Copy the CookieTrust embed code and place it on every domain you’ve configured. The script should be identical across all domains; it references the same SITE_ID. The snippet looks like this:

<script src="https://cmp.cookietrust.io/gdpr/autoblocker.umd.js"></script>
<script id="cookietrust-cmp" src="https://cmp.cookietrust.io/gdpr/[YOUR-SITE-ID]/latest/v2consent.js" async></script>

Replace [YOUR-SITE-ID] with your unique site identifier from the dashboard. Place this in the of your HTML, before any scripts that use cookies.

Step 4: Verify in browser DevTools.

Open your site in a browser and trigger a consent interaction (either accept or reject). Open DevTools, go to Application > Cookies, and look for a cookie with a domain scope like .example.com instead of example.com. This broad scope is what allows the cookie to be read by subdomains. You can now navigate between your domains and confirm the banner doesn’t reappear.

To verify it works, clear cookies, accept on shop.example.com, then visit blog.example.com in a new tab. The banner shouldn’t appear because the consent is now in the domain-zone cookie both can read.

Simplifying Multi-Domain Consent with CookieTrust

Building cross-domain consent manually is complex. You’d need to:

• Write custom code to detect when you’re on multiple domains
• Implement a server-side session or database to store and sync consent
• Build an API to query consent state from any domain
• Handle timezone differences, visitor IDs, and audit logging
• Manage CORS policies if domains are served from different servers
• Test across different browsers and consent states

Or, you can add two lines of code.

CookieTrust handles all of this. Our platform automatically detects when multiple domains are configured, switches your consent storage from localStorage to a domain-zone cookie, and ensures consent propagates instantly. No server-side code. No API calls. No infrastructure.

Here’s what you get:

• Automatic storage switching: Single domain uses localStorage, multiple domains use cookies, no configuration needed
• Cookie scoping: Consent cookies are automatically scoped to the domain zone, readable by all subdomains
• Instant consent propagation: Consent decisions sync immediately across domains
• Proof of consent: Full audit logs show when and where consent was given, across all domains
• Auto-blocking: Unwanted cookies are blocked until consent is given, even on subdomains
• WordPress integration: If you’re running WordPress, our plugin handles everything for you

We also provide a comparison of what you’d need to build versus what CookieTrust provides:

If you’re using WordPress, install our plugin from the WordPress plugin directory. It includes automatic consent syncing and requires no code at all.

Common Use Cases

E-commerce with shop subdomain: Your main site is at example.com, but checkout and product pages run on shop.example.com. When a customer accepts consent on your homepage, they won’t see the banner again on your shop.

SaaS with documentation and status subdomains: Your app is at app.example.com, your docs are at docs.example.com, and your status page is at status.example.com. A user agrees to analytics when logging into the app, and that choice follows them to your documentation and status pages.

Multilingual regional subdomains: You serve different languages on example.com, fr.example.com, de.example.com, and es.example.com. Consent given in one language region is recognized across all your regional sites. A user who accepts analytics tracking on the French version won’t be prompted again on the Spanish version.

Support and knowledge base subdomains: Run your support portal and knowledge base on subdomains. Consent given on one carries to the other, eliminating redundant banners.

Important note: This cross-domain sharing only works within the same domain zone. If you operate example.com and example.co.uk (different TLDs), they’re separate domain zones. Cookies set on .example.com cannot be read by .example.co.uk. You’ll need separate CookieTrust configurations for each TLD, and each will manage consent independently. This is a browser security boundary, not a CookieTrust limitation.

Conclusion

Cross-domain consent is a technical problem that shouldn’t require technical expertise to solve. Here’s what you need to remember:

• localStorage is origin-scoped and doesn’t work across subdomains
• First-party cookies with domain-zone scoping do work across subdomains
• CookieTrust automatically switches from localStorage to cookies when you add multiple domains
• No code changes are required on your part
• The same script works on all your domains; no per-domain customization needed
• Consent decisions sync instantly and are audit-logged for compliance

If you’re running multiple domains or subdomains and tired of showing your consent banner multiple times, CookieTrust eliminates the problem. Start your free trial at https://app.cookietrust.io/auth/signup and configure your domains today.