Schreibtisch mit Keksen – Symbolbild für WordPress Cookie-Einstellungen

Bei WordPress geht es nicht darum, möglichst viele Cookies in einem Banner aufzulisten. Entscheidend ist, was der Browser vor einer Entscheidung speichert, ausliest oder an externe Anbieter überträgt. Genau das wird bei vielen Installationen nicht sauber geprüft.

Stand: August 2026. Dieser Beitrag wurde vollständig überarbeitet. Er berücksichtigt § 25 TDDDG, aktuelle Anforderungen an Consent-Banner, Borlabs Cookie 3, Google Consent Mode v2 und typische Fehler bei extern geladenen Inhalten. Er ist eine technische Orientierung und keine individuelle Rechtsberatung.

Die Kurzfassung

  • Einwilligungspflichtige Speicher-, Lese- und Datenzugriffe müssen bis zur aktiven Zustimmung blockiert bleiben.
  • Statistik, Marketing und die meisten externen Medien dürfen grundsätzlich erst nach einer aktiven Zustimmung laden.
  • „Ablehnen“ muss so einfach erreichbar sein wie „Alle zulassen“.
  • Optionale Kategorien dürfen nicht vorausgewählt sein.
  • Die Entscheidung muss später leicht geändert oder widerrufen werden können.
  • Nach Plugin-, Theme-, Tag-Manager- oder Cache-Änderungen muss erneut getestet werden.

Braucht jede WordPress-Website ein Cookie-Banner?

Nein. Wenn eine Website ausschließlich technisch unbedingt erforderliche Funktionen nutzt und weder Informationen auf dem Endgerät für optionale Zwecke speichert noch darauf zugreift, ist dafür keine Einwilligung nach § 25 TDDDG nötig. Die datenschutzrechtliche Prüfung und die Informationspflichten nach der DSGVO entfallen dadurch nicht.

Der Begriff „Cookie-Banner“ greift außerdem zu kurz. § 25 TDDDG betrifft nicht nur Cookies, sondern grundsätzlich auch andere Zugriffe auf Informationen im Endgerät – etwa Local Storage, Tracking-Pixel oder vergleichbare Technologien. Ob dabei personenbezogene Daten verarbeitet werden, muss zusätzlich nach der DSGVO beurteilt werden.

Die Ausnahme für „notwendige“ Technik ist eng: Ein Dienst ist nicht schon deshalb erforderlich, weil er für Marketing, Komfort oder die eigene Auswertung nützlich ist. Er muss für einen von der nutzenden Person ausdrücklich gewünschten digitalen Dienst unbedingt erforderlich sein.

Rechtsgrundlage zum Nachlesen: § 25 TDDDG – Schutz der Privatsphäre bei Endeinrichtungen.

Welche Cookies setzt WordPress selbst?

WordPress Core verwendet vor allem funktionale Cookies für angemeldete Benutzer:innen und bestimmte Komfortfunktionen. Dazu gehören insbesondere:

  • Login- und Authentifizierungs-Cookies wie wordpress_[hash] und wordpress_logged_in_[hash],
  • Cookies für persönliche Einstellungen im Administrationsbereich wie wp-settings-*,
  • das temporäre wordpress_test_cookie auf der Login-Seite,
  • bei aktivierter Kommentarfunktion und entsprechender Auswahl Cookies für Name, E-Mail-Adresse und Website kommentierender Personen.

Für nicht angemeldete Besucher:innen, die nicht kommentieren, setzt WordPress Core damit nicht automatisch Analyse- oder Marketing-Cookies. In der Praxis entstehen die relevanten zusätzlichen Datenflüsse meistens durch Themes, Plugins, Tracking-Codes und eingebettete Inhalte.

Auch funktionale Cookies sollten mit Zweck und Speicherdauer korrekt dokumentiert werden. „Technisch erforderlich“ bedeutet nicht, dass sie in der Datenschutzerklärung verschwiegen werden dürfen. Technische Details findest du in der offiziellen WordPress-Dokumentation zu Cookies.

1. Erst die tatsächlichen Datenflüsse prüfen

