Cookie-Banner abgelehnt, Tracking lädt trotzdem: so testen und beheben Sie es

Am 22. Oktober 2026 fragte ein Shopify-Händler auf r/shopify, wie andere mit Skripten umgehen, die nach einem Klick auf Ablehnen weiter laden. Der Banner sagte das eine, der Browser tat das andere. Das ist das häufigste Cookie-Problem auf jeder Plattform: Der Banner speichert die Entscheidung, aber nichts auf der Seite ist so angeschlossen, dass es darauf hört. WooCommerce, Shopify, ein Headless-Frontend mit Next.js oder Astro und ein normales WordPress scheitern gleich, weil die Lecks aus eingebetteten Videos, Schriftarten, Theme-Code und Tag-Konfiguration kommen, nicht aus dem Banner-Plugin.

Diese Anleitung zeigt, wie Sie mit dem Browser prüfen, was Ihre Website nach dem Ablehnen sendet, welche Anfragen typischerweise durchrutschen, was der erweiterte Einwilligungsmodus von Google absichtlich überträgt und wie Sie jede Anfrage absichern. Zu jedem Punkt nenne ich Norm, Urteil oder Herstellerdokumentation. Es ist eine technische Prüfanleitung, keine Rechtsberatung.

#Warum lädt Tracking trotz Ablehnung im Cookie-Banner

Der Beitrag, mit dem der Thread begann, beschreibt die Trennlinie genau:

App-Pixel sind einfach. Die übernimmt Shopify. Alles andere? YouTube-Videos, Google Fonts, Chat-Widgets, SEO- und Analyse-Skripte: nein. Im Januar 2022 sprach ein Münchner Gericht einem Besucher 100 Euro zu, weil eine Website seine IP-Adresse über Google Fonts ohne Einwilligung an Google weitergegeben hatte.

(u/Plus_Cell394, r/shopify, 22. Oktober 2026, eigene Übersetzung)

Ein Banner steuert nur, was bei ihm registriert ist. Code, der fest im Theme steht, in ein Footer-Feld kopiert wurde, über einen Einbettungsblock kommt oder von einem Plugin geladen wird, das die Banner-Schnittstelle ignoriert, startet beim Seitenaufruf unabhängig von der Antwort. Der Banner zeigt “Abgelehnt” und hat mit seinem eigenen Status recht. Die Seite hat ihn nur nie gefragt.

#§ 25 TDDDG und das Urteil zu Google Fonts

In Deutschland steht die Regel in § 25 TDDDG (früher TTDSG): Speichern von Informationen in der Endeinrichtung und der Zugriff darauf sind nur mit Einwilligung zulässig, die nach der DSGVO erfolgen muss. Ausgenommen sind die Übertragung einer Nachricht und Zugriffe, die für einen ausdrücklich gewünschten Dienst unbedingt erforderlich sind.

Für Schriftarten gibt es ein bekanntes Urteil. Das LG München I (3 O 17493/20, Endurteil vom 20. Januar 2022) verurteilte einen Websitebetreiber, es zu unterlassen, die IP-Adresse des Klägers durch die Bereitstellung von Google Fonts an Google offenzulegen, und sprach 100 Euro Schadensersatz nach Art. 82 DSGVO zu. Laut Leitsatz fehlte ein Rechtfertigungsgrund, weil Google Fonts auch ohne Verbindung zu einem Google-Server beim Seitenaufruf genutzt werden kann.

Die Datenschutzkonferenz geht in ihrer Orientierungshilfe Telemedien 2021 (Version 1.1, Dezember 2022) über Schriftarten hinaus. In Rn. 99 nennt sie als typische Drittinhalte, deren Einbindung Daten an den Drittserver offenlegt: Werbeanzeigen, Schriftarten, Skripte, Stadtpläne, Videos, Fotos und Social-Media-Inhalte. In Rn. 135 hält sie fest, dass eine Schaltfläche “Einstellungen oder Ablehnen”, die erst auf eine weitere Banner-Ebene führt, als Ablehnungsoption nicht ausreicht.

#Was die EU-Ebene ergänzt: EuGH Planet49 und EDPB-Leitlinien 2/2023

