Cookie Consent for PrestaShop: What the Law Actually Requires

Almost every PrestaShop store has a cookie banner. Almost none of them are compliant — and the reason is technical, not legal. The banner sits politely in the corner while Google Analytics, Facebook Pixel and a half-dozen other scripts have already fired on page load, set their cookies, and phoned home. The customer clicks "Accept" or "Reject"; it changes nothing, because the tracking happened before they ever saw the choice. That single mistake — firing cookies before consent — is the most common cookie violation on PrestaShop stores, and it's also the one that turns a banner from a compliance tool into legal theatre.

This guide is specifically about consent: what valid consent must look like, why the order of operations (block first, fire later) is the whole game, and how that actually works inside PrestaShop's hook and module architecture. For the wider picture — data subject rights, your privacy policy, the GDPR register, what data you may keep — see GDPR and cookie compliance for PrestaShop and the broader GDPR for online stores. Here we stay on the banner and the scripts behind it.

Two laws, one rule you have to obey

Cookies sit at the intersection of two pieces of EU law, and it's worth knowing which does what — because they pull in slightly different directions.

The combined effect is simple to state and easy to get wrong: you must obtain explicit, informed consent before placing or reading any non-essential cookie. Note the word before. ePrivacy is about the act of writing to the device, so the consent has to come first — not "the banner is visible while the script runs," but the script genuinely does not run until the user opts in.

What counts as "strictly necessary" on a PrestaShop store

A short, defensible list of cookies you may set without asking — because the store cannot function without them, and the customer requested that function by, for example, adding something to their cart:

• PrestaShop's session cookie (PrestaShop-xxxxxxxx, the front-office session) — keeps the cart, the logged-in state and the CSRF token alive across pages. Without it there is no shop.
• Customer authentication — remembering that a logged-in customer is still logged in.
• Security tokens — CSRF protection on forms and checkout, fraud/bot signals.
• The consent cookie itself — you're allowed to remember the choice the user just made.
• Load balancing / routing — sticky-session cookies that send the user to the right server.

Everything past that line — analytics, advertising pixels, A/B-testing, embedded social feeds, video players that drop tracking cookies — needs consent first. A useful test: if the cookie exists to help you (measure, retarget, optimise) rather than to deliver the page the customer asked for, it's non-essential.

What valid consent actually has to look like

"They clicked something" is not consent. GDPR sets a quality bar, and regulators — particularly France's CNIL and Germany's data-protection authorities — now read it strictly. Valid consent is:

• Freely given. A real choice, with no penalty for declining. A cookie wall — "accept all or you can't use the site" — fails this in most of the EU, because consent isn't free when the only alternative is no access.
• Specific and granular. Analytics consent is separate from marketing consent. One blanket "accept cookies" button that bundles everything is too coarse; category-level toggles (necessary / analytics / marketing / preferences) are the accepted standard.
• Informed. The user understands what they're agreeing to. That doesn't mean a 10,000-word policy in the banner — a plain-language summary with a link to the full cookie list is enough.
• Unambiguous and affirmative. An explicit action — clicking "Accept." Continuing to browse is not consent. Scrolling is not consent. Pre-ticked boxes are explicitly prohibited.
• Withdrawable, as easily as it was given. If one click set the consent, one click (from a persistent "Cookie settings" link in the footer) must be able to revoke it.

So what does this mean for your banner design? "Reject all" has to be as visible and as one-click as "Accept all," on the first layer — not buried two clicks deep under "Manage preferences." A banner where saying no is harder than saying yes is the exact dark pattern that's drawing fines, and it's trivial for a regulator (or an annoyed customer) to spot.

The mistake that breaks 90% of PrestaShop banners: firing before consent

