Was sind Cookies?

Cookies sind kleine Textdateien, die Websites im Browser des Besuchers speichern. Technisch gesehen ist jeder Cookie ein Schluessel-Wert-Paar mit zusaetzlichen Metadaten (Ablaufdatum, Domain, Pfad, Sicherheitsflags). Der Browser sendet alle passenden Cookies bei jeder HTTP-Anfrage zurueck an den Server, wodurch Websites sich Dinge zwischen Seitenaufrufen "merken" koennen. WordPress nutzt Cookies fuer Login-Sitzungen, Admin-Einstellungen, Kommentarformulare und verschiedene Tracking-Zwecke.

Wie Cookies auf technischer Ebene funktionieren

Wenn deine WordPress-Seite eine Antwort an einen Browser sendet, kann sie einen oder mehrere Set-Cookie-Header enthalten. Jeder Header definiert einen Cookie mit einem Namen, einem Wert und optionalen Attributen wie Ablaufzeit und Geltungsbereich. Bei jeder nachfolgenden Anfrage an dieselbe Domain (und passenden Pfad) fuegt der Browser diese Cookies automatisch in den Cookie-Request-Header ein. Der Server liest sie und nutzt die gespeicherten Daten, um den Nutzer zu identifizieren, den Sitzungszustand wiederherzustellen oder das Verhalten zu verfolgen.

Dieser Mechanismus macht Login-Sitzungen moeglich. Ohne Cookies haette der Server keine Moeglichkeit zu wissen, dass die Person, die das Dashboard anfordert, dieselbe Person ist, die gerade ein Passwort auf der Login-Seite eingegeben hat.

First-Party-Cookies vs. Third-Party-Cookies

Die Unterscheidung zwischen First-Party- und Third-Party-Cookies ist zentral fuer Datenschutzverordnungen und relevant fuer jeden WordPress-Seitenbetreiber:

• First-Party-Cookies: Von deiner eigenen Domain gesetzt. Dazu gehoeren WordPress-Login-Sitzungscookies, DSGVO-Einwilligungspraefereenzen deines Cookie-Banner-Plugins, WooCommerce-Warenkorbinhalte und alle Cookies, die dein Theme oder benutzerdefinierter Code erstellt. First-Party-Cookies gelten allgemein als weniger datenschutzinvasiv, weil sie nur innerhalb deiner eigenen Seite arbeiten.
• Third-Party-Cookies: Von externen Domains ueber Ressourcen gesetzt, die auf deiner Seite geladen werden. Wenn deine WordPress-Seite Google Analytics, das Facebook Pixel, ein YouTube-Embed oder ein Werbescript laedt, setzen diese Dienste eigene Cookies auf anderen Domains. Third-Party-Cookies koennen Besucher ueber mehrere Websites hinweg verfolgen, weshalb sie das Hauptziel von Datenschutzvorschriften sind. Grosse Browser wie Safari und Firefox blockieren Third-Party-Cookies bereits standardmaessig, und Chrome baut sie ebenfalls ab.

Session-Cookies vs. Persistente Cookies

Cookies unterscheiden sich auch darin, wie lange sie bestehen:

• Session-Cookies: Diese Cookies haben kein explizites Ablaufdatum. Sie existieren nur im Speicher des Browsers und werden geloescht, wenn der Browser geschlossen wird. WordPress nutzt Session-Cookies fuer temporaere Zustaende, die nicht dauerhaft gespeichert werden muessen.
• Persistente Cookies: Diese Cookies haben ein definiertes Ablaufdatum und bleiben auf dem Geraet des Besuchers gespeichert, bis dieses Datum erreicht wird (oder der Nutzer sie manuell loescht). Der WordPress-Login-Cookie wordpress_logged_in_* ist ein persistenter Cookie, der typischerweise 48 Stunden dauert, oder 14 Tage, wenn der Nutzer "Angemeldet bleiben" ankreuzt. Google Analytics Cookies wie _ga bestehen standardmaessig 2 Jahre.

WordPress-Standard-Cookies im Detail

Eine Standard-WordPress-Installation setzt mehrere Cookies, die alle bestimmte Zwecke erfuellen:

• wordpress_test_cookie: Wird auf der Login-Seite gesetzt, um zu pruefen, ob der Browser ueberhaupt Cookies akzeptiert. Wenn dieser Cookie blockiert wird, zeigt WordPress einen Fehler an, dass Cookies aktiviert sein muessen, um sich einzuloggen.
• wordpress_logged_in_[hash]: Der Haupt-Authentifizierungs-Cookie fuer eingeloggte Nutzer. Er enthaelt den Benutzernamen, einen Ablauf-Zeitstempel und einen Hash, der verifiziert, dass der Cookie nicht manipuliert wurde. Dieser Cookie wird zur Identifizierung des Nutzers im Frontend verwendet.
• wordpress_[hash]: Ein separater Authentifizierungs-Cookie, der nur im Admin-Bereich (/wp-admin/) verwendet wird. Er bietet eine zusaetzliche Sicherheitsebene, indem er den Zugang zu Admin-Funktionen einschraenkt.
• wp-settings-[uid]: Speichert nutzerspezifische Admin-Interface-Einstellungen wie den Editor-Modus (visuell vs. Code), die Anzahl der Elemente pro Seite in Admin-Listen und Panel-Zustaende.
• wp-settings-time-[uid]: Zeichnet auf, wann der wp-settings-Cookie zuletzt aktualisiert wurde.
• comment_author_[hash]: Merkt sich den Namen, die E-Mail und die URL, die ein Besucher in einem Kommentarformular eingegeben hat, damit er sie beim naechsten Besuch nicht erneut eintippen muss. Wird nur gesetzt, wenn ein Besucher einen Kommentar absendet.

Diese Standard-WordPress-Cookies sind alle First-Party-Cookies und gelten allgemein als essentiell (notwendig fuer die Funktion der Seite). Die Kommentar-Cookies werden allerdings manchmal als nicht-essentiell eingestuft, da das Kommentieren optional ist.

DSGVO, ePrivacy und Cookie-Einwilligungspflichten

Die europaeische DSGVO und die ePrivacy-Richtlinie setzen strenge Regeln fuer Cookies. Fuer WordPress-Seitenbetreiber, die europaeische Besucher ansprechen, gelten diese Regeln unabhaengig vom Serverstandort:

• Essentielle Cookies: Cookies, die strikt notwendig sind, damit die Seite funktioniert (Login-Sitzungen, Sicherheits-Tokens, Warenkorb-Status), erfordern keine Einwilligung. Du musst sie trotzdem in deiner Datenschutzerklaerung offenlegen.
• Nicht-essentielle Cookies: Analytics-Cookies, Marketing-Cookies, Personalisierungs-Cookies und Third-Party-Tracking-Cookies erfordern eine informierte, ausdrueckliche Einwilligung, bevor sie gesetzt werden. Der Besucher muss aktiv zustimmen; vorangekreuzte Boxen oder "Durch Weiternutzung stimmst du zu"-Banner sind keine gueltige Einwilligung.
• Widerrufsrecht: Besucher muessen ihre Einwilligung genauso einfach widerrufen koennen, wie sie sie erteilt haben. Dein Cookie-Banner sollte eine Moeglichkeit bieten, die Praeferenzen jederzeit zu aendern.
• Informationspflichten: Du musst klar erklaeren, was jeder Cookie tut, wer ihn setzt und wie lange er dauert. Diese Informationen werden typischerweise in einer Cookie-Richtlinie oder Datenschutzerklaerung bereitgestellt.

Cookie-Einwilligungsverwaltung fuer WordPress

WordPress enthaelt standardmaessig keinen Cookie-Einwilligungsmechanismus. Du brauchst ein Consent-Management-Plugin. Beliebte Optionen sind:

• Complianz: Ein umfassendes DSGVO/CCPA-Cookie-Einwilligungs-Plugin, das Cookies auf deiner Seite automatisch erkennt und Cookie-Richtlinien generiert.
• CookieYes: Eine weit verbreitete Consent-Management-Plattform mit WordPress-Plugin und Cloud-basiertem Cookie-Scanning.
• Real Cookie Banner: Ein WordPress-spezifisches Einwilligungs-Plugin mit starkem Fokus auf deutsches/europaeisches Datenschutzrecht.
• Borlabs Cookie: Ein Premium-Plugin aus Deutschland, beliebt im DACH-Raum. Es unterstuetzt granulare Cookie-Kategorien und integriert sich mit vielen Drittanbieterdiensten.

