Cookie-Banner prüfen: Blockiert er optionale Skripte wirklich? 7 typische Fehler

Ein Klick auf „Alle ablehnen“ beweist noch nicht, dass das Tracking stoppt. Ein Praxisleitfaden zur Banner-Prüfung mit Network, Application, Consent Mode und wiederholbaren Tests.

Sie öffnen eine Website in einem neuen Browserprofil, klicken auf „Alle ablehnen“ und sehen, wie der Cookie-Hinweis verschwindet; von außen wirkt alles in Ordnung, doch wenn Sie einen Cookie-Banner prüfen, beginnt die eigentliche Arbeit genau jetzt: Ging schon vor dem Klick eine Anfrage an eine Werbeplattform, enthielt die Antwort den Versuch, eine Kennung zu setzen, die im Browser-Speicher verblieb, und erhielten die Tags nach der Ablehnung den richtigen Einwilligungsstatus? Der Banner ist nur das Bedienfeld, und das Audit muss zeigen, ob darunter tatsächlich alle Leitungen angeschlossen sind, denn die CMP hat den Standardstatus womöglich noch nicht gesetzt, während der Tag Manager bereits seine erste Regel ausführt.

Eine Sichtprüfung des Banners oder das grüne Häkchen eines automatisierten Scanners verrät nicht, was in den ersten Sekunden des Ladevorgangs geschah, und zeigt ebenso wenig, welches Skript eine Aktion ausgelöst hat, welcher Einwilligungsstatus ihm zu diesem Zeitpunkt vorlag und ob der sichtbare Endzustand zur gesamten vorausgegangenen Ereignisfolge passt. Deshalb vergleichen wir in einer gemeinsamen Zeitleiste das Verhalten der Website vor jeder Auswahl, nach Ablehnung aller optionalen Kategorien, nach der Einwilligung und nach einem späteren Widerruf; in jedem Zustand untersuchen wir Network-Anfragen, Antwort-Header, Cookies, localStorage und weitere Speicher, die Reihenfolge der Einwilligungssignale sowie den konkreten Initiator der jeweiligen Aktion. Erst dieser Vergleich trennt eine korrekte Konfiguration von einem Banner, der sich lediglich schließt.

Dies ist ein technischer Beitrag und keine individuelle Rechtsberatung: Er zeigt, wie Sie überprüfbare Tatsachen sammeln, ohne daraus weiter reichende Schlüsse zu ziehen, als die Belege tragen. Nutzt die Website Google Tag Manager, Google Analytics 4, Google Ads, Meta Pixel, eingebettete Videos, ein Chatfenster oder andere Drittanbieter-Werkzeuge, ist die auf einem Bildschirm sichtbare Cookie-Liste nur ein Teil des Bildes; entscheidend ist daher nicht die Frage „Ist ein Banner installiert?“, sondern „Was tut die Website in jedem Augenblick, in dem der Nutzer eine Auswahl trifft?“.

Cookie-Banner prüfen: was das Audit untersucht – und was es nicht belegt

Das Audit untersucht die technische Einwilligungskette von der ersten Seitenanfrage bis zur Zustandsänderung nach der Auswahl des Nutzers; allein am Endzustand lässt sie sich jedoch nicht beurteilen, weil die anfängliche Ladereihenfolge bereits eine Aktion ausgelöst haben kann, die ein später geschlossener Banner nicht rückgängig macht. Zum Umfang gehören die Reihenfolge beim Laden von Skripten, Netzwerkverbindungen, Cookies und andere Speicher, die Signale der Consent-Management-Plattform (CMP), die Konfiguration von Google Consent Mode (Einwilligungsmodus), das Verhalten der Kategorien und die Möglichkeit, eine Auswahl später zu ändern. Das Ergebnis ist eine Sammlung technischer Belege zur Cookie- und Tracking-Schicht, kein Zertifikat für die rechtliche Fehlerfreiheit sämtlicher Verarbeitungen personenbezogener Daten in der Organisation.

