CookieYes durch Complianz ersetzen: sicherer Wechsel ohne Consent-Ausfall

Ein Consent-Plugin in WordPress auszutauschen klingt zunächst banal: neues Plugin installieren, altes Plugin deaktivieren, fertig. Genau diese Reihenfolge kann aber dazu führen, dass für einige Minuten oder Stunden gar kein funktionierendes Consent-Management vorhanden ist – oder dass zwar ein neuer Banner sichtbar ist, Google Analytics trotzdem schon vor der Einwilligung geladen wird.

Bei einer echten Migration von CookieYes zu Complianz habe ich deshalb bewusst nicht nur auf die sichtbare Oberfläche geschaut, sondern auf den technischen Zustand darunter: Ist Complianz wirklich initialisiert? Existiert ein aktiver Banner-Datensatz? Welche Dienste erkennt die Website? Wie verhält sich Google Site Kit? Gibt es die WP Consent API? Und startet Google Analytics tatsächlich mit analytics_storage = denied?

Der folgende Ablauf ist das Ergebnis dieser praktischen Prüfung. Er ist deutlich gründlicher als „Plugin A aus, Plugin B an“. Wer zunächst grundsätzlich wissen möchte, welches Consent-Plugin besser passt, findet dazu meinen älteren Vergleich Complianz oder CookieYes?. Hier geht es ausschließlich um den sauberen Wechsel.

Die wichtigste Erkenntnis: „Complianz aktiv“ bedeutet noch lange nicht „Complianz fertig“

Der entscheidende Punkt war überraschend einfach: Complianz kann als WordPress-Plugin aktiviert sein, während der eigentliche Einrichtungsprozess noch nicht abgeschlossen ist. In diesem Zustand existieren zwar bereits Complianz-Optionen und Tabellen, aber der Banner selbst kann noch fehlen.

Genau deshalb sollte CookieYes nicht sofort deaktiviert werden. Solange nicht nachgewiesen ist, dass Complianz einen echten, aktiven Banner ausliefert und die Zustimmung technisch verarbeitet, bleibt die bisherige Consent-Lösung das Sicherheitsnetz.

Meine neue Grundregel: Das alte Consent-Plugin erst dann deaktivieren, wenn das neue System vollständig initialisiert, im Frontend sichtbar und technisch getestet ist.

Der Zielzustand der Migration

Für eine normale Unternehmenswebsite mit Google Site Kit und Google Analytics besteht der gewünschte Endzustand aus mehreren Komponenten, die zusammenarbeiten müssen:

  • Complianz ist installiert, aktiv und vollständig initialisiert.
  • Ein aktiver Complianz-Banner ist tatsächlich vorhanden.
  • Die Website verwendet EU-/DSGVO-Opt-in.
  • Akzeptieren, Ablehnen und Einstellungen sind erreichbar.
  • Eine Cookie-Richtlinie ist veröffentlicht.
  • Datenschutzerklärung und Impressum bleiben korrekt verknüpft.
  • CookieYes ist deaktiviert und sein externes Skript wird nicht mehr geladen.
  • Google Site Kit Consent Mode ist aktiviert.
  • Die WP Consent API steht als Brücke zur Verfügung.
  • Google Analytics startet vor der Einwilligung mit analytics_storage = denied.
  • Werbezwecke starten – sofern relevant – ebenfalls mit ad_storage = denied, ad_user_data = denied und ad_personalization = denied.

1. Vor dem Wechsel: erst inventarisieren, dann verändern

Ich beginne inzwischen jede Consent-Migration mit einer kleinen technischen Inventur. Der Name des aktiven Cookie-Plugins reicht nicht. Datenschutzrelevante Dienste können über andere Plugins, Theme-Code, Snippets oder externe Einbettungen eingebunden werden.

Mindestens diese Punkte sollten vor dem ersten Schreibzugriff geklärt sein:

  • Welches Consent-Plugin ist aktuell aktiv?
  • Ist Complianz bereits installiert?
  • Welche Analyse- und Marketingdienste laufen?
  • Ist Google Site Kit aktiv?
  • Welche Site-Kit-Module sind aktiv?
  • Welche GA4-Property und Measurement-ID werden verwendet?
  • Gibt es Google Maps, YouTube, reCAPTCHA oder Social-Media-Einbettungen?
  • Welche Formulare sind eingebaut?
  • Gibt es Code Snippets, WPCode oder „Custom CSS & JS“, über die externe Skripte nachgeladen werden?
  • Welche Datenschutzerklärung und welches Impressum sind bereits veröffentlicht?

