Recht & Compliance

Cookie-Einwilligung für PrestaShop: Was das Gesetz wirklich verlangt

David Miller Veröffentlicht: 15. Juni 2026 Aktualisiert: Recht & Compliance

139 Aufrufe 16 Min. Lesezeit

Geprüft im Juni 2026. Hinweise zur Durchsetzung (CNIL, TDDDG, Garante) spiegeln den Stand zu diesem Zeitpunkt wider und können sich ändern; dies ist technische Orientierung, keine Rechtsberatung, klären Sie Details für Ihre Märkte mit einem qualifizierten Berater.

Fast jeder PrestaShop-Shop hat ein Cookie-Banner. Fast keines davon ist rechtskonform, und der Grund ist technischer, nicht juristischer Natur. Das Banner sitzt brav in der Ecke, während Google Analytics, Facebook Pixel und ein halbes Dutzend weiterer Skripte beim Laden der Seite bereits ausgeführt wurden, ihre Cookies gesetzt und Daten nach Hause gesendet haben. Der Kunde klickt auf „Akzeptieren“ oder „Ablehnen“; es ändert nichts, weil das Tracking schon passiert ist, bevor er überhaupt eine Wahl gesehen hat. Dieser eine Fehler (Cookies vor der Einwilligung auszulösen) ist der häufigste Cookie-Verstoß in PrestaShop-Shops und genau der Punkt, der ein Banner von einem Compliance-Werkzeug in juristisches Theater verwandelt.

Dieser Leitfaden dreht sich ausdrücklich um Einwilligung: wie gültige Einwilligung aussehen muss, warum die Reihenfolge (erst blockieren, dann ausführen) entscheidend ist und wie das in der Hook- und Modularchitektur von PrestaShop tatsächlich funktioniert. Für das größere Bild, Betroffenenrechte, Ihre Datenschutzerklärung, das DSGVO-Verzeichnis, welche Daten Sie speichern dürfen, lesen Sie DSGVO- und Cookie-Compliance für PrestaShop sowie den allgemeinen Leitfaden DSGVO für Online-Shops. Hier bleiben wir beim Banner und den Skripten dahinter.

Zwei Gesetze, eine Regel, die Sie einhalten müssen

Laptop mit einem echten Keks auf dem Trackpad und einem hölzernen Richterhammer daneben — Die Cookie-Einwilligung liegt dort, wo Technik auf Recht trifft: Was Ihr Shop erfassen darf, entscheidet die Gesetzgebung, nicht die Vorliebe.

Cookies liegen an der Schnittstelle zweier EU-Rechtsakte. Es lohnt sich zu wissen, welcher wofür zuständig ist, denn sie ziehen in leicht unterschiedliche Richtungen.

Gesetz	Was es regelt	Was es für Cookies verlangt
ePrivacy-Richtlinie („Cookie-Richtlinie“)	Das Speichern oder Auslesen von Informationen auf dem Gerät eines Nutzers, jedes Cookie, Pixel, jeder localStorage-Eintrag oder Fingerprint	Vorherige Einwilligung für alles, was nicht unbedingt erforderlich ist, unabhängig davon, ob personenbezogene Daten verarbeitet werden
DSGVO	Verarbeitung personenbezogener Daten, sobald sie erhoben wurden	Eine gültige Rechtsgrundlage (bei Tracking/Marketing ist diese Grundlage die Einwilligung) und der Qualitätsmaßstab, den diese Einwilligung erfüllen muss

Die kombinierte Wirkung ist leicht auszusprechen und leicht falsch umzusetzen: Sie müssen eine ausdrückliche, informierte Einwilligung einholen, bevor Sie ein nicht notwendiges Cookie setzen oder auslesen. Beachten Sie das Wort bevor. ePrivacy betrifft den Schreibvorgang auf dem Gerät, also muss die Einwilligung zuerst kommen. Nicht „das Banner ist sichtbar, während das Skript läuft“, sondern das Skript läuft tatsächlich erst, wenn der Nutzer zustimmt.

Was in einem PrestaShop-Shop als „unbedingt erforderlich“ gilt