Rechtlich sind zwei miteinander verbundene Ebenen zu trennen: In Deutschland regelt § 25 TDDDG das Speichern von Informationen in der Endeinrichtung des Endnutzers und den Zugriff auf bereits dort gespeicherte Informationen und setzt damit die Vorgabe aus Art. 5 Abs. 3 der ePrivacy-Richtlinie um; dieser technische Anwendungsbereich ist nicht auf Dateien beschränkt, deren Name das Wort „Cookie“ enthält. Die DSGVO wird relevant, wenn personenbezogene Daten verarbeitet werden, und regelt zudem die Qualität einer wirksamen Einwilligung sowie die Grundsätze ihres Widerrufs; die technische Prüfung der einen Ebene ersetzt deshalb nicht die rechtliche Bewertung der anderen. Im Audit-Bericht benennen wir beide Ebenen getrennt, damit eine beobachtete technische Tatsache nicht als umfassenderer rechtlicher Schluss ausgegeben wird.

Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit erläutert, dass technisch nicht erforderliche Tracking-Technologien eine Einwilligung voraussetzen und die Ablehnung ebenso einfach sein muss wie die Zustimmung; doch auch die Kategoriebezeichnung „notwendig“ beweist für sich genommen nichts. Die Ausnahme für unbedingt erforderliche Vorgänge ist eng auszulegen: Die konkrete Aktion muss für einen vom Nutzer ausdrücklich angeforderten Dienst oder für die Übertragung einer Nachricht erforderlich sein, nicht bloß für bequeme Analysen, Marketing oder interne Interessen des Website-Betreibers. Das Audit muss die Aktion deshalb mit der Funktion verknüpfen, die sie erforderlich macht, und zugleich prüfen, ob dieselbe Kategorie nicht einen ganz anderen Zweck verbirgt, den die angeforderte Funktion nicht rechtfertigt.

Die in Suchanfragen verwendete Formulierung „DSGVO-Website-Audit“ bezeichnet bei dieser Leistung ausschließlich den Bereich Cookies, Tracking und Einwilligungsmanagement, denn die Rechtsgrundlagen anderer Prozesse, Anfragen betroffener Personen, Verträge und die interne Governance bleiben außerhalb dieses Umfangs. Unser Cookie- und Tracking-Audit liefert technische Tatsachen, anhand derer ein Jurist oder Datenschutzbeauftragter gerade diesen Teil der Website fundiert bewerten kann; DSGVO-Konformität ist jedoch kein einzelner Schalter, den ein technischer Scanner für die gesamte Organisation umlegen könnte. Diese Abgrenzung ist kein Haftungsausschluss, sondern macht klar, was der Bericht belegt und welche Fragen außerhalb des technischen Audits noch zu entscheiden sind.

Wie das Audit Belege gewinnt statt nur ein Scanner-Ergebnis

Ein belastbarer Test beginnt in einem sauberen Browserprofil ohne zuvor gespeicherte Einwilligung, Website-Cookies oder Anfragen von Erweiterungen; noch vor dem ersten Klick wird das Network-Protokoll aktiviert, der Bereich Application geprüft und der Ausgangszustand dokumentiert. Anschließend wird dieselbe Abfolge nach der Ablehnung, nach der Einwilligung und nach dem Widerruf wiederholt, wobei jedes Szenario von einem dokumentierten Zustand ausgeht und das vollständige Protokoll erhalten bleibt. Andernfalls kann die Auswahl von gestern wie ein Fehler des heutigen Banners aussehen oder, umgekehrt, den wirklichen Fehler verdecken.

Ein Network-Eintrag belegt, dass der Browser versucht hat, eine bestimmte Adresse zu erreichen, und zeigt Initiator, Status, Anfrage- und Antwort-Header sowie übermittelte Informationen; er beweist jedoch noch nicht, dass ein Cookie gespeichert wurde. Der Antwort-Header Set-Cookie zeigt den Versuch des Servers, eines zu setzen, doch der Browser kann diesen Versuch blockieren, während JavaScript über document.cookie oder localStorage ohne einen solchen Header schreiben kann. Das tatsächliche Ergebnis ist deshalb im Bereich Application zu prüfen, und kein einzelnes Indiz darf die übrigen ersetzen. Eine sichtbare Anfrage an eine Analytics-Domain belegt den Versuch eines Datenflusses, aber nicht automatisch, dass ein Analytics-Cookie erfolgreich gesetzt oder ein bestimmter Satz personenbezogener Daten vom Server empfangen wurde.

