Cookie-Banner, die nichts bewirken: Tracker vor der Einwilligung
Der Banner ist der sichtbare Teil. Entscheidend ist, welche Requests den Browser verlassen, bevor jemand auf Akzeptieren klickt — und wie Sie sie sehen.
Datenschutz · Veröffentlicht: 28. August 2026 · 3 Min. Lesezeit · Ольга Мирошник
Fast jede Website hat einen Einwilligungsbanner. Überraschend viele davon sind Dekoration: Die Skripte, die der Banner zurückhalten soll, sind längst geladen, wenn er erscheint. Der Banner bittet um Erlaubnis für etwas, das schon passiert ist.
Worauf Aufsichtsbehörden wirklich schauen
Nicht auf das Design. Die Frage ist eng und technisch: Hat zwischen Seitenaufruf und Klick auf Akzeptieren irgendetwas den Browser verlassen, das den Besucher identifiziert? Dazu zählen Analytics-Beacons, Werbepixel, Session-Recorder, eingebettete Videoplayer, Chat-Widgets, Schriftdienste, die IPs protokollieren, und jedes Cookie mit einer Kennung darin.
Daraus folgt zweierlei. Die Ablehnung muss so einfach sein wie die Zustimmung — ein "Alle ablehnen" auf dem ersten Screen, nicht drei Klicks tief in den Einstellungen. Und ein vorangekreuztes Kästchen ist in der EU keine Einwilligung; das ist seit Planet49 geklärt.
Woher die Lecks kommen
Tag-Manager. Der Container selbst ist meist harmlos; die Tags darin feuern beim Seitenaufruf, sofern nicht jeder einzelne an einen Consent-Trigger gebunden ist. Ein vergessener Tag ist ein Verstoß.
Fremde Einbettungen. Ein YouTube-iframe oder eine Karte setzt Cookies in dem Moment, in dem sie rendert. Die Lösung ist ein Platzhalter mit Klick-zum-Laden, nicht ein Absatz in der Datenschutzerklärung.
Die Selbsthosting-Annahme. Eine Schrift oder ein Skript von einem CDN sendet die IP des Besuchers an dieses CDN. Das ist eine Übermittlung, ganz gleich, ob Sie das CDN für einen Tracker halten.
Das Banner-Skript selbst. Mehrere Consent-Plattformen setzen eine Kennung, bevor eine Wahl getroffen wurde — ausgerechnet das Werkzeug, das für die Compliance gekauft wurde.
Wie Sie die Wahrheit sehen
Der Code sagt es Ihnen nicht, das Netzwerk schon. Laden Sie die Seite in einem sauberen Profil, klicken Sie nichts, und zeichnen Sie jeden Request auf:
requests vor der einwilligung
.filter(r => r.setztCookie || r.drittanbieter)
.groupBy(r => r.domain)
Alles auf dieser Liste, was für die Funktion der Seite nicht zwingend nötig ist, ist ein Befund. Wiederholen Sie es mit geklicktem "Alle ablehnen" — bedrückend viele Websites senden in beiden Fällen dieselben Requests. Und noch einmal nach "Akzeptieren", um zu bestätigen, dass die Tags, die feuern sollen, es auch tun.
Die Seiten, die vergessen werden
Der Einwilligungsstatus muss auf der ganzen Website halten, nicht nur auf der Startseite. Kampagnen-Landingpages außerhalb des CMS, alte Microsites auf einer Subdomain, der Checkout und alles, was ein anderer Stack ausliefert — dort wohnen die Ausnahmen. Ein seitenweiser Crawl findet sie; eine manuelle Prüfung der Startseite nie.
Halten Sie die Rechtsseiten ehrlich
Die Datenschutzerklärung sollte dieselben Auftragsverarbeiter nennen, die Ihr Netzwerkprotokoll zeigt. Wenn beide auseinandergehen, ist fast immer die Erklärung veraltet: Ein Dienstleister wurde vor einem Jahr getauscht, und niemand hat es der Rechtsabteilung gesagt. Erklärung, Cookie-Liste und tatsächliche Requests abzugleichen kostet einen Crawl und klärt die Frage, die Sie sonst unter Zeitdruck einer Behörde beantworten.
Ebenfalls lesenswert
Prüfen Sie, was davon auf Ihrer Website steckt
Der kostenlose Scan zeigt kaputte Links, JS-Fehler und Performance-Probleme in einer Minute.