Here is where PrestaShop specifics matter, because the failure is almost always architectural. Most stores add tracking by dropping a Google Analytics, Pixel or Tag Manager snippet into a module that hooks displayHeader (or pasting it directly into the theme's header.tpl, or using a custom-HTML "live edit"/header-injection module, or the ps_googleanalytics module). All of those inject the script into every page as the page renders — which is exactly when the cookie gets written, long before the visitor reads, let alone answers, the banner.

The cookie banner, meanwhile, is just front-end JavaScript that paints a box. If the two aren't wired together, the banner is cosmetic and you are non-compliant no matter how pretty it is. Two failure modes dominate:

• Fire-on-load. Scripts run immediately in hookHeader; the banner appears afterward. Cookies are already set. Clicking "Accept" or "Reject" changes nothing that already happened.
• Reject is ignored. The user clicks "Reject all," but the analytics script — registered independently of the banner — still fires on the next page. The two systems were never connected.

The fix is an order-of-operations fix, not a legal one. Non-essential scripts must be blocked by default and only injected after the relevant category is consented to. In practice that means one of three architectures: (1) the consent tool itself controls script injection, holding tags back until the user opts in; (2) you route everything through Google Tag Manager and gate each tag on a consent trigger; or (3) you route through Google Tag Manager with Google Consent Mode v2 — but only as a supporting layer, not a standalone compliance route. Consent Mode helps only if its default consent state is set to denied and no non-essential storage or tracking occurs before the visitor opts in; the "restricted, cookieless" pings Google sends before consent can still be legally sensitive and must be assessed and configured carefully rather than assumed compliant. It does not, by itself, satisfy the prior-blocking ePrivacy requires. You can verify which camp your store is in without any tooling: open the browser's developer tools, go to the Application → Cookies panel on a fresh visit before clicking anything, and look for _ga, _fbp and friends. If they're there, your banner is decoration.

What PrestaShop gives you natively — and where it stops

PrestaShop ships some legal scaffolding, and it helps to know exactly how far it goes before you reach for a module.

The honest summary: PrestaShop's native tools cover disclosure and data rights well, but none of them does the one thing this article is about — stop non-essential cookies from being written until the visitor says yes. That job needs a consent layer that actually controls script injection.

Implementing real consent in PrestaShop

The reason a dedicated module exists is precisely the gap above: you need something that intercepts the tracking scripts and releases them per-category, from the back office, without you editing theme files or wiring tag triggers by hand. Our Lightweight Cookie Banner is built for that specific job on PrestaShop:

• Block by default, release by category. Analytics and marketing scripts are held back until the visitor consents to that category — necessary / analytics / marketing / preferences each toggle independently. This is the prior-blocking the law actually requires, not a banner painted over scripts that already ran.
• Reject as easy as accept. "Reject all" sits on the first layer with the same prominence as "Accept all," which keeps you clear of the dark-pattern enforcement that's catching other stores.
• A consent record. It stores when each visitor consented and to what — the proof you'll want if a data-protection authority ever asks how you obtained consent.
• Re-consent on change. Add a new tracking category or revise your cookie policy, and it re-asks rather than silently relying on stale consent.
• Genuinely lightweight. It loads without dragging down your page — so the compliance layer doesn't cost you the PageSpeed score you've been protecting.

So what's the payoff? You configure it from the back office instead of paying a developer to splice consent logic into your theme, and the banner stops being a liability dressed up as a safeguard. If your store also leans on Google's stack, pair it with Consent Mode v2 so GA4 keeps recovering modelled conversions from the visitors who decline — you respect the "no" and still get a directional read on that traffic.

Country differences: the same rule, enforced unequally

The prior-consent rule is EU-wide, but the appetite for enforcing it isn't. A few that change how you'd configure the banner:

• France (CNIL). The strictest on banner design: "Refuse all" must be on the first layer, equal to "Accept all." CNIL has issued repeated, sizeable fines specifically over hard-to-find reject buttons.
• Germany. Analytics requires consent, full stop, and the TDDDG (the successor to the TTDSG) hard-codes the ePrivacy prior-consent rule into national law. German authorities are unsympathetic to "legitimate interest" arguments for tracking.
• Italy (Garante). Requires a first-visit banner offering accept / reject / manage, plus a linked cookie policy; has explicitly ruled against scroll-as-consent.
• Spain (AEPD) follows the EU standard and publishes detailed banner guidance, historically with lighter enforcement than France or Germany.
• UK (ICO). Post-Brexit the UK kept the rules as UK GDPR plus PECR; substantively the same prior-consent obligation, enforced by the ICO.

For the broader cross-border legal map beyond cookies, see e-commerce law in the EU.

Accept the analytics gap — and plan for it

An uncomfortable consequence of doing consent properly: your analytics get thinner. When a meaningful share of visitors decline tracking — figures in the 30–40% range are commonly reported, but treat that as directional and measure your own opt-in rate from the consent record — you simply lose visibility into that slice. That's not a bug to engineer around; it's the cost of compliance, and pretending otherwise is how stores end up back in the "fire before consent" trap. Sensible mitigations: lean on Consent Mode v2 for modelled conversions, consider server-side measurement for the data you can collect without device cookies, and shift your analysis from individual user journeys toward aggregate trends that survive a smaller sample.

The practical minimum that keeps you clear

If you want to be compliant without over-engineering it, in order:

• Install a consent layer that blocks scripts — not a banner that merely informs. (Lightweight Cookie Banner if you want it handled from the back office.)
• Configure it to hold analytics and marketing back until the matching category is accepted.
• Put "Reject all" on the first layer, equal to "Accept all."
• Publish a clear cookie policy (create a CMS page for it if your installation doesn't already have one) listing each cookie, its purpose and its lifespan.
• Verify it with developer tools: fresh visit, check Application → Cookies before clicking — no _ga / _fbp should exist. Then click "Reject all" and confirm they still don't appear.
• Keep the consent records so you can show how and when consent was obtained.

This isn't the absolute legal maximum in every jurisdiction — some require deeper disclosures — but it covers the fundamentals and keeps you away from the enforcement actions that actually happen. For market-specific wording, a lawyer familiar with your target countries is worth the hour; just don't let the pursuit of perfect documentation stop you from fixing the one thing that genuinely matters today, which is making sure no cookie is set before the visitor has said yes.

Related guides

• GDPR and Cookie Compliance for PrestaShop: What You Actually Need
• GDPR for Online Stores: What You Must Do (and What You Can Skip)
• E-Commerce Law in the EU: A Store Owner Guide to the Most Important Rules
• Accessibility for Online Stores: What the European Accessibility Act Means for You