Webflow Cookie Consent Integrationsguide: Native Banner, Custom Code og tredjeparts CMP til 2026
Webflow indtager en særegen position i website builder-økosystemet. Det er tættere på et designværktøj end et CMS, tættere på et CMS end en hosted applikationsplatform, og i stigende grad den platform, som bureauer vælger, når de ønsker fuldt skræddersyede marketingwebsteder uden den tekniske byrde ved at drive Next.js eller Drupal selv. Webflow leverer et native Cookie Consent-banner med fornuæftige standardindstillinger, eksponerer Custom Code-injektion på site- og sideniveau, integrerer med indlejret HTML og giver operätørerne en CMS Collections-model. Et Webflow-websted, der har aktiveret det native banner og stoppet der, er sjældent fuldt compliant; et websted, der har koblet det native banner til et tredjeparts CMP, har blokeret sin Custom Code og auditeret sine indlejrede scripts, er en af de reneste implementeringer, et bureau kan levere i 2026.
Hvad Webflows native Cookie Consent gør, og hvor det stopper
Webflow tilføjede den native Cookie Consent-funktion i 2022 og har videreudviklet den siden. Funktionen understøtter tre forudindstillede cookie-kategorier — Essential, Marketing og Personalization — eksponerer en konfigurerbar banner-UI tilgængelig via projektindstillingerne og knytter Google Analytics-blokering til brugerens valg. Banneret registrerer brugerens samtykke i en førstepartscookie. Når operätøren aktiverer funktionen, konfigurerer kategorierne og vælger samtykkestil (opt-in, opt-out eller implicit), håndterer platformen det synlige banner og den grundlæggende blokering af native integrationer.
Det, Webflows native banner ikke gør — og hvor de fleste bureaubygde implementeringer fejler — er at blokere den Custom Code, som operätørerne rutinemæssigt tilføjer til analytics, marketingpixels, chat-widgets og indlejrede videoer. Custom Code-injektionspunkterne kører, inden banneret er renderet, hvilket betyder, at ethvert tredjepartsscript tilføjet via disse punkter afvikles, inden der eksisterer nogen samtykkebeslutning. Bureauer tilføjer ofte Hotjar, Facebook Pixel, et tredjeparts CRM-script eller et Calendly-embed via Custom Code og antager, at det native banner håndterer blokeringen. Det gør det ikke.
Standardindstillingen opt-in vs. implicit samtykke
Det native banner eksponerer tre samtykkestile. Implicit samtykke-stilen har gentagne gange ført til regulatoriske afgørelser mod Webflow-hostede websteder i EEA. Opt-in-stilen er den korrekte standard for enhver implementering rettet mod EEA, UK, Brasilien, Schweiz eller en jurisdiktion, der har importeret GDPR-standarden. Operätøren skal vælge opt-in, konfigurere kategorierne til at være slået fra som standard og verificere i forhåndsvisningen, at afvis-knappen er mindst ligeså visuelt fremtrædende som acceptknappen.
Custom Code-blokering: det arbejde, det native banner ikke gør
Integrationsmønsteret, der fungerer på Webflow, har tre dele. Først, konfigurer det native banner korrekt. Dernæst, indpak hvert Custom Code-script i en samtykketjek, inden det afvikles. Endelig, beslut om det native banner er tilstrækkeligt, eller om et tredjeparts CMP skal erstatte det for audit-trail og per-vendor konfigurerbarhed.
Det enkleste blokeringsmønster er at læse Webflows samtykkecookie eller samtykkestatus fra platformens eksponerede JavaScript-hook og betinget afvikle tredjeparts logikken. For scripts i Footer Code-sektionen er mønsteret at indpakke snippetet i en event listener, der udløses ved Webflows samtykkeændringshændelse. For scripts i Head Code-sektionen — hvor de fleste analytics- og pixel-snippets befinder sig — er mønsteret at indlæse snippetet som en pladsholder, med den faktiske tredjepartsanmodning udskydt, indtil samtykketjekket passerer.
Placeholdersmønsteret for tredjepartsscripts
Mønsteret, der fungerer på tværs af de mest almindelige Webflow-integrationer, er <script type="text/plain">-pladsholderen. Tredjepartsscriptet er inkluderet i sidemarkeringen, men med type-attributten sat til en værdi, som browseren ikke vil afvikle. Et lille bootstrap-script — tilføjet én gang i Footer Code-sektionen — lytter efter Webflows samtykkeændringshændelse, identificerer pladsholderscripts, der matcher den indrømmede kategori, og omskriver deres type-attribut til text/javascript, så de afvikles. Mønsteret er det samme, som Drupals EU Cookie Compliance-modul anvender, og som Cloudflare Zaraz anvender ved kanten — hvad der ændrer sig på Webflow, er, at operätøren selv skal tilføje bootstrap-scriptet.
Tredjeparts CMP-muligheden: når det native banner ikke er nok
For websteder, der kræver en mere komplet audit-trail, per-vendor konfiguration, multi-jurisdiktion logik eller integration med IAB TCF, er det native banner ikke tilstrækkeligt, og et tredjeparts CMP — Cookiebot, OneTrust, Usercentrics, Iubenda eller lignende — bør erstatte det. Integrationsmønsteret kræver, at det native banner slås fra først, ellers vil de to samtykkeoverflader konflikte.
- Cookiebot-integration — installer Cookiebot-snippetet via Custom Code i Head-sektionen, markér Cookiebot-administrerede scripts med data-cookieconsent-attributter og deaktiver Webflows native banner i projektindstillingerne.
- OneTrust-integration — installer OneTrust CDN-snippetet, konfigurer OneTrust-dashboardet til at læse Webflows kategoristruktur og slå det native banner fra.
- Usercentrics-integration — installer Usercentrics-snippetet, konfigurer servicedefinitioner i Usercentrics-dashboardet og deaktiver det native banner.
- Iubenda-integration — installer Iubenda Consent Solution-snippetet, konfigurer politikken og kategorikobling og deaktiver det native banner.
Webflow CMS Collections og dynamisk renderet indhold
Webflows CMS Collections introducerer en samtykkeoverflade, som statiske sider ikke har. En Collection-side med et tredjeparts widget — et YouTube-embed i et blogindlæg, et TikTok-feed på en porteføljeside — arver de samtykkebeslutninger, der er truffet på den hostende side, men det indlejrede indhold respekterer ikke automatisk disse beslutninger, medmindre operätøren har konfigureret Collection til at rendere embeddet via en click-to-load-pladsholder. Mønsteret er at tilføje et Collection-felt til embed-URL og et separat felt der markerer den krævede samtykkekategori, derefter betinget rendere embeddet via en Custom Code-blok i Collection-skabelonen.
Validering og auditposition for 2026
En forsvarlig Webflow-implementering i 2026 skal bestå fire tekniske tjek. Først skal en ren browsersession serveret fra en EEA IP-adresse producere nul ikke-essentielle cookies, inden banneret er aktiveret. Dernæst skal afvisningsstien bevare den tilstand. Tredje skal acceptstien kun producere de tags, brugeren har samtykket til, og samtykkeloggen skal indeholde den matchende post. Fjerde skal en tilbagetrækning øjeblikkeligt stoppe yderligere tag-afviklinger, udløbe cookies sat under den samtykkede session og udbrede fravalget til eventuelle downstream tredjepartsmodtagere.
Det native banner registrerer brugerens samtykkestatus i en førstepartscookie, men vedligeholder ikke en serverside-auditlog, der kan forespørges på bruger- eller sessionsidentifikator. For implementeringer, der kræver en mere komplet audit-trail — multi-jurisdiktion rapportering, per-vendor samtykkeoptegnelser, integration med EDPBs forventede dokumentationsstandard — er et tredjeparts CMP det rigtige svar. Et Webflow-websted, der bevidst har valgt mellem de to stier, blokeret hver Custom Code-overflade og adresseret Collection embed-mønsteret, har omdannet platformens visuelle bygherres enkelhed til en forsvarlig del af et bureaus samtykkeposition frem for en skjult compliance-gæld.