Was wird geprüft
Im Tiefenscan: Der Browser lädt die Seite, wartet auf das Banner und klickt die Ablehnen-Option auf der ersten Ebene. Danach zählt alles, was noch passiert: Requests an Hosts, die der Scan als Marketing, Analytics oder Tag Manager kennt, und Cookies mit den Namen bekannter Tracker, _ga, _fbp, _gcl_au und Verwandte. Bleibt die Liste leer, ist die Zeile „ok“. Steht etwas darin, ist sie kritisch und nennt bis zu fünf Absender.
Zwei Sonderfälle. Der Abruf von gtm.js oder gtag.js allein zählt nicht, weil Consent Mode Advanced den Container absichtlich lädt und erst die Pings entscheiden. Und findet der Browser keinen Ablehnen-Button auf der ersten Ebene, wertet er den Zustand ohne Interaktion als Reject-Lauf; feuert dabei nichts, bleibt die Zeile „zu prüfen“ statt „ok“, denn einen Pass für einen Button, den es nicht gab, vergibt der Scan nicht.
Was der Scan nicht sieht: Requests, die erst nach Scrollen oder einem Klick entstehen, Tracker hinter unbekannten Hostnamen und alles nach dem Zeitlimit von 28 Sekunden. Läuft die Consent-Simulation nicht, fehlt diese Zeile ganz.
Warum ist das wichtig
Ein Banner, dessen „Ablehnen“ nichts bewirkt, liefert die Beschwerde, die sich am leichtesten belegen lässt: Screenshot vom Klick, Screenshot vom Netzwerk-Log, fertig. Mehr Beleg braucht eine Beschwerde nicht. Technisch ist die Ursache fast immer dieselbe. Die Einwilligung wird gespeichert, aber nicht an die Tags gebunden; das CMP führt Buch, und die Skripte laufen trotzdem. Der Tiefenscan sieht das in Sekunden, weil er nicht liest, was das Setup verspricht, sondern was der Browser tut.
Häufige Ursachen
- Die Tags sind im Tag-Manager nie an den Consent-Status gebunden, das Banner ist faktisch Deko.
- Ein nach dem CMP-Setup ergänztes Pixel wurde nie kategorisiert und läuft am Tag-Blocking vorbei.
- Hartkodierte Tracking-Snippets im Theme oder Template feuern außerhalb des Tag-Managers.
- Das CMP speichert die Ablehnung korrekt, aber bereits geladene Skripte laufen in der Session einfach weiter.