Mit WP-CLI lässt sich der technische Bestand sehr schnell erfassen:

wp plugin list --fields=name,status,version --format=json

wp option get googlesitekit_active_modules --format=json

wp option get googlesitekit_analytics-4_settings --format=json

wp option get googlesitekit_search-console_settings --format=json

Besonders wichtig: Eine Plugin-Liste ist nur der Anfang. Google Maps kann zum Beispiel direkt im Inhalt oder in einem Block eingebettet sein. Tracking-Code kann in WPCode liegen. reCAPTCHA kann über ein Formularplugin kommen. Eine saubere Migration braucht deshalb immer auch einen Blick auf tatsächlich ausgegebene Skripte und Einbettungen.

2. Complianz aktivieren – CookieYes aber noch nicht abschalten

Der sichere Ablauf beginnt damit, Complianz parallel zu installieren beziehungsweise zu aktivieren. CookieYes bleibt zunächst aktiv. Dadurch verhindert man eine Phase ohne Consent-Banner, falls Complianz noch nicht vollständig eingerichtet ist.

Wichtig ist allerdings, die Parallelphase kurz zu halten. Zwei gleichzeitig sichtbare Consent-Banner sind natürlich ebenfalls falsch. Das Ziel ist: Complianz vorbereiten, prüfen, übernehmen – und CookieYes unmittelbar danach deaktivieren.

3. Den Complianz-Assistenten wirklich initialisieren

Bei der praktischen Migration zeigte sich: Das aktivierte Plugin hatte bereits seine Datenbanktabellen angelegt, aber die Tabelle für Cookie-Banner enthielt noch keinen Banner. Der Assistent war also noch nicht vollständig initialisiert.

Complianz speichert die zentralen Wizard-Angaben in der WordPress-Option cmplz_options. Dort finden sich unter anderem Region, Dokumenttypen, Statistik-Einstellungen, Werbecookies und weitere Angaben.

wp option get cmplz_options --format=json

Für einen typischen EU-Stand müssen unter anderem die gewählte Region, Cookie-Banner, Cookie-Blocker, Statistiklösung und Dokumente sinnvoll gesetzt sein. Diese Werte darf man aber nicht blind auf jede Website kopieren. Eine Website mit reCAPTCHA, Maps, YouTube, Werbung oder eingebetteten Drittanbietern braucht andere Angaben als eine einfache Informationsseite.

Firmendaten zentralisieren, Dienste domainspezifisch prüfen

Sehr gut automatisierbar sind stabile Stammdaten: Anbieter, Anschrift, Telefon, E-Mail, verantwortliche Stelle, Quellen-URLs und Prüfdatum. Weniger sinnvoll ist eine pauschale Übernahme aller Dienste. Ob eine Domain Google Maps, reCAPTCHA oder Marketing-Cookies verwendet, muss für diese konkrete Domain festgestellt werden.

4. Nicht nur die Einstellungen prüfen – der Banner-Datensatz muss existieren

Das war einer der wichtigsten technischen Funde: Ein gefülltes cmplz_options reicht nicht. Complianz verwaltet die Banner in einer eigenen Tabelle. Bei Standardpräfix heißt sie typischerweise wp_cmplz_cookiebanners.

Zur Diagnose kann man beispielsweise prüfen:

wp db query "SELECT ID,title,`default`,position,use_categories,disable_cookiebanner,banner_version FROM wp_cmplz_cookiebanners ORDER BY ID"

Achtung: Das Tabellenpräfix muss nicht wp_ lauten. Außerdem würde ich diese Tabelle nicht als reguläre Konfigurationsschnittstelle behandeln. Lesen zur Diagnose ist hilfreich; direkte Schreibzugriffe sind eine Ausnahme und versionsabhängig. Der normale Weg bleibt Complianz selbst.

