Consent-Gate richtig konfigurieren

Würdigung — warum viele Banner reine Deko sind#

§ 25 TDDDG verlangt nicht „ein Banner zeigen", sondern „erst nach Einwilligung speichern oder lesen". Die Planet49-Linie hat das höchstrichterlich bestätigt: Die Einwilligung muss aktiv vorliegen, BEVOR das einwilligungspflichtige Skript geladen oder der Cookie gesetzt wird. Ein Banner, das erst poppt, während im Hintergrund schon Google-Analytics und Meta-Pixel feuern, ist genau das nicht.

Der Fehler ist selten Absicht. Die meisten Consent-Tools sind grundsätzlich in der Lage, Skripte vor der Einwilligung zu blockieren — aber sie tun es nur, wenn sie korrekt konfiguriert sind. Out-of-the-Box zeigt das Banner zwar, blockiert die Tracker aber nicht automatisch. Die Konfiguration entscheidet, ob das Banner ein Gate ist oder nur eine Hutkrempe.

Was Pre-Consent-Blocking technisch heißt#

Das Prinzip ist einfach: Bis der Besucher aktiv zustimmt, darf für keine nicht-zwingende Verarbeitung etwas geladen werden. Konkret heißt das:

• Skripte (Tracker, Pixel, Karten, Chat): Der <script src="…">-Tag wird gar nicht erst ausgeführt, oder er ist als type="text/plain" ausgeliefert und wird erst nach Einwilligung „aktiviert" (Standard-Pattern der meisten Tools).
• Cookies und LocalStorage: Vor der Einwilligung dürfen nur technisch unbedingt erforderliche Einträge gesetzt werden (das eigene Session-/CSRF-Cookie der Anwendung, der Consent-Cookie des Banners selbst). Werbe-/Tracking-/Komfort-Cookies sind tabu.
• Drittanbieter-Verbindungen (Schriften, Embeds): Auch ein scheinbar harmloser Aufruf an ein fremdes Schriften-CDN überträgt die IP des Besuchers. Wenn er nicht technisch zwingend ist, gehört er hinter das Gate — oder besser durch self-hosted Fonts ersetzt, dann entfällt die Frage ganz.

Die Faustregel: Vor dem Klick darf die Seite mit der Außenwelt nur das nötige Minimum reden — Auslieferung der eigenen Inhalte vom eigenen Server, sonst nichts.

Wie es bei den verbreiteten Tools konfiguriert wird#

Die in Deutschland verbreiteten Consent-Lösungen können Pre-Consent-Blocking — aber die Schalter sitzen unterschiedlich:

• Cookiebot: Auto-Blocking lässt sich im Manager-Backend aktivieren („Skript-Blocking" / „Vorab-Sperre"). Wichtig: Die Skripte müssen entweder über das Cookiebot-Skript in der korrekten Reihenfolge geladen werden (das tut die Blockade-Magie) oder manuell als type="text/plain" mit data-cookieconsent-Attribut markiert sein. Skripte, die das CMS hartcodiert ins HTML schreibt, müssen die zweite Variante bekommen.
• Usercentrics: Vergleichbares Modell, Pre-Consent-Blocking im „Data Processing Services"-Backend pro Dienst aktivieren. Jeder Dienst, der nicht „Essential" kategorisiert ist, gehört in „Block before consent". GTM-eingebundene Tags brauchen den Usercentrics-Trigger statt eines Page-View-Triggers.
• Borlabs Cookie (WordPress): Im Backend pro Cookie-Gruppe „Content Blocker" konfigurieren — sonst werden eingebettete YouTube-Videos, Google-Maps und Co. ungeblockt geladen. Die Default-Installation blockiert weniger, als die meisten denken.

Allen gemeinsam ist die Stolperfalle: Ein Skript, das nicht über das Consent-Tool registriert ist (etwa ein direkt ins Theme geschriebener Pixel-Schnipsel), wird auch nicht blockiert. Das Tool kann nur das blockieren, was es kennt. Deshalb gehört zu jeder Einrichtung ein vollständiges Drittanbieter-Inventar — sonst läuft am Banner vorbei, was niemand auf dem Schirm hat.