Ein Consent-Plugin kann nur kontrollieren, was korrekt eingebunden wurde. Lädt ein Theme, Plugin oder der Google Tag Manager ein Skript unabhängig vom Consent-Tool, hilft auch ein optisch perfektes Banner nicht.

Erstelle deshalb zuerst eine Bestandsaufnahme:

  • Welche Analyse-, Marketing- und Conversion-Dienste sind aktiv?
  • Welche externen Medien werden eingebettet – etwa YouTube, Vimeo, Google Maps, Social Feeds oder Buchungstools?
  • Welche Formulare, Captcha-, Chat- und Newsletter-Dienste werden verwendet?
  • Welche Skripte kommen über Theme, Plugins, Header-Code, Tag Manager oder CDN?
  • Welche Cookies, Local-Storage-Einträge und externen Requests entstehen vor einer Auswahl, nach „Ablehnen“ und nach „Alle zulassen“?

Prüfe nicht nur die Startseite. Teste mindestens eine Seite mit Formular, eingebettetem Video, Tracking, Shop- oder Buchungsfunktion sowie alle abweichenden Landingpages.

Scanner helfen – aber sie beweisen keine Rechtssicherheit

Ein Dienst wie CookieMetrix kann als schneller Erstcheck nützlich sein. Solche Scanner erfassen aber häufig nur eine einzelne URL und eine bestimmte Testsituation. Sie ersetzen weder eine manuelle Browserprüfung noch die Kontrolle verschiedener Consent-Zustände.

2. Google Fonts und andere externe Dateien lokal laden

Werden Google Fonts direkt von fonts.googleapis.com oder fonts.gstatic.com geladen, stellt der Browser eine Verbindung zu Google her. Dabei werden technisch bedingt unter anderem IP-Adresse und Request-Daten übertragen.

Die saubere Standardlösung ist deshalb: benötigte Schriftdateien lokal hosten und externe Font-Aufrufe vollständig entfernen. Prüfe dabei nicht nur das Theme. Auch Page Builder, Formular-, Popup-, Slider- und andere Plugins können Fonts nachladen.

Kontrolliere anschließend in den Entwicklerwerkzeugen des Browsers den Bereich „Network“. Suche dort unter anderem nach googleapis, gstatic und externen Font-Dateien. Ein pauschaler „Font Blocker“ sollte nicht die erste Wahl sein: Besser ist es, die Ursache direkt zu beseitigen.

3. Videos, Karten und andere Drittinhalte blockieren

Eingebettete Inhalte können bereits beim Seitenaufruf Verbindungen zu Dritten aufbauen – auch wenn noch niemand ein Video abspielt oder eine Karte bedient. Das betrifft je nach Einbindung beispielsweise YouTube, Vimeo, Google Maps, Instagram-Feeds, Chat-Systeme oder Terminbuchungstools.

Für einwilligungspflichtige Inhalte sollte vor der Freigabe nur ein lokaler Platzhalter erscheinen. Erst nach der passenden Zustimmung darf der externe Inhalt geladen werden. Der Platzhalter sollte verständlich benennen:

  • welcher externe Anbieter eingebunden wird,
  • dass beim Entsperren Daten an diesen Anbieter übertragen werden können,
  • welche Consent-Kategorie dafür benötigt wird,
  • wie die Datenschutzhinweise erreichbar sind.

Ein „datenschutzfreundlicher“ Einbettungsmodus kann die Datenmenge reduzieren. Er ersetzt aber nicht automatisch die Prüfung, ob vor der Einwilligung bereits externe Requests entstehen.

4. Consent-Banner richtig gestalten

Für eine klare erste Ebene hat sich folgende Struktur bewährt:

  • Alle zulassen
  • Ablehnen
  • Anpassen

„Ablehnen“ bedeutet dabei: Alle optionalen Dienste bleiben deaktiviert; unbedingt erforderliche Funktionen dürfen weiterlaufen. In der Detailansicht können Nutzer:innen einzelne Kategorien oder Dienste auswählen und diese Entscheidung anschließend über „Auswahl speichern“ bestätigen.

