Webflow Cookie Consent integratie handleiding: Native banner, aangepaste code en CMP van derden voor 2026
Webflow neemt een unieke positie in het ecosysteem van websitebouwers in. Dichter bij een ontwerptool dan een CMS, dichter bij een CMS dan een gehost applicatieplatform, en wordt steeds meer het platform van keuze voor bureaus wanneer ze volledig aangepaste marketingwebsites willen zonder de technische last van het beheren van een Next.js of Drupal-stack. Webflow levert een native Cookie Consent-banner met redelijke standaardwaarden, stelt Custom Code-injectie bloot op site- en paginaniveau, integreert met ingesloten HTML, en geeft operators een CMS Collections-model. Een Webflow-site die alleen de native banner heeft geactiveerd, is zelden volledig compliant; een site die de native banner heeft gekoppeld aan een CMP van een derde partij, de Custom Code heeft geblokkeerd en de ingesloten scripts heeft geauditeerd, is een van de schoonste builds die een bureau in 2026 kan leveren.
Wat de native Cookie Consent van Webflow doet en waar het stopt
Webflow voegde de native Cookie Consent-functie toe in 2022 en heeft deze sindsdien verder ontwikkeld. De functie ondersteunt drie vooraf ingestelde cookiecategorieën — Essential, Marketing en Personalization — stelt een configureerbare bannerinterface bloot via projectinstellingen en koppelt de blokkering van Google Analytics aan de keuze van de gebruiker. De banner registreert de toestemming van de gebruiker in een first-party cookie.
Wat de native banner van Webflow niet doet — en waar de meeste bureau-gebouwde implementaties falen — is het blokkeren van Custom Code die operators regelmatig toevoegen voor analytics, marketingpixels, chatwidgets en ingesloten video's. Custom Code-injectiepunten draaien voordat de banner wordt weergegeven, wat betekent dat scripts van derden die via die punten zijn toegevoegd, worden uitgevoerd voordat er een toestemmingsbeslissing bestaat. Bureaus voegen vaak Hotjar, Facebook Pixel, CRM-scripts van derden of Calendly-embeds toe via Custom Code en gaan ervan uit dat de native banner het blokkeren afhandelt. Dat doet het niet.
De standaard opt-in vs. impliciete toestemmingsinstelling
De native banner stelt drie toestemmingsstijlen bloot. De impliciete toestemmingsstijl is een bron geweest van herhaalde regulatoire bevindingen tegen Webflow-gehoste sites in de EEA. De opt-in stijl is de juiste standaard voor elke implementatie die de EEA, VK, Brazilië, Zwitserland, of een andere jurisdictie die GDPR-normen heeft aangenomen, target. Operators moeten opt-in kiezen, categorieën standaard uitgeschakeld configureren en in de preview verifiëren dat de weigeringsknop visueel minstens even prominent is als de acceptatieknop.
Custom Code blokkeren: het werk dat de native banner niet doet
Het werkende integratiepatroon in Webflow heeft drie delen. Ten eerste, de native banner correct configureren. Ten tweede, elk Custom Code-script inpakken in een toestemmingscontrole vóór uitvoering. Ten derde, beslissen of de native banner voldoende is of dat een CMP van een derde partij het moet vervangen voor audittracking en configurability per vendor.
Het eenvoudigste blokkeringspatroon is het lezen van de Webflow toestemmingscookie of toestemmingsstatus van de door het platform blootgestelde JavaScript-hook en conditioneel de logica van derden uitvoeren. Voor scripts die zijn toegevoegd in de Footer Code-sectie, is het patroon het inpakken van het snippet in een event listener die wordt geactiveerd op het Webflow toestemmingswijzigingsevenement. Voor scripts in de Head Code-sectie — waar de meeste analytics- en pixelsnippets leven — is het patroon het laden van het snippet als een placeholder, waarbij het daadwerkelijke verzoek van derden wordt uitgesteld totdat de toestemmingscontrole slaagt.
Het placeholderpatroon voor scripts van derden
Het patroon dat werkt voor de meeste gangbare Webflow-integraties is de <script type="text/plain">-placeholder. Het script van een derde partij wordt opgenomen in de paginamarkup maar met het type-attribuut ingesteld op een waarde die de browser niet uitvoert. Een klein bootstrapscript — eenmalig toegevoegd in de Footer Code-sectie — luistert naar het Webflow toestemmingswijzigingsevenement, identificeert placeholderscripts die overeenkomen met de gegeven categorie en herschrijft hun type-attribuut naar text/javascript voor uitvoering. Het patroon is identiek aan dat gebruikt door de Drupal EU Cookie Compliance-module en dat Cloudflare Zaraz aan de edge toepast.
CMP-opties van derden: wanneer de native banner niet voldoet
Voor sites die een volledigere audittrail nodig hebben, configuratie per vendor, multi-jurisdictionele logica of integratie met IAB TCF, is de native banner niet voldoende en moet een CMP van een derde partij — Cookiebot, OneTrust, Usercentrics, Iubenda — deze vervangen. De native banner moet eerst worden uitgeschakeld.
- Cookiebot-integratie — installeer het Cookiebot-snippet via Custom Code in de Head-sectie, markeer door Cookiebot beheerde scripts met data-cookieconsent-attributen en schakel de native Webflow-banner uit in de projectinstellingen.
- OneTrust-integratie — installeer het OneTrust CDN-snippet, configureer het OneTrust-dashboard om de categoriëstructuur van Webflow te lezen en schakel de native banner uit.
- Usercentrics-integratie — installeer het Usercentrics-snippet, configureer de servicedefinities in het Usercentrics-dashboard die de daadwerkelijke taginventaris van de operator weerspiegelen en schakel de native banner uit.
- Iubenda-integratie — installeer het Iubenda Consent Solution-snippet, configureer het beleid en de categoriemapping en schakel de native banner uit.
Webflow CMS Collections en dynamisch weergegeven inhoud
Webflow CMS Collections verdienen speciale aandacht omdat ze een toestemmingsoppervlak introduceren dat statische pagina's niet hebben. Een Collection-pagina die een widget van een derde partij insluit — YouTube-embed in een blogpost, TikTok-feed op een portfoliopagina — erft toestemmingsbeslissingen die zijn genomen op de hostingpagina, maar de ingesloten inhoud respecteert die beslissingen niet automatisch tenzij de operator de Collection heeft geconfigureerd om embeds te renderen via click-to-load-placeholders.
Validatie en auditpositie voor 2026
Een verdedigbare Webflow-implementatie in 2026 moet vier technische controles doorstaan. Ten eerste moeten schone browsersessies die worden bediend vanuit een EEA IP-adres nul niet-essentiële cookies produceren voordat de banner wordt geactiveerd. Ten tweede moet het weigeringspad die toestand handhaven. Ten derde moet het acceptatiepad alleen tags produceren waarmee de gebruiker heeft ingestemd en moet het toestemmingslogboek een overeenkomend record bevatten. Ten vierde moet een intrekking onmiddellijk verdere tagactivering stoppen en de opt-out doorgeven aan downstream ontvangers van derden.
De native banner registreert de toestemmingsstatus van de gebruiker in een first-party cookie maar houdt geen server-side auditlog bij waarop kan worden gezocht op gebruiker- of sessie-identifier. Voor implementaties die een volledigere audittrail nodig hebben — multi-jurisdictionele rapportage, toestemmingsrecords per vendor, integratie met de door EDPB verwachte documentatienormen — is een CMP van een derde partij het juiste antwoord. Een Webflow-site die bewust heeft gekozen tussen de twee paden, elk Custom Code-oppervlak heeft geblokkeerd en het Collection-embedpatroon heeft afgehandeld, heeft de eenvoud van de visual builder van het platform omgezet in een verdedigbaar onderdeel van de toestemmingspositie van het bureau in plaats van verborgen nalevingsschuld.