Ein Cookie-Scanner ist ein Werkzeug, das Ihre Website automatisiert aufruft und protokolliert, welche Cookies gesetzt werden und welche externen Dienste dabei Daten anfordern. Das Ergebnis ist eine Bestandsliste: Name, Anbieter, Laufzeit und Zweck der gefundenen Cookies und Tags. Diese Liste ist die Grundlage für alles, was ein Cookie-Banner später behaupten darf.

Wichtig ist die Einordnung gleich zu Beginn: Ein Scan ist eine Momentaufnahme, keine Zusicherung. Er zeigt, was zum Zeitpunkt des Aufrufs unter den Bedingungen des Scanners sichtbar war. Was er nicht gesehen hat, ist damit nicht ausgeschlossen. Wie sich das im Alltag auswirkt und wie oft ein erneuter Lauf nötig ist, behandeln wir in Warum Cookies scannen und erneut scannen.

Dieser Beitrag ist der technische Überblick. Sie erfahren, wie ein Scan abläuft, was jede Art von Scan grundsätzlich sehen kann und was nicht, und vor allem, wie Sie das Ergebnis mit Bordmitteln des Browsers selbst überprüfen. Erst danach geht es darum, wo die Tag-Erkennung von AdOpt in diesen Ablauf passt.

Ein Cookie ist eine kleine Datei, die ein Browser im Endgerät speichert. Ein Tag ist ein Code-Baustein auf Ihrer Seite, meist von einem Drittanbieter, der beim Laden ausgeführt wird. Ein einzelner Tag kann kein, ein oder mehrere Cookies auslösen. Er kann außerdem Daten im Local Storage ablegen oder Informationen des Browsers auslesen.

Für die Prüfung ist diese Unterscheidung wichtig, weil Sie in der Praxis zwei Blickwinkel brauchen. Der Blick auf Cookies sagt Ihnen, was im Gerät gespeichert wurde. Der Blick auf Tags sagt Ihnen, welcher Dienst dafür verantwortlich ist. Ein brauchbarer Scan-Bericht verbindet beides.

Die Details unterscheiden sich von Produkt zu Produkt. Das Grundprinzip ist aber bei den meisten Scannern ähnlich, und es hilft, es einmal zu verstehen, weil sich daraus die Grenzen ableiten lassen.

Ein Scanner ruft eine URL typischerweise mit einem automatisierten Browser auf. Dieser führt das JavaScript der Seite aus, lädt Bilder, Schriften und Skripte nach und verhält sich damit ähnlich wie der Browser eines Besuchers. Ein reiner Abruf des HTML-Quelltextes würde nicht genügen, denn die meisten Tags werden erst durch Skripte nachgeladen.

Ausgangspunkt ist meist ein sauberer Zustand ohne gespeicherte Cookies und ohne getroffene Einwilligungsentscheidung. Genau diesen Zustand sieht auch ein Erstbesucher. Ob und wie Ihr Produkt weitere Zustände simuliert, etwa nach einer Zustimmung, ist eine Frage an die Dokumentation Ihres Anbieters.

Während die Seite lädt, beobachtet der Scanner zwei Dinge. Erstens, welche Cookies und Einträge im Browser-Speicher entstehen. Zweitens, an welche Server die Seite Anfragen sendet. Die zweite Beobachtung ist oft aufschlussreicher, denn manche Dienste setzen zunächst gar keine Cookies, übertragen aber bereits die IP-Adresse und Seiteninformationen an einen fremden Server.

Aus den Anfragen lässt sich ableiten, welche Drittanbieter beteiligt sind. Die Cookies sagen, was gespeichert wurde. Die Anfragen sagen, wer angesprochen wurde. Beides gehört in die Bestandsaufnahme.

Der dritte Schritt ist der, in dem ein Scanner mehr leistet als ein Entwicklerwerkzeug. Die gefundenen Cookies und Tags werden bekannten Diensten zugeordnet und einer Kategorie zugewiesen, etwa notwendig, Statistik oder Marketing. Dafür greifen Scanner auf eine Wissensbasis zurück, die Cookie-Namen und Domains bekannten Zwecken zuordnet.

Wo diese Zuordnung nicht gelingt, bleibt ein Eintrag unklassifiziert. Das ist kein Fehler des Scanners, sondern ein ehrliches Ergebnis: Er kennt den Dienst nicht. Ein Mensch muss dann entscheiden. Wie Sie mit solchen Einträgen umgehen, beschreibt Scan-Ergebnisse richtig lesen.

