Integrationshandbuch für das Wix-Cookie-Einwilligungsbanner: Integriertes CMP, Velo und Drittanbieter-Einbettungen im Jahr 2026
Wix ist die Standard-Webplattform für Hunderte von Millionen kleiner Unternehmen, Kreativschaffender und Betreiber, die kein Entwicklerteam haben und auch keines wollen. Die Stärke der Plattform liegt genau darin — ein gehosteter Website-Baukasten, bei dem die zugrundeliegende Infrastruktur, die Zahlungsabwicklung, die Inhaltsverwaltung und zunehmend der Marketing-Stack von der Person abstrahiert werden, die die Seite tatsächlich betreibt. Diese Abstraktion ist auch der Ort, an dem sich Wix's Einwilligungsrisiken konzentrieren. Die Plattform liefert ein integriertes Cookie-Einwilligungsbanner, das der Betreiber mit ein paar Klicks aktivieren kann; das Banner beantwortet die oberflächliche Frage, ob ein Banner vorhanden ist; und der Betreiber macht weiter. Die schwierigeren Fragen — ob das Banner tatsächlich verhindert, dass Tags vor der Einwilligung ausgelöst werden, ob Drittanbieter-HTML-Einbettungen und Velo-Code korrekt gesperrt sind, ob das Einwilligungsprotokoll prüffähig ist, ob die Offenlegung grenzüberschreitender Übertragungen korrekt ist — werden selten gestellt, und eine Wix-Seite, die sie nicht gestellt hat, ist keine Wix-Seite, die GDPR, ePrivacy oder die regionalen Regelungen erfüllt, die sich damit abgestimmt haben. Dieser Leitfaden beschreibt, was zu konfigurieren und was hinzuzufügen ist, damit eine Wix-Bereitstellung im Jahr 2026 eine verteidigungsfähige Position erreicht.
Was das integrierte Cookie-Einwilligungsbanner von Wix tatsächlich tut
Das Wix Cookie Consent Banner — für jede Wix-Seite unter Settings, Privacy & Compliance verfügbar — ist eines der leistungsfähigeren nativen Einwilligungstools, die eine gehostete Plattform liefert. Es unterstützt Opt-in pro Kategorie über die Kategorien Essential, Functional, Analytics und Advertising, kann so konfiguriert werden, dass explizite zustimmende Handlungen erforderlich sind, unterstützt mehrsprachige Inhalte über die Übersetzungsschicht der Seite und integriert sich nativ mit der Einwilligungsrichtlinie, die Wix's eigene Marketing Apps respektieren. Wenn der Betreiber das Banner so konfiguriert, dass eine Einwilligung erforderlich ist, und Steuerungen pro Kategorie aktiviert, respektieren Wix's native Integrationen — Wix Analytics, die Facebook Pixel-Integration, die Google Ads-Integration, die Google Tag Manager-Integration, die Hotjar-Integration — die Wahl des Nutzers ohne weitere Verkabelung.
Was das Banner nicht tut und wo das häufigste Compliance-Versagen auftritt, ist die Sperrung von Drittanbieter-Skripten, die der Betreiber über Wix's Custom Code-Funktion, Velo-Code oder eingebettete HTML-Widgets hinzugefügt hat. Das Banner zeichnet die Wahl des Nutzers auf; die Aufgabe des Betreibers ist es, diese Wahl aus der Einwilligungsrichtlinie auszulesen und die Drittanbieter-Logik, die außerhalb der verwalteten Integrationsliste von Wix liegt, bedingt auszuführen. Das Muster funktioniert, sobald es eingerichtet ist, aber es ist nicht automatisch.
Die Standardkonfiguration reicht nicht aus
Die Standardkonfiguration des Banners, wenn der Betreiber es zum ersten Mal aktiviert, ist implizite Einwilligung — der Besuch der Seite gilt als Einwilligung, bis der Besucher ablehnt. Diese Position war die Quelle wiederholter Regulierungsfeststellungen gegen auf Wix gehostete Seiten im gesamten EEA, in Großbritannien und in Regelungen, die sich mit der GDPR abgestimmt haben. Der Betreiber muss die Konfiguration so ändern, dass vor dem Setzen nicht wesentlicher Cookies eine explizite zustimmende Einwilligung erforderlich ist, muss die Kategorieumschalter standardmäßig auf Aus setzen und muss überprüfen, ob die Ablehnungsoption in der Banner-UI mindestens genauso prominent ist wie die Akzeptierungsoption. Diese drei Einstellungen — explizite Einwilligung, standardmäßig Aus, prominente Ablehnung — sind das Minimum, das eine Wix-Seite benötigt, um den Schwellenwert zu überschreiten, den der EDPB in seinen Cookie-Banner-Leitlinien von 2023 festgelegt und in den Prioritäten der Task Force 2026 bekräftigt hat.
Wie Wix die Einwilligung unter der Haube verarbeitet
Wix stellt den Einwilligungsstatus des Besuchers über ein Einwilligungsrichtlinienobjekt bereit, das die internen Integrationen der Plattform lesen und das der Code des Betreibers über die Velo-Entwicklerplattform lesen kann. Die Velo API stellt die Einwilligungsrichtlinie unter wixWindow.consentPolicy im Frontend und im äquivalenten Modul im Backend bereit. Die Einwilligungsrichtlinie gibt ein strukturiertes Objekt mit booleschen Flags pro Kategorie und einem Zeitstempel zurück; der Velo-Code oder Custom Code des Betreibers liest diese Flags, bevor er eine nicht wesentliche Drittanbieter-Logik initialisiert.
Die von Wix bereitgestellten Einwilligungskategorien entsprechen der Standardtaxonomie. Essential umfasst Sitzungs-, Warenkorb-, Sicherheits- und Lastausgleichs-Cookies und erfordert keine Einwilligung. Functional umfasst Einstellungen, zuletzt angesehene Listen und ähnliche nicht wesentliche, aber nicht verfolgende Speicherung. Analytics umfasst Wix Analytics, Google Analytics 4, Microsoft Clarity und ähnliche Messwerkzeuge. Advertising umfasst Facebook Pixel, Google Ads, TikTok Pixel, LinkedIn Insight und das breitere Marketing-Pixel-Inventar. Native Wix Marketing Apps werden automatisch auf diese Kategorien gesperrt; alles, was vom Betreiber hinzugefügt wird, muss manuell gesperrt werden.
Das Integrationsmuster für Drittanbieter-Einbettungen und Custom Code
Das Muster, das auf Wix funktioniert, hat vier Teile. Erstens, konfigurieren Sie das integrierte Cookie Consent Banner so, dass eine explizite Einwilligung erforderlich ist, setzen Sie die Kategorieumschalter standardmäßig auf Aus und stellen Sie sicher, dass die Ablehnungsoption mindestens genauso prominent ist wie die Akzeptierung. Zweitens, identifizieren Sie jedes Drittanbieter-Skript, das die Seite außerhalb von Wix's nativer Integrationsliste hinzufügt — typischerweise befinden sie sich in Settings, Custom Code, in Velo-Code-Modulen oder in eingebetteten HTML-Widgets — und inventarisieren Sie, welcher Einwilligungskategorie jedes angehört. Drittens, schließen Sie jedes Drittanbieter-Skript in eine Einwilligungsprüfung ein, die die Einwilligungsrichtlinie vor der Ausführung liest. Viertens, stellen Sie sicher, dass der vom Banner angezeigte Datenschutzhinweis die tatsächlichen Drittanbieter-Empfänger widerspiegelt, nicht die generische Wix-Vorlagensprache.
- Custom Code unter Settings — Betreiber fügen üblicherweise Google Tag Manager, zusätzliche Facebook Pixels, zusätzliche Google Ads-Conversion-Tags, Hotjar-Snippets und Anrufverfolgungs-Skripte über Custom Code hinzu. Jedes davon muss mit der entsprechenden Consent Mode-Einstellung in der Custom Code-UI konfiguriert werden — Wix stellt die Auswahl der Einwilligungskategorie auf Snippet-Ebene bereit — damit das Snippet nur geladen wird, wenn die entsprechende Kategorie erteilt wurde.
- Velo-Code — Backend- und Frontend-Velo-Code kann wixWindow.consentPolicy lesen und bedingt an Drittanbieter-APIs weiterleiten. Jedes Velo-Modul, das einen Drittanbieter-Endpunkt aufruft, um Ereignisse zu protokollieren, Pixel auszulösen oder Daten mit einem CRM zu synchronisieren, muss die entsprechende Kategorie vor der Ausführung prüfen.
- Eingebettete HTML-Widgets — eingebettete HTML-iFrames von Drittanbietern (Chat-Widgets, Kalender-Widgets, Social-Media-Einbettungen) laden typischerweise ihre eigenen Skripte, die ihre eigenen Cookies setzen. Das Muster besteht darin, den iFrame innerhalb eines Velo-gesteuerten Wrappers zu rendern, der das iFrame-Element bedingt nur dann einfügt, wenn das entsprechende Gate erteilt wurde.
- Wix Studio-Seiten — Wix Studio erbt denselben Einwilligungsrichtlinienmechanismus, fügt aber responsives Design und Entwickler-Modus-Funktionen hinzu, die die Wartung der Velo-artigen Einwilligungssperrung erleichtern. Das Integrationsmuster ist identisch; die Wartungsergonomie ist besser.
Die Wix-spezifischen Compliance-Fallstricke
Drei Muster wiederholen sich bei Wix-Bereitstellungen und machen den Großteil der von Regulatoren gemeldeten Probleme aus. Das erste ist der vom Betreiber verwaltete Drittanbieter-Google Tag Manager-Container — der Betreiber installiert GTM über Custom Code und fügt dann Dutzende von Tags über die GTM-UI hinzu, ohne Consent Mode v2 innerhalb von GTM selbst zu konfigurieren. Das Wix-Banner sperrt den GTM-Lader korrekt, aber sobald GTM geladen ist, werden die Tags darin ohne weitere Einwilligungsprüfungen ausgelöst, es sei denn, GTM wurde so konfiguriert, dass es Consent Mode respektiert. Die Lösung besteht darin, Consent Mode v2 im GTM-Container zu aktivieren und den Trigger jedes Tags mit dem entsprechenden Einwilligungssignal zu verbinden.
Das zweite ist der eingebettete Formularanbieter — Typeform, JotForm, Calendly und ähnliche — der seine eigenen Cookies für Analyse- und Vorausfüllzwecke lädt. Das Wix-Banner sperrt das eingebettete Widget standardmäßig nicht; der Betreiber muss das Widget-Element selbst über Velo sperren oder das Klick-zum-Laden-Platzhaltermuster verwenden, das das iFrame-Laden verzögert, bis der Nutzer damit interagiert.
Das dritte ist die Offenlegung grenzüberschreitender Übertragungen. Wix's Hosting-Infrastruktur läuft über Regionen einschließlich der Vereinigten Staaten, und viele der Drittanbieter-Empfänger des Betreibers laufen anderswo; die Datenschutzhinweisvorlage, die Wix liefert, nennt diese Gerichtsbarkeiten nicht spezifisch, und der Betreiber muss den Hinweis bearbeiten, um jede Empfängerregion zu nennen. Die EDPB-Leitlinien von 2023 haben explizit erklärt, dass generische Sprache über von Dienstleistern verarbeitete Daten nicht ausreicht, und derselbe Standard gilt für auf Wix gehostete Seiten.
Validierung und Prüfungsposition für 2026
Eine verteidigungsfähige Wix-Bereitstellung im Jahr 2026 muss vier technische Prüfungen bestehen. Erstens muss eine saubere Browsersitzung, die von einer EEA-IP-Adresse bedient wird, null nicht wesentliche Cookies erzeugen, bevor das Banner betätigt wurde — nicht nur null von Wix verwaltete Cookies, sondern null Cookies aus jedem Custom Code-Snippet, Velo-Modul und eingebetteten Widget. Zweitens muss der Ablehnungspfad diesen Zustand beibehalten. Drittens muss der Akzeptierungspfad nur die Tags erzeugen, denen der Nutzer zugestimmt hat, und das Wix-Einwilligungsprotokoll zusammen mit einem betreiberseitigen Protokoll muss den übereinstimmenden Datensatz enthalten. Viertens muss ein Widerruf sofort weitere Tag-Auslösungen stoppen, die während der eingewilligten Sitzung gesetzten Cookies ablaufen lassen und die Abmeldung an alle nachgelagerten Drittanbieter-Empfänger weitergeben, die ihren eigenen Status aufrechterhalten.
Die Erwartung an einen Prüfpfad ist der Bereich, in dem Wix sich verbessert, aber immer noch Betreiberaufwand erfordert. Die Plattform zeichnet Einwilligungsentscheidungen in ihrem eigenen Protokoll auf, das für den Website-Eigentümer zugänglich ist, was für viele Regulierungsanfragen ausreicht. Bei Bereitstellungen, die einen vollständigeren Prüfpfad benötigen — Banner-Version, Kategoriestatus, Sprachversion und Status der nachgelagerten Empfänger — muss der Betreiber Velo-Code hinzufügen, der Einwilligungsereignisse in einen abfragbaren externen Speicher schreibt. Eine Wix-Seite, die das integrierte Banner korrekt konfiguriert hat, jeden Custom Code- und Velo-Pfad gesperrt hat, den Datenschutzhinweis bearbeitet hat, um jeden grenzüberschreitenden Empfänger zu nennen, und das Prüfpfad-Protokoll hinzugefügt hat, ist eine Wix-Seite, die die Einfachheit des gehosteten Baukastens der Plattform von einer Compliance-Haftung in einen verteidigungsfähigen Teil der Einwilligungsposition eines Publishers umgewandelt hat.