Cumplimiento y Legal

Consentimiento de cookies para PrestaShop: lo que exige realmente la ley

David Miller Publicado: 12 nov 2025 Actualizado: 13 ago 2026 Cumplimiento y Legal

139 vistas 18 min de lectura

Las referencias de aplicación normativa (CNIL, TDDDG, Garante) describen las prácticas de aplicación de la normativa, que pueden cambiar con el tiempo; esto es orientación técnica, no asesoramiento legal, confirma los detalles de tus mercados con un asesor cualificado.

Casi todas las tiendas PrestaShop tienen un banner de cookies. Casi ninguno cumple, y el motivo es técnico, no jurídico. El banner aparece discretamente en una esquina mientras Google Analytics, Facebook Pixel y media docena de scripts más ya se han ejecutado al cargar la página, han instalado sus cookies y han enviado datos a sus servidores. El cliente hace clic en "Aceptar" o "Rechazar"; no cambia nada, porque el seguimiento ocurrió antes de que pudiera ver la opción. Ese único error (disparar cookies antes del consentimiento) es la infracción de cookies más habitual en tiendas PrestaShop, y también la que convierte un banner de herramienta de cumplimiento en puro teatro legal.

Esta guía trata específicamente sobre el consentimiento: cómo debe ser un consentimiento válido, por qué el orden de las operaciones (bloquear primero, ejecutar después) lo es todo, y cómo funciona eso en la práctica dentro de la arquitectura de hooks y módulos de PrestaShop. Para una visión más amplia, derechos de los interesados, tu política de privacidad, el registro del RGPD, qué datos puedes conservar, consulta GDPR and cookie compliance for PrestaShop y la guía general GDPR for online stores. Aquí nos centramos en el banner y en los scripts que hay detrás.

Dos leyes, una regla que tienes que cumplir

Portátil con una galleta real sobre el trackpad y un mazo de juez de madera al lado — El consentimiento de cookies está donde la tecnología se cruza con la ley: lo que tu tienda puede rastrear lo decide la normativa, no la preferencia.

Las cookies se sitúan en la intersección de dos normas de la UE, y conviene saber qué regula cada una, porque apuntan en direcciones ligeramente distintas.

Ley	Qué regula	Qué exige para las cookies
Directiva ePrivacy ("Directiva de cookies")	Almacenar o leer información en el dispositivo de un usuario, cualquier cookie, píxel, entrada de localStorage o huella digital	Consentimiento previo para todo lo que no sea estrictamente necesario, independientemente de si trata datos personales
RGPD	El tratamiento de datos personales una vez recogidos	Una base jurídica válida (para seguimiento/marketing, esa base es el consentimiento) y el estándar de calidad que debe cumplir ese consentimiento

El efecto combinado es fácil de formular y fácil de aplicar mal: debes obtener un consentimiento explícito e informado antes de colocar o leer cualquier cookie no esencial. Fíjate en la palabra antes. ePrivacy se ocupa del acto de escribir en el dispositivo, así que el consentimiento tiene que llegar primero. No "el banner está visible mientras el script se ejecuta", sino que el script de verdad no se ejecuta hasta que el usuario acepta.

Qué cuenta como "estrictamente necesario" en una tienda PrestaShop

Una lista breve y defendible de cookies que puedes establecer sin pedir permiso, porque la tienda no puede funcionar sin ellas y el cliente ha solicitado esa función, por ejemplo, al añadir algo a su carrito:

La cookie de sesión de PrestaShop (PrestaShop-xxxxxxxx, la sesión de la tienda pública), mantiene vivos entre páginas el carrito, la sesión iniciada y el token CSRF. Sin ella no hay tienda.
Autenticación del cliente. Recordar que un cliente que ha iniciado sesión sigue conectado.
Tokens de seguridad, protección CSRF en formularios y proceso de pago, señales contra fraude/bots.
La propia cookie de consentimiento, puedes recordar la elección que acaba de hacer el usuario.
Balanceo de carga / enrutamiento, cookies de sesión persistente que envían al usuario al servidor correcto.