Am Ende steht ein Bericht. Er ist nur dann nützlich, wenn er in den Hinweis einfließt, den Ihre Besucher sehen. Denn die Aufsichtsbehörden erwarten, dass die Angaben im Banner mit der Wirklichkeit übereinstimmen. Die Orientierungshilfe der Datenschutzkonferenz nennt als typisches Defizit ausdrücklich, dass in Bannern andere Informationen stehen als in der Datenschutzerklärung, etwa andere Rechtsgrundlagen, andere Drittanbieter oder andere Zwecke (OH Digitale Dienste, Version 1.2, Rn. 40).

Ein Scan ohne Übernahme der Ergebnisse ist deshalb eine Bestandsaufnahme ohne Wirkung. Und eine Übernahme ohne technische Sperre der Tags ist eine Beschreibung ohne Durchsetzung. Beide Lücken behandeln wir weiter unten.

Jede automatisierte Prüfung hat einen Sichtbereich. Wer ihn kennt, liest Scan-Ergebnisse richtig. Die folgenden Punkte beschreiben Scanner im Allgemeinen. Was Ihr konkretes Produkt davon abdeckt, entnehmen Sie bitte dessen Dokumentation.

Sichtbar sind Cookies, die beim Laden der aufgerufenen Seite gesetzt werden, Einträge im Local und Session Storage, sowie Anfragen an externe Server, die beim Laden entstehen. Ebenso sichtbar sind Tags, die direkt im Quelltext eingebunden sind oder von einem Tag-Manager beim Laden ausgespielt werden.

Diese Bandbreite ist wichtig, weil § 25 TDDDG nicht nur Cookies erfasst. Die Orientierungshilfe stellt klar, dass die Vorschrift technikneutral formuliert ist und alle Verfahren erfasst, mit denen Informationen gespeichert oder ausgelesen werden können. Als Beispiel nennt sie ausdrücklich auch Web-Storage-Objekte (OH Digitale Dienste, Version 1.2, Rn. 21).

Bestimmte Bereiche entziehen sich einer automatisierten Prüfung systematisch. Prüfen Sie bei Ihrem Produkt jeweils, wie es damit umgeht:

• Seiten, die der Scanner nie aufruft. Ein Scan sieht nur die URLs, die er besucht. Unterseiten mit eigenen Einbindungen bleiben unbemerkt, wenn sie nicht Teil der Prüfung sind.
• Bereiche hinter einem Login. Kundenkonten, Warenkörbe und Bezahlvorgänge lösen oft eigene Tags aus.
• Tags, die erst nach einer Interaktion laden. Ein eingebettetes Video, ein Chat-Widget oder ein Formular lädt oft erst nach einem Klick.
• Bedingte Ausspielung. Tags, die nur bei bestimmten Endgeräten, Regionen oder Kampagnenparametern erscheinen, tauchen nur auf, wenn der Scan diese Bedingung erfüllt.
• Serverseitige Verarbeitung. Was ein Server unsichtbar an einen Dienst weiterreicht, hinterlässt im Browser keine Spur.
• Änderungen nach dem Scan. Ein neuer Tag, der nach dem Lauf eingebaut wird, fehlt im Bericht bis zum nächsten Lauf.

Keiner dieser Punkte ist ein Mangel eines bestimmten Produkts. Es sind Eigenschaften jeder Momentaufnahme. Deshalb bleibt die eigene Gegenprobe im Browser wichtig, die wir gleich beschreiben.

Ein häufiges Missverständnis lautet, es müsse erst ein personenbezogenes Datum im Cookie stehen, damit die Einwilligungspflicht greift. Die Orientierungshilfe sagt das Gegenteil: § 25 Absatz 1 TDDDG begründet ein Einwilligungserfordernis für das Speichern und Auslesen von Informationen unabhängig von einem Personenbezug (OH Digitale Dienste, Version 1.2, Rn. 26 und 28).

Die Vorschrift selbst ist in ihrem ersten Absatz knapp: Speicherung und Zugriff sind nur zulässig, wenn der Endnutzer auf der Grundlage von klaren und umfassenden Informationen eingewilligt hat. Absatz 2 Nummer 2 nimmt nur Vorgänge aus, die unbedingt erforderlich sind, damit ein ausdrücklich gewünschter digitaler Dienst bereitgestellt werden kann (§ 25 TDDDG im Wortlaut).