Für jeden Befund notieren wir die geprüfte URL und den Nutzerpfad, Zeitpunkt, Geräte- und Browserkontext, gewählten Einwilligungsstatus, Initiator der Anfrage, Ziel, Übermittlungsergebnis und Speicheränderungen, damit nach einer Korrektur exakt derselbe Test wiederholt werden kann. Ein automatisierter Scan liefert ein breites Anfangsinventar, durchläuft aber nicht sämtliche Menüs, Kaufschritte, Anmeldebereiche, Sprachfassungen und dynamisch geöffneten Integrationen und kann einen Zweck nicht zuverlässig allein aus Dateinamen oder Domain ableiten; darauf folgen daher manuelle Szenarien und ein Gespräch mit den Verantwortlichen der Werkzeuge. Dabei klären wir, wer das Werkzeug eingeführt hat, welchem Zweck es dient, in welchem Tag-Container es liegt und welchem Einwilligungssignal es folgen soll, damit sich der technische Befund mit der beabsichtigten Konfiguration verbinden lässt. Ein Beleg ohne Kontext ist nur ein Screenshot; Kontext ohne Beleg ist nur ein Versprechen.

1. Optionale Skripte starten vor der Auswahl des Nutzers

Ein kritischer Reihenfolgefehler entsteht, wenn der CMP-Banner zwar schnell sichtbar wird, der Analytics- oder Werbe-Tag aber bereits gestartet ist: Der Nutzer liest noch die Schaltflächen, während der Browser schon einen Drittanbieter kontaktiert oder eine Kennung gespeichert hat. Die Vorgabe ist an diesem Punkt eindeutig: Nicht erforderliche Cookies dürfen nicht vor der Auswahl aktiviert werden. Die technische Prüfung beginnt deshalb mit dem ersten Laden des Dokuments und nicht erst in dem Moment, in dem das Audit die Schaltfläche „Alle ablehnen“ gefunden und betätigt hat.

In einer Google-Tag-Manager-Umgebung liegt die Ursache häufig in einer falschen Ereignisreihenfolge, denn der Standardstatus der Einwilligung muss vor den Tags gesetzt werden – über den Trigger „Initialisierung der Einwilligung“ oder eine andere Lösung, die dieselbe Reihenfolge garantiert – und erst nach der Nutzeraktion wird eine Aktualisierung gesendet. Trifft der Standard zu spät ein, kann ein Tag für einen kurzen Moment einen undefinierten oder früher gespeicherten Zustand sehen und starten; ein Banner, der sich schneller schließt, behebt dieses Rennen nicht, weil der Fehler in der Ausführungsreihenfolge und nicht in der Animation liegt.

Die Aussage „Cookies werden vor der Einwilligung geladen“ muss im Audit präziser aufgeteilt werden: Möglich sind das Laden des Skripts selbst, eine Network-Anfrage, ein Signal ohne Cookies, der Versuch, per Set-Cookie etwas zu setzen, oder eine tatsächlich gespeicherte Kennung, und jede dieser Aktionen besitzt einen anderen Beweiswert. Beim Advanced Consent Mode, dem erweiterten Einwilligungsmodus, können bestimmte Google-Tags trotz verweigertem Speicherzugriff laden und Messungen ohne Cookies senden; die bloße Anwesenheit des Skripts genügt daher weder als Nachweis eines Verstoßes noch als Beleg für Konformität.

Die Korrektur beginnt mit einer Werkzeugkarte und einem eindeutigen Zustandsmodell: Welche Tags dürfen ohne Auswahl laufen, welche benötigen eine bestimmte Kategorie, und welches Ereignis ändert den Standardstatus? Nach der Konfigurationsänderung wiederholen wir die Prüfung in einem sauberen Profil und mit erhaltenem Network-Protokoll, wobei die ersten Anfragen und ihre Initiatoren besondere Aufmerksamkeit erhalten. Tritt der Fehler nur gelegentlich auf, spricht das meist für ein Rennen zwischen CMP, Tag-Container und Website-Code, das in der Ladereihenfolge selbst beseitigt werden muss, statt es hinter einem optisch schnelleren Banner zu verbergen.

2. „Alle ablehnen“ ändert die Oberfläche, aber nicht den Datenfluss

Eine Schaltfläche kann den Banner schließen, die Auswahl grau markieren und sogar den Wert „denied“ speichern, während Drittanbieter-Tags unverändert weiterlaufen; beim Ablehnungstest geht es daher nicht um einen verschwundenen Hinweis, sondern um den Vergleich zweier Zustände. Vor und nach der Ablehnung aller optionalen Kategorien erfassen wir Anfragen und Speicher und prüfen anschließend, ob die betreffenden Tags kein auslösendes Ereignis mehr erhalten, ob keine neuen Kennungen erscheinen und ob weitere Seitenaufrufe die Ablehnung beibehalten. Eine frühere Sitzung verfälscht diesen Test leicht: Wurde gestern eingewilligt, kann die Website heute zunächst mit dem gestrigen Zustand laden und ihn erst durch „Alle ablehnen“ ändern, nachdem die erste Anfrage bereits gesendet wurde. Auch das manuelle Löschen von Cookies zwischen den Schritten schafft eine künstliche Sauberkeit und prüft den echten Widerrufsmechanismus nicht. Die anfängliche Ablehnung und der spätere Widerruf sind deshalb getrennte Szenarien: Das erste beginnt ohne Entscheidung, das zweite mit einer bewusst erteilten Einwilligung, und ihre Ergebnisse dürfen nicht in einem Screenshot vermischt werden.

