Pre-Consent-Cookies

Cookies, die vor der Consent-Entscheidung gesetzt werden, sind ein typischer Compliance-Befund.

Was wird geprüft

Liest den Set-Cookie-Header der ersten Antwort, vor jeder Consent-Entscheidung.

Warum ist das wichtig

Cookies, die vor der Consent-Entscheidung gesetzt werden, sind ein typischer Compliance-Befund.

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.

So beheben

CMP-Tag-Blocking aktivieren; Session-Cookies (PHPSESSID etc.) als essential markieren.

Passende Vorlage

CMP- und GTM-Consent-QA-Vorlage

Der wiederholbare Testplan für Default-denied, Consent-Update und Reject, über alle vier Signale.

QA-Vorlage holen →

Erst selbst prüfen

Der Tracking-Check testet diesen Punkt zusammen mit allen anderen in Sekunden.

Tracking-Check starten →

Verwandte Checks

Pre-Consent-Scripts →Cookie-Banner / CMP →3rd-Party-Cookies →

Häufige Fragen

Was bedeutet ein negativer Befund im Check Pre-Consent-Cookies?

Cookies, die vor der Consent-Entscheidung gesetzt werden, sind ein typischer Compliance-Befund. CMP-Tag-Blocking aktivieren; Session-Cookies (PHPSESSID etc.) als essential markieren.

Wie behebt man einen negativen Befund im Check Pre-Consent-Cookies?

CMP-Tag-Blocking aktivieren; Session-Cookies (PHPSESSID etc.) als essential markieren.

Behebung

Verdrahtet in Tagen, nicht in Sprints.

Befunde aus dem Tracking-Check gehen im Audit Sprint in eine Reihenfolge mit Aufwand, jeder Baustein mit Abnahmekriterium.

Zur Leistung Audit Sprint anfragen