Magento Cookie Consent: How to Handle Third-Party Extensions and Tracking

Why Magento Stores Face a Unique Cookie Consent Challenge

Magento (now Adobe Commerce) differs from most ecommerce platforms in one critical way: its extension ecosystem. A typical Magento store runs between 15 and 40 third-party extensions, each potentially setting its own cookies without the store owner's knowledge. Payment gateways, analytics tools, recommendation engines, live chat widgets, and marketing pixels all contribute to a sprawling cookie footprint that the platform's built-in cookie notice was never designed to handle.

Under Article 5(3) of the ePrivacy Directive, storing or accessing information on a visitor's device requires prior informed consent, unless the cookie is strictly necessary. A default Magento installation provides a basic cookie restriction mode, but it only covers core cookies. It does nothing to detect or block the tracking scripts that extensions inject into your storefront.

The enforcement risk is real. In September 2025, CNIL fined SHEIN 150 million euros for setting cookies before users gave consent and for providing reject options that did not function correctly. Online retailers are firmly in regulators' sights.

What Magento's Built-In Cookie Restriction Mode Actually Does

Adobe Commerce and Magento Open Source include a cookie restriction mode that, when enabled, displays a banner asking visitors to accept cookies before certain data is stored. The system classifies its own cookies as exempt or non-exempt and suppresses non-exempt cookies until the visitor clicks accept.

This sounds reasonable on paper. The problem is scope. Cookie restriction mode only governs cookies set by the Magento core application. Third-party extension scripts, Google Analytics tags, Meta Pixel code, and any JavaScript injected through layout XML or template overrides all fire independently of this mechanism. A visitor who has not yet consented may already have _ga, _fbp, and half a dozen other tracking cookies on their device.

For stores selling to customers in the EU or UK, this gap creates a compliance failure from the moment the page loads.

Identifying Every Cookie Your Extensions Set

Before you can manage consent, you need a complete inventory of what your store sets. There are two practical approaches.

Manual Auditing with Browser DevTools

Open your storefront in Chrome, navigate to DevTools (Application > Cookies), and browse through your key pages: homepage, category, product detail, cart, and checkout. Record every cookie name, domain, duration, and purpose. Repeat the process in a private browsing window to capture first-visit behaviour. This method is thorough but time-consuming, and you will need to repeat it each time you add or update an extension.

Automated Cookie Scanning

A cookie scanner crawls your site, detects all cookies and tracking technologies, and categorises them automatically. This catches cookies set by asynchronous scripts, lazy-loaded widgets, and conditional logic that manual audits miss. Running scheduled scans ensures your inventory stays current as extensions update.

The table below shows cookies commonly found on Magento stores with popular extensions installed:

Content Security Policy and Cookie Consent Conflicts

Adobe Commerce 2.4.7 and later enforces a Content Security Policy (CSP) in restrict mode for payment pages and report-only mode for all other pages. CSP dictates which external domains can load scripts, styles, and other resources on your storefront. This creates a specific interaction with cookie consent management that many store owners overlook.

If your consent management solution needs to inject or modify scripts dynamically (for example, switching a tracking script from type="text/plain" to type="text/javascript" after consent), the script's source domain must be whitelisted in your CSP configuration. Without this, the browser silently blocks the script even after the visitor grants consent, and your analytics data disappears.

The fix is straightforward: add your CMP's domain and any conditionally loaded third-party domains to the relevant CSP directives in your csp_whitelist.xml file. Test thoroughly in a staging environment, because an overly restrictive CSP breaks functionality while an overly permissive one defeats the security purpose entirely.

Blocking Extension Scripts Until Consent Is Given

The core technical challenge on Magento is preventing third-party scripts from executing before the visitor makes a choice. There are several approaches, each with trade-offs.

Script Type Attribute Swapping

Change the type attribute of tracking scripts from text/javascript to text/plain and add a data attribute indicating the cookie category. Your CMP then listens for consent events and swaps the type back for approved categories. This approach works well for inline scripts and simple tag insertions. It requires modifying extension templates or using Magento's layout XML to override script blocks.