Auch nach einer Ablehnung darf eine Website Aktionen ausführen, die für eine vom Nutzer ausdrücklich angeforderte Sicherheits-, Warenkorb- oder andere Funktion tatsächlich erforderlich sind; die Behauptung „Jede Anfrage nach der Ablehnung ist schlecht“ wäre deshalb ebenso ungenau wie das grüne Häkchen des Banners. Für jede verbleibende Verbindung sind Zweck, Initiator und Speichervorgang zu klären. Danach wird die CMP so konfiguriert, dass die Ablehnung zuerst den Einwilligungsstatus aktualisiert und die Tags eingebaute oder ausdrücklich festgelegte Einwilligungsprüfungen verwenden; funktional ist eine Schaltfläche erst, wenn sie den darunter angeschlossenen Datenfluss auf mehreren Seiten vorhersehbar verändert. Stoppt die Ablehnung den Werbe-Tag, lässt aber ein First-Party-Session-Cookie bestehen, kann das dem erwarteten Ergebnis entsprechen; aktiviert eine Kategorie stillschweigend eine andere, ist die Konfiguration nicht verlässlich. Nach der Korrektur muss sich die Ablehnung auf mehreren Seiten ohne manuelles Leeren des Speichers wiederholen lassen und jedes Mal einen gleichen, reproduzierbaren und belegbaren Zustand ergeben.

3. Kategorien und Cookie-Richtlinie entsprechen nicht dem wirklichen Inventar

Ein Banner kann technisch diszipliniert arbeiten und dennoch irreführen, wenn Kategorien oder Richtlinie eine andere Website beschreiben, wie es nach dem Kopieren einer Vorlage, der Übernahme eines Tag-Containers oder dem Hinzufügen eines neuen Werkzeugs ohne Aktualisierung der Dokumentation vorkommt. Dann steht in der Richtlinie noch ein längst nicht mehr verwendetes Cookie, während Video-Player, Chatfenster oder der Tag einer Werbe-Conversion unerwähnt bleiben, und der Nutzer entscheidet auf Grundlage unvollständiger Informationen. Das Unternehmen kann in dieser Lage nicht begründen, welcher Empfänger Daten erhält, zu welchem Zweck dies geschieht und wie lange eine Kennung bestehen bleibt.

Eine Cookie-Richtlinie muss sich am tatsächlichen Inventar orientieren und Zweck, Dienstanbieter oder Empfänger sowie Speicherdauer nennen, nicht bloß das wiedergeben, was der Katalog einer CMP automatisch erkannt hat. Ein Cookie mit demselben Namen kann in verschiedenen Konfigurationen anders verwendet werden, während für eine individuelle First-Party-Kennung möglicherweise überhaupt keine Beschreibung in einer öffentlichen Datenbank existiert. Das Audit verbindet das technische Objekt deshalb mit dem wirklichen Zweck des Website-Betreibers und dem verantwortlichen Werkzeug. Seine Aufgabe besteht nicht darin, die Vermutung eines Katalogs abzuschreiben, sondern zu prüfen, ob Konfiguration, Empfänger und Dauer dem entsprechen, was das Unternehmen tatsächlich nutzt und erklären kann.

Das Inventar endet nicht im Tab Cookies: Zu prüfen sind localStorage, sessionStorage, IndexedDB, Pixel- und Serveranfragen sowie Kennungen in URL- oder Formularabläufen, sofern sie am Tracking beteiligt sind. Die technischen Leitlinien des Europäischen Datenschutzausschusses (EDSA) verdeutlichen, dass der ePrivacy-Anwendungsbereich nicht an eine einzelne Speichertechnologie gebunden ist; eine Richtlinie mit dem Versprechen „Wir verwenden keine Cookies“ beantwortet daher noch nicht, ob die Website mit einer anderen Methode auf Informationen im Endgerät zugreift oder Messsignale sendet. Eine Liste von Cookie-Namen ist somit der Beginn der Inventarisierung, nicht die vollständige Übersicht über Technologien, die Kennungen speichern, auslesen oder versenden können.