Der DevTools-Beweis: selbst nachprüfen, in zwei Minuten#

Niemand muss dem Tool glauben — der Browser liefert den Beweis. Vorgehen:

1. Inkognito-Fenster öffnen (kein gespeicherter Consent-Cookie aus früheren Besuchen).
2. DevTools öffnen (F12), Tab „Network" wählen, „Disable cache" aktivieren.
3. Seite laden — und währenddessen NICHT das Banner anklicken.
4. Im Network-Tab nach den verdächtigen Domains filtern: facebook, google, googletagmanager, doubleclick, hotjar, linkedin. Was VOR dem Banner-Klick erscheint, sollte nicht da sein.
5. Im Tab „Application" → „Cookies" prüfen: Welche Cookies sind gesetzt, BEVOR irgendetwas geklickt wurde? Erlaubt ist der Consent-Cookie des Banners selbst und technisch zwingende Cookies — alles andere ist ein Befund.

Das ist die unbestechliche Prüfung. Wenn Schritt 4 oder 5 etwas Verdächtiges zeigt, ist das Pre-Consent-Blocking nicht korrekt — egal, was das Banner-Backend sagt.

Wenn das Tool es nicht kann — die Architektur-Frage#

Manchmal lohnt sich die Konfiguration nicht. Wenn eine Kanzlei-Site ohnehin nur zwei oder drei nicht-zwingende Dienste einbindet (vielleicht Schrift-CDN, vielleicht Karten-Embed), ist der schnellere Weg, die Dienste durch DSGVO-freundliche Alternativen zu ersetzen — Schriften lokal, Karten als statisches Bild oder per Click-to-Load, Analytics cookielos. Dann braucht es weder Consent-Tool noch Gate, weil nichts Einwilligungspflichtiges mehr passiert.

Das ist genau die Linie, die wir auf fahoch2.de fahren: keine einwilligungspflichtigen Bausteine, deshalb auch kein Banner — die saubere Auflösung der Frage. Wer Tracker zwingend braucht (etwa für ein laufendes Marketing-Setup), kommt ums echte Gate nicht herum. Wer sie nicht braucht, sollte die Architektur entlasten, statt das Banner perfektionieren.

Für eine vollständige Bestandsaufnahme — Drittanbieter-Inventar, Consent-Konfiguration, Pre-Consent-Verifikation — empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

§ 25 TDDDG fordert, dass nicht-zwingende Skripte und Cookies erst NACH der Einwilligung geladen werden — sichtbares Banner allein reicht nicht. Die verbreiteten Consent-Tools können Pre-Consent-Blocking, müssen aber explizit so konfiguriert werden (Cookiebot: Auto-Blocking + type="text/plain" für hartcodierte Skripte; Usercentrics: Dienste auf „Block before consent"; Borlabs: Content Blocker pro Gruppe). Was das Tool nicht kennt, blockiert es nicht — deshalb gehört ein vollständiges Drittanbieter-Inventar dazu. Der unbestechliche Nachweis sind die Browser-DevTools: Inkognito öffnen, Network + Cookies vor dem Banner-Klick prüfen, was da bereits steht. Wenn die Konfiguration zum Krampf wird, ist die ehrlichere Lösung oft, die einwilligungspflichtigen Bausteine architektonisch zu entfernen — dann fällt das Gate-Problem weg.

Quellen#

• TDDDG § 25 — Schutz der Privatsphäre bei Endeinrichtungen — abgerufen 2026-05-31
• BGH I ZR 7/16 (Planet49), Urteil vom 28.05.2020 — abgerufen 2026-05-31
• EuGH C-673/17 (Planet49), Urteil vom 01.10.2019 — abgerufen 2026-05-31
• DSGVO Art. 6, 7 (VO EU 2016/679) — abgerufen 2026-05-31

Disclaimer: Allgemeine fachliche Information zum Zeitpunkt der Veröffentlichung — keine Rechtsberatung im Einzelfall. Die konkrete Tool-Konfiguration und ihre datenschutzrechtliche Bewertung gehören in die anwaltliche bzw. fachliche Endprüfung.