Cuando el banner de cookies cambia y nadie te avisa

El cookie banner monitoring consiste en controlar qué plataforma de gestión del consentimiento (CMP) funciona en un sitio, confirmar que sobrevive a cada deploy y comprobar que los tags de marketing siguen comportándose bien en torno al consentimiento. Si el banner desaparece, el sitio empieza a instalar cookies de seguimiento sin preguntar, lo que es un problema de RGPD; si cambia, GA4 y el Meta Pixel pueden dejar de cargarse mientras todas las páginas parecen perfectamente sanas.

Ninguna página devuelve un 404 y ningún monitor de uptime se pone en rojo. La primera señal suele ser un gráfico de conversiones que deja de cuadrar unas semanas más tarde.

Quién toca el banner y por qué nadie te avisa

El consentimiento queda a caballo entre departamentos. Legal se encarga de la política de cookies y muchas veces del contrato con la CMP. Un desarrollador controla el plugin o el script del <head>. Marketing gestiona los tags que dependen de él. Del resultado final no se ocupa nadie, así que los cambios se hacen por motivos que tienen lógica para un equipo y nunca llegan a los demás.

Algunos ejemplos típicos. Un desarrollador instala Complianz o CookieYes en un WordPress que ya tenía un sistema de consentimiento. Legal pasa la cuenta de Cookiebot a OneTrust y lo archiva como una gestión contractual. Una actualización del tema o del CMS elimina el snippet que cargaba la CMP. Alguien renombra las categorías de consentimiento y un tag acaba en una categoría que ningún visitante activa. O el banner estaba desactivado en staging para facilitar las pruebas, y ese ajuste sale a producción con la release.

Cada uno de estos casos es un cambio SEO silencioso de manual, con la diferencia de que el daño cae sobre la analítica y el cumplimiento normativo en lugar de sobre el posicionamiento.

Qué le hace un cambio de CMP a GA4 y al Meta Pixel

La mayoría de las CMP bloquean scripts antes del consentimiento, ya sea por la URL del script o asignando los tags a categorías. Una CMP nueva no sabe nada de las excepciones que tenía configuradas la anterior, así que un tag que antes se cargaba tras «Aceptar» puede no cargarse nunca. Google Tag Manager está en la página, el contenedor se dispara y el tag de GA4 que hay dentro sigue bloqueado.

Con Google Consent Mode v2 el fallo cuesta más de ver. La página fija un estado por defecto con gtag('consent', 'default', {...}), y el banner debería llamar a gtag('consent', 'update', {...}) cuando el visitante acepta. Si el banner nuevo nunca envía esa actualización, analytics_storage y ad_storage se quedan en denegado. GA4 sigue recibiendo hits, pero son pings sin cookies, y los informes se llenan de datos modelados en lugar de sesiones observadas. En la pestaña Network lo ves en la petición a /g/collect: el parámetro gcs vale G100 cuando los dos tipos de almacenamiento están denegados y G111 cuando ambos están concedidos.

El fallo contrario parece una buena noticia. Si el banner desaparece del todo, los tags se disparan para todo el mundo y las sesiones de GA4 suben de golpe. Esa subida es un problema de cumplimiento, no crecimiento.

Un desajuste de categorías golpea sobre todo a la publicidad de pago. Cuando el Meta Pixel depende de una categoría «marketing» que el nuevo banner esconde en una segunda pantalla, las campañas siguen gastando mientras las conversiones dejan de atribuirse.

Qué debería hacer la página en cada estado

Estado	GA4 / GTM	Meta Pixel	Cookies que deberías ver
Antes de elegir	Bloqueado, o Consent Mode con denegado por defecto	Sin cargar	Ni _ga ni _fbp
Tras «Aceptar»	Se carga gtag.js, /g/collect con gcs=G111	Se carga fbevents.js	_ga, _ga_<ID>, _fbp
Tras «Rechazar»	Sin hits, o solo hits sin cookies	Sin cargar	Ni _ga ni _fbp

Cookie banner monitoring a mano: cómo probar el consentimiento

1. Abre una ventana privada nueva. Una elección de consentimiento guardada de una visita anterior esconderá el problema.
2. Carga la home y anota qué CMP muestra el banner. Cookiebot, Iubenda, OneTrust, CookieYes y Complianz tienen un marcado y unas URLs de script reconocibles.
3. Abre DevTools, ve a Network y filtra por collect, gtag y fbevents. Revisa también Application > Cookies.
4. Pulsa «Aceptar» y confirma que aparecen las peticiones y las cookies de la tabla anterior. Comprueba que el measurement ID de la petición (tid=G-...) sigue siendo el del cliente.
5. Repite en otra ventana privada nueva, esta vez pulsando «Rechazar».
6. Haz lo mismo en cada plantilla importante, y no te saltes la página de gracias o de confirmación del pedido, porque ahí se disparan los tags de conversión.

Son unos diez minutos por sitio. Asumible una vez, poco realista después de cada release en treinta sitios de clientes.

Qué vigila Deltio del banner y dónde se detiene

Deltio revisa la home de cada sitio una vez al día, registra qué CMP está presente y te avisa por Slack y email cuando el proveedor aparece, desaparece o cambia. El mismo ciclo diario comprueba GA4, GTM y el Meta Pixel en las páginas monitorizadas e informa de un tag que ha desaparecido o cuyo ID ha cambiado. Así, un cambio de banner y un pixel ausente aparecen en el mismo lugar y el mismo día.

No audita si tu configuración de consentimiento es legalmente adecuada ni hace un inventario de las cookies que instala un sitio. Te dice qué hay en la página y qué ha cambiado desde la comprobación anterior. Para el resto del sitio de un cliente, consulta la checklist de monitorización web para agencias y nuestra guía para monitorizar los sitios web de clientes en busca de cambios.

Un buen punto de partida es ese cliente en el que legal, el desarrollador y marketing nunca han coincidido en la misma llamada. Puedes añadir ese sitio con 14 días de prueba.