Eine praktische Korrektur ist ein zentrales Quellregister, aus dem sowohl die CMP-Klassifizierung als auch die technische Tabelle der Richtlinie und die Audit-Szenarien gepflegt werden; jeder Eintrag nennt den internen Verantwortlichen für das Werkzeug, Anbieter, Zweck, auslösenden Einwilligungsstatus, verwendeten Speicher, Empfänger und Dauer. Das Hinzufügen eines neuen Tags ist dann nicht mehr nur eine Arbeit im Google-Tag-Manager-Container, sondern eine kontrollierte Änderung, bei der vor der Veröffentlichung die Information für den Nutzer und die Testfälle aktualisiert werden müssen. Dasselbe Register liefert nach der Änderung den Ausgangspunkt für einen wiederholbaren Test und zeigt, wer im Unternehmen für die Behebung einer Abweichung verantwortlich ist.

4. Eine Network-Anfrage wird mit dem Nachweis eines Cookies verwechselt

Eine im Network-Bereich sichtbare Analytics-Domain ist ein wichtiger Befund, doch allein daraus folgt nicht die Aussage „Ein Cookie wurde gesetzt“: Der Eintrag belegt den Verbindungsversuch und zeigt, was der Browser der URL, den Headern oder dem Anfrageinhalt hinzugefügt hat; eine fehlgeschlagene, blockierte oder abgebrochene Anfrage ist jedoch nicht dasselbe wie Daten, die der Server erfolgreich empfangen hat. Für den Cookie-Teil ist zu prüfen, ob der Anfrage-Header Cookie enthielt, ob in der Antwort Set-Cookie erschien, ob der Browser dies blockierte und ob der Eintrag tatsächlich im Speicher ankam. Eine Anfrage kann blockiert oder abgebrochen werden, bevor der Server Daten erhält, und diese Grenze des Belegs muss auch die Formulierung des Befunds widerspiegeln, statt Verbindungsversuch, Übermittlungsergebnis und Speicherung in einer Behauptung zusammenzufassen.

Auch der umgekehrte Schluss ist nicht sicher, denn eine Anfrage ohne Cookie kann den Einwilligungsstatus und andere Parameter enthalten, während die Website eine localStorage-Kennung, einen URL-Parameter oder eine andere technische Methode nutzt; das Fehlen eines Cookies macht die Verbindung nicht automatisch anonym oder leer. Umgekehrt ist Set-Cookie eine Anweisung des Servers an den Browser und keine Garantie für die Speicherung, weil der Browser sie aufgrund der Domain, von Sicherheitsattributen, Drittanbieter-Beschränkungen oder einer anderen Richtlinie ablehnen kann; ein per JavaScript gesetztes First-Party-Cookie kann wiederum ohne diesen Antwort-Header erscheinen. Die DevTools zeigen auch Blockierungsgründe, weshalb Set-Cookie zusammen mit der Entscheidung des Browsers und dem tatsächlichen Application-Zustand zu lesen ist. Fehlt im Cookies-Tab eine neue Zeile, färben wir das Signal nicht zu „ohne Daten“ um, sondern prüfen URL, Header, Parameter und weitere Speicher.

Die sicherste Methode verbindet drei Ansichten in einer Zeitleiste: Was löste die Anfrage aus, was wies der Server an und was blieb anschließend in genau diesem Browserprofil gespeichert? Der Audit-Bericht nennt bewusst nur das Belegte. Darin steht etwa „Vor der Auswahl wurde eine Anfrage an Domain X gesendet“, „In der Antwort wurde der Versuch festgestellt, ein Cookie zu setzen“ oder „Nach der Ablehnung verblieb die Kennung Y im Bereich Application“, denn ein Entwickler kann einen solchen Schritt wiederholen, der Jurist erkennt die Grenzen der technischen Tatsache und das Ergebnis lässt sich nach der Korrektur objektiv vergleichen. Aus einem einzelnen Screenshot leiten wir nicht die gesamte Verarbeitungskette ab, weil er nur die konkrete Aktion, den Zustand und den Zeitpunkt belegen kann, in dem er aufgenommen wurde.

5. Der Widerruf der Einwilligung ist versteckt oder technisch unvollständig