Google Tag Manager as a Consent Layer

Move all third-party scripts into GTM and use consent initialisation triggers to gate their firing. With Google Consent Mode v2, GTM can pass consent signals to Google tags automatically. Non-Google tags need custom trigger conditions based on a dataLayer push from your CMP. This centralises script management but requires every extension's tracking code to be moved out of Magento templates and into GTM containers.

CMP-Based Script Blocking

A dedicated consent management platform can handle script blocking without requiring changes to extension code. Kukie.io, for instance, can detect and block scripts by category before they execute, then release them once the visitor provides consent. This approach reduces the development effort for stores with many extensions.

Handling Google Consent Mode v2 on Magento

Since March 2024, Google requires Consent Mode v2 for any site using Google Ads or Google Analytics. A standard Magento installation does not send consent signals to Google natively. Without a CMP or custom implementation providing these signals, Google treats all visitors as having denied consent, which severely reduces the data available for conversion modelling and audience building.

Consent Mode v2 requires two new parameters beyond the original version: ad_user_data and ad_personalization. Your CMP must pass these to the Google tag (gtag.js or GTM) based on the visitor's choices. When consent is denied, Google Analytics 4 operates in cookieless ping mode and uses conversion modelling to estimate the data gap. When consent is granted, full measurement resumes.

Classifying Magento Core Cookies Correctly

Not every Magento cookie needs consent. Getting the classification wrong in either direction causes problems: over-blocking breaks the checkout flow, while under-blocking creates compliance risk.

PHPSESSID and form_key are strictly necessary. They manage the server session and protect against cross-site request forgery. Blocking these breaks the cart and checkout entirely. mage-cache-storage and related local storage entries manage the full-page cache and customer section data. These are functional but not strictly necessary for the site to operate, meaning some GDPR interpretations may require consent for them.

Product recommendation cookies, recently viewed product trackers, and comparison list cookies fall into the functional or analytics category depending on whether they feed into personalisation engines. If your recommendation extension uses cookies to build a browsing profile for personalised suggestions, those cookies require consent under the GDPR.

Payment Gateway Cookies and the Essential Cookie Exception

Magento stores typically integrate payment providers such as Stripe, PayPal, Braintree, or Klarna. These gateways set their own cookies for fraud detection, session management, and device fingerprinting. The question of whether payment gateway cookies qualify as strictly necessary is nuanced.

Cookies required to complete a transaction the visitor has explicitly requested are generally exempt under Recital 32 of the ePrivacy Directive. Fraud detection cookies set during checkout are typically considered essential. Cookies that persist after the transaction for remarketing or analytics purposes are not.

Review each payment extension's cookie documentation and test what gets set at each stage of the checkout flow. If a payment provider sets a persistent cookie on the product page before the visitor even reaches checkout, that cookie likely needs consent.

Practical Implementation Checklist

Getting Magento cookie consent right requires a structured approach. Follow these steps in order:

1. Run a full cookie scan of your storefront, including all page types and the checkout flow.
2. Map every detected cookie to the extension or script that sets it.
3. Classify each cookie into the correct category: strictly necessary, functional, analytics, or marketing.
4. Choose a consent management approach: CMP integration, GTM-based blocking, or script attribute swapping.
5. Configure CSP whitelisting for your CMP and any conditionally loaded domains.
6. Implement Google Consent Mode v2 signals.
7. Test that rejected cookies are genuinely blocked, not just hidden from the banner.
8. Set up recurring scans to catch new cookies introduced by extension updates.

Verify your implementation using Chrome DevTools. After rejecting all non-essential cookies, check the Application tab. No analytics or marketing cookies should be present. If they are, your blocking mechanism has a gap.

Frequently Asked Questions

Take Control of Your Cookie Compliance

If you are not sure which cookies your Magento store sets, start with a free scan. Kukie.io detects, categorises, and helps you manage every cookie across your extensions and tracking scripts - so your visitors get a clear choice, and you stay on the right side of the law.

Start Free - Scan Your Website