El 22 de octubre de 2026 el dueño de una tienda Shopify preguntó en r/shopify cómo resuelven otros los scripts que siguen cargando después de que el visitante pulse Rechazar. El banner decía una cosa y el navegador hacía otra. Es el problema de cookies más habitual en cualquier plataforma: el banner guarda la elección, pero nada en la página está conectado para obedecerla. WooCommerce, Shopify, una tienda headless en Next.js o Astro y un WordPress normal fallan igual, porque las fugas vienen de vídeos insertados, fuentes, código del tema y configuración de etiquetas, no del plugin del banner.
Esta guía muestra cómo comprobar, solo con el navegador, qué envía tu web después de Rechazar, qué peticiones se escapan con más frecuencia, qué transmite a propósito el modo de consentimiento avanzado de Google y cómo bloquear cada una. Cada punto remite a la norma, la sentencia o la documentación del proveedor. Es una guía práctica de pruebas, no asesoramiento jurídico.
Por qué siguen cargando scripts después de rechazar las cookies
La publicación que abrió el hilo lo resumía así:
Los píxeles de las apps son fáciles. Shopify se encarga de ellos. ¿Todo lo demás? Vídeos de YouTube, Google Fonts, widgets de chat, scripts de SEO y analítica: nada. En enero de 2022, un tribunal de Múnich concedió 100 euros a un visitante porque una web pasó su dirección IP a Google a través de Google Fonts, sin consentimiento.
(u/Plus_Cell394, r/shopify, 22 de octubre de 2026, traducción propia)
Un banner solo controla lo que está registrado en él. El código fijo en el tema, pegado en un campo del pie, añadido por un bloque de inserción o cargado por un plugin que ignora la interfaz del banner se ejecuta al cargar la página, sea cual sea la respuesta. El banner muestra “Rechazado” y acierta sobre su propio estado. La página simplemente nunca le preguntó.
Artículo 22.2 de la LSSI y la guía de cookies de la AEPD
En España la regla está en el artículo 22.2 de la LSSI: los prestadores pueden usar dispositivos de almacenamiento y recuperación de datos en los equipos de los usuarios siempre que estos hayan dado su consentimiento tras recibir información clara y completa sobre su uso.
La Guía sobre el uso de las cookies de la AEPD, actualizada en mayo de 2024, concreta el banner: la opción de rechazar debe ofrecerse en la misma capa y al mismo nivel que la de aceptar, con un mecanismo similar; si se usa un botón para aceptar, debe usarse un botón para rechazar. Un banner que cumple eso en pantalla y luego no bloquea nada es justo el caso de este artículo.
A nivel europeo, el TJUE declaró en Planet49 (C-673/17) que una casilla premarcada no es consentimiento válido y que el artículo 5.3 de la Directiva ePrivacy se aplica sea o no dato personal la información. Las Directrices 2/2023 del CEPD sobre el alcance técnico de ese artículo (versión 2.0, adoptada el 7 de octubre de 2024) incluyen el JavaScript con el que una entidad ordena al navegador enviar peticiones asíncronas con información, y dedican apartados a los píxeles de seguimiento y al seguimiento solo por dirección IP. “No usamos cookies” no cierra la cuestión. Si encaja una excepción es una pregunta jurídica. Si la petición ocurre, lo puedes comprobar tú.
Cómo comprobar el banner de cookies con las herramientas para desarrolladores
Chrome, Brave, Firefox y Edge funcionan igual aquí.
- Abre un perfil nuevo o una ventana privada sin extensiones. Los bloqueadores de anuncios ocultan justo las peticiones que buscas.
- Abre las herramientas para desarrolladores antes de cargar la página. En la pestaña Network marca “Preserve log” y “Disable cache”.
- Carga la portada sin tocar el banner. Apunta cada dominio externo. Antes de elegir, no debería cargar nada opcional.
- Pulsa Rechazar y recorre una ficha de producto, una página con vídeo, la de contacto y el carrito. Las fugas suelen estar en plantillas que la portada no usa.
- Filtra la lista por trozos de dominio:
google,gstatic,doubleclick,facebook,tiktok,youtube,hotjar,clarity, el nombre de tu proveedor de chat. - En la pestaña Application (Storage en Firefox) revisa Cookies, Local storage y Session storage de cada origen. Todo lo que vaya más allá del registro del rechazo y las cookies funcionales de sesión necesita explicación.
- Repite con Aceptar para confirmar que las herramientas funcionan cuando están permitidas.
Anota el resultado en una tabla: dominio, página, antes de elegir, tras Rechazar, tras Aceptar. Esa tabla es tu lista de arreglos.
Qué se escapa con más frecuencia tras pulsar Rechazar
| Origen | Cómo aparece en Network | Causa habitual |
|---|---|---|
| YouTube o Vimeo insertado | youtube.com, ytimg.com, googlevideo.com al cargar la página | iframe normal en el contenido o en un bloque del tema |
| Google Fonts | fonts.googleapis.com y fonts.gstatic.com | El tema o un plugin carga las fuentes desde Google en vez de archivos locales |
| Widget de chat | Script del proveedor y websocket en cada página | Código pegado en el pie o en los ajustes del tema |
| Mapas | maps.googleapis.com, teselas del mapa | Buscador de tiendas o mapa en la página de contacto |
| Píxeles fijos en el tema | connect.facebook.net, analytics.tiktok.com, etiquetas de Google Ads | Código en los campos de cabecera, fuera del sistema de consentimiento |
| Etiquetas del gestor de etiquetas | Se disparan en la vista previa de GTM con consentimiento denegado | Etiquetas sin ajustes de consentimiento o activadores en todas las páginas |
Google describe el modo de privacidad mejorada de YouTube (youtube-nocookie.com) como que las reproducciones insertadas no influyen en la personalización del espectador en YouTube. No dice que el reproductor no envíe nada a Google, así que cambiar el dominio no basta.
Las fuentes tienen sentencia. El tribunal regional de Múnich (LG München I, 3 O 17493/20, 20 de enero de 2022) consideró que pasar la IP dinámica de un visitante a Google mediante Google Fonts sin consentimiento vulneraba sus derechos, ordenó cesar y concedió 100 euros de indemnización. El tribunal razonó que Google Fonts se puede usar sin que el navegador se conecte a un servidor de Google.
Modo de consentimiento v2 de Google: qué siguen enviando el básico y el avanzado
Si ves peticiones a Google Analytics tras Rechazar, comprueba primero qué modo usas. La descripción del modo de consentimiento distingue dos:
- Básico: las etiquetas de Google quedan bloqueadas hasta que el visitante interactúa con el banner. Según Google, antes del consentimiento no se envía nada, ni siquiera el estado por defecto.
- Avanzado: las etiquetas cargan enseguida con denegación por defecto. Mientras no hay consentimiento, envían el estado y mediciones sin cookies. Con
analytics_storagedenegado, Google Analytics no lee ni escribe sus cookies, pero las mediciones siguen llegando a dominios de Analytics “para medición básica y modelado”.
El modo avanzado genera peticiones a Google tras Rechazar a propósito. Si eso vale para tu web es justo la pregunta del artículo 22.2 de la LSSI, que decides con tu asesor y no con la etiqueta. El manual de implementación de Google señala dos errores que provocan fugas reales en ambos modos: el comando con el estado por defecto debe ejecutarse antes de config y event, y un banner que carga de forma asíncrona necesita wait_for_update.
Shopify, WooCommerce y headless: dónde el código esquiva el banner
Según la documentación de Shopify sobre píxeles web, las extensiones de píxel de aplicaciones respetan la Customer Privacy API y en regiones que exigen consentimiento solo se ejecutan después de obtenerlo. El código del tema no tiene esa protección. Para él está la Customer Privacy API, con analyticsProcessingAllowed(), marketingAllowed() y el evento visitorConsentCollected. El estado por defecto depende de los ajustes de privacidad de la tienda: en regiones sin exigencia de consentimiento todo está permitido, así que un mercado mal configurado parece un banner roto.
En WooCommerce, WordPress y headless no hay entorno aislado de plataforma. En un hilo de r/woocommerce de octubre de 2026 sobre qué plugin de consentimiento elegir, una respuesta señaló los dos huecos que se pasan por alto con GTM:
Consent Mode solo habla con las etiquetas de Google. Tu píxel de Meta no lee esas señales. […] No todos los píxeles viven en GTM. Los plugins de WooCommerce (Meta for WooCommerce, Google for WooCommerce y similares) suelen meter su propio píxel directamente en la página. La vista previa de GTM no los muestra en absoluto.
(u/Bignose_boy, r/woocommerce, 12 de octubre de 2026, traducción propia)
Si tras Aceptar ves dos peticiones a fbevents.js, el píxel está cargado dos veces, por GTM y por un plugin. Revisa los campos de código de cabecera y pie, los plugins que imprimen sus propias etiquetas y el contenido insertado en las entradas. Nuestra guía de Google Analytics 4 explica cómo conectar las etiquetas de Google al consentimiento, y el artículo sobre scripts de terceros muestra cómo ver qué carga cada script.
Cómo cerrar cada fuga
- Vídeos y mapas: sustituye el iframe por un marcador que crea el iframe solo tras un clic o tras el consentimiento. Sirve la miniatura desde tu servidor, o será otra petición a terceros.
- Fuentes: descarga los archivos, sírvelos desde tu dominio con
@font-facey elimina cualquier enlace a fonts.googleapis.com. - Chat: muestra un botón local “Escríbenos” y carga el script del proveedor tras el clic o el consentimiento.
- Píxeles fijos: muévelos al gestor de etiquetas o al sistema de píxeles de la plataforma, para que se aplique la comprobación del consentimiento.
- Gestor de etiquetas: define requisitos de consentimiento en cada etiqueta y prueba en la vista previa con consentimiento denegado.
Después repite la prueba y vuelve a rellenar la tabla. Guárdala con la fecha: cuando cambies de tema, añadas un plugin o toques GTM, la repites y comparas columna por columna.
Nuestra auditoría de preparación UE para WooCommerce incluye esta prueba en cada plantilla, y el chequeo gratuito de sitio muestra las peticiones a terceros de una dirección pública.