Eine Einwilligung ist kein einmaliger Klick, den die Website anschließend vergessen darf: Art. 7 Abs. 3 DSGVO sieht vor, dass sie jederzeit widerrufen werden kann, und verlangt, dass der Widerruf so einfach ist wie ihre Erteilung. Kann die Einwilligung direkt im ersten Bildschirm der Startseite erteilt werden, während für den Widerruf ein Unterabschnitt der Datenschutzerklärung gesucht, eine E-Mail geschrieben oder der Browser-Speicher geleert werden muss, ist der Mechanismus nicht gleichwertig zugänglich; eine übliche Lösung ist ein dauerhafter Link zur Verwaltung der Auswahl im Footer der Website. Seine Auffindbarkeit prüfen wir von jeder Seite und auch dann, wenn der Banner nicht mehr sichtbar ist, denn genau in diesem Zustand möchte ein Nutzer seine frühere Entscheidung ändern.

Der technische Test beginnt mit einer bewusst erteilten Einwilligung und tatsächlich aktivierten Tags. Anschließend öffnet das Audit die Auswahlverwaltung, widerruft die optionalen Kategorien und navigiert weiter durch die Website, ohne durch manuelles Löschen des Speichers einen künstlichen Neuanfang zu erzeugen. Zu prüfen ist, ob die CMP den aktualisierten Zustand sendet und die Tags ihn empfangen, ob keine neuen einwilligungsbasierten Datenflüsse mehr beginnen und was mit lokal gespeicherten Kennungen geschieht; so wird eine Schaltfläche sichtbar, die zwar die neue Auswahl speichert, aber bereits geladenen Tags nichts davon mitteilt. Zugleich halten wir die Reihenfolge der Änderungsereignisse fest, um eine korrekt gespeicherte Auswahl von einer Lage zu trennen, in der der abhängige Tag das Update zu spät oder gar nicht erhält.

Der Widerruf wirkt für die Zukunft und schreibt weder die Vergangenheit um noch löscht er von sich aus alle zuvor rechtmäßig verarbeiteten Daten. Nach dem Widerruf muss die weitere Verarbeitung beendet werden, die auf dieser Einwilligung beruhte; die Speicherung oder Löschung bereits serverseitig empfangener Daten kann jedoch eine gesonderte Bewertung erfordern. Im Audit-Bericht trennen wir deshalb das Stoppen künftiger Datenflüsse von der Frage nach der Speicherung früherer Daten und versprechen nicht, dass eine technische Auswahländerung beides erledigt. Die Korrektur muss Oberfläche und Integration verbinden: Der Link muss auf jeder Seite auffindbar sein, die CMP den aktuellen Zustand anzeigen, die Änderung jeden abhängigen Tag erreichen und der Test mit mehreren Kombinationen von Kategorien wiederholt werden, denn „Alles ablehnen“ kann funktionieren, während das einzelne Abschalten des Marketing-Schalters ohne Wirkung bleibt. Auch die Löschung von Browser-Kennungen ist nach deren Funktion zu beurteilen; ein Klick in der CMP leert nicht automatisch jedes System eines Drittanbieters.

6. Basic und Advanced Consent Mode werden verwechselt oder modellierte Daten versprochen

Basic und Advanced Consent Mode sind nicht zwei Gestaltungen desselben Schalters: Im Basic-Modus, dem einfachen Einwilligungsmodus, werden Google-Tags vor der Einwilligung nicht geladen, und Google erhält bis dahin keine Messdaten aus diesen Tags; nach der Einwilligung können die Tags mit der üblichen Messung beginnen. Im Advanced-Modus, dem erweiterten Einwilligungsmodus, laden sie mit anfangs verweigertem Speicherzugriff und können Messungen ohne Cookies senden, solange keine Einwilligung vorliegt. Dieser Modus darf daher nicht als Zustand beschrieben werden, in dem „nichts gesendet wird“, und Basic ist nicht automatisch die schlechtere Analytics-Konfiguration. Der Unterschied liegt im tatsächlichen Verhalten der Tags vor der Auswahl, nicht im Aussehen des Banners oder im Namen einer einzelnen Einstellung.

Die Wahl muss auf der rechtlichen Bewertung und den Analytics-Anforderungen des Unternehmens beruhen, nicht auf der Annahme, der Name eines Google-Produkts löse ePrivacy- oder DSGVO-Anforderungen von selbst. Die Google-Dokumentation zum Einwilligungsmodus trennt das Blockieren von Tags im Basic-Modus von Messungen ohne Cookies im Advanced-Modus; im Audit prüfen wir jedoch die reale Konfiguration: Gelten die Standardwerte vor den Tags, welches Update wird nach dem Klick gesendet, und welche Anfragen erscheinen in jedem Zustand tatsächlich? Der Name eines Produktmodus ist kein rechtlicher Schluss, weshalb der Bericht den geprüften Datenfluss und die gewählte Konfiguration des Unternehmens beschreibt, anstatt ihnen automatisch ein Konformitätslabel zu verleihen.

