Cookie-Banner zu einer Webflow-Website hinzufügen

Alle Beiträge

Um ein Cookie-Banner in eine Webflow-Website einzubinden, fügen Sie das Skript Ihrer Consent-Plattform unter Site settings, Custom code, Head code ein, oberhalb aller anderen Tracking-Skripte, und veröffentlichen dann. Leeren Sie vorher die nativen Felder für Google Analytics und Meta Pixel unter Apps and Integrations: Was dort steht, lädt außerhalb Ihres Tag Managers, wo keine Einwilligungssperre hinreicht.

Webflow lädt Tracking von zwei Stellen, und Ihr Banner steuert nur eine

Fast alle Anleitungen zu dieser Frage hören an derselben Stelle auf: bei einem Consent-Tool registrieren, das Snippet in den Head einfügen, veröffentlichen. Das stimmt, entscheidet aber nicht darüber, ob das Setup hält. Eine Webflow-Website hat zwei voneinander unabhängige Stellen, an denen Tracking in die Seite gelangt, und ein Banner steuert nur eine davon.

Site settings, Custom code ist der Bereich, den Sie kontrollieren. Standardwerte, Banner und Container stehen alle im Feld Head code, in der Reihenfolge, in der Sie sie anlegen, und jedes Tag, das der Container auslöst, lässt sich hinter eine Einwilligungsbedingung stellen.

Site settings, Apps and Integrations ist der Bereich, den viele vergessen, obwohl sie ihn genutzt haben. Tragen Sie dort eine GA4-Mess-ID ein, bindet Webflow Google Analytics für Sie auf jeder Seite ein. Tragen Sie eine Meta-Pixel-ID ein, passiert dasselbe mit dem Pixel. Keines von beiden läuft über Ihren Container, also wirkt nichts, was Sie dort konfigurieren. Ihr GA4-Tag zu sperren ändert nichts, solange in diesem Feld eine Mess-ID steht.

Die beiden Felder verhalten sich nicht einmal gleich. Das Meta-Pixel-Feld hat einen Schalter Delay for cookie consent, der das Pixel zurückhält, bis eine Einwilligung gespeichert ist, und Webflows Dokumentation sagt ausdrücklich, dass Sie dafür trotzdem ein eigenes Banner brauchen. Das Google-Analytics-Feld hat nichts Vergleichbares: Das eine lässt sich warten lassen, das andere nicht.

Wenn Sie diese Felder leeren, ändert sich, was GA4 zählt. Halten Sie deshalb vorher einen Ausgangswert fest. Notieren Sie eine Woche GA4-Sitzungen neben einer anderen Zahl, der Sie für dieselben Tage vertrauen, etwa CDN-Requests oder Bestellungen. Sobald das Banner live ist, zeigt die Zustimmungsrate in Ihrem Consent-Tool, wie viel der Differenz auf die Einwilligung entfällt. Dieser Anteil schwankt je nach Region, Zielgruppe und Banner-Design. Messen Sie also Ihren eigenen, statt eine Zahl zu übernehmen.

Wie richten Sie ein Cookie-Banner in Webflow ein?

1. Zuerst die nativen Tracking-Felder leeren

   Öffnen Sie Site settings, Apps and Integrations. Steht dort eine GA4-Mess-ID oder eine Meta-Pixel-ID, bindet Webflow dieses Tag selbst auf jeder Seite ein, außerhalb Ihres Containers, wo keine Einwilligungsbedingung Ihrer Tags hinreicht. Leeren Sie die Felder und laden Sie beides über den Container. Bleibt eines davon stehen, während dasselbe Tag auch im Container läuft, zählen Sie doppelt und lassen zugleich Daten durch.

2. „Denied“-Standardwerte über alles andere setzen

   Setzen Sie ganz oben in Site settings, Custom code, Head code einen Consent-Mode-Standardwert, der ad_storage, analytics_storage, ad_user_data und ad_personalization ablehnt. Er muss über dem Banner und dem Container stehen: Ein Standardwert, der erst ankommt, nachdem ein Tag gefeuert hat, ist eine verspätete Korrektur, kein Standardwert. Als eigener Stub übersteht er außerdem einen langsamen oder fehlgeschlagenen Request des Banners.

3. Erst das Banner, dann den Container einfügen

   Beides gehört in dasselbe Feld Head code, das Banner zuerst, damit es seinen Zustand registriert, bevor der Container geparst wird. Das Feld fasst bis zu 50.000 Zeichen, genug für alle drei zusammen. Es gibt also keinen Grund, eine lange Konfiguration aus Platzgründen woanders unterzubringen.

4. Das noscript des Containers in den Footer code setzen

   Webflow bietet einen Platz im Head und einen vor dem schließenden body-Tag, aber keinen direkt nach dem öffnenden body-Tag, wo das noscript-Fragment eines Containers laut Dokumentation normalerweise hingehört. Footer code ist hier die praktikable Platzierung, und sie ist weit weniger wichtig als das Snippet im Head.