Wichtig: Die Buttons müssen nicht zwangsläufig exakt dieselbe Farbe haben. Unzulässig beziehungsweise hochriskant ist aber eine manipulative Gestaltung, die Zustimmung deutlich hervorhebt und Ablehnung versteckt, abschwächt oder mit mehr Klicks erschwert. Größe, Kontrast, Position, Beschriftung und Klickaufwand müssen insgesamt eine echte, gleichwertige Wahl ermöglichen.

Zusätzlich gilt:

  • Keine vorausgewählten Häkchen für Statistik, Marketing oder externe Medien.
  • Klare Zwecke statt Sammelbegriffe wie „Optimierung“ ohne Erläuterung.
  • Anbieter, Speicherdauer und relevante Drittlandübermittlungen nachvollziehbar erklären.
  • Einwilligungen nachweisbar dokumentieren.
  • Einen dauerhaft erreichbaren Link wie „Cookie-Einstellungen“ oder „Datenschutz-Einstellungen“ anbieten.
  • Der Widerruf muss so einfach sein wie die Einwilligung.
  • Impressum und Datenschutzerklärung müssen unabhängig von der Auswahl erreichbar bleiben.

Vertiefend: Bericht der Cookie-Banner-Taskforce des Europäischen Datenschutzausschusses und die BfDI-Empfehlungen vom August 2026.

5. Borlabs Cookie 3: die technische Checkliste

Borlabs Cookie kann Consent, Dienste und Content Blocker zentral verwalten. Das Plugin macht eine Website aber nicht allein durch seine Installation rechtskonform.

Prüfe bei Borlabs Cookie 3 insbesondere:

  1. Dienste und Anbieter: Jeder tatsächlich genutzte Dienst ist mit dem richtigen Anbieter und Zweck angelegt.
  2. Service-Gruppen: Statistik, Marketing und externe Medien sind sachlich passend zugeordnet. „Essentiell“ wird nicht als Auffangbecken verwendet.
  3. Ausführung: Optionale Skripte werden wirklich erst nach der zugehörigen Zustimmung ausgeführt.
  4. Content Blocker: Einwilligungspflichtige Iframes und Embeds laden vorher keine Drittinhalte.
  5. Dialog: „Alle zulassen“, „Ablehnen“ und „Anpassen“ sind auf der ersten Ebene gleichwertig erreichbar.
  6. Detailansicht: Kategorien, Dienste, Anbieter und Zwecke sind verständlich beschrieben.
  7. Widerruf: Die Einstellungen lassen sich von jeder Seite erneut öffnen.
  8. Versionierung: Bei neuen Diensten oder wesentlich geänderten Zwecken wird geprüft, ob eine erneute Einwilligung erforderlich ist.
  9. Cache: Nach Änderungen werden WordPress-, Optimierungs-, Server- und CDN-Caches geleert.

Hinweis: Der Borlabs-Link ist ein Partner-Link. Für dich ändert sich der Preis dadurch nicht.

6. Borlabs Cookie und PixelYourSite ohne Doppeltracking

PixelYourSite kann unter anderem Meta Pixel, Google Analytics und Google Ads ausspielen. Der häufigste Fehler ist nicht das Consent-Banner, sondern eine doppelte oder parallele Einbindung: einmal über PixelYourSite, zusätzlich über den Tag Manager, das Theme oder einen anderen Code-Snippet.

Lege deshalb für jeden Tag genau eine technische Quelle fest. Borlabs verwaltet die Einwilligung; das Tracking-Plugin oder der Tag Manager darf den Dienst nur im passenden Consent-Zustand ausführen. Wenn der Tag Manager den Code ausliefert, darf derselbe Dienst nicht zusätzlich über Borlabs oder PixelYourSite feuern.

Teste im Browser unter anderem, ob Requests zu Meta-, Google-Analytics- und Google-Ads-Domains vor der Einwilligung oder nach „Ablehnen“ erscheinen. Verlasse dich nicht nur darauf, dass im Banner die richtige Kategorie angezeigt wird.

7. Google Consent Mode v2: Basic oder Advanced?