Eine kurze, vertretbare Liste von Cookies, die Sie ohne Nachfrage setzen dürfen, weil der Shop ohne sie nicht funktioniert und der Kunde diese Funktion angefordert hat, zum Beispiel indem er etwas in den Warenkorb gelegt hat:

Das Session-Cookie von PrestaShop (PrestaShop-xxxxxxxx, die Front-Office-Sitzung), hält Warenkorb, Login-Status und CSRF-Token über Seiten hinweg aktiv. Ohne dieses Cookie gibt es keinen Shop.
Kundenauthentifizierung. Merkt sich, dass ein eingeloggter Kunde weiterhin eingeloggt ist.
Sicherheits-Token, CSRF-Schutz in Formularen und an der Kasse, Betrugs-/Bot-Signale.
Das Einwilligungs-Cookie selbst. Sie dürfen sich die Entscheidung merken, die der Nutzer gerade getroffen hat.
Load Balancing / Routing, Sticky-Session-Cookies, die den Nutzer an den richtigen Server leiten.

Alles jenseits dieser Grenze, Analytics, Werbepixel, A/B-Tests, eingebettete Social Feeds, Videoplayer, die Tracking-Cookies setzen, benötigt zuerst eine Einwilligung. Ein nützlicher Test: Wenn das Cookie dazu dient, Ihnen zu helfen (messen, retargeten, optimieren), statt die vom Kunden angeforderte Seite auszuliefern, ist es nicht notwendig.

Wie gültige Einwilligung tatsächlich aussehen muss

„Sie haben auf etwas geklickt“ ist keine Einwilligung. Die DSGVO setzt einen Qualitätsmaßstab, und Aufsichtsbehörden, besonders die französische CNIL und die deutschen Datenschutzbehörden, lesen ihn inzwischen streng. Gültige Einwilligung ist:

Freiwillig. Eine echte Wahl, ohne Nachteil bei Ablehnung. Eine Cookie Wall, „alles akzeptieren oder Sie können die Website nicht nutzen“, scheitert daran in den meisten EU-Ländern, weil Einwilligung nicht freiwillig ist, wenn die einzige Alternative kein Zugang ist.
Spezifisch und granular. Einwilligung für Analytics ist getrennt von Einwilligung für Marketing. Ein pauschaler Button „Cookies akzeptieren“, der alles bündelt, ist zu grob; Schalter auf Kategorieebene (notwendig / Analytics / Marketing / Präferenzen) sind der akzeptierte Standard.
Informiert. Der Nutzer versteht, worin er einwilligt. Das bedeutet keine 10.000-Wörter-Richtlinie im Banner, eine verständliche Zusammenfassung mit Link zur vollständigen Cookie-Liste reicht aus.
Eindeutig und aktiv. Eine ausdrückliche Handlung, der Klick auf „Akzeptieren“. Weitersurfen ist keine Einwilligung. Scrollen ist keine Einwilligung. Vorangekreuzte Kästchen sind ausdrücklich verboten.
Widerrufbar, so einfach wie sie erteilt wurde. Wenn ein Klick die Einwilligung gesetzt hat, muss ein Klick (über einen dauerhaft verfügbaren Link „Cookie-Einstellungen“ im Footer) sie auch widerrufen können.

Was bedeutet das für Ihr Banner-Design? „Alle ablehnen“ muss auf der ersten Ebene genauso sichtbar und mit einem Klick erreichbar sein wie „Alle akzeptieren“, nicht zwei Klicks tief unter „Einstellungen verwalten“ versteckt. Ein Banner, bei dem Nein sagen schwerer ist als Ja sagen, ist genau das Dark Pattern, das Bußgelder auslöst, und für eine Aufsichtsbehörde (oder einen verärgerten Kunden) trivial zu erkennen.

Hier werden die PrestaShop-Details wichtig, denn der Fehler ist fast immer architektonisch. Die meisten Shops fügen Tracking ein, indem sie ein Google-Analytics-, Pixel- oder Tag-Manager-Snippet in ein Modul legen, das an displayHeader hängt (oder es direkt in die header.tpl des Themes kopieren, ein Custom-HTML-Modul für „Live Edit“/Header-Injection nutzen oder das Modul ps_googleanalytics verwenden). All diese Varianten injizieren das Skript in jede Seite während die Seite gerendert wird, und genau dann wird das Cookie geschrieben, lange bevor der Besucher das Banner liest, geschweige denn beantwortet.

