Cookie-Einwilligung technisch umsetzen: vom Banner bis zum Consent-Speicher

Ein Cookie-Banner einzublenden ist der leichte Teil. Die eigentliche Herausforderung beginnt danach: Werden Skripte wirklich erst nach Zustimmung geladen, wird die Einwilligung nachweisbar gespeichert, und passiert beim Widerruf tatsächlich etwas Technisches – oder bleibt alles beim Klick einfach unverändert im Hintergrund laufen?

Während der Artikel zum Cookie-Banner die rechtliche Grundfrage klärt, geht es hier um die technische Umsetzung: was ein Consent-System im Hintergrund leisten muss, damit die sichtbare Einwilligung auch der tatsächlichen Datenverarbeitung entspricht.

Der häufigste Fehler: Banner zeigen, Skripte trotzdem laden

Viele Cookie-Banner erfüllen nur die halbe Aufgabe. Sie werden eingeblendet, sammeln einen Klick ein – aber im Hintergrund laden Analyse- oder Marketing-Skripte längst, bevor überhaupt eine Entscheidung getroffen wurde. Das passiert häufig, wenn ein Banner nachträglich über eine bestehende Website gelegt wird, ohne die eigentliche Skript-Einbindung anzupassen.

Technisch korrekt bedeutet Einwilligung vor Verarbeitung, dass nicht notwendige Skripte erst nach einer aktiven Zustimmung überhaupt in den Ladevorgang der Seite eingebunden werden – nicht nur optisch verborgen, sondern tatsächlich blockiert. Ein Skript, das im Quelltext bereits enthalten ist und lediglich per CSS ausgeblendet wird, reicht dafür nicht aus.

Dieser Unterschied fällt oft erst auf, wenn jemand gezielt danach sucht. Optisch ist ein Banner, das nur die Anzeige steuert, von einem, das tatsächlich die Skript-Ausführung blockiert, nicht zu unterscheiden – beide zeigen dieselbe Oberfläche. Der Unterschied liegt ausschließlich im Code dahinter, weshalb eine rein visuelle Abnahme eines neuen Banners nicht ausreicht.

Wie eine korrekte Blockierung technisch aussieht

Eine saubere Umsetzung lädt zunächst nur das, was für den Betrieb der Seite zwingend nötig ist. Alle weiteren Skripte – etwa für Statistik oder Marketing – werden als sogenannte Platzhalter im Quelltext hinterlegt, deren tatsächliche Ausführung erst durch das Consent-System freigegeben wird, sobald die passende Kategorie akzeptiert wurde.

Ein einfaches Beispiel für diese Trennung ist ein Skript-Tag, das zunächst einen anderen Typ als text/javascript trägt und erst nach Zustimmung aktiviert wird, etwa <script type="text/plain" data-consent="statistik">. Die genaue technische Lösung hängt vom eingesetzten Consent-Tool und Content-Management-System ab, das Grundprinzip bleibt aber gleich: keine Ausführung ohne vorherige Freigabe.

Kategorien statt Alles-oder-nichts

Eine reine Ja/Nein-Entscheidung wird der eigentlichen Anforderung selten gerecht. Üblich ist eine Einteilung in Kategorien wie notwendig, funktional, Statistik und Marketing, wobei notwendige Dienste ohne Einwilligung laufen dürfen, während alle anderen Kategorien einzeln zustimmungspflichtig sind.

Technisch bedeutet das, dass jedes eingebundene Skript im Consent-System einer dieser Kategorien zugeordnet sein muss – und dass die Freigabe pro Kategorie getrennt erfolgt. Ein Banner, der zwar einzelne Kategorien anzeigt, im Hintergrund aber alle Skripte gemeinsam freischaltet, sobald irgendeine Kategorie akzeptiert wurde, erfüllt diese Trennung nur zum Schein.

Consent-Speicherung und Nachweispflicht

Eine erteilte oder verweigerte Einwilligung muss dokumentiert werden können – nicht nur für den einzelnen Besuch, sondern auch, um im Zweifel nachzuweisen, dass ein Nutzer tatsächlich zugestimmt hat. Consent-Management-Tools speichern dafür üblicherweise einen Zeitstempel, die konkret akzeptierten Kategorien und eine Kennung des Endgeräts, meist über ein eigenes technisches Cookie oder einen vergleichbaren Speichermechanismus.

