¿Por qué vuelve una cookie de seguimiento tras rechazarla?

Todos los artículos

Casi siempre porque el script que la creó sigue en marcha. Borrar una cookie no detiene el código que la escribió: si ese código no sabe que el consentimiento está denegado, vuelve a escribirla en su siguiente envío. Las otras causas son un borrado dirigido al dominio o la ruta equivocados y una cookie que pone tu servidor.

¿Por qué reaparece una cookie borrada después de un rechazo?

Una cookie es un archivo que guarda el navegador. La etiqueta que la creó es código que se ejecuta en la página, y sigue ejecutándose cuando el banner se cierra. Borras el archivo y el código sigue ahí, listo para volver a escribirlo la próxima vez que envíe algo.

Lo reprodujimos con el gtag.js real de Google en un dominio de prueba en noviembre de 2026. Con la analítica aún concedida, borramos _ga y _ga_<id> correctamente. Las dos desaparecieron. El siguiente evento que envió la etiqueta volvió a escribir la cookie de sesión, _ga_<id>, al momento. En una web de un cliente con la que trabajamos ese mismo mes, una cookie de analítica volvió cuando la página quedó oculta y no con un evento. Los equipos suelen interpretarlo como un fallo de la herramienta de consentimiento. Lo que falla es el orden de las operaciones.

La solución es avisar primero a la etiqueta. En la misma prueba, enviar gtag('consent', 'update', { analytics_storage: 'denied' }) y borrar después las cookies hizo que no volvieran ni con otro evento ni con una página oculta simulada. Una etiqueta que sabe que el consentimiento está denegado deja de escribir; una que no lo sabe deshará tu borrado.

¿Por qué parece que borrar la cookie no sirve de nada?

Porque el borrado tiene que coincidir con la cookie a la que apunta. Un navegador solo elimina una cookie cuando el nombre, el dominio y la ruta del borrado coinciden con los que se usaron al crearla, como explica la referencia de MDN sobre la cabecera Set-Cookie. Las etiquetas de Google ponen las suyas en el nivel de dominio más alto posible, así que en shop.example.com la cookie _ga vive en .example.com.

En nuestra prueba, un borrado escrito como document.cookie = '_ga=; Max-Age=0; path=/', sin dominio, no eliminó nada. El script se ejecutó sin errores y la cookie siguió ahí. Añade domain=.example.com y desaparece. Con la ruta pasa lo mismo: un borrado en / no alcanza una cookie creada en una ruta distinta de /.

¿Y las cookies que pone el servidor?

Ningún script de la página puede leer ni borrar una cookie marcada como HttpOnly. Las configuraciones de etiquetado del lado del servidor suelen usar una, por ejemplo la cookie FPID que puede emitir un contenedor de servidor. Solo el servidor puede hacerla caducar, así que el servidor tiene que saber del rechazo y actuar en la siguiente petición. Si usas un contenedor de servidor, comprueba que su cliente lee el estado del consentimiento y deja de emitir la cookie cuando está denegado. Cómo pasar la señal de consentimiento a un contenedor de servidor cubre esa parte.

¿De verdad ha vuelto la cookie o nunca se fue?

Compruébalo antes de arreglarlo. Algunas cookies tienen que quedarse: tu registro de consentimiento y las estrictamente necesarias, como una cookie de sesión o de carrito. Las cookies del dominio de otra empresa no las puede eliminar tu web en ningún caso. Después abre el panel de almacenamiento del navegador y mira la columna de dominio. Una cookie en el dominio principal puede pertenecer a otra web tuya en el mismo dominio, y quien decide es el banner de esa web. Una cookie con un valor nuevo se ha vuelto a escribir. Una con el valor antiguo nunca se borró. Y si apareció antes de que el visitante eligiera nada, la etiqueta se ejecutó antes de fijar el valor por defecto denegado: es un problema de orden de carga, no de borrado. Nuestro artículo sobre cómo comprobar si una etiqueta pone cookies de verdad explica cómo leer esos paneles.

¿Cómo evitas que una cookie vuelva tras un rechazo?

1. Envía primero la señal de denegación

   Avisa a cada herramienta en el formato que escucha antes de tocar el almacenamiento: una actualización de consentimiento para las etiquetas de Google y la llamada equivalente para cada proveedor. Una etiqueta que sabe que el consentimiento está denegado deja de escribir.

2. Borra en todos los niveles de dominio

   Borra cada cookie en el host actual y en cada dominio superior hasta el registrable, con path=/. Un borrado sin dominio no alcanza, sin avisar, las cookies del dominio principal.

3. Retén las etiquetas que aún no se han ejecutado

   Asegúrate de que nada pendiente de cargar pueda arrancar tras el rechazo y escribir la cookie de nuevo. Eso lo hace el bloqueo de etiquetas, no el borrado.

4. Haz caducar en el servidor las cookies del servidor

   Para cualquier cookie HttpOnly, haz que el servidor lea el estado del consentimiento y la haga caducar en la siguiente petición. Ningún script de la página puede hacerlo.

5. Prueba con una página oculta y una recarga

   Acepta, luego rechaza, después envía un evento, cambia de pestaña y recarga. Mira el panel de cookies después de cada paso. Un rechazo que solo aguanta hasta el siguiente envío no está funcionando.

Para el orden completo que debe seguir una retirada, incluido el reinicio de identidad que necesitan la mayoría de las librerías, mira qué pasa cuando alguien retira el consentimiento de cookies.

Cómo lo gestiona Velo

Cuando un visitante rechaza una categoría que había permitido, Velo envía la señal de denegación a cada proveedor que tiene configurado y después borra las cookies propias conocidas y las claves de almacenamiento de esa categoría en el host actual y en cada dominio superior hasta el registrable, con path=/. No puede alcanzar las cookies HttpOnly ni las de otra ruta, y no toca su propio registro de consentimiento, porque ese registro es lo que demuestra que el rechazo ocurrió.