5. Die Skripte prüfen, die schon im Head stehen

   Jedes Anbieterskript, das direkt in den Head code eingefügt wurde, lädt eigenständig und lässt sich nicht über einen Tag Manager sperren, dem es nie gehörte. Gehen Sie dieses Feld durch, bevor Sie die Website für fertig erklären. Jedes Skript wird entweder als gesperrtes Tag in den Container verschoben, so eingebettet, dass die Consent-Ebene es zurückhalten kann, oder als unbedingt erforderlich begründet: eine Frage, die Sie für jedes Skript einzeln klären sollten.

6. Veröffentlichen, dann auf der Live-Domain prüfen

   Custom Code erscheint in der Vorschau, geht aber erst live, wenn Sie veröffentlichen. Ein Test im Designer beweist also nichts. Veröffentlichen Sie, laden Sie die Live-Domain in einem sauberen Browserprofil und klicken Sie nichts an: Es dürfen keine Analytics- oder Werbe-Cookies gesetzt werden und keine Requests Ihre Anbieter erreichen. Stimmen Sie dann zu und prüfen Sie, ob alles erscheint. Testen Sie die Live-Domain, nicht nur die Staging-Subdomain webflow.io, denn beide können unterschiedliche veröffentlichte Stände haben.

Den vollständigen Ablauf vor dem Livegang, den Sie einmal gründlich durchgehen sollten, finden Sie unter Cookie-Banner vor dem Livegang testen.

Woran scheitern viele auf Webflow?

Vorschau heißt nicht veröffentlicht. Webflows Dokumentation sagt es klar: Die Wirkung von Custom Code erscheint in der Vorschau, geht aber erst live, wenn die Website veröffentlicht ist. Jede Consent-Prüfung muss auf der veröffentlichten Website stattfinden.

Components vervielfältigen alles, was Sie hineinlegen. Ein Snippet in einer Component, die in einem globalen Header steckt, landet auf jeder Seite, die sie nutzt. Zwei Container auf einer Seite sind ein Problem für sich, und es sieht lange wie ein Consent-Fehler aus, bevor irgendjemand den Header verdächtigt. Websiteweite Snippets gehören in die Site settings.

Code auf Seitenebene läuft nach websiteweitem Code. Custom Code auf einer einzelnen Seite steht im Markup nach dem websiteweiten Code. Für Standardwerte ist das die richtige Reihenfolge, bedeutet aber auch: Ein Stub mit Standardwerten auf einer einzelnen Seite kann sie nicht retten, denn der websiteweite Container wurde darüber schon geparst.

Das dokumentierte Pixel-Banner ist eine Sperre für das Pixel, keine Consent-Ebene. Webflow dokumentiert, wie man für sein natives Meta Pixel von Hand ein Banner baut: Interactions zum Ein- und Ausblenden, dazu ein Skript im Footer code, das beim Klick die Pixel-Einwilligung erteilt. Das gilt nur für dieses Pixel, und Webflow sagt das auch. Als allgemeine Consent-Ebene gelesen, reicht es nicht: Es erteilt die Einwilligung, bietet aber keinen Weg zum Widerruf, der Ablehnen-Button blendet nur das Banner aus, und sonst steuert es nichts auf der Seite. Dass der Widerruf so einfach sein muss wie die Erteilung, verlangt Artikel 7 DSGVO. Es ist also ein Ausgangspunkt, kein fertiges Ergebnis.

Das Banner ist da, und trotzdem tauchen Cookies auf

Gehen Sie die Quellen in der Reihenfolge durch, in der sie sich meist als Ursache erweisen. Zuerst die Felder unter Apps and Integrations, die nichts in Ihrem Container sichtbar macht. Dann Skripte, die direkt in den Head code eingefügt wurden. Drittens ein Snippet, das über eine Component vervielfältigt wird. Erst dann öffnen Sie den Container.

Eine vierte Quelle geht nicht auf Webflow zurück: Ein korrekt gesperrtes Tag kann nachgelagert trotzdem das Pixel eines anderen Anbieters laden, das ist hier beschrieben. Den vollständigen Ablauf vor dem Livegang finden Sie unter Cookie-Banner vor dem Livegang testen.

Eine Frage zur Platzierung kommt bei fast jedem Webflow-Projekt: Head oder Tag Manager? Die Antwort lautet: beides, je nach Aufgabe. Legen Sie einen Stub mit „denied“-Standardwerten in den Head code, damit der abgelehnte Zustand existiert, bevor irgendetwas lädt, und lassen Sie das Tool selbst dort, wo die Leute, die die Tags verwalten, es erreichen. Liegt das Tool nur im Head und schlägt sein Request fehl, feuert der Container ohne registrierte Standardwerte. Das ist ein Fehler in die falsche Richtung.

Velo wird auf Webflow als ein einziges Snippet in diesem Feld Head code installiert: Standardwerte, Banner und der Einwilligungsstatus, den der Container liest, schon durch den Aufbau in der richtigen Reihenfolge.