Das Cookie-Banner ist unterdessen nur Frontend-JavaScript, das ein Feld einblendet. Wenn beides nicht miteinander verdrahtet ist, ist das Banner Kosmetik und Sie sind nicht rechtskonform, egal wie hübsch es aussieht. Zwei Fehlermuster dominieren:

Ausführung beim Laden. Skripte laufen sofort in hookHeader; das Banner erscheint danach. Cookies sind bereits gesetzt. Ein Klick auf „Akzeptieren“ oder „Ablehnen“ ändert nichts an dem, was schon passiert ist.
Ablehnung wird ignoriert. Der Nutzer klickt auf „Alle ablehnen“, aber das Analytics-Skript, unabhängig vom Banner registriert, läuft auf der nächsten Seite trotzdem. Die beiden Systeme waren nie verbunden.

Die Lösung ist eine Frage der Ablaufreihenfolge, keine juristische Formel. Nicht notwendige Skripte müssen standardmäßig blockiert und erst nach Einwilligung in die passende Kategorie injiziert werden. In der Praxis bedeutet das eine von drei Architekturen: (1) Das Consent-Tool steuert die Skript-Injektion selbst und hält Tags zurück, bis der Nutzer zustimmt; (2) Sie leiten alles über Google Tag Manager und knüpfen jedes Tag an einen Consent-Trigger; oder (3) Sie leiten über Google Tag Manager mit Google Consent Mode v2, aber nur als unterstützende Ebene, nicht als eigenständigen Weg zur Rechtskonformität. Consent Mode hilft nur, wenn sein Standard-Einwilligungsstatus auf denied gesetzt ist und vor der Zustimmung des Besuchers keine nicht notwendige Speicherung oder Nachverfolgung erfolgt; die „eingeschränkten, cookielosen“ Pings, die Google vor der Einwilligung sendet, können rechtlich trotzdem sensibel sein und müssen sorgfältig bewertet und konfiguriert werden, statt sie einfach als rechtskonform anzunehmen. Allein erfüllt er nicht die Vorab-Blockierung, die ePrivacy verlangt. Sie können ohne jedes Spezialtool prüfen, in welche Kategorie Ihr Shop fällt: Öffnen Sie die Entwicklertools des Browsers, gehen Sie bei einem frischen Besuch in den Bereich Application → Cookies bevor Sie irgendetwas anklicken, und suchen Sie nach _ga, _fbp und ähnlichen Cookies. Wenn sie da sind, ist Ihr Banner Dekoration.

Wie „erst blockieren“ im Markup aussieht

Die konkrete Technik hinter einer Consent-Schicht, die wirklich blockiert, ist simpel: Ein Skript, das warten muss, wird nicht als normales <script src> ausgeliefert. Es wird mit einem entschärften Typ ausgeliefert, damit der Browser es nicht ausführt, und die Consent-Schicht schreibt diesen Typ erst dann in text/javascript um, wenn die passende Kategorie akzeptiert wurde. Wenn man es einmal gesehen hat, ist die ganze Behauptung „vor Einwilligung blockieren“ entmystifiziert:

<!-- BLOCKED until consent: the browser parses but does NOT run this. -->
<script type="text/plain" data-cookiecategory="analytics"
        src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>

<!-- When the visitor accepts "analytics", the consent layer flips the type
     so the browser then executes it – never before. -->

Wenn ein Skript in Ihrem Seitenquelltext bereits ein aktives type="text/javascript" hat (oder gar kein type), ist es nicht blockiert. Es läuft beim Laden, mit Banner oder ohne. Dieses eine Attribut ist die praktische Trennlinie zwischen einer funktionierenden Consent-Schicht und einem Banner, das über bereits ausgeführten Skripten liegt. Was folgt daraus? Wenn Sie ein Cookie-Modul oder ein GTM-Setup prüfen, zeigt Ihnen ein Blick in den Quelltext und auf entschärfte Tracking-Tags (text/plain) in fünf Sekunden, ob Prior-Blocking echt oder nur Kosmetik ist.

Was PrestaShop nativ bietet, und wo es endet