In meinem Testfall war die Tabelle zunächst leer. Der Frontend-Banner konnte deshalb noch nicht zuverlässig als fertig eingerichtet gelten. Erst nachdem ein Default-Banner existierte, lieferte Complianz im Frontend die vollständige Opt-in-Struktur mit den Schaltflächen „Akzeptieren“, „Ablehnen“ und „Einstellungen ansehen“.

5. Die Cookie-Richtlinie gehört zum fertigen Setup

Ein funktionierender Banner allein ist noch nicht das Ende. Complianz kann die Cookie-Richtlinie als dynamisches Dokument erzeugen. In Gutenberg verwendet Complianz dafür einen eigenen Dokumentblock.

<!-- wp:complianz/document {"title":"Cookie-Richtlinie (EU)","selectedDocument":"cookie-statement"} /-->

Die Seite sollte veröffentlicht sein und der Banner sollte auf die rechtlichen Dokumente sinnvoll verweisen. Eine bereits vorhandene Datenschutzerklärung muss nicht blind durch einen von Complianz generierten Text ersetzt werden. Gerade bei individuellen Datenschutzerklärungen kann es sinnvoll sein, sie als eigenes Dokument weiterzuführen und Complianz vor allem für Consent und Cookie-Richtlinie einzusetzen.

6. Der unsichtbare Stolperstein: Google Site Kit

Nach der sichtbaren Complianz-Umstellung war der kritischste Test noch nicht erledigt: Was passiert mit Google Analytics?

Google Site Kit kann GA4 direkt in den Seitenkopf einbauen. Wenn man nur den Cookie-Banner wechselt, sagt das noch nichts darüber aus, mit welchem Consent-Zustand Google startet.

Site Kit besitzt deshalb einen eigenen Consent Mode. Den Status kann man über die Site-Kit-Schnittstelle beziehungsweise intern über die Option googlesitekit_consent_mode kontrollieren. Nach der Aktivierung muss der Seitenkopf vor jeder Zustimmung mit einem verweigerten Ausgangszustand starten.

wp option get googlesitekit_consent_mode --format=json

Im erfolgreichen Test enthielt der HTML-Kopf anschließend sinngemäß diesen Zustand:

analytics_storage: denied
ad_storage: denied
ad_user_data: denied
ad_personalization: denied
functionality_storage: denied
security_storage: denied
personalization_storage: denied

Das ist ein wesentlich stärkerer Nachweis als „der Banner sieht richtig aus“. Der Nutzer hat zu diesem Zeitpunkt noch nichts gewählt – und Analytics-Speicherung ist bereits auf denied gesetzt.

7. Warum die WP Consent API die saubere Brücke ist

Der nächste Fund war die Verbindung zwischen Complianz und Site Kit. Site Kit meldete zunächst, dass keine WP Consent API vorhanden war. Der Site-Kit-Consent-Mode ließ sich zwar aktivieren, für die saubere Kommunikation zwischen Consent-Management und anderen Plugins ist die WP Consent API aber die bessere Grundlage.

Nach Installation und Aktivierung der WP Consent API erkannte Site Kit die Schnittstelle sofort.

Technisch ist die Kette dann klar:

  1. Der Besucher entscheidet im Complianz-Banner.
  2. Complianz setzt seine Kategorien wie funktional, Präferenzen, Statistik oder Marketing.
  3. Complianz synchronisiert diese Entscheidung mit der WP Consent API.
  4. Site Kit verwendet die Consent-Schnittstelle beziehungsweise Google Consent Mode.
  5. Google erhält entsprechend aktualisierte Consent-Signale.

Im Complianz-JavaScript ist diese Kopplung ausdrücklich vorgesehen: Beim Setzen einer Consent-Kategorie wird auch der WP-Consent-Status aktualisiert. Genau diese Verbindung macht aus mehreren einzelnen Plugins ein konsistentes Consent-System.

8. Erst jetzt CookieYes deaktivieren

Erst nachdem Complianz-Banner, Cookie-Richtlinie, Site-Kit-Consent-Mode und WP Consent API funktionierten, habe ich CookieYes deaktiviert.

Danach reicht es nicht, nur in der Plugin-Liste nachzusehen. Die tatsächliche Seitenausgabe muss erneut kontrolliert werden. Vor der Umstellung war im HTML beispielsweise das externe CookieYes-Skript zu sehen:

https://cdn-cookieyes.com/client_data/.../script.js

Nach der Deaktivierung darf dieses Skript nicht mehr ausgeliefert werden. Gleichzeitig muss Complianz weiterhin vorhanden sein. So lässt sich ein Doppelbetrieb zuverlässig ausschließen.

9. Meine Testmatrix nach der Migration

Eine Consent-Migration ist für mich erst abgeschlossen, wenn mindestens die folgenden Punkte geprüft wurden:

PrüfungSollzustand
Complianz Pluginaktiv
CookieYes Plugininaktiv
CookieYes CDN-Skriptnicht mehr im HTML
Complianz-Bannervorhanden und aktiv
Akzeptierenvorhanden und funktional
Ablehnenvorhanden und funktional
Einstellungenvorhanden und funktional
Cookie-Richtlinieveröffentlicht
Datenschutz/Impressumkorrekt verknüpft
Site Kit Consent Modeaktiv
WP Consent APIaktiv und von Site Kit erkannt
analytics_storage vor Zustimmungdenied
ad_storage vor Zustimmungdenied
Doppelbannernein

Zusätzlich teste ich eine solche Seite in einem privaten Browserfenster, weil bestehende Consent-Cookies den Eindruck verfälschen können. Mobil sollte die Darstellung ebenfalls geprüft werden.

10. CookieYes nicht sofort löschen

Deaktivieren und Löschen sind für mich zwei getrennte Schritte. Nach einer Migration lasse ich das alte Plugin zunächst deaktiviert installiert. So ist ein schneller Rückweg möglich, falls in der Beobachtungsphase etwas auffällt.

Erst wenn Banner, Dienste, Formulare, Analyse und rechtliche Dokumente stabil sind, kann das alte Plugin entfernt werden. Vorher würde ich auch prüfen, ob irgendwo noch Shortcodes, Blöcke oder Einstellungen des alten Plugins referenziert werden.

11. Was sich gut automatisieren lässt

Der Wechsel ist ein gutes Beispiel dafür, dass WordPress-Administration teilweise sehr gut standardisiert werden kann – aber nicht durch blindes Kopieren einer Konfiguration.

Gut automatisierbar sind:

  • Plugin-Inventur
  • Status von Complianz und CookieYes
  • Site-Kit-Module und GA4-ID
  • Site-Kit Consent Mode
  • WP Consent API vorhanden/aktiv
  • Existenz eines Default-Banners
  • Existenz einer Cookie-Richtlinie
  • HTML-Prüfung auf CookieYes-Skripte
  • HTML-Prüfung auf Consent-Mode-Defaults
  • Speicherung des Prüfergebnisses pro Domain

Für mehrere Websites lohnt sich deshalb eine zentrale Domain-Tabelle. Pro Website kann man zum Beispiel Status, Prüfzeitpunkt, Kurzbefund und nächste Aktion speichern. So muss dieselbe Inventur nicht bei jedem späteren Check erneut komplett durchgeführt werden.

12. Was ich nicht blind automatisieren würde

Einige Angaben bleiben domainspezifisch und sollten bewusst geprüft werden:

  • Google Maps tatsächlich eingebunden?
  • reCAPTCHA wirklich aktiv?
  • YouTube oder Vimeo vorhanden?
  • Social-Media-Einbettungen oder nur normale Links?
  • Werbe- oder Remarketing-Cookies?
  • Formularanbieter und externe Verarbeitung?
  • Newsletter oder CRM?
  • Externe Backup-Ziele?
  • Individuelle Datenschutzerklärung oder generiertes Dokument?

Auch direkte SQL-Schreibzugriffe in Complianz-Tabellen würde ich nicht als allgemeinen Automatisierungsweg einplanen. Plugin-eigene Funktionen, REST-Schnittstellen oder der Assistent sind vorzuziehen. Ein Datenbankeingriff ist höchstens ein diagnostischer beziehungsweise kontrollierter Ausnahmefall, wenn man genau weiß, welche Plugin-Version und welches interne Verhalten vorliegen.

