Was wird geprüft
Im HTTP: Der Scan ruft die Seite einmal auf, ohne Browser und ohne Klick, und liest die Set-Cookie-Header der Antwort nach dem letzten Redirect. Kein Cookie heißt „ok“. Jedes Cookie heißt „zu prüfen“, mit den ersten drei Namen in der Zeile. Der Scan bewertet die Namen nicht, er kennt den Zweck nicht. Wer den Scan als „Cookieless“ startet, bekommt einen Hinweis statt „zu prüfen“.
Was der Scan hier nicht sieht: Cookies, die JavaScript setzt. _ga, _fbp, _gcl_au und Verwandte entstehen im Browser, und die prüft der Tiefenscan im Befund Reject wird respektiert, getrennt nach Accept- und Reject-Zustand. Cookies fremder Domains stehen im Befund 3rd-Party-Cookies.
Warum ist das wichtig
Der Server setzt Cookies, bevor irgendein Banner erscheint. Das ist für Session, Warenkorb und Load Balancer in Ordnung und für alles andere nicht. Das Problem ist selten der Verstoß, sondern die Lücke in der Dokumentation: Die Datenschutzerklärung listet die Cookies des Analytics-Tools, aber nicht das Varianten-Cookie des serverseitigen A/B-Tests, nicht das Affiliate-Cookie aus dem Backend, nicht das Cookie des Bot-Schutzes. Genau diese Namen liefert der Scan. Wer sie einmal mit der Erklärung abgleicht, hat den Teil des Audits erledigt, den Prüfer als Erstes aufschlagen.
Häufige Ursachen
- Server-seitige Session- oder Load-Balancer-Cookies (PHPSESSID, AWSALB) sind harmlos, gehören aber als essential dokumentiert.
- Ein CDN oder Bot-Schutz setzt eigene Cookies, die in der Cookie-Dokumentation schlicht fehlen.
- Das Backend schreibt Affiliate- oder Attributions-Cookies schon mit der ersten Antwort, vor jeder Einwilligung.
- Server-seitiges A/B-Testing verteilt Varianten-Cookies vor der Consent-Entscheidung.