Cómo añadir un banner de cookies en Webflow

Todos los artículos

Para añadir un banner de cookies a una web de Webflow, pega el script de tu plataforma de consentimiento en Site settings, Custom code, Head code, por encima de cualquier otro script de seguimiento, y publica. Antes, vacía los campos nativos de Google Analytics y Meta Pixel en Apps and Integrations: lo que haya ahí se carga fuera de tu gestor de etiquetas, donde no llega ningún filtro de consentimiento.

Webflow carga el seguimiento desde dos lugares, y tu banner controla uno

Casi todas las guías sobre esta cuestión se quedan en el mismo punto: date de alta en una herramienta de consentimiento, pega el fragmento en el head y publica. Es correcto, pero no es lo que decide si la configuración aguanta. Una web de Webflow tiene dos puntos independientes por los que el seguimiento entra en la página, y un banner controla uno.

Site settings, Custom code es el apartado que controlas tú. Los valores por defecto, el banner y el contenedor van todos en la caja de Head code en el orden en que los pongas, y cada etiqueta que dispara el contenedor puede quedar retenida tras una condición de consentimiento.

Site settings, Apps and Integrations es el apartado que la gente olvida que usó. Pega ahí un ID de medición de GA4 y Webflow inyecta Google Analytics en todas las páginas por ti; pega un ID de Meta Pixel y hace lo mismo con el píxel. Ninguno de los dos pasa por tu contenedor, así que nada de lo que configures en él les afecta. Condicionar tu etiqueta de GA4 no cambia nada mientras haya un ID de medición en ese campo.

Los dos campos ni siquiera se comportan igual. El de Meta Pixel tiene un interruptor Delay for cookie consent que retiene el píxel hasta que se registra el consentimiento, y la documentación de Webflow deja claro que activarlo sigue requiriendo un banner propio. El de Google Analytics no tiene nada equivalente: uno se puede hacer esperar y el otro no.

Vaciar esos campos cambia lo que cuenta GA4, así que toma antes una referencia. Apunta una semana de sesiones de GA4 junto a otro recuento de los mismos días del que te fíes, como las peticiones a la CDN o los pedidos. Cuando el banner esté activo, la tasa de aceptación de tu herramienta de consentimiento te dirá qué parte de la diferencia se debe al consentimiento. Esa proporción varía según la región, el público y el diseño del banner, así que mide la tuya en lugar de tomar prestada una cifra.

¿Cómo configuras un banner de cookies en Webflow?

1. Vacía primero los campos de seguimiento nativos

   Abre Site settings, Apps and Integrations. Si ahí hay un ID de medición de GA4 o un ID de Meta Pixel, Webflow inyecta esa etiqueta en todas las páginas por su cuenta, fuera de tu contenedor, donde no llega ninguna condición de consentimiento de tus etiquetas. Vacíalos y carga las dos a través del contenedor. Si dejas una en su sitio mientras la misma etiqueta también se ejecuta en el contenedor, además de la fuga, cuentas doble.

2. Pon los valores por defecto denegados por encima de todo

   Arriba del todo de Site settings, Custom code, Head code, fija un valor por defecto de Consent Mode que deniegue ad_storage, analytics_storage, ad_user_data y ad_personalization. Tiene que ir por encima del banner y del contenedor: un valor por defecto que llega después de que se haya disparado una etiqueta es una corrección tardía, no un valor por defecto. Al ser un bloque independiente, también aguanta aunque la petición del banner sea lenta o falle.

3. Añade el banner y después el contenedor

   Los dos van en la misma caja de Head code, primero el banner, para que registre su estado antes de que se procese el contenedor. La caja admite hasta 50,000 caracteres, de sobra para los tres juntos, así que no hay motivo para llevarte una configuración larga a otro sitio por ahorrar espacio.

4. Pon el noscript del contenedor en Footer code

   Webflow te da un hueco en el head y otro antes de la etiqueta de cierre del body, pero ninguno justo después de la etiqueta de apertura del body, que es donde la documentación suele indicar que va el fragmento noscript de un contenedor. Footer code es la ubicación que funciona aquí, y importa mucho menos que el fragmento del head.