Todo lo que queda más allá de esa línea, analítica, píxeles publicitarios, pruebas A/B, contenidos sociales incrustados, reproductores de vídeo que dejan cookies de seguimiento, necesita consentimiento previo. Una prueba útil: si la cookie existe para ayudarte a ti (medir, hacer retargeting, optimizar) en lugar de entregar la página que el cliente ha solicitado, no es esencial.

Cómo debe ser realmente un consentimiento válido

"Han hecho clic en algo" no es consentimiento. El RGPD fija un estándar de calidad, y los reguladores, en especial la CNIL francesa y las autoridades alemanas de protección de datos, ya lo interpretan de forma estricta. Un consentimiento válido es:

Libremente dado. Una elección real, sin penalización por rechazar. Un muro de cookies, "acepta todo o no puedes usar el sitio", no supera este requisito en la mayor parte de la UE, porque el consentimiento no es libre si la única alternativa es perder el acceso.
Específico y granular. El consentimiento para analítica es independiente del consentimiento para marketing. Un único botón genérico de "aceptar cookies" que agrupa todo es demasiado amplio; los conmutadores por categoría (necesarias / analítica / marketing / preferencias) son el estándar aceptado.
Informado. El usuario entiende qué está aceptando. Eso no significa meter una política de 10.000 palabras en el banner. Basta con un resumen claro y un enlace a la lista completa de cookies.
Inequívoco y afirmativo. Una acción explícita. Hacer clic en "Aceptar." Seguir navegando no es consentimiento. Hacer scroll no es consentimiento. Las casillas premarcadas están expresamente prohibidas.
Revocable con la misma facilidad con que se otorgó. Si un clic estableció el consentimiento, un clic (desde un enlace persistente de "Configuración de cookies" en el pie de página) debe poder revocarlo.

¿Qué significa esto para el diseño de tu banner? "Rechazar todo" tiene que ser tan visible y requerir un solo clic igual que "Aceptar todo", en la primera capa, no escondido dos clics más abajo bajo "Gestionar preferencias." Un banner donde decir no es más difícil que decir sí es exactamente el patrón oscuro que está atrayendo multas, y para un regulador (o un cliente molesto) es trivial detectarlo.

El error que rompe el 90% de los banners de PrestaShop: ejecutar antes del consentimiento

Aquí es donde importan los detalles de PrestaShop, porque el fallo casi siempre es arquitectónico. La mayoría de las tiendas añaden seguimiento insertando un fragmento de Google Analytics, Pixel o Tag Manager en un módulo que se engancha a displayHeader (o pegándolo directamente en el header.tpl del tema, o usando un módulo de HTML personalizado de "edición en vivo"/inyección en cabecera, o el módulo ps_googleanalytics). Todos esos métodos inyectan el script en cada página mientras la página se renderiza, justo cuando se escribe la cookie, mucho antes de que el visitante lea el banner, y ni hablar de responderlo.

Mientras tanto, el banner de cookies es solo JavaScript de front-end que pinta una caja. Si ambos no están conectados, el banner es cosmético y no cumples, por bonito que sea. Predominan dos modos de fallo:

Ejecución al cargar. Los scripts se ejecutan inmediatamente en hookHeader; el banner aparece después. Las cookies ya están instaladas. Hacer clic en "Aceptar" o "Rechazar" no cambia nada de lo que ya ha pasado.
El rechazo se ignora. El usuario hace clic en "Rechazar todo", pero el script de analítica, registrado de forma independiente al banner, vuelve a ejecutarse en la página siguiente. Los dos sistemas nunca estuvieron conectados.