Ein korrektes Consent-Management-Setup blockiert nicht-essentielle Cookies und Scripts, bis der Besucher seine Einwilligung gibt. Das bedeutet, Google Analytics, Facebook Pixel und aehnliche Dienste sollten nicht laden oder Cookies setzen, bis der Besucher im Consent-Banner auf "Akzeptieren" klickt.

Cookie-Sicherheitsflags: SameSite, Secure und HttpOnly

Moderne Cookies koennen Sicherheitsflags enthalten, die steuern, wie sie uebertragen und zugaenglich gemacht werden:

• Secure: Der Cookie wird nur ueber HTTPS-Verbindungen gesendet. Ohne dieses Flag koennten Cookies auf unverschluesselten HTTP-Verbindungen abgefangen werden.
• HttpOnly: Der Cookie kann nicht per JavaScript ueber document.cookie ausgelesen werden. Dies verhindert, dass Cross-Site-Scripting (XSS)-Angriffe Sitzungs-Cookies stehlen.
• SameSite: Steuert, ob der Cookie bei Cross-Site-Anfragen gesendet wird. Der Wert Strict bedeutet, der Cookie wird nie cross-site gesendet. Lax erlaubt den Cookie bei Top-Level-Navigationen (wie dem Klicken eines Links), blockiert ihn aber bei Cross-Site-POST-Anfragen und iframes. None (kombiniert mit Secure) erlaubt den Cookie in allen Kontexten, was fuer Third-Party-Cookies notwendig ist, die domainuebergreifend funktionieren muessen.

WordPress setzt das HttpOnly-Flag bei Authentifizierungs-Cookies standardmaessig. Mehr ueber diese Flags erfaehrst du in unserem Artikel ueber HTTP-Sicherheitsheader.

Wie viele Cookies sind zu viele

Jeder Cookie wird bei jeder HTTP-Anfrage an die passende Domain mitgesendet. Das bedeutet, wenn deine WordPress-Seite 20 Cookies mit insgesamt 4KB setzt, werden diese 4KB Cookie-Daten in jeder einzelnen Anfrage fuer Seiten, Bilder, Stylesheets, Scripts und AJAX-Aufrufe mitgeschickt. Bei einer Seite mit 80 Anfragen sind das 320KB zusaetzliche Daten, die hin und her uebertragen werden.

Browser erzwingen Limits fuer Cookies:

• Pro Domain: Die meisten Browser erlauben etwa 50 Cookies pro Domain mit einem Gesamtgroessenlimit von roughly 4KB pro Cookie.
• Total pro Cookie: Der kombinierte Name und Wert eines einzelnen Cookies sollte 4.096 Bytes nicht ueberschreiten.

Wenn deine WordPress-Seite viele Cookies setzt (besonders grosse von Analytics- und Werbe-Scripts), kann das die Seitenladezeiten merklich verlangsamen. Um das zu vermeiden, erwaege, statische Assets von einer cookie-freien Domain oder Subdomain auszuliefern, und minimiere die Anzahl der Drittanbieter-Scripts, die du laedst.

Was InspectWP prueft

InspectWP listet alle Cookies auf, die deine WordPress-Seite waehrend des Crawls setzt, einschliesslich ihrer Namen, Werte, Domains, Pfade und Sicherheitsattribute (Secure, HttpOnly, SameSite). Das hilft dir, Third-Party-Cookies zu identifizieren, die eine DSGVO-Einwilligung erfordern, Cookies von Diensten zu erkennen, die du nicht wissentlich hinzugefuegt hast, und zu ueberpruefen, ob deine Authentifizierungs-Cookies die richtigen Sicherheitsflags gesetzt haben. Die Cookie-Liste in deinem InspectWP-Report ist ein nuetzlicher Ausgangspunkt fuer das Erstellen oder Aktualisieren deiner Cookie-Richtlinie.