5. Resuelve los scripts que ya están en el head

   Cualquier script de un proveedor pegado directamente en Head code se carga por su cuenta, y un gestor de etiquetas que nunca lo ha controlado no puede condicionarlo. Haz inventario de esa caja antes de dar la web por terminada. Cada script, o pasa al contenedor como etiqueta condicionada, o se envuelve para que la capa de consentimiento pueda retenerlo, o se justifica como estrictamente necesario: una cuestión de requisitos que conviene resolver script a script.

6. Publica y comprueba en el dominio en producción

   El código personalizado aparece en la vista previa, pero no se activa hasta que publicas, así que una comprobación en el Designer no demuestra nada. Publica, carga el dominio en producción con un perfil limpio y no hagas clic en nada: no debería instalarse ninguna cookie de analítica ni de publicidad, ni llegar ninguna petición a tus proveedores. Después acepta y confirma que aparece todo. Prueba el dominio en producción, no solo el subdominio de staging webflow.io, porque los dos pueden tener publicados estados distintos.

La secuencia completa previa al lanzamiento, que merece la pena hacer bien una vez, está en cómo probar un banner de cookies antes de publicarlo.

¿Qué pilla desprevenida a la gente en Webflow?

La vista previa no es la web publicada. La documentación de Webflow lo dice sin rodeos: los efectos del código personalizado aparecen en la vista previa, pero no se activan hasta que se publica la web. Todas las comprobaciones de consentimiento tienen que hacerse en la web publicada.

Los Components duplican todo lo que metas en ellos. Un fragmento dentro de un Component usado en una cabecera global se publica en todas las páginas que lo usan. Dos contenedores en una página son un problema aparte, y parece un fallo de consentimiento mucho antes de que nadie sospeche de la cabecera. Los fragmentos para toda la web van en Site settings.

El código de página se ejecuta después del código de toda la web. El código personalizado de una página concreta aparece en el marcado después del código de toda la web. Para los valores por defecto ese es el orden correcto, y significa que un bloque de valores por defecto añadido a una página no puede salvarla: el contenedor de toda la web ya se ha procesado más arriba.

El banner documentado para el Pixel es un filtro para el píxel, no una capa de consentimiento. Webflow explica cómo construir a mano un banner para su Meta Pixel nativo: Interactions para mostrarlo y ocultarlo, más un script en Footer code que concede el consentimiento al píxel con un clic. Está pensado solo para ese píxel y así lo dice. Como capa de consentimiento general se queda corto: concede el consentimiento pero no ofrece forma de retirarlo, el botón de rechazar solo oculta el banner y no controla nada más de la página. El artículo 7 del RGPD exige que retirar el consentimiento sea tan fácil como darlo, así que es un punto de partida, no la meta.

Cuando el banner está activo y siguen apareciendo cookies

Revisa los orígenes en el orden en que suelen resultar ser la respuesta. Primero, los campos de Apps and Integrations, que nada de tu contenedor deja ver. Segundo, los scripts pegados directamente en Head code. Tercero, un fragmento duplicado a través de un Component. Solo entonces abre el contenedor.

Hay un cuarto origen que no es culpa de Webflow: una etiqueta bien condicionada puede cargar a su vez el píxel de otro proveedor, algo que tratamos aquí. La secuencia completa previa al lanzamiento está en cómo probar un banner de cookies antes de publicarlo.

Hay una duda de ubicación que surge en casi todos los proyectos de Webflow: el head o el gestor de etiquetas. La respuesta es los dos, cada uno con su función. Deja en Head code un pequeño bloque con los valores por defecto denegados para que el estado denegado exista antes de que cargue nada, y deja la herramienta en sí donde puedan llegar quienes gestionan las etiquetas. Si la herramienta vive solo en el head y su petición falla, el contenedor se dispara sin ningún valor por defecto registrado, y eso falla en la dirección equivocada.

Velo se instala en Webflow como un único fragmento en esa caja de Head code: valores por defecto, banner y el estado de consentimiento que lee el contenedor, en el orden correcto por diseño.