Consent Mode v2 übermittelt Consent-Signale an Google. Besonders relevant sind analytics_storage, ad_storage, ad_user_data und ad_personalization. Der Consent Mode ersetzt weder ein Consent-Banner noch eine Rechtsgrundlage.

Basic Consent Mode

Google-Tags werden bis zur Interaktion mit dem Banner blockiert. Ohne Zustimmung werden keine Daten an Google gesendet – auch kein Consent-Status. Das ist die datenschutzkonservativere Variante.

Advanced Consent Mode

Google-Tags können bereits bei verweigerter Einwilligung sogenannte cookieless pings senden. Dadurch erhält Google mehr Signale für Modellierungen. Genau diese Übertragung vor einer Zustimmung ist rechtlich umstritten. Wer sie einsetzen will, sollte den konkreten Datenfluss und die Rechtsgrundlage fachkundig prüfen lassen.

Für viele kleine und mittlere Websites ist Basic Consent Mode daher der robustere Ausgangspunkt. Wichtig ist in beiden Varianten die tatsächliche Konfiguration: Ein lokal bereitgestellter Google Tag Manager macht die darin enthaltenen Analyse- oder Marketing-Tags nicht automatisch „notwendig“.

Dokumentation: Google: Funktionsweise des Consent Mode und Borlabs: Google Tag Manager und Consent Mode in Version 3.

8. So prüfst du die fertige Konfiguration

Nutze ein frisches privates Browserfenster und teste mindestens diese Zustände getrennt:

  1. Vor jeder Auswahl: Nur unbedingt erforderliche Technik lädt. Optionale Cookies, Local-Storage-Einträge und Drittanbieter-Requests fehlen.
  2. Nach „Ablehnen“: Optionale Dienste bleiben blockiert. Die Website bleibt grundsätzlich nutzbar.
  3. Nach „Alle zulassen“: Die freigegebenen Dienste laden genau einmal und in der richtigen Kategorie.
  4. Nach individueller Auswahl: Nur die gewählten Kategorien und Dienste werden aktiviert.
  5. Nach Widerruf: Optionale Tags laden bei weiteren Seitenaufrufen nicht mehr. Prüfe zusätzlich, welche Cookies das Tool technisch löschen kann.

Kontrolliere jeweils:

  • Entwicklerwerkzeuge: Network, Application/Storage und Cookies
  • Google Tag Assistant beziehungsweise die Vorschau des Tag Managers
  • Meta Pixel Helper, sofern Meta Pixel eingesetzt wird
  • mehrere Seitentypen, Gerätebreiten und eingeloggte wie nicht eingeloggte Zustände
  • das Verhalten nach geleertem Cache

Die häufigsten Fehler

  • Das Banner ist korrekt konfiguriert, aber das Theme lädt den Tracking-Code zusätzlich.
  • Ein Tag feuert gleichzeitig über PixelYourSite und den Google Tag Manager.
  • Ein Scanner prüft nur die Startseite; Videos oder Formulare auf Unterseiten bleiben unentdeckt.
  • Google Fonts sind im Theme lokal, werden aber durch ein Plugin erneut extern geladen.
  • „Ablehnen“ ist nur in einer zweiten Ebene oder als unauffälliger Textlink erreichbar.
  • Nach einer Änderung werden alte Cache-Dateien weiter ausgeliefert.
  • Die technische Konfiguration und die Datenschutzerklärung beschreiben unterschiedliche Dienste.
  • Neue Plugins oder Marketing-Tags werden aktiviert, ohne den Consent erneut zu prüfen.

Fazit

Eine belastbare WordPress-Konfiguration besteht aus drei Teilen: saubere Datenflüsse, eine echte Wahl im Consent-Banner und wiederholbare technische Tests. Borlabs Cookie kann das gut abbilden – aber nur, wenn Theme, Plugins, Tag Manager und eingebettete Inhalte konsequent darauf abgestimmt sind.

Prüfe deshalb nicht nur, ob ein Banner sichtbar ist. Prüfe, was tatsächlich passiert, bevor jemand zustimmt.


PS: Danke an Andreas von SEOFX – SEO & Webdesign in Nürnberg für den Hinweis auf die veralteten Links in der früheren Version dieses Beitrags.