Der EuGH entschied in Planet49 (C-673/17), dass ein vorausgewähltes Ankreuzkästchen keine wirksame Einwilligung ist und Art. 5 Abs. 3 der ePrivacy-Richtlinie unabhängig vom Personenbezug gilt. Die EDPB-Leitlinien 2/2023 zum technischen Anwendungsbereich (Version 2.0 vom 7. Oktober 2024) zählen JavaScript dazu, mit dem eine Stelle den Browser anweist, asynchrone Anfragen mit Informationen zu senden, und behandeln Tracking-Pixel und reines IP-Tracking gesondert. Ein “wir setzen keine Cookies” beendet die Prüfung also nicht. Ob eine Ausnahme greift, ist eine rechtliche Frage. Ob die Anfrage überhaupt stattfindet, können Sie selbst prüfen.

#Welche Banner-Gestaltungen die Aufsichtsbehörden beanstandet haben

Der Bericht der Cookie-Banner-Taskforce des EDPB (angenommen am 17. Januar 2023) fasst Praktiken zusammen, die die Behörden bei koordinierten Beschwerden geprüft haben. Er ergänzt die Rn. 135 der DSK-Orientierungshilfe und lässt sich im selben Durchgang wie der Netzwerktest abarbeiten:

• Keine Ablehnen-Schaltfläche auf der ersten Ebene. Eine große Mehrheit der Behörden sah einen Banner mit Akzeptieren, aber ohne Ablehnungsoption auf derselben Ebene als Verstoß.
• Vorausgewählte Kästchen auf der zweiten Ebene. Laut Taskforce führen sie nicht zu einer wirksamen Einwilligung.
• Ein Link statt einer Schaltfläche zum Ablehnen sowie Farben und Kontraste, die “Alle akzeptieren” hervorheben. Für Kontraste setzt der Bericht keinen festen Standard, sondern verlangt eine Prüfung im Einzelfall.
• Als “essenziell” eingestufte Cookies, die nicht unbedingt erforderlich sind. Der Bericht betont, dass Websitebetreiber die Cookie-Liste aktuell halten und die Erforderlichkeit jedes Eintrags belegen müssen.
• Kein einfacher Widerruf. Erwartet wird ein dauerhaft sichtbarer Link oder ein kleines Symbol, das die Datenschutzeinstellungen erneut öffnet. Bei Shopify öffnet privacyBanner.showPreferences() aus der Customer Privacy API das Einstellungsfenster, bei Cloudflare Zaraz zaraz.showConsentModal() das Einwilligungsfenster.

#Cookie-Banner in den Entwicklertools prüfen: Schritt für Schritt

Chrome, Brave, Firefox und Edge funktionieren hier gleich.

1. Öffnen Sie ein neues Profil oder ein privates Fenster ohne Erweiterungen. Werbeblocker verstecken genau die Anfragen, die Sie suchen.
2. Öffnen Sie die Entwicklertools vor dem Laden der Seite. Im Network-Tab “Preserve log” und “Disable cache” aktivieren.
3. Startseite laden, Banner nicht anfassen. Jede fremde Domain notieren. Vor der Entscheidung sollte nichts Optionales laden.
4. Auf Ablehnen klicken, dann Produktseite, eine Seite mit Video, Kontakt und Warenkorb aufrufen. Lecks sitzen oft in Vorlagen, die die Startseite nicht nutzt.
5. Die Liste nach Domain-Teilen filtern: google, gstatic, doubleclick, facebook, tiktok, youtube, hotjar, clarity, Name des Chat-Anbieters.
6. Im Tab Application (in Firefox: Storage) Cookies, Local Storage und Session Storage je Herkunft prüfen. Alles außer der gespeicherten Ablehnung und funktionalen Sitzungscookies braucht eine Begründung.
7. Den Test mit Akzeptieren wiederholen, um zu sehen, dass die Werkzeuge mit Einwilligung funktionieren.

Halten Sie das Ergebnis als Tabelle fest: Domain, Seite, vor der Wahl, nach Ablehnen, nach Akzeptieren. Das ist Ihre Liste der Korrekturen.

#Welche Drittinhalte nach dem Ablehnen typischerweise laden

Google beschreibt den erweiterten Datenschutzmodus von YouTube (youtube-nocookie.com) so, dass Aufrufe eingebetteter Videos die Personalisierung beim Zuschauer nicht beeinflussen. Dass keine Daten an Google gehen, steht dort nicht. Der Domainwechsel allein ist also keine Lösung.

