Guia d'integració del consentiment de cookies a Webflow: bàner natiu, codi personalitzat i CMP de tercers per al 2026

Webflow ocupa una posició diferenciada dins l'ecosistema de constructors de llocs web. Està més a prop d'una eina de disseny que d'un CMS, més a prop d'un CMS que d'una plataforma d'aplicacions allotjades, i cada cop és més la plataforma que les agències trien quan volen llocs de màrqueting completament personalitzats sense la càrrega d'enginyeria de gestionar un stack Next.js o Drupal per compte propi. Webflow lliura un bàner natiu Cookie Consent amb valors predeterminats raonables, exposa la injecció de codi personalitzat a nivell de lloc i pàgina, s'integra amb HTML incrustat i ofereix als operadors un model de CMS Collections. Un lloc Webflow que ha activat el bàner natiu i s'ha aturat aquí rarament és totalment compliant; un lloc que ha connectat el bàner natiu a un CMP de tercers, ha limitat el codi personalitzat i ha auditat els scripts incrustats és una de les implementacions més netes que una agència pot lliurar el 2026.

Què fa el Cookie Consent natiu de Webflow i on s'atura

Webflow va afegir la funció nativa Cookie Consent el 2022 i l'ha millorat des d'aleshores. La funció admet tres categories de cookies preconfigurades — Essential, Marketing i Personalization — exposa una interfície de bàner configurable accessible des de la configuració del projecte, i vincula el bloqueig de Google Analytics a l'elecció de l'usuari. El bàner registra el consentiment de l'usuari en una cookie de primera part i exposa l'estat del consentiment a les eines integrades de Webflow. Quan l'operador activa la funció, configura les categories i selecciona l'estil de consentiment (opt-in, opt-out o implícit), la plataforma gestiona el bàner visible i el bloqueig bàsic de les integracions natives.

El que el bàner natiu de Webflow no fa — i on la majoria dels desplegaments construïts per agències fallen — és bloquejar el codi personalitzat que els operadors afegeixen habitualment per a analítiques, píxels de màrqueting, widgets de xat i vídeos incrustats. Els punts d'injecció de Custom Code s'executen abans que el bàner s'hagi renderitzat, el que significa que qualsevol script de tercers afegit a través d'aquests punts s'executa abans que existeixi cap decisió de consentiment. Les agències sovint afegeixen Hotjar, Facebook Pixel, un script CRM de tercers o un embed de Calendly via Custom Code i assumeixen que el bàner natiu gestiona el bloqueig. No ho fa.

La configuració predeterminada opt-in vs. consentiment implícit

El bàner natiu exposa tres estils de consentiment. L'estil de consentiment implícit ha estat la font de troballes repetides dels reguladors contra llocs allotjats a Webflow a l'EEA. L'estil opt-in és el predeterminat correcte per a qualsevol desplegament dirigit a l'EEA, UK, Brasil, Suïssa o qualsevol jurisdicció que hagi importat l'estàndard GDPR. L'operador ha de seleccionar opt-in, configurar les categories perquè estiguin desactivades per defecte i verificar en la previsualització que el botó de rebuig és com a mínim tan visualment prominent com el botó d'acceptació.

Bloqueig del codi personalitzat: la feina que el bàner natiu no fa

El patró d'integració que funciona a Webflow té tres parts. Primer, configurar correctament el bàner natiu. Segon, embolicar cada script de codi personalitzat en una verificació de consentiment abans d'executar-se. Tercer, decidir si el bàner natiu és suficient o si un CMP de tercers ha de substituir-lo per a la traçabilitat d'auditoria i la configurabilitat per proveïdor.

El patró de bloqueig més senzill és llegir la cookie de consentiment de Webflow o l'estat de consentiment del hook de JavaScript exposat per la plataforma i executar condicionalment la lògica de tercers. Per als scripts afegits a la secció Footer Code, el patró és embolicar el fragment en un listener d'esdeveniments que s'activa en l'esdeveniment de canvi de consentiment de Webflow. Per als scripts de la secció Head Code — on viuen la majoria dels fragments d'analítiques i píxels — el patró és carregar el fragment com a marcador de posició, amb la sol·licitud real de tercers diferida fins que la verificació de consentiment passi.

El patró de marcador de posició per a scripts de tercers

El patró que funciona en les integracions Webflow més comunes és el marcador de posició <script type="text/plain">. El script de tercers s'inclou al marcatge de la pàgina però amb l'atribut type establert a un valor que el navegador no executarà. Un petit script bootstrap — afegit una vegada a la secció Footer Code — escolta l'esdeveniment de canvi de consentiment de Webflow, identifica els scripts de marcador de posició que coincideixen amb la categoria concedida i reescriu el seu atribut type a text/javascript perquè s'executin. El patró és el mateix que utilitza el mòdul EU Cookie Compliance de Drupal i que Cloudflare Zaraz aplica a la vora — el que canvia a Webflow és que l'operador ha d'afegir el bootstrap ell mateix.

L'opció CMP de tercers: quan el bàner natiu no és suficient

Per als llocs que necessiten una traçabilitat d'auditoria més completa, configuració per proveïdor, lògica multijurisdicció o integració amb IAB TCF, el bàner natiu no és suficient i un CMP de tercers — Cookiebot, OneTrust, Usercentrics, Iubenda o similar — hauria de substituir-lo. El patró d'integració és senzill però requereix desactivar primer el bàner natiu, en cas contrari les dues superfícies de consentiment entraran en conflicte.

CMS Collections de Webflow i contingut renderitzat dinàmicament

Les CMS Collections de Webflow mereixen atenció específica perquè introdueixen una superfície de consentiment que les pàgines estàtiques no tenen. Una pàgina de col·lecció que incrusta un widget de tercers — un embed de YouTube dins d'un post de blog, un feed de TikTok dins d'una pàgina de portafoli — hereta les decisions de consentiment preses a la pàgina que l'allotja, però el contingut incrustat no respecta automàticament aquestes decisions a menys que l'operador hagi configurat la col·lecció per renderitzar l'embed mitjançant un marcador de posició click-to-load.

Validació i postura d'auditoria per al 2026

Un desplegament Webflow defensable el 2026 ha de superar quatre verificacions tècniques. Primer, una sessió de navegador neta servida des d'una adreça IP de l'EEA ha de produir zero cookies no essencials abans que el bàner s'hagi accionat. Segon, el camí de rebuig ha de mantenir aquest estat. Tercer, el camí d'acceptació ha de produir únicament les etiquetes a les quals l'usuari ha consentit, i el registre de consentiment ha de contenir el registre corresponent. Quart, una retirada ha d'aturar immediatament les activacions d'etiquetes, caducar les cookies establertes durant la sessió consentida i propagar la cancel·lació als destinataris de tercers aigües avall.

El bàner natiu registra l'estat de consentiment de l'usuari en una cookie de primera part però no manté un registre d'auditoria del costat del servidor que es pugui consultar per identificador d'usuari o sessió. Per als desplegaments que necessiten una traçabilitat d'auditoria més completa — informes multijurisdicció, registres de consentiment per proveïdor, integració amb l'estàndard de documentació esperat de l'EDPB — un CMP de tercers és la resposta correcta. Un lloc Webflow que ha triat deliberadament entre les dues vies, ha bloquejat cada superfície de Custom Code i ha abordat el patró d'incrustació de col·leccions ha convertit la simplicitat del constructor visual de la plataforma en una part defensable de la postura de consentiment d'una agència en lloc d'un deute de compliment ocult.

← Blog Llegir tot →