PrestaShop liefert einige rechtliche Grundbausteine mit. Es hilft, genau zu wissen, wie weit sie reichen, bevor Sie zu einem Modul greifen.

Native Option	Was sie tut	Die Lücke
ps_legalcompliance (Legal Compliance, 1.7+)	Fügt eine statische Cookie-Infoleiste hinzu und verlinkt Ihre rechtlichen CMS-Seiten (AGB, Datenschutz, Cookies) an den richtigen Stellen	Es informiert; es blockiert keine Skripte und erfasst keine granulare, widerrufbare Einwilligung. Für sich allein ist es kein Consent Manager.
PrestaShop Official GDPR module (psgdpr)	Bearbeitet Betroffenenanfragen, Export, Auskunft, Löschung, und ein Framework für Einwilligungs-Checkboxen in Formularen	Gebaut für Betroffenenrechte, nicht für Cookie-/Skript-Gating. Es hält Ihr Pixel nicht zurück, bis ein Besucher zustimmt.
Eine CMS-Seite „Cookies“	Ein Ort, an dem Sie Ihre Cookie-Richtlinie veröffentlichen. PrestaShop bringt sie versions- und installationsprofilübergreifend nicht zuverlässig standardmäßig mit. Wenn Ihre Installation (oder ein Modul) sie also noch nicht angelegt hat, sollten Sie selbst eine CMS-Seite hinzufügen und verlinken.	Eine Richtlinienseite ist erforderlich, aber ihre Veröffentlichung steuert nicht, welche Skripte laufen.

Die ehrliche Kurzfassung: Die nativen Werkzeuge von PrestaShop decken Information und Betroffenenrechte gut ab, aber keines erledigt die eine Aufgabe, um die es in diesem Artikel geht. Nicht notwendige Cookies daran zu hindern, geschrieben zu werden, bis der Besucher Ja sagt. Dafür braucht es eine Consent-Schicht, die die Skript-Injektion tatsächlich kontrolliert.

So setzen Sie echte Einwilligung in PrestaShop um

Der Grund für ein dediziertes Modul ist genau die oben beschriebene Lücke: Sie brauchen etwas, das Tracking-Skripte abfängt und sie pro Kategorie aus dem Back Office freigibt, ohne dass Sie Theme-Dateien bearbeiten oder Tag-Trigger von Hand verdrahten müssen. Unser Lightweight Cookie Banner ist genau für diese Aufgabe in PrestaShop gebaut:

Standardmäßig blockieren, nach Kategorie freigeben. Analytics- und Marketing-Skripte werden zurückgehalten, bis der Besucher in diese Kategorie einwilligt, notwendig / Analytics / Marketing / Präferenzen lassen sich unabhängig voneinander schalten. Das ist die Vorab-Blockierung, die das Gesetz tatsächlich verlangt, kein Banner über Skripten, die bereits gelaufen sind.
Ablehnen so einfach wie akzeptieren. „Alle ablehnen“ steht auf der ersten Ebene mit derselben Sichtbarkeit wie „Alle akzeptieren“. Damit vermeiden Sie die Dark-Pattern-Durchsetzung, die andere Shops trifft.
Ein Einwilligungsnachweis. Es speichert, wann jeder Besucher in was eingewilligt hat. Genau der Nachweis, den Sie brauchen, wenn eine Datenschutzbehörde fragt, wie Sie die Einwilligung eingeholt haben.
Erneute Einwilligung bei Änderungen. Fügen Sie eine neue Tracking-Kategorie hinzu oder überarbeiten Sie Ihre Cookie-Richtlinie, fragt es erneut, statt sich still auf veraltete Einwilligung zu verlassen.
Wirklich schlank. Es lädt, ohne Ihre Seite auszubremsen. Die Compliance-Schicht kostet Sie also nicht den PageSpeed-Wert, den Sie geschützt haben.