13. Ein praktischer Ablauf für die nächste Website

  1. Impressum und Datenschutzerklärung lesen und Stammdaten sichern.
  2. Aktive Plugins und externe Dienste inventarisieren.
  3. CookieYes-Status und aktuelles Banner dokumentieren.
  4. Complianz installieren beziehungsweise aktivieren.
  5. Complianz für EU/DSGVO und die konkrete Website konfigurieren.
  6. Prüfen, ob ein echter Default-Banner existiert.
  7. Cookie-Richtlinie veröffentlichen.
  8. Datenschutzerklärung und Impressum korrekt verknüpfen.
  9. Site Kit und GA4-Konfiguration prüfen.
  10. Site Kit Consent Mode aktivieren.
  11. WP Consent API installieren, falls sie fehlt.
  12. HTML vor Zustimmung auf analytics_storage = denied prüfen.
  13. Complianz-Banner im Inkognito-Fenster testen.
  14. CookieYes deaktivieren.
  15. HTML erneut auf CookieYes-Skript prüfen.
  16. Akzeptieren, Ablehnen und Einstellungen erneut testen.
  17. Ergebnis dauerhaft in der Domain-Dokumentation speichern.

14. Ein wichtiger Unterschied: Script-Blocking und Consent Mode sind nicht dasselbe

Bei Google-Diensten muss man zwei Ebenen auseinanderhalten. Die erste Ebene ist klassisches Blocking: Ein Skript wird vor der Zustimmung gar nicht ausgeführt. Die zweite Ebene ist Google Consent Mode: Google-Code kann vorhanden sein, startet aber mit verweigerten Speichersignalen und erhält erst nach einer gültigen Zustimmung ein Update.

Deshalb reicht die Frage „Ist gtag.js im HTML?“ allein nicht aus. Entscheidend ist zusätzlich, mit welchen Consent-Defaults es startet. In meinem Test war der klare technische Sollwert analytics_storage = denied vor jeder Nutzerentscheidung.

15. Häufige Fehler beim Wechsel von CookieYes zu Complianz

  • CookieYes zu früh deaktivieren: Es entsteht eine Phase ohne funktionierenden Banner.
  • Nur auf die Plugin-Aktivierung schauen: Complianz kann aktiv sein, obwohl noch kein Banner-Datensatz existiert.
  • Nur den sichtbaren Banner testen: GA4 kann trotzdem mit falschem Consent-Zustand starten.
  • Site Kit vergessen: Site Kit ist häufig die eigentliche Quelle des Google-Tags.
  • WP Consent API ignorieren: Dann fehlt eine saubere gemeinsame Consent-Schnittstelle zwischen Plugins.
  • Cookie-Richtlinie vergessen: Der technische Banner ist dann zwar da, das Dokument-Setup aber unvollständig.
  • CookieYes sofort löschen: Ein schneller Rollback wird unnötig erschwert.
  • Eine Musterkonfiguration auf alle Websites kopieren: Drittanbieter und Formulare unterscheiden sich von Domain zu Domain.

Fazit

Der Wechsel von CookieYes zu Complianz ist technisch gut beherrschbar, wenn man ihn als Migration und nicht als simplen Plugin-Tausch behandelt. Der sichtbare Banner ist dabei nur ein Teil des Systems.

Für mich besteht eine saubere Migration inzwischen aus fünf Nachweisen: Complianz ist vollständig initialisiert, ein funktionierender Banner existiert, die rechtlichen Dokumente sind verknüpft, Site Kit startet mit korrekten Consent-Defaults und CookieYes ist anschließend vollständig aus der Seitenausgabe verschwunden.

Gerade die Kombination aus Complianz + WP Consent API + Site Kit Consent Mode ist dabei interessant. Sie verhindert, dass Consent nur als sichtbare Oberfläche behandelt wird. Die Entscheidung des Besuchers wird technisch an die beteiligten Komponenten weitergereicht.

Und genau das ist der Punkt, den ich aus diesem Test mitnehme: Nicht der Banner muss „gut aussehen“. Der gesamte Consent-Weg muss nachweisbar funktionieren.

Hinweis: Dieser Beitrag beschreibt meine technische Vorgehensweise bei WordPress-Websites und ersetzt keine individuelle Rechtsberatung.