Für den Scan folgt daraus: Auch ein Cookie, das scheinbar nur eine Zufallszahl enthält, gehört in die Bestandsaufnahme. Die Frage, ob dafür eine Einwilligung nötig ist, entscheiden Sie erst nach dem Blick auf den Zweck, nicht nach dem Blick auf den Inhalt. Warum das den Unterschied zwischen Bestandsaufnahme und Nachweis ausmacht, vertieft der Beitrag zum Scannen nach DSGVO und TDDDG.

Kein Scanner nimmt Ihnen die Gegenprobe ab, und das sollte er auch nicht. Mit einem aktuellen Browser können Sie in zehn Minuten überprüfen, ob das, was Ihr Hinweis und Ihr Scan-Bericht behaupten, mit dem tatsächlichen Verhalten Ihrer Seite übereinstimmt. Das ist der Kern der Verifizierbarkeit: Sie müssen einem Werkzeug nicht glauben, Sie können nachsehen.

Öffnen Sie ein privates Fenster oder ein frisches Browserprofil ohne Erweiterungen. Erweiterungen, etwa Werbeblocker, verändern das Ergebnis. Öffnen Sie die Entwicklerwerkzeuge. In Chrome finden Sie die Cookies unter Application, dort unter Storage und Cookies, nach Auswahl der jeweiligen Domain (Dokumentation zur Cookie-Ansicht in Chrome DevTools).

Dort sehen Sie pro Cookie unter anderem Name, Domain, Ablaufdatum, Größe und Sicherheitsattribute. Ein Filterfeld erlaubt die Suche nach Name oder Wert. Wechseln Sie außerdem einmal zum Netzwerk-Reiter und laden Sie die Seite neu, damit Sie die Anfragen an Drittanbieter mitlesen können.

Laden Sie die Seite, ohne im Banner etwas anzuklicken. Notieren Sie, welche Cookies bereits vorhanden sind und an welche fremden Domains Anfragen gehen. Nach der Orientierungshilfe muss die Einwilligung vorliegen, bevor der einwilligungsbedürftige Zugriff erfolgt. Cookies, die schon beim ersten Aufruf gesetzt werden, um erst danach die Einwilligung abzufragen, sind nicht zulässig (OH Digitale Dienste, Version 1.2, Rn. 36).

Bleiben nur Cookies übrig, deren Zweck Sie belegen können und die für die gewünschte Funktion unbedingt erforderlich sind, ist das ein gutes Zeichen. Jeder andere Eintrag ist eine Frage an Ihr Setup. Welche Cookies unter die Ausnahme fallen, klärt der Beitrag zum Cookie-Banner nach TDDDG.

Löschen Sie alle Websitedaten (Cookies und lokalen Speicher, nicht nur die Cookies), laden Sie die Seite neu und klicken Sie im Banner auf Ablehnen. Sehen Sie sich Cookies, lokalen Speicher und Netzwerkanfragen erneut an. Es dürfen keine Einträge hinzukommen, die einwilligungsbedürftig sind. Wiederholen Sie den Test mit einem sauberen Fenster, nach dem Löschen aller Websitedaten, und mit der Zustimmung. Jetzt sollten die Tags erscheinen, die Sie in Ihrem Hinweis beschrieben haben.

Der Unterschied zwischen beiden Läufen ist Ihr Nachweis im Kleinen. Wenn nach Ablehnen dieselben Anfragen mit denselben Kennungen laufen wie nach Zustimmen, sperrt Ihr Setup nichts. Dann hilft es nicht, dass der Scan alles korrekt aufgelistet hat. Beim erweiterten Consent Mode laden Google-Tags auch nach Ablehnen, senden aber den Status denied und ohne Cookies: Dann zählt, was die Anfragen tatsächlich enthalten, nicht nur, ob ein Tag geladen wurde.

Stellen Sie nun drei Listen nebeneinander: was Ihr Scan gefunden hat, was Ihr Cookie-Hinweis nennt und was Ihre Datenschutzerklärung aufführt. Die drei Listen sollten übereinstimmen. Abweichungen sind fast immer entweder ein veralteter Text oder ein Tag, den niemand dokumentiert hat.