Aktualisierung vom 27. Oktober 2026. Dieselbe Lücke steckt in WooCommerce-Produktseiten, deren Galerie ein Video zeigt. Ein eingebetteter YouTube- oder Vimeo-Player ist selbst ein Drittinhalt, der beim Seitenaufruf lädt, noch vor jedem Klick, solange kein Vorschaubild bis zum Druck auf Play an seiner Stelle steht. Ich habe das in unserem Plugin Reel geändert, das WooCommerce um ein Produktvideo in der Galerie ergänzt. Seit Version 1.0.27 zeigen YouTube- und Vimeo-Videos ein Vorschaubild mit Play-Schaltfläche, und der Player lädt erst, wenn der Kunde darauf drückt. Wer das Video nie startet, lädt nichts vom Player. YouTube spielt von youtube-nocookie.com ab, und das Vorschaubild füllt den reservierten 16:9-Rahmen, sodass nichts verrutscht. Ist Autoplay eingeschaltet, wird der Player wie bisher direkt eingebettet. Version 1.1.0 brachte das Video als letzte Galerie-Folie; auch dort lädt der Player erst beim Klick, und Autoplay greift an dieser Stelle nicht. Prüfen Sie Ihren Shop im Network-Tab der Entwicklertools mit abgelehnter Einwilligung. Erscheinen vor dem ersten Klick Anfragen an youtube.com, ytimg.com oder Vimeo-Domains, braucht die Einbettung ein Vorschaubild, das den Player erst per Klick lädt.

#Einwilligungsmodus v2: was einfach und erweitert noch senden

Wenn Sie nach dem Ablehnen Anfragen an Google Analytics sehen, prüfen Sie zuerst, welcher Modus läuft. Googles Übersicht zum Einwilligungsmodus unterscheidet:

• Einfach: Google-Tags sind bis zur Interaktion mit dem Banner blockiert. Laut Google werden vorher keine Daten gesendet, nicht einmal der Standardstatus.
• Erweitert: Tags laden sofort mit verweigerten Standardwerten. Solange die Einwilligung fehlt, senden sie den Status und Messungen ohne Cookies. Bei verweigertem analytics_storage liest und schreibt Google Analytics keine eigenen Cookies, Messungen gehen aber weiter an Analytics-Domains “für grundlegende Messung und Modellierung”. Bei verweigertem ad_storage laufen Anfragen über eine andere Domain.

Der erweiterte Modus erzeugt nach dem Ablehnen also absichtlich Google-Anfragen. Ob das für Ihre Website trägt, ist genau die Frage nach § 25 TDDDG, die Sie mit Ihrer Beratung klären, nicht der Tag. Im einfachen Modus bedeutet Ablehnen keine Google-Anfrage. Zwei Fehler aus Googles Implementierungsanleitung führen in beiden Modi zu echten Lecks: Der Standardbefehl muss vor config und event laufen, und ein asynchron geladener Banner braucht wait_for_update.

#Shopify, WooCommerce und Headless: wo Code am Banner vorbeiläuft

Laut Shopify-Dokumentation zu Web-Pixeln beachten Web-Pixel-App-Erweiterungen die Customer Privacy API und laufen in Regionen mit Einwilligungspflicht erst nach der Einwilligung. Theme-Code bekommt diesen Schutz nicht. Dafür gibt es die Customer Privacy API mit analyticsProcessingAllowed(), marketingAllowed() und dem Ereignis visitorConsentCollected. Wichtig: Der Standard hängt von den Datenschutzeinstellungen des Shops ab. Regionen ohne Einwilligungspflicht erlauben alles, ein falsch eingestellter Markt sieht also aus wie ein kaputter Banner. Der Autor des Threads lädt Skripte nur, wenn analyticsProcessingAllowed() true liefert, beim Laden und erneut nach visitorConsentCollected. Er beobachtete, dass seine Themes Version 0.1 der API geladen hatten, während die Dokumentation 0.2 zeigt.

Wer bei Shopify einen eigenen Banner baut, speichert die Wahl mit setTrackingConsent() und den Zwecken analytics, marketing und preferences; laut Dokumentation darf das nur nach einer Handlung des Besuchers geschehen, nie automatisch. shouldShowBanner() sagt, ob der Besucher in einer Region mit Banner ist, aber nicht, ob er schon eingewilligt hat. Für Headless-Shops mit Hydrogen verweist Shopify auf Hydrogen Analytics und Consent: Dort wird die Shopify-Sitzung serverseitig verwaltet, sodass die Einwilligung über Seitenaufrufe hinweg erhalten bleibt und im Checkout beachtet wird.

