Warum setzt eine Website trotz „Ablehnen" Cookies? Die 8 häufigsten Ursachen
Praxis
Kurz gesagt
Nach dem Klick auf „Ablehnen" laufen trotzdem Tracking-Cookies
Wenn nach dem Klick auf „Ablehnen" weiterhin Tracking-Cookies gesetzt werden, liegt das fast nie am Consent-Banner selbst, sondern daran, dass das Banner die betreffenden Skripte technisch nicht blockiert. Ein Banner zeigt eine Auswahl an – ausführen oder verhindern muss sie die Website. Zwischen beidem klafft in der Praxis eine Lücke, und zwar auf sehr vielen Seiten mit korrekt aussehendem Banner.
Was „Ablehnen" technisch bedeuten müsste
Wenn eine Besucherin ablehnt, dürfen ab diesem Moment keine nicht-notwendigen Cookies mehr gesetzt und keine Daten mehr an Analyse- oder Marketingdienste übertragen werden. Bereits gesetzte, nicht-notwendige Cookies sollten zusätzlich gelöscht werden. Erlaubt bleibt nur, was für den Betrieb der Seite unerlässlich ist – dazu zählt insbesondere das Cookie, in dem die Ablehnung selbst gespeichert wird.
Ein Consent-Tool erreicht das auf einem von zwei Wegen: Entweder es hält Skripte zurück, bis eine Einwilligung vorliegt (Skript-Blocking), oder es signalisiert den eingebundenen Diensten den Consent-Status, damit diese sich selbst zurückhalten (z. B. Google Consent Mode). Beide Wege können unabhängig voneinander scheitern.
Die acht häufigsten Ursachen
1. Skripte sind fest im Quelltext eingebunden
Der mit Abstand häufigste Fall. Das Analytics- oder Pixel-Snippet steht als normales <script src="..."> im Template, das Consent-Tool kennt es nicht und blockiert es deshalb auch nicht. Das Banner erscheint, die Ablehnung wird brav gespeichert – und das Skript ist längst geladen. Erkennbar daran, dass die Cookies schon vor jeder Interaktion gesetzt werden.
2. Der Tag Manager lädt ohne Consent-Bedingung
Der Google Tag Manager selbst ist harmlos, die darin konfigurierten Tags sind es nicht. Feuern Tags auf All Pages statt auf ein Consent-Event oder ohne die entsprechenden Consent-Einstellungen, setzen sie ihre Cookies unabhängig von der Auswahl im Banner. Klassisch ist auch der Fall, dass ein neu angelegter Tag nachträglich hinzugefügt und dabei die Consent-Bedingung vergessen wurde.
3. Consent Mode ist konfiguriert, blockiert aber nicht
Der Google Consent Mode ist kein Blocker, sondern eine Signalisierung. Steht analytics_storage auf denied, verzichtet Google Analytics auf das Setzen von Cookies, sendet aber weiterhin cookielose Pings. Das kann rechtlich zulässig sein – wichtig ist zu verstehen, dass „Consent Mode aktiv" nicht gleichbedeutend mit „es fließen keine Daten" ist. Setzt der Consent Mode dagegen erst nach dem ersten Seitenaufruf ein oder fehlt der Standardzustand denied, laufen die ersten Sekunden ungeschützt.
4. Eingebettete Inhalte von Drittanbietern
YouTube-Videos, Google Maps, per CDN geladene Schriften, Social-Media-Feeds, Chat-Widgets, Bewertungssiegel und reCAPTCHA setzen eigene Cookies oder bauen Verbindungen zu fremden Servern auf, sobald das iFrame lädt. Consent-Tools blockieren Skripte oft zuverlässig, iFrames im Seitentemplate dagegen nicht. Abhilfe: Zwei-Klick-Lösung oder Platzhalter, die den Inhalt erst nach Einwilligung nachladen.
5. Das Blocking greift erst nach dem Neuladen
Manche Konfigurationen setzen die Auswahl erst beim nächsten Seitenaufruf um. Wer ablehnt und auf derselben Seite bleibt, wird bis zum Klick auf den nächsten Link weiter getrackt. In Logfiles fällt das kaum auf, in einem phasenweisen Scan sofort.
6. Falsche Kategorisierung im Consent-Tool
Viele Consent-Management-Plattformen kategorisieren erkannte Cookies automatisch vor. Landet ein Marketing-Cookie in der Kategorie „Notwendig", wird es korrekterweise nie blockiert – die Ursache liegt dann nicht in der Technik, sondern in einer ungeprüft übernommenen Voreinstellung. Ein Blick in die Kategorienliste des eigenen Tools lohnt fast immer.
7. Caching und CDN liefern eine alte Version aus
Wird die Seite gecacht ausgeliefert, kann eine ältere Fassung mit fest eingebundenem Tracking-Snippet noch wochenlang im Umlauf sein, obwohl im CMS längst korrigiert wurde. Typisch nach einem Relaunch oder einer Consent-Tool-Umstellung.
8. Serverseitiges Tracking
Bei serverseitigem Tagging läuft die Erfassung ganz oder teilweise über die eigene Domain. Clientseitige Blocker greifen dann nicht mehr, und die gesetzten Cookies sehen aus wie Erstanbieter-Cookies. Die Einwilligungspflicht richtet sich aber nach dem Zweck, nicht danach, wer den Cookie technisch setzt.
Welche Cookies nach dem Ablehnen unkritisch sind
Nicht jedes Cookie nach dem Ablehnen ist ein Problem. Regelmäßig unkritisch sind:
- das Consent-Cookie, in dem die Ablehnung gespeichert wird
- Session-Cookies für Warenkorb, Login oder Formularzustand
- Cookies zur Lastverteilung (Load Balancing) und zum CSRF-Schutz
- Cookies, die eine bewusst getroffene Nutzereinstellung speichern, etwa die Sprachwahl
Auffällig sind dagegen Cookies mit Laufzeiten von Monaten oder Jahren, Cookies von Domains wie doubleclick.net, facebook.com oder google-analytics.com sowie Erstanbieter-Cookies mit typischen Analyse-Namen wie _ga, _gid oder _fbp.
In fünf Minuten selbst nachweisen
- Browser im Inkognito-Modus öffnen, damit keine Altbestände stören.
- Entwicklertools öffnen (F12), Tab Application → Cookies.
- Seite laden, noch nichts klicken, und die gesetzten Cookies notieren. Alles, was hier schon steht, ist Phase 1 – ohne jede Einwilligung.
- Im Banner auf „Ablehnen" klicken. Die Cookieliste erneut ansehen: Ist etwas dazugekommen? Wurde etwas gelöscht?
- Im Tab Network auf die Zieldomains achten – Anfragen an Analyse- und Marketingdienste sind ebenso aussagekräftig wie die Cookies selbst, weil dabei bereits die IP-Adresse übertragen wird.
- Denselben Test auf einer Unterseite wiederholen, idealerweise auf einer mit Video-Einbettung oder Formular.
Wer das für mehr als eine Handvoll Seiten machen muss, stößt schnell an Grenzen: Der Test ist manuell, schlecht dokumentierbar und nach jedem Deployment hinfällig.
Automatisiert prüfen
Genau dafür gibt es Cookienator. Das Tool lädt jede Seite in einem echten Headless-Chrome, klickt den Cookie-Banner selbst und vergleicht drei Phasen: vor der Interaktion, nach „Ablehnen" und nach „Akzeptieren". Erfasst werden alle gesetzten Cookies mit Kategorie, Herkunft und Laufzeit sowie Anfragen an bekannte Analyse- und Marketingdienste. Am Ende steht ein eindeutiges Prüfergebnis: Bestanden, Prüfen oder Verstoß. Im Free-Tarif prüfst du damit kostenlos die Startseite deiner Domain; ab dem Pro-Tarif folgt der Scanner auch internen Links und findet Fehler, die nur auf einzelnen Unterseiten auftreten. Die bezahlten Tarife prüfen zudem automatisch und wiederkehrend und benachrichtigen dich, wenn sich etwas ändert – wichtig, weil die oben beschriebenen Ursachen fast alle nachträglich entstehen: durch ein neues Tag, ein Plugin-Update oder eine neue Einbettung.
FAQ
Häufige Fragen
Das hängt vom Zweck des Cookies ab. Nach § 25 TDDDG ist das Speichern von Informationen auf dem Endgerät ohne Einwilligung nur zulässig, wenn es für den vom Nutzer ausdrücklich gewünschten Dienst unbedingt erforderlich ist. Analyse- und Marketing-Cookies erfüllen diese Ausnahme in der Regel nicht. Die konkrete Bewertung gehört in fachkundige Hände – ein Scan liefert dafür die technische Grundlage.
Consent-Management-Plattformen prüfen meist ihre eigene Konfiguration. Was außerhalb ihrer Kontrolle passiert – fest eingebundene Skripte, iFrames, serverseitiges Tracking – taucht dort nicht auf. Eine unabhängige Messung von außen sieht dagegen, was im Browser tatsächlich geschieht.
Nein. Kampagnen-Landingpages, Blogartikel mit Videoeinbettung, Buchungs- und Checkout-Strecken werden häufig von anderen Personen gepflegt und enthalten zusätzliche Einbindungen. Fehler treten überdurchschnittlich oft genau dort auf.
Bleiben nicht-notwendige Cookies nach der Ablehnung auf dem Gerät liegen, wird die Ablehnung faktisch nicht umgesetzt. Ein sauber konfiguriertes Consent-Tool entfernt sie deshalb aktiv.
Nachgekaut