La solución es de orden de operaciones, no legal. Los scripts no esenciales deben estar bloqueados por defecto e inyectarse solo después de que se haya consentido la categoría correspondiente. En la práctica, eso significa una de tres arquitecturas: (1) la propia herramienta de consentimiento controla la inyección de scripts, reteniendo las etiquetas hasta que el usuario acepta; (2) canalizas todo a través de Google Tag Manager y condicionas cada etiqueta a un activador de consentimiento; o (3) canalizas a través de Google Tag Manager con Google Consent Mode v2, pero solo como capa de apoyo, no como vía de cumplimiento independiente. Consent Mode solo ayuda si su estado de consentimiento predeterminado está configurado como denied y no se produce ningún almacenamiento ni seguimiento no esencial antes de que el visitante acepte; los pings "restringidos, sin cookies" que Google envía antes del consentimiento pueden seguir siendo jurídicamente sensibles y deben evaluarse y configurarse con cuidado, en lugar de asumirse como conformes. Por sí solo, no satisface el bloqueo previo que exige ePrivacy. Puedes comprobar en qué grupo está tu tienda sin ninguna herramienta especial: abre las herramientas de desarrollo del navegador, ve al panel Application → Cookies en una visita nueva antes de hacer clic en nada y busca _ga, _fbp y similares. Si están ahí, tu banner es decorativo.

Cómo se ve "bloquear primero" en el marcado

La técnica concreta detrás de una capa de consentimiento que bloquea de verdad es sencilla: un script que debe esperar no se entrega como un <script src> normal. Se entrega con su tipo neutralizado para que el navegador no lo ejecute, y la capa de consentimiento reescribe ese tipo a text/javascript solo cuando se acepta la categoría correspondiente. Verlo una vez desmitifica toda la afirmación de "bloquear antes del consentimiento":

<!-- BLOCKED until consent: the browser parses but does NOT run this. -->
<script type="text/plain" data-cookiecategory="analytics"
        src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>

<!-- When the visitor accepts "analytics", the consent layer flips the type
     so the browser then executes it – never before. -->

Si un script ya aparece como type="text/javascript" activo (o no tiene ningún type) en el código fuente de tu página, no está bloqueado, se ejecuta al cargar, con banner o sin banner. Ese atributo es la línea divisoria práctica entre una capa de consentimiento que funciona y un banner pintado encima de scripts que ya se han ejecutado. ¿Y qué importa? Cuando evalúes cualquier módulo de cookies o configuración de GTM, ver el código fuente y comprobar si las etiquetas de seguimiento están neutralizadas (text/plain) te dice en cinco segundos si el bloqueo previo es real o cosmético.

Qué te ofrece PrestaShop de forma nativa, y dónde se queda corto

PrestaShop incluye cierta estructura legal básica, y ayuda saber exactamente hasta dónde llega antes de recurrir a un módulo.

Opción nativa	Qué hace	La carencia
ps_legalcompliance (Legal Compliance, 1.7+)	Añade una barra estática de información sobre cookies y enlaza tus páginas legales CMS (condiciones, privacidad, cookies) en los lugares adecuados	Informa; no bloquea scripts ni recoge consentimiento granular y revocable. Por sí solo no es un gestor de consentimiento.
PrestaShop Official GDPR module (psgdpr)	Gestiona solicitudes de derechos de los interesados, exportación, acceso, eliminación, y un marco de casillas de consentimiento para formularios	Está pensado para derechos sobre datos, no para controlar cookies/scripts. No va a retener tu Pixel hasta que un visitante acepte.
Una página CMS de política de "Cookies"	Un lugar donde publicar tu política de cookies. PrestaShop no siempre trae una por defecto en todas las versiones y perfiles de instalación, así que si tu instalación (o un módulo) no la ha creado ya, deberías añadir una página CMS y enlazarla tú mismo.	La página de política es necesaria, pero publicarla no controla qué scripts se ejecutan.

El resumen honesto: las herramientas nativas de PrestaShop cubren bien la información y los derechos sobre datos, pero ninguna hace lo único de lo que trata este artículo, impedir que se escriban cookies no esenciales hasta que el visitante diga que sí. Para eso hace falta una capa de consentimiento que controle realmente la inyección de scripts.

Implementar un consentimiento real en PrestaShop

La razón de existir de un módulo dedicado es precisamente la carencia anterior: necesitas algo que intercepte los scripts de seguimiento y los libere por categoría, desde el panel de administración, sin editar archivos del tema ni montar activadores de etiquetas a mano. Nuestro Lightweight Cookie Banner está construido para ese trabajo concreto en PrestaShop:

Bloqueo por defecto, liberación por categoría. Los scripts de analítica y marketing quedan retenidos hasta que el visitante consiente esa categoría, necesarias / analítica / marketing / preferencias se activan de forma independiente. Este es el bloqueo previo que la ley exige de verdad, no un banner pintado encima de scripts que ya se ejecutaron.
Rechazar tan fácil como aceptar. "Rechazar todo" está en la primera capa con la misma prominencia que "Aceptar todo", lo que te mantiene lejos de las sanciones por patrones oscuros que están alcanzando a otras tiendas.
Un registro de consentimiento. Guarda cuándo consintió cada visitante y a qué, la prueba que querrás tener si alguna autoridad de protección de datos pregunta cómo obtuviste el consentimiento.
Nuevo consentimiento cuando cambias algo. Añade una nueva categoría de seguimiento o revisa tu política de cookies, y volverá a preguntar en lugar de apoyarse silenciosamente en un consentimiento antiguo.
Realmente ligero. Carga sin lastrar tu página, para que la capa de cumplimiento no te cueste la puntuación PageSpeed que llevas cuidando.

¿Cuál es el beneficio práctico? Lo configuras desde el panel de administración en lugar de pagar a un desarrollador para insertar lógica de consentimiento en tu tema, y el banner deja de ser un riesgo disfrazado de protección. Esto es habilitación técnica, te da el bloqueo previo y el registro de consentimiento que la ley espera, pero por sí solo no convierte tu tienda en "conforme"; tu política de cookies, tus decisiones de categorización y tus declaraciones sobre encargados del tratamiento siguen siendo responsabilidad tuya como responsable del tratamiento. Si tu tienda también depende del ecosistema de Google, combínalo con Consent Mode v2 para que GA4 siga modelando conversiones de los visitantes que rechazan, Consent Mode estima estadísticamente esa parte perdida, no recupera sus datos reales, y aun así respetas el "no" bloqueando primero.

Diferencias por país: la misma regla, aplicación desigual

La regla del consentimiento previo es común en toda la UE, pero el apetito por hacerla cumplir no lo es. Algunos ejemplos que cambian cómo configurarías el banner:

Francia (CNIL). La más estricta en diseño de banners: "Rechazar todo" debe estar en la primera capa, al mismo nivel que "Aceptar todo." La CNIL ha impuesto repetidas multas importantes específicamente por botones de rechazo difíciles de encontrar.
Alemania. La analítica requiere consentimiento, punto, y la TDDDG (sucesora de la TTDSG) incorpora de forma expresa a la ley nacional la regla de consentimiento previo de ePrivacy. Las autoridades alemanas no suelen aceptar argumentos de "interés legítimo" para el seguimiento.
Italia (Garante). Exige un banner en la primera visita que ofrezca aceptar / rechazar / gestionar, además de una política de cookies enlazada; ha rechazado expresamente el scroll como consentimiento.
España (AEPD) sigue el estándar de la UE y publica guías detalladas sobre banners, históricamente con una aplicación menos intensa que Francia o Alemania.
Reino Unido (ICO). Tras el Brexit, el Reino Unido mantuvo las reglas como UK GDPR más PECR; en lo sustancial, la misma obligación de consentimiento previo, aplicada por la ICO.

Para el mapa legal transfronterizo más amplio, más allá de las cookies, consulta e-commerce law in the EU.

Acepta la brecha de analítica, y planifícala

Una consecuencia incómoda de hacer bien el consentimiento: tu analítica se vuelve menos completa. Cuando una parte significativa de visitantes rechaza el seguimiento, se suelen citar cifras en torno al 30–40%, pero tómalo como una orientación y mide tu propia tasa de aceptación a partir del registro de consentimiento, simplemente pierdes visibilidad sobre ese segmento. No es un fallo que haya que esquivar con ingeniería; es el coste del cumplimiento, y fingir lo contrario es como las tiendas acaban de nuevo en la trampa de "ejecutar antes del consentimiento." Mitigaciones razonables: apóyate en Consent Mode v2 para conversiones modeladas (estimadas, no recuperadas), considera la medición del lado del servidor para los datos que puedes recoger sin cookies de dispositivo, y desplaza tu análisis desde recorridos de usuarios individuales hacia tendencias agregadas que sobreviven con una muestra más pequeña.

