Guía de integración do consentimento de cookies en Webflow: banner nativo, código personalizado e CMP de terceiros para 2026
Webflow ocupa unha posición singular no ecosistema de construtores de sitios web. Está máis preto dunha ferramenta de deseño que dun CMS, máis preto dun CMS que dunha plataforma de aplicacións aloxadas, e cada vez máis é a plataforma que as axencias elixen cando queren sitios de mercadotecnia completamente personalizados sen a carga técnica de xestionar un stack Next.js ou Drupal. Webflow entrega un banner nativo Cookie Consent con valores predeterminados razoables, expón a inxección de Custom Code a nivel de sitio e páxina, intégrase co HTML incrustado e ofrece aos operadores un modelo CMS Collections. Un sitio Webflow que activou o banner nativo e parou aí é raramente totalmente conforme; un que conectou o banner nativo a un CMP de terceiros, limitou o Custom Code e auditou os scripts incrustados é un dos despregamentos máis limpos que unha axencia pode entregar en 2026.
Que fai o Cookie Consent nativo de Webflow e onde se detén
Webflow engadiu a función nativa Cookie Consent en 2022 e melloorouaa dende entón. A función admite tres categorías de cookies preconfiguradas — Essential, Marketing e Personalization — expón unha interface de banner configurable accesible a través da configuración do proxecto e vincula o bloqueo de Google Analytics á elección do usuario. O banner rexistra o consentimento do usuario nunha cookie de primeira parte.
O que o banner nativo de Webflow non fai — e onde a maioría dos despregamentos construídos por axencias fallan — é bloquear o Custom Code que os operadores engaden rutinariamente para análises, píxeles de mercadotecnia, widgets de chat e vídeos incrustados. Os puntos de inxección de Custom Code execútanse antes de que o banner se renderice. As axencias engaden a miúdo Hotjar, Facebook Pixel, un script CRM de terceiros ou un embed de Calendly vía Custom Code asumindo que o banner nativo xestiona o bloqueo. Non o fai.
A configuración predeterminada opt-in fronte ao consentimento implícito
O banner nativo expón tres estilos de consentimento. O estilo de consentimento implícito foi fonte de achados regulatorios repetidos contra sitios aloxados en Webflow no EEE. O estilo opt-in é o predeterminado correcto para calquera despregamento dirixido ao EEE, UK, Brasil, Suíza ou calquera xurisdicción que importase o estándar GDPR. O operador debe seleccionar opt-in, configurar as categorías como desactivadas por defecto e verificar na vista previa que o botón de rexeitamento é polo menos tan visualmente prominente como o botón de aceptación.
Bloqueo do Custom Code: o traballo que o banner nativo non fai
O padrón de integración que funciona en Webflow ten tres partes. Primeiro, configurar correctamente o banner nativo. Segundo, envolver cada script de Custom Code nunha verificación de consentimento antes de executarse. Terceiro, decidir se o banner nativo é suficiente ou se un CMP de terceiros debe substituílo.
O padrón de bloqueo máis sinxelo é ler a cookie de consentimento de Webflow ou o estado de consentimento do hook de JavaScript exposto e executar condicionalmente a lóxica de terceiros. Para scripts no Footer Code, o padrón é envolver o fragmento nun escoitador de eventos que se activa no evento de cambio de consentimento de Webflow. Para scripts no Head Code — onde viven a maioría dos fragmentos de análise e píxeles — o padrón é cargar o fragmento como marcador de posición, coa solicitude real diferida ata que pase a verificación de consentimento.
O padrón de marcador de posición para scripts de terceiros
O padrón que funciona nas integracións Webflow máis comúns é o marcador de posición <script type="text/plain">. O script de terceiros inclúese no marcado da páxina pero co atributo type establecido nun valor que o navegador non executará. Un pequeno script bootstrap — engadido unha vez no Footer Code — escoita o evento de cambio de consentimento de Webflow, identifica scripts marcadores que corresponden á categoría concedida e reescribe o seu atributo type a text/javascript. O padrón é o mesmo que usa o módulo EU Cookie Compliance de Drupal e que Cloudflare Zaraz aplica no edge.
A opción de CMP de terceiros: cando o banner nativo non é suficiente
Para sitios que precisan un rastro de auditoría máis completo, configuración por provedor, lóxica multixurisdicional ou integración con IAB TCF, o banner nativo non é suficiente e un CMP de terceiros — Cookiebot, OneTrust, Usercentrics, Iubenda — debería substituílo. Require desactivar primeiro o banner nativo.
- Integración con Cookiebot — instalar o fragmento de Cookiebot vía Custom Code na sección Head, marcar scripts xestionados por Cookiebot con atributos data-cookieconsent e desactivar o banner nativo de Webflow na configuración do proxecto.
- Integración con OneTrust — instalar o fragmento CDN de OneTrust, configurar o panel de OneTrust para ler a estrutura de categorías de Webflow e desactivar o banner nativo.
- Integración con Usercentrics — instalar o fragmento de Usercentrics, configurar as definicións de servizos que reflicten o inventario real de etiquetas do operador e desactivar o banner nativo.
- Integración con Iubenda — instalar o fragmento de Iubenda Consent Solution, configurar a política e a asignación de categorías e desactivar o banner nativo.
CMS Collections de Webflow e contido renderizado dinámicamente
As CMS Collections de Webflow merecen atención específica porque introducen una superficie de consentimento que as páxinas estáticas non teñen. Unha páxina de colección que incrusta un widget de terceiros — un embed de YouTube nun post, un feed de TikTok nunha páxina de portafolio — herda as decisións de consentimento tomadas na páxina que a alberga, pero o contido incrustado non respecta automaticamente esas decisións a menos que o operador configurase a colección para renderizar o embed mediante un marcador de posición click-to-load.
Validación e postura de auditoría para 2026
Un despregamento Webflow defendible en 2026 debe superar catro verificacións técnicas. Primeiro, unha sesión de navegador limpa servida desde unha IP do EEE debe producir cero cookies non esenciais antes de que o banner sexa accionado. Segundo, a ruta de rexeitamento debe manter ese estado. Terceiro, a ruta de aceptación debe producir só as etiquetas consentidas e o rexistro de consentimento debe conter o rexistro correspondente. Cuarto, unha retirada debe deter inmediatamente os disparos de etiquetas e propagar a cancelación aos destinatarios de terceiros.
O banner nativo rexistra o estado de consentimento nunha cookie de primeira parte pero non mantén un rexistro de auditoría do lado do servidor consultable por identificador de usuario. Para despregamentos que precisan un rastro de auditoría máis completo — informes multixurisdicionais, rexistros por provedor, integración co estándar esperado do EDPB — un CMP de terceiros é a resposta correcta. Un sitio Webflow que elixiu deliberadamente entre as dúas vías, bloqueou cada superficie de Custom Code e abordou o padrón de incrustación en coleccións, transformou a sinxeleza do construtor visual da plataforma nunha parte defendible da postura de consentimento dunha axencia en lugar dunha débeda de cumprimento oculta.