Was ist ein Cookie?

HTTP ist ein zustandsloses Protokoll: Jede Anfrage des Browsers an einen Server steht für sich, ohne Erinnerung an die vorherige. Cookies lösen genau dieses Problem. Besucht man eine Website, kann der Server in seiner Antwort den Header Set-Cookie mitschicken, ein Name-Wert-Paar samt optionalem Ablaufdatum, Domain und Sicherheits-Attributen.

Der Browser speichert diese kleine Datei und schickt sie bei jeder weiteren Anfrage an dieselbe Domain automatisch im Cookie-Header zurück. So merkt sich ein Onlineshop den Warenkorb zwischen zwei Seitenaufrufen, und so bleibt man eingeloggt, ohne bei jedem Klick das Passwort einzugeben. Der technische Standard RFC 6265 beschreibt Cookies deshalb als Mechanismus zur Zustandsverwaltung über ein Protokoll, das im Kern keinen Zustand kennt.

Nicht jedes Cookie erfüllt denselben Zweck. Manche sind für den Betrieb der Seite unverzichtbar, etwa das Sitzungs- oder Warenkorb-Cookie, andere speichern nur Präferenzen wie Sprache oder Währung, wieder andere existieren allein zur Reichweitenmessung oder für Werbung. Gerade Letztere berühren das technische SEO direkt, weil sie bestimmen, welche Skripte vor oder nach der Einwilligung des Nutzers laden.

Die Grenze zwischen beiden hängt nicht vom Inhalt des Cookies ab, sondern davon, wer es setzt und von welcher Domain aus. Derselbe Analytics-Anbieter kann als First-Party-Cookie laufen, wenn er auf der eigenen Domain konfiguriert ist, oder als Third-Party-Cookie, wenn sein Skript direkt von seiner eigenen Domain lädt.

Ein Session-Cookie trägt kein Ablaufdatum: Es lebt, solange der Browser geöffnet ist, und verschwindet beim Schließen. Es hält zum Beispiel ein halb ausgefülltes Formular oder eine aktive Anmeldung fest. Ein persistentes Cookie dagegen trägt das Attribut Expires oder Max-Age und überlebt Tage, Monate oder Jahre, bis zu diesem Datum oder bis der Nutzer es manuell löscht. Browser räumen Session-Cookies beim Schließen zuverlässig auf, weshalb sie sich für kurzlebige, sensible Zustände wie eine Zahlungssitzung eignen.

Das Attribut SameSite entscheidet, ob ein Cookie auch bei Anfragen von einer anderen Domain mitgeschickt wird. Mit Strict läuft es nur bei Anfragen, die von der eigenen Seite ausgehen; mit Lax, dem Standardwert der meisten modernen Browser, auch beim direkten Navigieren zur Seite; mit None geht es in jedem Kontext mit, verlangt dafür aber das Attribut Secure und eine HTTPS-Verbindung. Diese Kontrolle entstand als Antwort auf CSRF-Angriffe, bei denen eine bösartige Website ausnutzte, dass der Browser Session-Cookies einer anderen Seite unbemerkt mitschickte.

Neben SameSite schließen zwei weitere Attribute die Lücke: HttpOnly verhindert, dass JavaScript das Cookie im Browser ausliest, und Secure erzwingt die Übertragung ausschließlich über HTTPS. Wird ein Third-Party-Cookie blockiert, weichen manche Werbetreibende auf Alternativen wie den Tracking-Pixel oder Fingerprinting aus, jeweils mit eigenen technischen und rechtlichen Grenzen.

In der EU braucht jedes Cookie, das nicht zwingend für den Betrieb der Seite nötig ist, die vorherige Einwilligung des Nutzers, laut Artikel 5.3 der ePrivacy-Richtlinie (2002/58/EG). Erlaubt das Cookie außerdem, eine Person zu identifizieren, greift zusätzlich die DSGVO als Datenschutzrahmen. Deshalb erfüllt jeder Cookie-Banner, der wirklich Skripte blockiert, bis der Nutzer entscheidet, eine echte rechtliche Funktion, weit über die Optik hinaus.

Die Haltung der Browser zu Third-Party-Cookies hat mehrfach gewechselt. Safari blockiert sie seit 2020 standardmäßig per Intelligent Tracking Prevention, Firefox seit 2019 per Enhanced Tracking Protection. Chrome dagegen, das jahrelang die Abschaffung angekündigt hatte, änderte den Kurs: Im April 2025 bestätigte Google, dass Third-Party-Cookies ohne den geplanten zusätzlichen Hinweis-Dialog bleiben, und im Oktober 2025 stellte der Konzern die meisten Privacy-Sandbox-APIs ein, die als Ersatz entwickelt worden waren, weil die Branche sie kaum nutzte.

Für Website-Betreiber heißt das praktisch: First-Party-Cookies bleiben die stabilere Basis für Analytics und Personalisierung, während man sich bei Third-Party-Cookies darauf einstellen muss, dass Safari und Firefox sie weiterhin blockieren, auch wenn Chrome sie nun doch nicht abschafft. Eine Prüfung des technischen SEO sollte deshalb erfassen, welche Cookies vor der Einwilligung laden, ein häufiger Fehler, der sowohl die Rechtskonformität als auch die Ladezeit belastet.

• Jedes Cookie nach Zweck klassifizieren, notwendig, Präferenzen, Statistik oder Marketing, bevor die Cookie-Richtlinie geschrieben wird, nicht danach.
• SameSite=Lax als Standardwert setzen und None nur für Cookies reservieren, die wirklich domainübergreifend funktionieren müssen.
• Jedes Session-Cookie mit Secure und HttpOnly versehen, um das Diebstahlrisiko durch ein bösartiges Skript zu senken.
• Skripte von Drittanbietern erst nach ausdrücklicher Einwilligung laden; nur das Setzen des Cookies zu blockieren reicht nicht aus.
• Persistenten Cookies ein realistisches Ablaufdatum geben: Ein Präferenz-Cookie muss nicht zwei Jahre leben, wenn der Nutzer seine Wahl vorher ändert.
• In der Cookie-Richtlinie den echten Namen jedes Cookies, den Anbieter und die Laufzeit dokumentieren, keine generische Beschreibung.

• Das Analytics- oder Tracking-Pixel-Skript laden, bevor der Nutzer zugestimmt hat, auch wenn der Cookie-Banner schon sichtbar ist.
• "First-Party-Cookie" mit "datenschutzfreundlich" verwechseln: Auch ein First-Party-Cookie kann sensible Daten sammeln, wenn es nicht sorgfältig gestaltet ist.
• Session-Cookies ohne Secure setzen, auf Seiten, die Teile des Inhalts noch über HTTP ausliefern, und die Sitzung damit im Klartext exponieren.
• Davon ausgehen, Chrome habe Third-Party-Cookies bereits abgeschafft, ein Irrglaube, der seit 2020 kursiert und den Google selbst im April 2025 widerlegt hat.
• SameSite=None vorsorglich bei allen Cookies setzen, was die Angriffsfläche für CSRF unnötig vergrößert.