Die Orientierungshilfe verlangt für den Hinweis, dass Nutzende erfahren, wer auf das Endgerät zugreift, in welcher Form und zu welchem Zweck, welche Funktionsdauer die Cookies haben und ob Dritte Zugriff erlangen können (OH Digitale Dienste, Version 1.2, Rn. 37). Dritte sind einzeln zu benennen. Der allgemeine Hinweis auf „Partner“ genügt nicht (Rn. 120). Das ist ein konkreter Maßstab, an dem Sie Ihre drei Listen messen können.

Der Tag-Scanner von AdOpt klassifiziert die Tags, die auf den mit dem Hinweis verknüpften URLs gefunden werden. Ein Tag ist dabei der Auslöser für ein oder mehrere Cookies. Die Funktion steht bereits im kostenlosen Tarif zur Verfügung.

Die Kategorien der AdOpt-Plattform sind notwendig, Marketing bzw. Werbung, Statistik bzw. Analyse, Leistung und funktional. Erkennt der Scanner einen Tag nicht, erscheint er als „Unbekannt“. Diese Einträge muss der Verantwortliche einer der fünf Kategorien zuordnen und die Änderung veröffentlichen. Der Hinweis, den Besucher sehen, enthält dann die Liste der Drittanbieter-Tags und -Cookies mit der von Ihnen festgelegten Einstufung. Besucher können pro Kategorie entscheiden.

Wir sagen hier bewusst nichts zu Scan-Intervall, Tiefe oder Abdeckung von Login-Bereichen, weil wir diese Angaben nicht als Zusage formulieren können. Für jedes Produkt, auch für unseres, gilt: Lesen Sie in der Dokumentation, wie oft der Scan läuft, wie viele Seiten er besucht und was er nicht abdeckt. Verlassen Sie sich nicht auf pauschale Aussagen wie „findet alles“.

Ergänzen Sie den Scan deshalb um die Gegenprobe aus dem vorigen Abschnitt. Sie ist unabhängig von jedem Werkzeug, und sie fällt Ihnen auf, wenn zwischen zwei Scan-Läufen ein Tag hinzugekommen ist.

Ein praktischer Rhythmus verbindet beides. Der Scan liefert die Bestandsliste und die Vorklassifizierung, die Gegenprobe prüft stichprobenartig das Verhalten. Legen Sie fest, wer im Team die Gegenprobe durchführt, wann sie stattfindet und wo das Ergebnis mit Datum abgelegt wird. So entsteht mit wenig Aufwand ein Verlauf, den Sie später vorzeigen können.

Ein solcher Verlauf hat einen Nebeneffekt, den viele unterschätzen: Er zeigt Ihnen, wie schnell sich Ihr Tag-Bestand ändert. Wer in drei Monaten drei neue Dienste findet, weiß, dass der Prüfrhythmus zu lang war.

Eine Klassifizierung sagt, was ein Tag ist. Sie verhindert nicht, dass er lädt. In AdOpt legt die Einstellung „Tag aktiv oder inaktiv“ nur den Standardzustand des Hinweises fest, also ob der Schalter beim ersten Besuch an oder aus ist. Sie ersetzt nicht die Sperre der Tags, die als eigene Funktion, manuell oder automatisch, eingerichtet wird.

Das ist der Punkt, an dem sich Verifizierbarkeit entscheidet. Die Frage lautet nicht „Hat der Scan den Tag gefunden?“, sondern „Läuft der Tag vor der Einwilligung nicht?“. Diese Frage beantwortet der Browser-Test oben, nicht der Bericht. Die Wahl des Besuchers hält AdOpt mit einer eindeutigen CookieID im Browser als Nachweis fest.

Egal, für welches Produkt Sie sich entscheiden: Diese Fragen gehören in jede Bewertung, und die Antworten stehen in der Dokumentation, nicht im Werbetext.

1. Wie oft läuft der Scan, und wodurch wird er ausgelöst? Nur auf Knopfdruck, nach Zeitplan oder bei Änderungen?
2. Wie viele und welche Seiten werden besucht? Nur die Startseite oder auch Unterseiten?
3. Was geschieht mit Bereichen hinter einem Login? Werden sie geprüft oder bleiben sie außen vor?
4. Was passiert mit Einträgen, die nicht erkannt werden? Werden sie gekennzeichnet, oder verschwinden sie?
5. Wie kommt das Ergebnis in den Hinweis? Automatisch, halbautomatisch oder per Hand?