Wichtig ist, dass diese Speicherung selbst wieder nachvollziehbar und im Rahmen einer datenschutzkonformen Website dokumentiert ist. Ein Consent-Tool, das die Zustimmung speichert, aber selbst nicht in der Datenschutzerklärung auftaucht, ist ein klassischer blinder Fleck.

Auch die Speicherdauer der Einwilligung selbst sollte begrenzt sein. Eine Zustimmung, die vor mehreren Jahren erteilt wurde, spiegelt nicht mehr zwangsläufig den aktuellen Stand der eingesetzten Tools wider. Viele Consent-Systeme fragen deshalb nach Ablauf einer bestimmten Zeit automatisch erneut, statt eine einmal erteilte Zustimmung unbegrenzt fortgelten zu lassen.

Was beim Widerruf technisch passieren muss

Einwilligung muss genauso leicht widerrufbar sein, wie sie erteilt wurde. Technisch bedeutet das: Es braucht eine dauerhaft erreichbare Möglichkeit, die Cookie-Einstellungen erneut zu öffnen – meist über einen kleinen, permanenten Link oder ein schwebendes Symbol –, und der Widerruf muss tatsächlich dazu führen, dass bereits gesetzte, nicht mehr erwünschte Cookies gelöscht und zugehörige Skripte deaktiviert werden.

Ein häufiger Mangel: Der Widerrufs-Link existiert, führt aber nur zu einer neuen Anzeige des Banners, ohne dass bereits aktive Skripte tatsächlich gestoppt werden. Das ist besonders bei Analyse-Tools relevant, die nach dem ersten Laden eigenständig weiterlaufen, wenn sie nicht aktiv beendet werden.

Eingebettete Drittinhalte als Sonderfall

Videos, Karten oder Social-Media-Widgets bringen häufig eigene Cookies und Datenübertragungen mit, die separat vom klassischen Tracking-Skript behandelt werden müssen. Ein eingebettetes Video sollte technisch so eingerichtet werden, dass der eigentliche Inhalt erst nach Zustimmung lädt – etwa über ein Vorschaubild, das erst nach Klick durch den echten Inhalt ersetzt wird.

Wird ein solches Element einfach direkt in die Seite eingebunden, ohne diese Zwischenstufe, überträgt es beim bloßen Laden der Seite bereits Daten an den Drittanbieter – unabhängig davon, ob überhaupt eine Einwilligung erteilt wurde. Das betrifft in der Praxis viele iframe-Einbindungen, die aus Bequemlichkeit unverändert aus einer Anleitung kopiert werden.

Wer ein Content-Management-System einsetzt, sollte prüfen, ob eingebaute Blöcke für Videos oder Karten diese Zwischenstufe bereits mitbringen oder ob sie standardmäßig direkt einbinden. Viele Systeme liefern die unkomplizierte, aber datenschutzrechtlich riskantere Variante als Standard aus, während die datensparsame Variante erst über ein zusätzliches Plugin oder eine manuelle Anpassung aktiviert werden muss.

Typische technische Fehler im Überblick

Neben dem verfrühten Laden von Skripten gehören zu den häufigsten technischen Mängeln: ein voreingestelltes Häkchen bei optionalen Kategorien, ein „Alle akzeptieren“-Button, der optisch deutlich hervorgehoben ist, während „Ablehnen“ versteckt oder erst über ein Untermenü erreichbar ist, sowie Cookies, die trotz Ablehnung weiterhin gesetzt werden, weil ein älteres Skript-Fragment übersehen wurde.

Eine regelmäßige technische Prüfung – etwa durch einen Blick in die Entwicklerwerkzeuge des Browsers direkt nach dem Laden der Seite, vor jeder Interaktion mit dem Banner – deckt solche Lücken zuverlässiger auf als eine rein visuelle Kontrolle des Banners.

Hinweis: Dieser Beitrag bietet eine allgemeine Orientierung und ersetzt keine individuelle Rechtsberatung.

Häufige Fragen