Was bringt Ihnen das konkret? Sie konfigurieren es im Back Office, statt einen Entwickler dafür zu bezahlen, Consent-Logik in Ihr Theme einzubauen, und das Banner ist keine als Schutzmaßnahme verkleidete Haftungsquelle mehr. Das ist technische Befähigung. Es gibt Ihnen die Vorab-Blockierung und den Einwilligungsnachweis, die das Gesetz erwartet, aber es macht Ihren Shop nicht allein „rechtskonform“; Ihre Cookie-Richtlinie, Ihre Kategorisierungsentscheidungen und Ihre Angaben zu Auftragsverarbeitern bleiben Ihre Verantwortung als Verantwortlicher. Wenn Ihr Shop außerdem auf Googles Stack setzt, kombinieren Sie es mit Consent Mode v2, damit GA4 weiterhin Conversions von Besuchern modelliert, die ablehnen, Consent Mode schätzt diesen verlorenen Anteil statistisch, er stellt keine echten Daten wieder her, und Sie respektieren das „Nein“ weiterhin, indem Sie zuerst blockieren.

Länderunterschiede: dieselbe Regel, ungleich durchgesetzt

Die Regel der vorherigen Einwilligung gilt EU-weit, aber der Durchsetzungswille ist unterschiedlich. Einige Beispiele, die beeinflussen, wie Sie Ihr Banner konfigurieren sollten:

Frankreich (CNIL). Am strengsten beim Banner-Design: „Alle ablehnen“ muss auf der ersten Ebene stehen, gleichwertig zu „Alle akzeptieren“. Die CNIL hat wiederholt erhebliche Bußgelder speziell wegen schwer auffindbarer Ablehnen-Buttons verhängt.
Deutschland. Analytics erfordert Einwilligung, Punkt, und das TDDDG (der Nachfolger des TTDSG) schreibt die ePrivacy-Regel der vorherigen Einwilligung fest ins nationale Recht. Deutsche Behörden zeigen wenig Verständnis für „berechtigtes Interesse“-Argumente beim Tracking.
Italien (Garante). Verlangt beim ersten Besuch ein Banner mit Akzeptieren / Ablehnen / Verwalten plus verlinkter Cookie-Richtlinie; hat Scrollen als Einwilligung ausdrücklich abgelehnt.
Spanien (AEPD) folgt dem EU-Standard und veröffentlicht ausführliche Banner-Leitlinien, historisch mit geringerer Durchsetzung als Frankreich oder Deutschland.
UK (ICO). Nach dem Brexit hat das Vereinigte Königreich die Regeln als UK GDPR plus PECR beibehalten; inhaltlich dieselbe Pflicht zur vorherigen Einwilligung, durchgesetzt vom ICO.

Für die breitere grenzüberschreitende Rechtskarte jenseits von Cookies lesen Sie E-Commerce-Recht in der EU.

Akzeptieren Sie die Analytics-Lücke, und planen Sie dafür

Eine unbequeme Folge sauber umgesetzter Einwilligung: Ihre Analytics-Daten werden dünner. Wenn ein relevanter Anteil der Besucher Tracking ablehnt. Werte im Bereich von 30-40 % werden häufig berichtet, aber verstehen Sie das als Richtwert und messen Sie Ihre eigene Opt-in-Rate anhand des Einwilligungsnachweises, verlieren Sie schlicht die Sichtbarkeit für diesen Anteil. Das ist kein Bug, den man technisch umgehen sollte; es ist der Preis der Compliance, und wer so tut, als wäre es anders, landet schnell wieder in der Falle „Ausführung vor Einwilligung“. Sinnvolle Gegenmaßnahmen: Nutzen Sie Consent Mode v2 für modellierte (geschätzte, nicht wiederhergestellte) Conversions, prüfen Sie serverseitige Messung für Daten, die Sie ohne Geräte-Cookies erfassen dürfen, und verschieben Sie Ihre Analyse von individuellen Nutzerreisen hin zu aggregierten Trends, die auch mit einer kleineren Stichprobe tragfähig bleiben.

Häufig gestellte Fragen

Öffnen Sie Ihren Shop in einem frischen Inkognito-Fenster, öffnen Sie DevTools → Application → Cookies und schauen Sie nach, bevor Sie das Banner berühren. Wenn _ga, _fbp oder _gcl_au bereits vorhanden sind, wurden die Skripte beim Laden ausgeführt und Ihr Banner ist Kosmetik. Klicken Sie dann auf „Alle ablehnen“ und laden Sie neu: Wenn sie wieder auftauchen, ist die Ablehnung nicht mit den Skripten verbunden. Ein zweiter Hinweis steckt im Seitenquelltext, blockierte Tags tragen type="text/plain"; aktive nicht.