Die Antworten zeigen, wie viel Kontrolle bei Ihnen bleibt. Ein Produkt, das ehrlich sagt, was es nicht sieht, ist meistens verlässlicher als eines, das nichts einschränkt. Wer die Grenzen kennt, kann sie mit organisatorischen Maßnahmen schließen, etwa mit einem festen Prüfrhythmus vor Kampagnenstarts.

Wie Sie Ergebnisse dann konkret lesen und mit den Kategorien arbeiten, zeigt der Praxisbeitrag zum Scan-Audit.

Drei Annahmen begegnen uns immer wieder, und alle drei führen zu einem falschen Sicherheitsgefühl.

„Der Scan war grün, also bin ich fertig.“ Ein Scan bestätigt den Zustand zum Zeitpunkt des Laufs. Er sagt nichts über die Wochen danach und nichts über Seiten, die er nicht besucht hat.

„Was der Scan nicht findet, gibt es nicht.“ Der Scan findet, was unter seinen Bedingungen sichtbar wurde. Serverseitige Vorgänge, Tags hinter einem Login und bedingt ausgespielte Skripte gehören zu den blinden Flecken jeder Momentaufnahme.

„Klassifiziert heißt geschützt.“ Die Klassifizierung ist eine Beschriftung. Geschützt sind Besucher erst, wenn die Tags vor der Einwilligung tatsächlich nicht laufen. Das lässt sich nur im Betrieb prüfen.

Jede dieser Annahmen lässt sich mit dem Browser-Test entkräften, und genau deshalb gehört er in Ihre Routine.

Ein Cookie-Scanner ruft Ihre Website automatisiert auf und protokolliert, welche Cookies, Speichereinträge und externen Anfragen dabei entstehen. Die gefundenen Tags werden Diensten und Kategorien zugeordnet. Das Ergebnis ist eine Bestandsliste für Ihren Cookie-Hinweis und Ihre Datenschutzerklärung. Sie gilt für den Zeitpunkt und die Bedingungen des Laufs und ersetzt keine laufende Kontrolle.

Nein, das kann kein Scanner grundsätzlich zusagen. Er sieht, was unter seinen Bedingungen geladen wird. Unterseiten, die er nicht besucht, Bereiche hinter einem Login, Tags nach einer Interaktion und serverseitige Vorgänge bleiben potenziell unsichtbar. Fragen Sie in der Dokumentation Ihres Produkts nach und ergänzen Sie den Scan um eine eigene Prüfung im Browser.

Nein. Der Scan liefert die Grundlage für die Angaben im Hinweis. Ob die Einwilligung wirksam eingeholt wird und ob einwilligungsbedürftige Tags vor der Entscheidung ruhen, entscheidet sich im Betrieb. Nach der Orientierungshilfe der Datenschutzkonferenz muss die Einwilligung vorliegen, bevor der Zugriff auf das Endgerät erfolgt.

Öffnen Sie ein privates Browserfenster, starten Sie die Entwicklerwerkzeuge und sehen Sie sich Cookies und Netzwerkanfragen an, bevor Sie im Banner etwas anklicken. Wiederholen Sie den Test nach Ablehnen und nach Zustimmen. Vergleichen Sie das Ergebnis mit Ihrem Scan-Bericht, Ihrem Hinweis und Ihrer Datenschutzerklärung. Abweichungen sind Ihre Aufgabenliste.

Er klassifiziert die auf den verknüpften URLs gefundenen Tags in die Kategorien notwendig, Marketing bzw. Werbung, Statistik bzw. Analyse, Leistung und funktional. Was er nicht erkennt, erscheint als „Unbekannt“ und muss von Ihnen einer Kategorie zugeordnet und veröffentlicht werden. Die Funktion ist im kostenlosen Tarif enthalten.

• Warum Cookies scannen und erneut scannen: DSGVO und TDDDG
• Cookie-Audit: Scan-Ergebnisse richtig lesen und Kategorien pflegen
• DSGVO in Deutschland: der vollständige Leitfaden für Unternehmen

---

Ein Scan zeigt, was da ist. Erst die Gegenprobe im Browser zeigt, ob das, was da ist, auch das ist, was Sie Ihren Besuchern sagen.

Wollen Sie wissen, was Ihre Website vor dem ersten Klick tatsächlich setzt?

Vereinbaren Sie ein Gespräch mit unserem Team