Cookie-Banner testen: Was setzt die Seite, bevor jemand klickt?
Ein echtes Chromium in der EU öffnet die URL, wartet auf das Banner, notiert jedes Cookie und jede Drittanbieter-Anfrage bis dahin, drückt dann Alle ablehnen über den Weg des CMP und notiert erneut. Du siehst dem Browser dabei zu.
Gib eine öffentliche Seiten-URL ein. Der Scan dauert fünfzehn bis dreißig Sekunden, der Browser ist währenddessen eingeblendet.
Diese Prüfung öffnet einen echten Browser auf unseren Servern und braucht JavaScript in deinem.
Beobachtungen, keine Urteile. Deine Eingabe wird für dieses Ergebnis verarbeitet und in ein Nutzungsjournal geschrieben, das die Datenschutzerklärung beschreibt; sonst wird nichts gespeichert.
Drei Listen statt einer Ampel
Der Bericht trennt, was ein Cookie-Scanner sonst gern zusammenwirft.
Vor der Entscheidung
Alle Cookies im Jar und alle Anfragen der Seite, nach registrierbarer Domain gruppiert und gezählt, im Zustand vor der Antwort auf das Banner. Dazu die Millisekunde, in der das Banner sichtbar wurde.
Der Ablehnen-Pfad
Wie die Ablehnung zustande kam: Alle-ablehnen-Schaltfläche auf der ersten Ebene, SDK-Aufruf des CMP, per Text gefundener Button, oder gar nicht, weil kein Ablehnen-Element gefunden wurde und das Banner stehen blieb.
Nach der Ablehnung
Noch einmal alle Cookies, aufgeteilt in: war vorher schon da, hat das CMP selbst gesetzt, um die Entscheidung zu merken, und ist trotz Ablehnung neu dazugekommen.
So läuft ein Scan ab
-
Frischer Browser, EU-Adresse
Kein Profil, keine alten Cookies. Die Seite wird geladen, der Scan wartet bis zu fünf Sekunden auf ein Consent-Banner.
-
Zustand festhalten
Cookie-Jar und Netzwerkprotokoll werden gelesen, bevor irgendjemand auf irgendetwas geklickt hat. Auch Cookies aus eingebetteten Frames sind dabei.
-
Ablehnen wie das CMP es vorsieht
Ein Erkenner für Usercentrics, Cookiebot, OneTrust, consentmanager und Borlabs findet das Ablehnen-Element oder ruft das SDK. Passt keiner, sucht eine Heuristik einen Ablehnen-Button per Text. Nichts wird per CSS versteckt.
-
Vergleichen
Zweiter Blick in den Jar. Der Bericht zeigt CMP, Bannerzeit, beide Cookie-Listen, die Drittanbieter vor der Entscheidung und den Ablehnen-Pfad.
Wie der Check funktioniert und wo er aufhört
Der Scan ist eine ganz normale Browserberg-Session, die den Consent-Bericht ausführt, denselben Code, mit dem der Consent-Autopilot arbeitet, wenn ein Agent eine Seite für einen Kunden öffnet. Ein Modell ist nicht beteiligt. Ein Container startet, Chromium navigiert, und der Bericht entsteht aus dem Cookie-Jar des Browsers und seinem Netzwerkprotokoll. Die Scans dieser Seite laufen als gemessene Sessions einer eigenen Organisation, gedeckelt pro Besucher und pro Tag; an einem vollen Nachmittag kann das heißen, dass du kurz warten musst.
Warum ein Browser und kein Abruf per HTTP
Die meisten Cookies, um die es geht, setzt JavaScript, oft ein Tag-Manager mehrere Sekunden nach dem HTML. Ein serverseitiger Abruf sieht davon nichts. Der Check wartet, bis sich die Seite beruhigt hat und das Banner steht, und liest dann den Jar so, wie Chromium ihn hält.
Der Ablehnen-Pfad ist der spannende Teil
Ein Consent-Dialog kann technisch ablehnbar sein und trotzdem einen Besucher, der nicht will, über drei Ebenen schicken. Der Bericht hält fest, wie die Ablehnung erreicht wurde. Die Erkenner schalten auf sicher: Hat ein CMP seine Test-Ids seit dem Schreiben des Erkenners umbenannt, wird nichts gedrückt, das Banner wird als offen gemeldet, und die Nachher-Listen bleiben leer statt erfunden.
Was das Tool bewusst nicht entscheidet
Ein Cookie vor der Entscheidung ist eine Beobachtung. Ob es eine Einwilligung gebraucht hätte, ist eine Frage nach seinem Zweck, und der Zweck steht nicht im Namen. Ein Session-Cookie vom Load-Balancer und eine Werbe-ID sehen für einen Browser gleich aus. Der Bericht hat deshalb keine Spalten namens notwendig, technisch erforderlich oder Verstoß. Er liest keine Datenschutzerklärung, vergleicht die Cookie-Liste im CMP nicht mit dem, was tatsächlich gesetzt wurde, und sieht keine Cookies auf Unterseiten, die du nicht gescannt hast.
Aus demselben Grund enthält der Bericht keine Aussage zu § 25 TDDDG oder zur DSGVO. Beobachtungen, keine Rechtsberatung. Was ein Datenschutzbeauftragter, eine Entwicklerin oder ein Journalist damit anfängt, ist eine Bewertung, die das Tool nicht treffen kann und nicht vorgibt zu treffen. Es liefert das Material: Namen, Hosts, Zeiten und den Weg, den ein ablehnender Besucher gehen muss.
Was gespeichert wird
Die eingegebene URL landet nur im Nutzungsjournal, das die Tagesgrenze ehrlich hält. Der Bericht existiert in deinem Browser-Tab, und sobald die Session freigegeben ist, nirgendwo sonst.
Fragen zu Cookie-Scannern
Wie finde ich heraus, welche Cookies eine Website setzt?
Mit leerem Profil öffnen und in den Entwicklerwerkzeugen unter Speicher nachsehen, oder diesen Check nutzen. Der tut dasselbe in einem Chromium in der EU und liefert dazu die Zeitachse: was vor der Antwort auf das Banner da war und was danach.
Sagt mir das Tool, ob mein Cookie-Banner in Ordnung ist?
Nein. Es berichtet, was im Browser passiert ist. Ob ein bestimmtes Cookie eine Einwilligung gebraucht hätte, hängt von seinem Zweck ab, und den sieht man von außen nicht.
Warum sind nach Alle ablehnen trotzdem Cookies da?
Drei Gründe kommen ständig vor: Das CMP merkt sich die Ablehnung in einem Cookie, First-Party-Cookies wie eine Session-ID werden unabhängig von der Einwilligung gesetzt, und manche Tags feuern vor dem Banner und ihre Cookies bleiben einfach. Der Bericht trennt die drei.
Kann ich auch Alle akzeptieren testen?
Das öffentliche Tool drückt Ablehnen. Die API dahinter nimmt eine policy von reject, accept oder detect-only, sodass eine eigene Session alle drei vergleichen kann.
Geht das auch hinter einem Login?
Nicht mit dem öffentlichen Tool, das nur eine URL nimmt. In deiner eigenen Session läuft derselbe Consent-Bericht nach einem Login aus dem Zugangsdaten-Tresor auf jeder Seite, die die Session erreicht.
Den Bericht auf jeder Seite abrufen, die du automatisierst
Fünf Browserstunden, keine Karte. Consent-Bericht aus der eigenen Session mit reject, accept oder detect-only.