Reicht „Alle akzeptieren“ plus ein Link „Einstellungen verwalten“, oder brauche ich ein sichtbares „Alle ablehnen“?

Sie brauchen „Alle ablehnen“ auf der ersten Ebene, mit derselben Sichtbarkeit und demselben Klickaufwand wie „Alle akzeptieren“. Ablehnung hinter „Einstellungen verwalten“ zu verstecken, ist genau das Dark Pattern, für das CNIL und andere wiederholt Bußgelder verhängt haben. Gleichwertige Sichtbarkeit auf dem ersten Screen ist die sichere Standardeinstellung in den strengen Märkten.

Nein. Consent Mode signalisiert Google-Tags, ob der Besucher eingewilligt hat, und modelliert die Conversions, die Sie durch Ablehnungen verlieren, er schätzt sie, er stellt keine echten Daten wieder her. Er ist eine unterstützende Ebene, nicht die Vorab-Blockierung, die ePrivacy verlangt. Wenn nicht notwendige Cookies weiterhin geschrieben werden, bevor der Besucher zustimmt, rettet Consent Mode Sie nicht; Sie brauchen zuerst eine Schicht, die die Skripte wirklich zurückhält.

Kann ich das PrestaShop-Modul ps_googleanalytics behalten und trotzdem rechtskonform sein?

Nur wenn etwas es steuert. Für sich allein injiziert ps_googleanalytics sein Tag beim Laden der Seite und setzt das GA-Cookie vor der Einwilligung. Sie leiten es entweder durch eine Consent-Schicht / GTM, die es blockiert, bis „Analytics“ akzeptiert wurde, oder Sie ersetzen es. Das Modul ist nicht das Problem; seine bedingungslose Ausführung ist es.

In den meisten EU-Ländern: nein. Einwilligung ist nicht „freiwillig“, wenn die einzige Alternative der Verlust des Zugangs zur Website ist. Über einige Rechtsordnungen und bestimmte Modelle mit bezahlter Alternative wird diskutiert, aber für einen normalen PrestaShop-Shop ist eine Cookie Wall die falsche Standardeinstellung. Bieten Sie stattdessen einen echten Ablehnungsweg an.

Das praktische Minimum, das Sie aus der Schusslinie hält

Wenn Sie rechtskonform sein wollen, ohne es unnötig komplex zu machen, dann in dieser Reihenfolge:

Installieren Sie eine Consent-Schicht, die Skripte blockiert, kein Banner, das nur informiert. (Lightweight Cookie Banner, wenn Sie es aus dem Back Office steuern möchten.)
Konfigurieren Sie sie so, dass Analytics und Marketing zurückgehalten werden, bis die passende Kategorie akzeptiert wurde.
Platzieren Sie „Alle ablehnen“ auf der ersten Ebene, gleichwertig zu „Alle akzeptieren“.
Veröffentlichen Sie eine klare Cookie-Richtlinie (legen Sie dafür eine CMS-Seite an, falls Ihre Installation noch keine hat), die jedes Cookie, seinen Zweck und seine Lebensdauer aufführt.
Prüfen Sie es mit den Entwicklertools: frischer Besuch, Application → Cookies vor dem Klicken prüfen. Es sollten keine _ga / _fbp vorhanden sein. Klicken Sie dann auf „Alle ablehnen“ und bestätigen Sie, dass sie weiterhin nicht erscheinen.
Bewahren Sie die Einwilligungsnachweise auf, damit Sie zeigen können, wie und wann Einwilligung eingeholt wurde.

Das ist nicht in jeder Rechtsordnung das absolute rechtliche Maximum, manche verlangen tiefere Offenlegungen, aber es deckt die Grundlagen ab und hält Sie von den Durchsetzungsfällen fern, die tatsächlich passieren. Für marktspezifische Formulierungen ist eine Stunde mit einem Anwalt, der Ihre Zielländer kennt, gut investiert; lassen Sie nur nicht die Suche nach perfekter Dokumentation verhindern, dass Sie das eine Problem beheben, das heute wirklich zählt: sicherzustellen, dass kein Cookie gesetzt wird, bevor der Besucher Ja gesagt hat.