Bei WooCommerce, WordPress und Headless-Frontends gibt es keine Plattform-Sandbox. In einem Thread auf r/woocommerce vom Oktober 2026 ging es eigentlich um die Wahl eines Consent-Plugins, am Ende vor allem ums Testen. Eine Antwort benennt die zwei Lücken, die bei GTM-Setups übersehen werden:

Consent Mode spricht nur mit Google-Tags. Das Meta-Pixel liest diese Signale nicht. […] Nicht jedes Pixel steckt im GTM. WooCommerce-Plugins (Meta for WooCommerce, Google for WooCommerce und ähnliche) setzen ihr Pixel oft direkt in die Seite. Die GTM-Vorschau zeigt die gar nicht an.

(u/Bignose_boy, r/woocommerce, 12. Oktober 2026, eigene Übersetzung)

Ein anderer Teilnehmer empfiehlt zusätzlich, einen wiederkehrenden Besucher zu testen, der seine Einwilligung zurückzieht, ohne den Browser zu leeren (u/anamap_alex). Prüfen Sie Header- und Footer-Felder, Plugins mit eigenen Tags (Bewertungen, Chat, Marketing) und Einbettungen im Beitragsinhalt. Unsere Anleitung zu Google Analytics 4 beschreibt die Anbindung über die Einwilligung, der Artikel zu Drittanbieter-Skripten zeigt, wie Sie prüfen, was jedes Skript nachlädt.

Aktualisierung vom 24. Oktober 2026. Das Consent-Tool ist selbst Code, der auf jeder Seite läuft, und braucht deshalb Updates und Überwachung wie jedes andere Plugin. Der wöchentliche Schwachstellenbericht von Wordfence für den 12. bis 18. Oktober 2026 nennt vier Einwilligungs-Plugins. In Complianz bis Version 7.5.5 konnten nicht angemeldete Besucher über Kommentarinhalte gespeichertes Cross-Site-Scripting einschleusen, das erst nach Freigabe des Kommentars ausgeführt wird; Version 7.5.6 behebt es. WPConsent bis 1.1.9 hatte eine ähnliche Lücke über Kommentare, wenn die Funktion Script Blocking aktiv ist (behoben in 1.2.0). Die Record of Consent Extension for Complianz bis 2.5 speicherte eingeschleusten Code über den Parameter uid (behoben in 2.6), und Lightweight Cookie Notice bis 1.19 enthielt einen fest eingetragenen, öffentlich bekannten Sicherheitsschlüssel von W3 Total Cache, relevant für Seiten, auf denen auch W3 Total Cache läuft (behoben in 1.20). Nehmen Sie das Consent-Plugin in denselben Update-Rhythmus und dieselben Schwachstellenwarnungen auf wie den Rest der Installation. Unser Sicherheitsaudit für WordPress prüft genau das.

#Einwilligungseinstellungen im Google Tag Manager prüfen

Die Tag-Manager-Hilfe zum Einwilligungsmodus beschreibt drei Funktionen, mit denen sich die meisten Fragen nach dem Muster “warum hat dieses Tag ausgelöst” klären lassen:

1. Trigger Consent Initialization - All Pages. Jeder Web-Container hat ihn. Er löst vor allen anderen Triggern aus, auch vor Initialization, und ist nur für Tags gedacht, die die Einwilligung setzen oder aktualisieren, etwa die Banner-Vorlage. Läuft der Banner auf einem späteren Trigger, feuern andere Tags, bevor es überhaupt einen Einwilligungsstatus gibt.
2. Additional Consent Checks pro Tag (Advanced Settings > Consent Settings). Der Standard “Not set” bedeutet keine zusätzliche Prüfung. Mit “Require additional consent for tag to fire” löst das Tag nur aus, wenn alle aufgeführten Einwilligungsarten erteilt sind. Ein Tag ohne eingebaute Einwilligungsprüfung, etwa ein als Custom HTML eingefügtes Meta-Pixel, feuert sonst unabhängig von der Wahl des Besuchers.
3. Consent Overview. Aktivierung unter Admin > Container Settings. Die Übersicht teilt Tags in “Consent Not Configured” und “Consent Configured” und erlaubt Massenänderungen. Jedes Marketing-Tag in der ersten Gruppe ist ein Kandidat für ein Leck.