Preguntas frecuentes

Abre tu tienda en una ventana de incógnito nueva, abre DevTools → Application → Cookies y mira antes de tocar el banner. Si _ga, _fbp o _gcl_au ya están ahí, los scripts se ejecutaron al cargar y tu banner es cosmético. Luego haz clic en "Rechazar todo" y recarga: si vuelven a aparecer, el rechazo no está conectado a los scripts. Una segunda pista está en el código fuente de la página, las etiquetas bloqueadas llevan type="text/plain"; las activas no.

¿Basta con "Aceptar todo" y un enlace a "Gestionar preferencias", o necesito un "Rechazar todo" visible?

Necesitas un "Rechazar todo" en la primera capa, con la misma prominencia y el mismo coste de clic que "Aceptar todo." Esconder el rechazo detrás de "Gestionar preferencias" es el patrón oscuro concreto que la CNIL y otros reguladores han multado repetidamente. La misma prominencia en la primera pantalla es el valor seguro en los mercados estrictos.

No. Consent Mode indica a las etiquetas de Google si el visitante ha consentido y modela las conversiones que pierdes de quienes rechazan, las estima, no recupera datos reales. Es una capa de apoyo, no el bloqueo previo que exige ePrivacy. Si las cookies no esenciales siguen escribiéndose antes de que el visitante acepte, Consent Mode no te salva; primero necesitas una capa que retenga de verdad los scripts.

¿Puedo mantener el módulo ps_googleanalytics de PrestaShop y seguir cumpliendo?

Solo si algo lo controla. Por sí solo, ps_googleanalytics inyecta su etiqueta al cargar la página y establece la cookie de GA antes del consentimiento. O lo canalizas a través de una capa de consentimiento / GTM que lo bloquee hasta que se acepte "analytics", o lo sustituyes. El problema no es el módulo; es ejecutarlo sin condiciones.

¿Están permitidos los muros de cookies ("acepta o vete")?

En la mayor parte de la UE, no. El consentimiento no es "libremente dado" si la única alternativa es perder el acceso al sitio. Algunas jurisdicciones y ciertos modelos con alternativa de pago se debaten, pero para una tienda PrestaShop general un muro de cookies es el punto de partida equivocado. Ofrece una vía real de rechazo.

El mínimo práctico para mantenerte fuera de problemas

Si quieres cumplir sin sobredimensionarlo, en este orden:

Instala una capa de consentimiento que bloquee scripts, no un banner que solo informe. (Lightweight Cookie Banner si quieres gestionarlo desde el panel de administración.)
Configúrala para retener analítica y marketing hasta que se acepte la categoría correspondiente.
Pon "Rechazar todo" en la primera capa, al mismo nivel que "Aceptar todo."
Publica una política de cookies clara (crea una página CMS para ella si tu instalación aún no tiene una) que enumere cada cookie, su finalidad y su duración.
Verifícalo con las herramientas de desarrollo: visita nueva, comprueba Application → Cookies antes de hacer clic, no debería existir ninguna _ga / _fbp. Luego haz clic en "Rechazar todo" y confirma que siguen sin aparecer.
Conserva los registros de consentimiento para poder demostrar cómo y cuándo se obtuvo el consentimiento.

Esto no es el máximo legal absoluto en todas las jurisdicciones, algunas exigen información más profunda, pero cubre los fundamentos y te aleja de las actuaciones sancionadoras que sí ocurren en la práctica. Para textos específicos por mercado, merece la pena dedicar una hora a un abogado familiarizado con tus países objetivo; simplemente no dejes que la búsqueda de documentación perfecta te impida arreglar lo único que de verdad importa hoy: asegurarte de que no se instala ninguna cookie antes de que el visitante haya dicho que sí.