„Ohne Cookies“ bedeutet nicht „ohne Informationen“; der Name eines Signals darf im Bericht daher nicht die Prüfung seines Inhalts und Zwecks ersetzen. Im Network-Bereich sind Ziel, Parameter, Einwilligungsstatus und Initiator zu untersuchen, während Google Tag Assistant oder die Debugging-Werkzeuge für Consent Mode dabei helfen, Standard- und aktualisierte Zustände zu prüfen. Diese Ansichten ergänzen einander: Die erste zeigt den Datenfluss des konkreten Versuchs, die zweite die Konfigurationslogik. Widersprechen sie einander, erhält nicht der schönere Bildschirm den Vorzug; stattdessen ist zu ermitteln, wo das Standard- oder Update-Ereignis den Tag nicht in der vorgesehenen Reihenfolge erreicht hat.

Auch modellierte Daten sind keine garantierte Belohnung für das Einschalten des Advanced-Modus, denn die Verfügbarkeit der Verhaltensmodellierung in Google Analytics 4 hängt von den von Google festgelegten Property-, Datenvolumen- und Qualitätsbedingungen ab und kann fehlen oder wieder entfallen, wenn diese nicht länger erfüllt sind. Die Modellierung stellt keine einzelnen Sitzungen ablehnender Nutzer wieder her. In einem Angebot versprechen wir deshalb eine korrekte Konfiguration und eine überprüfbare Reihenfolge der Signale, nicht eine bestimmte Menge modellierter Daten, die vom Google-System und der Eignung der jeweiligen Property abhängt. Das Ergebnis des Audits ist somit eine reproduzierbare Konfiguration samt Signalprüfung und kein Versprechen über ein Datenvolumen, das der Dienstleister nicht kontrolliert.

7. Der Test endet auf der ersten Seite und am ersten Tag

Die Startseite deckt das Tracking-Inventar selten vollständig ab: Ein Video-Tag lädt womöglich erst beim Abspielen, eine Kartenintegration auf der Kontaktseite, eine Werbe-Conversion nach dem Absenden eines Formulars, ein Zahlungswerkzeug im letzten Schritt des Warenkorbs und ein Chat- oder Personalisierungsskript nach einer bestimmten Zeit. Wer eine einzige URL öffnet, einige Sekunden wartet und den Scanner schließt, kann einen technisch richtigen Bericht über diese eine Ansicht verfassen und zugleich einen gefährlich unvollständigen Bericht über die gesamte Website. Jeder dieser Zustände muss durch die Aktion geöffnet werden, die ihn wirklich auslöst; das Inventar der Startseite darf nicht automatisch als Stellvertreter aller Templates und Nutzerpfade gelten.

Die Szenarien bauen wir nach realen Nutzerpfaden und Website-Templates auf und decken öffentliche Seiten, Beiträge, Kontaktformulare, Kontobereiche, Kaufprozesse, eingebettete Inhalte sowie jede wesentliche Sprach- oder Regionalfassung ab. Auch das mobile Layout ist zu prüfen, in dem CMP-Schaltflächen einander überlagern oder der Link zur Auswahl unerreichbar werden kann, obwohl am Desktop alles funktioniert. Ein automatisierter Crawl liefert Breite, während ein manuelles Szenario jene Zustände öffnet, die ein Bot ohne Konto, Klick oder Eingabe nie erreicht. Sprach- und Regionalfassungen sind ebenso wenig dekorative Duplikate wie das mobile Layout, wenn sich darin geladene Integrationen oder die dem Nutzer angebotenen Auswahlmöglichkeiten unterscheiden.