Danach prüfen Sie das Ergebnis im Tag Assistant. Googles Anleitung zur Fehlersuche empfiehlt, im Summary das früheste Consent-Ereignis zu wählen und zu prüfen, ob ad_storage, ad_user_data, ad_personalization und analytics_storage gesetzt sind, und im Consent-Tab die Spalten On-page Default und On-page Update zu vergleichen. Als typischen Fehler nennt Google einen zu spät gesetzten Standard: Seite öffnet, Werbe-Tag feuert, erst dann wird der Standard auf denied gesetzt. Google rät außerdem davon ab, den gtag-Consent-Befehl aus einem Custom-HTML-Tag aufzurufen. Wer regionale Standards nutzt, wiederholt die Prüfung mit einem simulierten Standort in Chrome.

#Welches Skript die Anfrage ausgelöst hat: Initiator, Filter, HAR

Die Referenz zum Network-Panel von Chrome beschreibt die Werkzeuge für die Ursachensuche. Unter More filters zeigt “3rd-party requests” nur Anfragen fremder Herkunft. Der Filter domain: akzeptiert Platzhalter wie domain:*.google.com, cookie-name: zeigt, welche Antwort ein bestimmtes Cookie setzt. Die Spalte Initiator verlinkt bei Skripten auf die genaue Zeile im Quellcode, daran erkennen Sie, ob Theme, Plugin, Container oder ein eingefügtes Snippet verantwortlich ist. Mit Network request blocking sperren Sie testweise ein URL-Muster und sehen, ob die Seite danach noch funktioniert. Für die Dokumentation exportieren Sie das Protokoll als “HAR (sanitized)”: Chrome lässt dabei sensible Daten wie Cookies weg, die Datei kann also in ein Ticket.

#WP Consent API, Next.js und Cloudflare Zaraz: was sie sperren und was nicht

• WordPress und WooCommerce: Das Plugin WP Consent API vereinheitlicht die Kommunikation von Einwilligungskategorien zwischen Banner-Plugin und anderen Plugins, verwaltet selbst aber keine Einwilligung. Laut Beschreibung gibt die Funktion für den Einwilligungstyp false zurück, wenn kein Consent-Plugin ihn setzt, und dann gelten alle Kategorien als erlaubt. Eingebettete iframes fremder Dienste muss weiterhin die Blockierfunktion des Consent-Plugins abfangen.
• Next.js: Nach der Dokumentation zu @next/third-parties lädt GoogleTagManager den Container nach der Hydration, und YouTubeEmbed nutzt lite-youtube-embed. Keine der Komponenten prüft die Einwilligung. Laut lite-youtube-embed verwendet der Player youtube-nocookie.com, das Standard-Vorschaubild kommt aber von i.ytimg.com, also von einer Google-Domain, noch vor dem Klick. Für eine strenge Umsetzung ein eigenes Vorschaubild hinterlegen.
• Cloudflare Zaraz: Laut Zaraz-Dokumentation zur Einwilligungsverwaltung hat ein neu hinzugefügtes Tool keinen Zweck zugewiesen und überspringt die Einwilligung standardmäßig. Jedes Tool braucht einen Zweck, sonst lädt es für alle.

#Fehlerbild, Ursache, Prüfstelle

#So schließen Sie jedes Leck

• Videos und Karten: iframe durch einen Platzhalter ersetzen, der das iframe erst nach Klick oder Einwilligung erzeugt. Das Vorschaubild vom eigenen Server ausliefern, sonst ist es selbst eine Drittanfrage.
• Schriftarten: Dateien herunterladen, per @font-face von der eigenen Domain ausliefern, jeden Verweis auf fonts.googleapis.com entfernen.
• Chat: lokale Schaltfläche “Chat starten” zeigen und das Anbieter-Skript erst nach Klick oder Einwilligung laden.
• Fest eingebaute Pixel: in den Tag Manager oder das Pixel-System der Plattform verschieben, damit die Prüfung greift.
• Tag Manager: Einwilligungsanforderungen für jedes Tag setzen und in der Vorschau mit verweigerter Einwilligung testen.

Danach den Test wiederholen und die Tabelle neu ausfüllen. In der Spalte “nach Ablehnen” sollten nur noch Ihre eigene Domain und Dienste stehen, die Sie bewusst zulassen, jeweils mit dokumentierter Begründung. Die DSK erinnert in derselben Orientierungshilfe daran, dass Verantwortliche nach Art. 5 Abs. 2 DSGVO vorab prüfen und dokumentieren müssen, auf welche Rechtsgrundlage sie eine Verarbeitung stützen.

Unser WooCommerce-EU-Readiness-Audit enthält diesen Test für jede Vorlage, und der kostenlose Website-Check zeigt Drittanfragen einer öffentlichen URL.