Here is the confusion that costs PrestaShop merchants the most: they install the official GDPR module, see "GDPR" in the title, tick the box, and assume they are covered. They are not — and not because the module is bad. It is because "GDPR compliance" and "cookie compliance" are two separate legal duties that happen to land on the same store, and PrestaShop's native tooling only addresses the first one. The GDPR module manages personal data (access requests, deletion, consent on forms). It does not show a cookie banner, it does not block a single tracking script, and it has no idea Google Consent Mode exists. So the most common compliant-looking PrestaShop store is half-compliant: tidy data handling, and a Google Analytics tag firing on page one before anyone clicked anything.
This guide is the PrestaShop-specific map of both duties: what the platform gives you out of the box, exactly where it stops, and what you have to add yourself. It is deliberately the overview that ties the two together. The deep legal reading of cookie consent (what counts as valid consent, dark patterns, banner mechanics) lives in cookie consent for PrestaShop: what the law actually requires, and the general "what you must do and what you can skip" checklist for any online store is in GDPR for online stores. This post stays on PrestaShop ground: back-office paths, the actual module, and what to wire up.
Two duties, one store: the distinction that catches everyone
Before touching a setting, get the legal geography right, because it decides which tool solves which problem.
| GDPR (data protection) | ePrivacy / cookie consent | |
|---|---|---|
| Governs | What you do with personal data once you hold it | Storing or reading anything on the visitor's device |
| On a PrestaShop store | Customer accounts, orders, newsletter sign-ups, contact-form messages | Analytics, Pixel, remarketing, A/B testing, embedded video |
| Native PrestaShop tool | The official GDPR module (psgdpr) + Customer privacy settings | None — you add this yourself |
| Consent needed before… | Processing for marketing; not for fulfilling the order itself | Any non-essential script fires |
So what? If you only solve one of these, an automated regulator scan still flags you. The cookie side is the one PrestaShop leaves entirely to you, and it is the one that triggers fines — the French regulator CNIL has made non-compliant cookie banners a standing enforcement priority, and its targets are not only household names. The GDPR side is mostly handled natively, as long as you actually configure it rather than just installing it.
What PrestaShop gives you natively for GDPR
PrestaShop provides an official GDPR module, technical name psgdpr, maintained by PrestaShop itself and available from the module catalog / Module Manager — you install and configure it rather than relying on it being there by default. It is genuinely useful — for data, not cookies. Find it under Modules → Module Manager, search "GDPR", install it, and configure from there. What it actually does:
- Data access export. A logged-in customer can request, straight from their account, an export (PDF or CSV) of their core account and order data plus data from compliant modules that integrate with psgdpr. That covers much of the Article 15 "right of access" without you building an export by hand — but it does not automatically include data held by third-party modules that do not integrate, so audit those separately.
- Right to be forgotten. Customers can request deletion; you action it from the module. So what? Instead of digging through Customers, Addresses and Orders to scrub one person, you get a single workflow — and a record that you honoured the request.
- Consent checkboxes on forms. The module can add and log consent on supported forms (such as registration, newsletter and contact) and on modules that integrate with it via its integration hooks. You write the text; it logs the agreement.
- A consent log. Each agreement is timestamped and stored, which is your proof when someone asks "did this person opt in?"
Alongside the module, PrestaShop exposes account-related controls at Shop Parameters → Customer Settings (the B2B toggle, "Ask for a birthdate", and partner-offer options), and it is here that psgdpr surfaces its consent text on the registration and account forms. The native settings do not log consent on their own — that is the module's job — but they shape what data the account flow collects in the first place. None of this is glamorous, but it is the part you do not have to buy or build.
Where the native GDPR module stops — flatly
The single most important sentence in this article: the PrestaShop GDPR module does nothing about cookies. It does not display a cookie banner. It does not block, delay or gate a single analytics or marketing script. It is unaware of Google Consent Mode. Merchants conflate "GDPR module installed" with "cookie compliant" constantly, and that gap is precisely what regulators scan for. Everything in the next section is on you to add.
The cookie side PrestaShop leaves entirely to you
Cookies are governed by the ePrivacy Directive, a separate rule from GDPR, and PrestaShop ships no native mechanism for it. The legal detail of what makes consent valid — prior consent, granular categories, equal-prominence buttons, easy withdrawal, no dark patterns — is covered in depth in our cookie-consent law guide, so here we stay on the PrestaShop mechanics: where the leaks actually are in a PrestaShop install, and how to find them.
Where tracking scripts get injected in PrestaShop
On a typical store, the tags that need gating arrive through a handful of predictable routes. Knowing them turns "audit my cookies" from vague advice into a checklist:
- Modules hooking displayHeader / displayBeforeBodyClosingTag. Most analytics and pixel modules (and PrestaShop's own Google Analytics module, ps_googleanalytics) inject their JavaScript here, unconditionally, on every page. That is why the GA4 cookie often appears before the banner is even rendered.
- Theme template edits. Tags pasted directly into header.tpl or via a "raw HTML" module fire the instant the page loads, with no consent check at all.
- Server-side cookies. A client-side banner cannot stop a module that sets cookies in PHP through setcookie() or PrestaShop's Cookie class. These slip past most consent tools entirely.
To find what your own install is doing, two checks. First, the visitor's view: open the store in an incognito window, open DevTools → Application → Cookies before touching any banner. If you see _ga, _gid, _fbp or _gcl_au, scripts are firing without consent. Second, the code view: search your modules folder for server-side cookie setters —
grep -r "setcookie\|new Cookie" modules/ --include="*.php"
— and you will usually find one or two modules quietly setting cookies the banner never knew about. So what? A banner that records a "reject" while these keep running is not a shield; it is documented evidence that you knew and did nothing.
The four cookie categories on a PrestaShop store
When you map your cookies, they fall into four buckets. The essential column is the one PrestaShop itself populates and is exempt from consent:
| Category | Typical PrestaShop cookies | Consent required? |
|---|---|---|
| Strictly necessary | Session (PrestaShop-xxxx), cart, CSRF token, the consent cookie itself | No (exempt) |
| Functional | Language/currency preference, recently viewed, wishlist | Depends — non-essential persistent functional cookies usually need consent, but strictly necessary cookies for a service the user explicitly requested (e.g. a session-scoped UI preference) may be exempt |
| Analytics | GA4 (_ga, _gid), Matomo, Hotjar | Yes |
| Marketing | Facebook Pixel (_fbp), Google Ads (_gcl_au), remarketing | Yes |
Google Consent Mode v2 — the part PrestaShop modules forget
Since March 2024, sites using Google Ads, remarketing or conversion-measurement features — or Google tags that feed those features — for EEA users should implement Consent Mode v2. It mainly applies to Google's advertising and measurement features for EEA/UK/Swiss users (Ads remarketing, personalization and conversion measurement) rather than every basic GA4 or Tag Manager deployment. It is a small JavaScript layer that tells Google tags whether the visitor consented, across four signals (ad_storage, analytics_storage, ad_user_data, ad_personalization), all defaulting to denied until your banner says otherwise. So what for a PrestaShop owner? Without it, you do not just risk a fine — you lose conversion modelling and remarketing data even from visitors who would have consented, because Google increasingly drops measurement from sites that do not signal consent. PrestaShop's stock Google Analytics module does not implement Consent Mode v2, so this is a gap you fill with a dedicated cookie module or a Google Tag Manager setup. The implementation specifics belong in the cookie-consent guide; the point here is simply that it is not handled for you.
The PrestaShop GDPR + cookie checklist, in order
Pulling both duties together, here is the sequence we recommend for a PrestaShop store, native tools first:
- 1. Install and configure psgdpr. Not just install — write the consent text, enable export and deletion, confirm the consent checkboxes appear on registration, newsletter and contact forms. This is your GDPR-data baseline, native and free.
- 2. Audit your cookies. Incognito + DevTools, list every cookie before consent, plus the grep for server-side setters. You cannot gate what you have not inventoried.
- 3. Add a cookie consent layer. PrestaShop ships none, so this is an add-on: a banner that genuinely blocks non-essential scripts until consent, with granular categories and equal-prominence accept/reject. The legal bar is detailed in the cookie-consent guide.
- 4. Wire up Consent Mode v2. Default all four signals to denied, update on the visitor's choice, so Google tags behave and you keep modelled data.
- 5. Keep demonstrable cookie-consent records. The psgdpr log covers form consent; cookie consent needs its own demonstrable record (timestamp, the choice made, the banner version and the method) as audit proof. Server-side logging is a robust way to do this, but the requirement is to be able to demonstrate consent — it can be implemented in different ways as long as it is adequate.
- 6. Publish a cookie policy page. A CMS page listing every cookie, its purpose, duration and the third party behind it, linked from the footer alongside a "Cookie settings" link that reopens the banner.
- 7. Re-audit after every module or theme change. A new module can quietly add a tracker; quarterly is a sane minimum.
How this fits the rest of your store's legal duties
GDPR and cookies are one corner of running a compliant European store. Rather than cram everything here (the cannibalising trap that gets posts demoted), here is the map to the siblings that own each topic:
- The full picture of what EU law expects of an online shop: e-commerce law in the EU.
- The general GDPR checklist beyond PrestaShop specifics — what you must do and what you can skip: GDPR for online stores.
- The legal mechanics of a valid cookie banner: cookie consent for PrestaShop.
- What your store's legal pages must contain: terms and conditions for your store.
- And on the security side that GDPR also touches, protecting payment data: payment security in PrestaShop.
Where mypresta.rocks fits
The native psgdpr module covers your data obligations, and we would never sell you a replacement for something PrestaShop hands you free. The hole is the cookie side — script-blocking, granular categories, Consent Mode v2 and a banner light enough not to wreck your PageSpeed. Plenty of consent platforms solve it by loading 200–500KB of third-party JavaScript onto a store that is already heavy, trading a compliance problem for a speed problem. Our approach is the opposite: a lightweight cookie-consent module that gates the scripts, signals Google correctly, and logs consent for audit — configured from the back office, without forking your theme. So what does that buy you? The half of compliance PrestaShop leaves open, closed without a developer invoice and without slowing the store you spent so long making fast.
Cookie and GDPR compliance is not glamorous, and it does not lift conversions on its own. But on PrestaShop the danger is specific and avoidable: assuming the GDPR module covered cookies when it never touched them. Configure psgdpr properly, audit what is actually firing on your pages, and add the cookie layer the platform leaves out — and you move from compliant-looking to actually compliant, before an automated scan makes the decision for you.
Comments
No comments yet. Be the first!
Be the first to ask a question or share useful feedback.
Leave a comment
Share a question, an installation detail, or feedback that could help another reader.