Ein einmaliges Audit deckt Veränderungen im Zeitverlauf nicht ab, denn ein neuer Marketing-Tag, ein ausgetauschtes CMP-Template oder ein importierter Google-Tag-Manager-Container kann eine zuvor korrekte Reihenfolge stören, ohne den Banner sichtbar zu verändern. Deshalb braucht jedes neue Werkzeug einen Test vor der Veröffentlichung und einen anschließenden Vergleich. Diese Disziplin sollte bereits im Vertrag zur Website-Entwicklung eingeplant werden, wie wir im Beitrag über 10 Fehler bei der Beauftragung einer Website-Entwicklung erläutert haben. In unserem Audit-Prozess ist nach der Umsetzung ein erneuter Scan nach 30 und 180 Tagen mit denselben Szenarien und Belegfeldern vorgesehen, damit sichtbar wird, ob die Korrektur den realen Veröffentlichungsalltag übersteht und ob später neue Werkzeuge oder Konfigurationsabweichungen hinzugekommen sind. Der erste Termin zeigt, ob die Umsetzung dem täglichen Betrieb standhält, der zweite spätere Veränderungen; beim Wiederholungstest vergleichen wir konkrete Anfragen, Speicher und Einwilligungsstatus mit dem ursprünglichen Befund, statt uns auf den Eindruck zu beschränken, es sehe „jetzt besser aus“.

Was Sie im technischen Cookie- und Tracking-Audit erhalten

Das erste Ergebnis des Audits ist ein geprüftes Inventar von Cookies, Speichern, Tags und Drittanbieter-Anfragen. Jeder Befund ist mit Seite, Nutzeraktion und Einwilligungsstatus verbunden; daneben stehen der Beleg und seine Grenze: ein Network-Eintrag, ein Versuch per Set-Cookie, ein tatsächlich im Bereich Application gespeichertes Cookie, ein localStorage-Eintrag oder ein CMP-Ereignis. Der Entwickler erhält damit einen reproduzierbaren Fehler statt der vagen Notiz „DSGVO reparieren“, während die datenschutzverantwortliche Person erkennt, welche Tatsachen noch eine rechtliche Entscheidung verlangen. Für jeden Befund bleibt zudem ein Wiederholungsweg, damit nach der Umsetzung genau dieselbe Seite, Auswahl, Anfrage und Speicherwirkung geprüft werden kann.

Der zweite Teil ist die Umsetzung: Wir ordnen CMP-Kategorien sowie die Reihenfolge der Standard- und Update-Ereignisse im Google Tag Manager, konfigurieren die Einwilligungsprüfungen für Google Analytics 4, Google Ads, Meta Pixel und weitere Werkzeuge und erstellen die Texte für Cookie-Erklärung und Datenschutzerklärung. Basic oder Advanced Consent Mode wählen wir anhand Ihrer rechtlichen Bewertung und Ihrer Analytics-Anforderungen, ohne Advanced als universell richtige Variante darzustellen oder modellierte Daten zu versprechen, wenn die betreffende Google-Property Googles Bedingungen nicht erfüllt. Das Ergebnis der Umsetzung prüfen wir in denselben Einwilligungszuständen, in denen der ursprüngliche Befund erfasst wurde, damit sich die Konfigurationsänderung mit vergleichbaren Belegen begründen lässt.

Die Leistung kostet ab 800 €, die Umsetzung dauert 1–4 Wochen, abhängig vom Umfang der Website, der Zahl ihrer Sprachen und Templates, der Komplexität von CMP und Tag-Containern sowie der Anzahl benötigter Integrationen. Vor Beginn trennen wir in Preis und Zeitplan klar zwischen Audit-Belegen, technischen Korrekturen und Fragen, die der Jurist oder Datenschutzbeauftragte des Unternehmens entscheiden muss; nach 30 und 180 Tagen führen wir einen erneuten Scan anhand der festgelegten Szenarien durch. Preis und Dauer beziehen sich damit auf einen eindeutig benannten technischen Umfang und nicht auf das unbestimmte Versprechen, den gesamten Datenschutz des Unternehmens zu ordnen.

Benötigen Sie ein „DSGVO-Website-Audit“, klären wir zunächst, dass dies hier den Umfang Cookies, Tracking, CMP und Consent Mode meint und keine vollständige Prüfung der DSGVO-Konformität der gesamten Organisation. Wir versprechen daher nur, was technisch belegbar ist: das Verhalten der Website vor der Auswahl, nach Ablehnung, nach Einwilligung und nach deren Widerruf, die an Werkzeuge übermittelten Signale sowie die Stellen, an denen die Belege für einen rechtlichen Schluss noch nicht ausreichen. Diese Trennung ermöglicht es, die technische Arbeit mit einem überprüfbaren Ergebnis abzuschließen und die Rechtsfragen an die Person zu übergeben, die für die umfassendere Verarbeitung personenbezogener Daten verantwortlich ist. Fragen Sie Ihr Cookie- und Tracking-Audit an, indem Sie uns die Adresse Ihrer Website und die verwendete CMP oder Ihren Tag Manager nennen.