Guía de integración del consentimiento de cookies en Webflow: banner nativo, código personalizado y CMP de terceros para 2026
Webflow ocupa una posición singular en el ecosistema de constructores de sitios web. Está más cerca de una herramienta de diseño que de un CMS, más cerca de un CMS que de una plataforma de aplicaciones alojadas, y cada vez más es la plataforma que las agencias eligen cuando quieren sitios de marketing completamente personalizados sin la carga de ingeniería de gestionar un stack Next.js o Drupal. Webflow entrega un banner nativo Cookie Consent con valores predeterminados razonables, expone la inyección de Custom Code a nivel de sitio y página, se integra con HTML incrustado y ofrece a los operadores un modelo CMS Collections. Un sitio Webflow que ha activado el banner nativo y se ha detenido ahí raramente es totalmente conforme; uno que ha conectado el banner nativo a un CMP de terceros, limitado su Custom Code y auditado sus scripts incrustados es uno de los despliegues más limpios que una agencia puede entregar en 2026.
Qué hace el Cookie Consent nativo de Webflow y dónde se detiene
Webflow añadió la función nativa Cookie Consent en 2022 y la ha iterado desde entonces. La función admite tres categorías de cookies preconfiguradas — Essential, Marketing y Personalization — expone una interfaz de banner configurable desde la configuración del proyecto y vincula el bloqueo de Google Analytics a la elección del usuario. El banner registra el consentimiento en una cookie de primera parte y expone el estado de consentimiento a las propias herramientas de Webflow.
Lo que el banner nativo no hace — y donde fallan la mayoría de despliegues de agencias — es bloquear el Custom Code que los operadores añaden rutinariamente para analytics, píxeles de marketing, widgets de chat y vídeos incrustados. Los puntos de inyección de Custom Code se ejecutan antes de que el banner se haya renderizado. Las agencias suelen añadir Hotjar, Facebook Pixel, un script CRM de terceros o un embed de Calendly vía Custom Code asumiendo que el banner nativo gestiona el bloqueo. No lo hace.
La configuración predeterminada opt-in frente al consentimiento implícito
El banner nativo expone tres estilos de consentimiento. El estilo de consentimiento implícito ha sido fuente de hallazgos regulatorios repetidos contra sitios alojados en Webflow en el EEA. Opt-in es el predeterminado correcto para cualquier despliegue dirigido a EEA, UK, Brasil, Suiza o cualquier jurisdicción que haya importado el estándar GDPR. El operador debe seleccionar opt-in, configurar las categorías como desactivadas por defecto y verificar en la vista previa que el botón de rechazo es al menos tan visualmente prominente como el botón de aceptación.
Bloqueo del Custom Code: el trabajo que el banner nativo no hace
El patrón de integración que funciona en Webflow tiene tres partes. Primero, configurar correctamente el banner nativo. Segundo, envolver cada script de Custom Code en una verificación de consentimiento antes de ejecutarse. Tercero, decidir si el banner nativo es suficiente o si un CMP de terceros debe reemplazarlo para la traza de auditoría y la configurabilidad por proveedor.
El patrón de bloqueo más sencillo es leer la cookie de consentimiento de Webflow o el estado de consentimiento del hook de JavaScript expuesto y ejecutar condicionalmente la lógica de terceros. Para scripts en la sección Footer Code, el patrón es envolver el fragmento en un listener de eventos que se activa en el evento de cambio de consentimiento de Webflow. Para scripts en Head Code — donde viven la mayoría de los fragmentos de analytics y píxeles — el patrón es cargar el fragmento como marcador de posición, con la solicitud real diferida hasta que pase la verificación de consentimiento.
El patrón de marcador de posición para scripts de terceros
El patrón que funciona en las integraciones Webflow más comunes es el marcador de posición <script type="text/plain">. El script de terceros se incluye en el marcado de la página pero con el atributo type establecido a un valor que el navegador no ejecutará. Un pequeño script bootstrap — añadido una vez en Footer Code — escucha el evento de cambio de consentimiento de Webflow, identifica scripts marcadores que coinciden con la categoría concedida y reescribe su atributo type a text/javascript. El patrón es el mismo que usa el módulo EU Cookie Compliance de Drupal y que Cloudflare Zaraz aplica en el edge.
La opción de CMP de terceros: cuando el banner nativo no es suficiente
Para sitios que necesitan una traza de auditoría más completa, configuración por proveedor, lógica multijurisdicción o integración con IAB TCF, el banner nativo no es suficiente y un CMP de terceros — Cookiebot, OneTrust, Usercentrics, Iubenda — debería reemplazarlo. Requiere desactivar primero el banner nativo.
- Integración con Cookiebot — instalar el fragmento de Cookiebot vía Custom Code en la sección Head, marcar scripts gestionados por Cookiebot con atributos data-cookieconsent y desactivar el banner nativo en la configuración del proyecto.
- Integración con OneTrust — instalar el fragmento CDN de OneTrust, configurar el panel de OneTrust para leer la estructura de categorías de Webflow y desactivar el banner nativo.
- Integración con Usercentrics — instalar el fragmento de Usercentrics, configurar definiciones de servicios en el panel que reflejen el inventario real de etiquetas del operador y desactivar el banner nativo.
- Integración con Iubenda — instalar el fragmento de Iubenda Consent Solution, configurar la política y el mapeo de categorías y desactivar el banner nativo.
CMS Collections de Webflow y contenido renderizado dinámicamente
Las CMS Collections de Webflow merecen atención específica porque introducen una superficie de consentimiento que las páginas estáticas no tienen. Una página de colección que incrusta un widget de terceros — un embed de YouTube en un post, un feed de TikTok en una página de portafolio — hereda las decisiones de consentimiento tomadas en la página que la aloja, pero el contenido incrustado no respeta automáticamente esas decisiones a menos que el operador haya configurado la colección para renderizar el embed mediante un marcador de posición click-to-load.
Validación y postura de auditoría para 2026
Un despliegue Webflow defendible en 2026 debe superar cuatro verificaciones técnicas. Primero, una sesión de navegador limpia desde una IP de la EEA debe producir cero cookies no esenciales antes de que el banner sea accionado. Segundo, la ruta de rechazo debe mantener ese estado. Tercero, la ruta de aceptación debe producir solo las etiquetas consentidas y el registro de consentimiento debe contener el registro correspondiente. Cuarto, una retirada debe detener inmediatamente los disparos de etiquetas, expirar las cookies establecidas durante la sesión consentida y propagar la cancelación a los destinatarios de terceros.
El banner nativo registra el estado de consentimiento en una cookie de primera parte pero no mantiene un registro de auditoría del lado del servidor consultable por identificador de usuario. Para despliegues que necesitan una traza de auditoría más completa — informes multijurisdicción, registros por proveedor, integración con el estándar esperado del EDPB — un CMP de terceros es la respuesta correcta. Un sitio Webflow que ha elegido deliberadamente entre ambas vías, bloqueado cada superficie de Custom Code y abordado el patrón de incrustación en colecciones, ha convertido la simplicidad del constructor visual de la plataforma en una parte defendible de la postura de consentimiento de una agencia en lugar de una deuda de cumplimiento oculta.