Revisar el banner de cookies: ¿bloquea de verdad los scripts no esenciales? 7 errores frecuentes

Que el botón «Rechazar» funcione no demuestra que el seguimiento se detenga. Una guía práctica para revisar el banner de cookies con Network, Application, Consent Mode y pruebas repetidas.

Usted abre el sitio web en un perfil nuevo del navegador, pulsa «Rechazar» y ve desaparecer el aviso de cookies; desde fuera todo parece correcto, pero revisar el banner de cookies empieza justo entonces: ¿ya se había enviado una solicitud a una plataforma publicitaria antes del clic, contenía la respuesta un intento de asignar un identificador que quedó en el almacenamiento del navegador y recibieron las etiquetas el estado de consentimiento correcto después del rechazo? El botón es solo el cuadro de mandos, y la auditoría debe comprobar que los cables estén realmente conectados, porque puede que la CMP aún no haya definido el estado predeterminado cuando el gestor de etiquetas ya esté ejecutando su primera regla.

Ni una inspección visual del banner ni la marca verde de un escáner automático revelan qué ocurrió durante los primeros segundos de carga; tampoco indican qué script provocó la acción, qué estado de consentimiento tenía disponible en ese momento ni si el estado final visible refleja toda la secuencia anterior de acontecimientos. Por eso comparamos en una misma línea temporal el comportamiento del sitio web antes de elegir, después de rechazar todas las categorías no esenciales, después de aceptarlas y después de retirar el consentimiento, y en cada estado examinamos las solicitudes de red, las cabeceras de respuesta, las cookies, localStorage y otros mecanismos de almacenamiento, la secuencia de las señales de consentimiento y el iniciador concreto de cada acción. Solo esta comparación distingue una configuración correcta de un banner que simplemente se cierra.

Este es un artículo técnico, no un dictamen jurídico individual: explica cómo recopilar hechos verificables sin extraer conclusiones que las pruebas no permiten sostener. Si el sitio web utiliza Google Tag Manager, Google Analytics 4, Google Ads, Meta Pixel, vídeos insertados, un chat u otras herramientas de terceros, la lista de cookies que aparece en una sola pantalla será apenas una parte del conjunto; la pregunta decisiva, por tanto, no es «¿está instalado el banner?», sino «¿qué hace el sitio web en cada momento en que el usuario elige?».

Qué implica revisar el banner de cookies — y qué no demuestra

La auditoría comprueba la cadena técnica del consentimiento desde la primera solicitud de la página hasta el cambio de estado que sigue a la elección del usuario, pero no puede evaluarse únicamente por el estado final, porque la secuencia inicial de carga puede haber iniciado ya una acción que el posterior cierre del banner no deshace. El alcance incluye el orden de carga de los scripts, las conexiones de red, las cookies y otros sistemas de almacenamiento, las señales de la CMP o plataforma de gestión del consentimiento, la configuración de Google Consent Mode, el funcionamiento de las categorías y la posibilidad de modificar después la elección; el resultado es un conjunto de pruebas sobre la capa de cookies y seguimiento, no un certificado de que todo el tratamiento de datos personales de la organización sea jurídicamente impecable.

Desde el punto de vista jurídico hay que separar dos niveles relacionados: en España, el artículo 22.2 de la Ley de Servicios de la Sociedad de la Información y de Comercio Electrónico (LSSI-CE) aplica el marco del artículo 5, apartado 3, de la Directiva ePrivacy al almacenamiento de información en el equipo terminal del usuario y al acceso a información ya almacenada en él, y este alcance técnico no se limita a archivos cuyo nombre contenga la palabra «cookie». El RGPD entra en juego cuando se tratan datos personales y también determina la calidad del consentimiento válido y los principios de su retirada, de modo que comprobar técnicamente uno de esos ámbitos no sustituye la evaluación jurídica del otro. En el informe de auditoría nombramos ambos niveles por separado para que un hecho técnico observado no se presente como una conclusión jurídica más amplia.

La Agencia Española de Protección de Datos explica que las cookies no exentas no pueden utilizarse antes de obtener el consentimiento y que la opción de rechazar debe ser tan fácil y visible como la de aceptar; aun así, el mero nombre de una categoría como «necesarias» no demuestra nada por sí solo. La excepción de lo estrictamente necesario debe interpretarse de forma restrictiva: la acción concreta ha de ser indispensable para prestar un servicio solicitado expresamente por el usuario o para efectuar la transmisión de una comunicación, no solo conveniente para la analítica, el marketing o las necesidades internas del titular del sitio web. El auditor debe vincular esa acción con la función que la hace necesaria y comprobar al mismo tiempo que la misma categoría no oculte otra finalidad completamente distinta que la función solicitada por el usuario no justifique.

La expresión de búsqueda «auditoría RGPD de un sitio web» designa en este servicio únicamente el ámbito de las cookies, el seguimiento y la gestión del consentimiento, pues quedan fuera las bases jurídicas de otros tratamientos, las solicitudes de los interesados, los contratos y la gobernanza interna. Nuestro servicio de auditoría de cookies y seguimiento aporta los hechos técnicos con los que un abogado o un profesional de la protección de datos puede evaluar con fundamento esta parte concreta del sitio web, pero el cumplimiento del RGPD no es un interruptor que un escáner técnico pueda accionar para toda una organización. Esta delimitación no elude responsabilidades: deja claro qué demuestra el informe y qué cuestiones deben resolverse fuera de la auditoría técnica.

Cómo obtiene la auditoría pruebas, no solo el resultado de un escáner

Una buena prueba comienza en un perfil limpio del navegador, sin consentimientos guardados, cookies del sitio web ni solicitudes generadas por extensiones; antes de hacer clic se activa el registro de Network, se revisa la sección Application y se documenta el estado inicial. A continuación se repite la misma secuencia de acciones después del rechazo, de la aceptación y de la retirada, iniciando cada escenario desde un estado documentado y conservando el registro completo, porque, de lo contrario, la elección de ayer puede parecer un error del banner de hoy o, al contrario, ocultar el fallo real.

Una entrada de Network demuestra que el navegador intentó comunicarse con una dirección concreta y permite examinar el iniciador, el estado, las cabeceras de la solicitud y de la respuesta y la información enviada, pero todavía no prueba que se haya almacenado una cookie. La cabecera de respuesta Set-Cookie muestra que el servidor intentó crearla, aunque el navegador puede bloquear ese intento; a su vez, JavaScript puede escribir en document.cookie o en localStorage sin esa cabecera. Por eso el resultado real debe comprobarse en Application y ninguna de estas señales puede sustituir a las demás. Una solicitud visible a un dominio de analítica documenta un intento de transferencia de datos, no que se haya creado correctamente una cookie analítica ni que el servidor haya recibido un conjunto concreto de datos personales.

Para cada hallazgo anotamos la URL y el recorrido de usuario probados, la hora, el contexto del dispositivo y del navegador, el estado de consentimiento seleccionado, el iniciador de la solicitud, el destino, el resultado del envío y los cambios en el almacenamiento, de modo que tras la corrección sea posible repetir exactamente la misma prueba. El escaneo automático ofrece un inventario inicial amplio, pero no recorre todos los menús, pasos de compra, áreas de acceso restringido, versiones lingüísticas e integraciones que se abren dinámicamente, ni puede determinar con seguridad la finalidad solo por el nombre de un archivo o dominio; por eso se completa con escenarios manuales y una conversación con los responsables de las herramientas. En ella aclaramos quién implantó cada herramienta, con qué finalidad, en qué contenedor de etiquetas reside y qué señal de consentimiento debe respetar, para relacionar el hallazgo técnico con la configuración prevista. Una prueba sin contexto es solo una captura de pantalla; un contexto sin prueba es solo una promesa.

1. Los scripts no esenciales se ejecutan antes de que el usuario elija

Se produce un error crítico de secuencia cuando el banner de la CMP aparece enseguida, pero la etiqueta de analítica o publicidad ya se ha ejecutado: el usuario todavía está leyendo los botones mientras el navegador se ha comunicado con un tercero o ha guardado un identificador. La explicación de la Agencia Española de Protección de Datos es inequívoca en este punto: las cookies no exentas no pueden utilizarse antes de que el usuario acepte, por lo que la comprobación técnica empieza con la primera carga del documento, no cuando el auditor por fin encuentra y pulsa «Rechazar».

En un entorno de Google Tag Manager, la causa habitual es un orden de eventos incorrecto: el estado de consentimiento predeterminado debe establecerse antes que las etiquetas, mediante el activador «Inicialización del consentimiento: todas las páginas» o cualquier otra solución que garantice el mismo orden, y solo después de la acción del usuario se envía la actualización. Si el valor predeterminado llega tarde, durante un instante la etiqueta puede encontrar un estado indefinido o guardado con anterioridad y ejecutarse; que el banner se cierre deprisa no corrige esta carrera, porque el problema está en el orden de ejecución, no en la animación.

La frase «las cookies se cargan antes del consentimiento» debe desglosarse con mayor precisión durante la auditoría: puede haberse cargado el propio script, efectuado una solicitud de red, enviado una señal sin cookies, intentado crear una cookie mediante Set-Cookie o almacenado realmente un identificador, y cada acción tiene un valor probatorio distinto. En el modo de consentimiento avanzado, algunas etiquetas de Google con el almacenamiento denegado pueden cargarse y enviar señales sin cookies, así que la mera presencia del script no basta para concluir ni que existe una infracción ni que hay cumplimiento.

La corrección empieza con un mapa de herramientas y un único modelo de estados bien definido: qué etiquetas pueden funcionar sin elección, cuáles necesitan una categoría concreta y qué evento cambia el valor predeterminado. Después de modificar la configuración, la prueba se repite en un perfil limpio y conservando el registro de Network, con especial atención a las primeras solicitudes y sus iniciadores; si el fallo solo aparece algunas veces, suele indicar una carrera entre la CMP, el contenedor de etiquetas y el código del sitio web que debe resolverse en el propio orden de carga, no ocultarse con un banner visualmente más rápido.

2. «Rechazar» cambia la interfaz, pero no el flujo de datos

El botón puede cerrar el banner, mostrar la elección en gris e incluso guardar el valor «denied» mientras las etiquetas de terceros siguen funcionando como antes; por eso la prueba de rechazo no pregunta si ha desaparecido un texto, sino que compara dos estados. Registramos las solicitudes y el almacenamiento antes y después de rechazar todas las categorías no esenciales y comprobamos a continuación que las etiquetas correspondientes no reciban un evento que las active, que no aparezcan identificadores nuevos y que las siguientes páginas vistas conserven el rechazo. Una sesión anterior altera esta prueba con facilidad: si ayer se otorgó el consentimiento, hoy el botón «Rechazar» puede cargar primero la página con el estado de ayer y cambiarlo solo después, cuando la primera solicitud ya ha salido. Borrar manualmente las cookies entre pasos también crea una limpieza artificial y no pone a prueba el verdadero mecanismo de retirada; por eso el rechazo inicial y la retirada posterior son escenarios distintos: el primero empieza sin una decisión y el segundo con un consentimiento otorgado de forma consciente, y sus resultados no deben mezclarse en una misma captura de pantalla.

Incluso después del rechazo, el sitio web puede realizar acciones que sean realmente necesarias para una función de seguridad, para el carrito o para otra función solicitada expresamente por el usuario, de modo que afirmar que «cualquier solicitud posterior al rechazo es mala» sería tan impreciso como la marca verde del banner. Hay que averiguar la finalidad, el iniciador y la acción de almacenamiento de cada conexión que permanezca y configurar después la CMP para que el rechazo actualice primero el estado del consentimiento y las etiquetas apliquen las comprobaciones de consentimiento integradas o expresamente definidas. Un botón funcional es el que modifica de forma previsible, en varias páginas, el flujo de datos conectado por debajo. Si el rechazo detiene la etiqueta publicitaria pero mantiene una cookie de sesión propia, ese puede ser el resultado esperado; si una categoría activa otra en silencio, la configuración no es fiable y, tras la corrección, el rechazo debe poder repetirse en varias páginas sin limpiar manualmente el almacenamiento y producir cada vez un estado igual, reproducible y demostrable.

3. Las categorías y la política de cookies no coinciden con el inventario real

Un banner puede estar bien configurado técnicamente y, aun así, inducir a error si las categorías o la política describen otro sitio web, algo habitual después de copiar una plantilla, heredar un contenedor de etiquetas o añadir una herramienta nueva sin actualizar la documentación. La política conserva entonces una cookie que dejó de utilizarse hace tiempo, mientras que no menciona un reproductor de vídeo, un chat o una etiqueta de conversión publicitaria, y el usuario elige a partir de información incompleta. En esta situación, la empresa no puede justificar qué destinatario recibe los datos, con qué finalidad ni cuánto tiempo vive el identificador.

La Agencia Española de Protección de Datos vincula la política de cookies con el inventario real, en el que deben constar la finalidad, el proveedor o destinatario y el plazo de conservación, no solo lo que el catálogo de la CMP haya reconocido automáticamente. Una cookie con un mismo nombre puede tener usos diferentes según la configuración, mientras que un identificador propio y personalizado quizá no tenga descripción alguna en una base de datos pública; por eso la auditoría relaciona el objeto técnico con la finalidad real del titular del sitio web y con la herramienta responsable. La tarea no consiste en copiar la conjetura de un catálogo, sino en comprobar que la configuración, el destinatario y el plazo corresponden a lo que la empresa utiliza realmente y puede explicar.

El inventario no termina en la pestaña Cookies: hay que revisar localStorage, sessionStorage, IndexedDB, los píxeles y las solicitudes al servidor, además de los identificadores utilizados en las URL o en los flujos de formularios cuando intervienen en el seguimiento. Las directrices técnicas del Comité Europeo de Protección de Datos explican que el ámbito de ePrivacy no está ligado a una única tecnología de almacenamiento; por tanto, una política que prometa «no usamos cookies» todavía no responde si el sitio web accede mediante otro método a información del equipo terminal o envía señales de medición. La lista de nombres de cookies es, por ello, el comienzo del inventario, no un registro completo de las tecnologías capaces de almacenar, leer o enviar identificadores.

La solución práctica es mantener un registro maestro único que sirva de fuente para la clasificación de la CMP, la tabla técnica de la política y los escenarios de auditoría, y en el que cada entrada indique el responsable de la herramienta dentro de la empresa, el proveedor, la finalidad, el estado de consentimiento que la activa, el almacenamiento empleado, el destinatario y el plazo. Así, añadir una etiqueta ya no es solo un cambio en el contenedor de Google Tag Manager, sino una modificación controlada que, antes de publicarse, exige actualizar la información facilitada al usuario y los casos de prueba. Ese mismo registro ofrece después un punto de partida para repetir la prueba y indica quién es responsable dentro de la empresa de corregir cada incumplimiento.

4. Una solicitud de Network se confunde con la prueba de una cookie

Ver un dominio de analítica en el panel Network es un hallazgo importante, pero no permite afirmar por sí solo que «se ha creado una cookie»: la entrada demuestra un intento de conexión y muestra qué añadió el navegador a la URL, las cabeceras o el contenido de la solicitud, pero una solicitud fallida, bloqueada o cancelada no equivale a datos recibidos correctamente por el servidor. Para la parte relativa a las cookies hay que comprobar si la cabecera de la solicitud contenía Cookie, si la respuesta incluía Set-Cookie, si el navegador no la bloqueó y si la entrada llegó realmente al almacenamiento. La solicitud puede quedar bloqueada o cancelada antes de que el servidor reciba los datos, y ese límite probatorio debe reflejarse también en la redacción del hallazgo, sin fundir en una misma afirmación el intento de conexión, el resultado del envío y el almacenamiento.

La conclusión contraria tampoco es segura: una solicitud sin cookie puede contener el estado de consentimiento y otros parámetros, y el sitio web puede emplear un identificador de localStorage, un parámetro de URL u otro método técnico; la ausencia de una cookie no convierte automáticamente la conexión en anónima ni significa que no contenga datos. A su vez, Set-Cookie es una instrucción del servidor al navegador, no una garantía de que se haya guardado, pues el navegador puede rechazarla por el dominio, los atributos de seguridad, las restricciones a terceros u otra política; una cookie propia creada por JavaScript puede aparecer sin esa cabecera de respuesta. DevTools también muestra los motivos del bloqueo, así que la presencia de Set-Cookie debe interpretarse junto con la decisión del navegador y el estado real de Application. Si no hay una fila nueva en la pestaña Cookies, no concluimos por ello que la señal no contenga datos, sino que revisamos la URL, las cabeceras, los parámetros y otros sistemas de almacenamiento.

El método más seguro reúne tres vistas en una misma línea temporal —qué provocó la solicitud, qué pidió hacer el servidor y qué quedó almacenado después en ese perfil concreto del navegador—, y el informe de auditoría nombra deliberadamente solo aquello que se ha demostrado. Escribimos «antes de la elección se envió una solicitud al dominio X», «en la respuesta se detectó un intento de crear una cookie» o «en Application permanecía el identificador Y después del rechazo», porque un desarrollador puede repetir esos pasos, un jurista ve los límites del hecho técnico y el resultado se puede comparar objetivamente tras la corrección. No deducimos toda la cadena de tratamiento de datos a partir de una sola captura, pues esta solo puede probar la acción, el estado y el momento concretos en que se tomó.

5. La retirada del consentimiento está oculta o es técnicamente incompleta

El consentimiento no es un clic único del que el sitio web pueda olvidarse: el artículo 7, apartado 3, del RGPD reconoce el derecho a retirarlo en cualquier momento y exige que hacerlo sea tan fácil como darlo, algo que la Agencia Española de Protección de Datos también explica de forma práctica. Si el usuario puede consentir en la primera pantalla de la página de inicio, pero para retirar el consentimiento debe buscar un apartado de la política de privacidad, escribir un correo o borrar los datos desde la configuración del navegador, el mecanismo no está disponible en condiciones equivalentes; una solución habitual es mantener un enlace permanente para gestionar las preferencias en el pie de página. Comprobamos que pueda encontrarse desde cualquier página y también cuando el banner ya no está visible, porque es precisamente entonces cuando el usuario intenta cambiar su decisión anterior.

La prueba técnica parte de un consentimiento otorgado deliberadamente y de etiquetas activadas de verdad; después, el auditor abre la gestión de preferencias, retira las categorías no esenciales y sigue navegando por el sitio web sin crear un comienzo artificial mediante el borrado manual del almacenamiento. Hay que comprobar que la CMP envíe el estado actualizado y que las etiquetas lo reciban, que no se inicien nuevos flujos de datos basados en el consentimiento y qué ocurre con los identificadores guardados localmente, porque así se descubre un botón que guarda la nueva elección pero no la comunica a las etiquetas ya cargadas. Al mismo tiempo registramos la secuencia de eventos del cambio para distinguir una elección guardada correctamente de una situación en la que la etiqueta dependiente recibe la actualización demasiado tarde o no la recibe.

La retirada actúa hacia el futuro y no reescribe por sí misma el pasado ni elimina todos los datos tratados lícitamente con anterioridad; por tanto, debe detener el tratamiento posterior basado en ese consentimiento, mientras que conservar o borrar los datos que el servidor recibió antes puede requerir otra evaluación. En el informe separamos por eso la interrupción de los flujos de datos futuros de la cuestión relativa a la conservación de los datos anteriores, sin prometer que un cambio técnico de preferencias resuelva ambos asuntos. La corrección debe unir la interfaz con la integración: el enlace ha de encontrarse desde cada página, la CMP debe mostrar el estado actual, el cambio debe llegar a cada etiqueta dependiente y la prueba debe repetirse con varias combinaciones de categorías, porque «rechazar todo» puede funcionar mientras que desactivar únicamente el control de marketing no tenga efecto. La eliminación de identificadores del navegador también debe evaluarse según su función, no prometerse como si un clic en la CMP pudiera limpiar automáticamente los sistemas de todos los terceros.

6. Se confunden los modos básico y avanzado de Consent Mode o se prometen datos modelizados

Los modos básico y avanzado de Consent Mode no son dos diseños de un mismo interruptor: en el modo básico, las etiquetas de Google no se cargan antes del consentimiento y, hasta entonces, Google no recibe los datos de medición de esas etiquetas; una vez otorgado, pueden empezar la medición habitual. En el modo avanzado, se cargan con el almacenamiento inicialmente denegado y, mientras no se haya dado el consentimiento, pueden enviar señales sin cookies, de modo que no debe describirse como un estado en el que «no se envía nada» ni presentarse el modo básico como una configuración analítica automáticamente peor. La diferencia está en el comportamiento real de las etiquetas antes de la elección, no en el aspecto del banner ni en el nombre de un ajuste.

La elección debe basarse en la evaluación jurídica y las necesidades analíticas de la empresa, no en la idea de que el nombre de un producto de Google resuelve por sí mismo los requisitos de ePrivacy o del RGPD. La documentación de Google sobre Consent Mode distingue el bloqueo de las etiquetas en el modo básico de las señales sin cookies del modo avanzado, pero en la auditoría comprobamos la configuración real: si los valores predeterminados entran en vigor antes que las etiquetas, qué actualización se envía después del clic y qué solicitudes aparecen de verdad en cada estado. El nombre comercial de un modo no es una conclusión jurídica, por lo que el informe describe el flujo comprobado y la configuración elegida por la empresa en lugar de asignarles una etiqueta automática de cumplimiento.

«Sin cookies» no significa «sin información», así que el nombre de una señal no debe sustituir en el informe la evaluación de su contenido y su finalidad. En Network hay que examinar el destino, los parámetros, el estado de consentimiento y el iniciador, mientras que Google Tag Assistant o las herramientas de depuración de Consent Mode ayudan a comprobar los estados predeterminados y actualizados; estas vistas se complementan, porque la primera revela el flujo de datos del intento concreto y la segunda, la lógica de la configuración. Si ambas discrepan, no se da la razón a la pantalla más atractiva: hay que localizar dónde no llegó a la etiqueta, en el orden previsto, el evento predeterminado o el de actualización.

Los datos modelizados tampoco son una recompensa garantizada por activar el modo avanzado, ya que la disponibilidad de la modelización del comportamiento de Google Analytics 4 depende de las condiciones que Google establece para la propiedad, el volumen y la calidad de los datos, y la función puede no estar disponible o desaparecer si dejan de cumplirse. La modelización no reconstruye las sesiones de usuarios concretos que han rechazado, por lo que en la propuesta prometemos una configuración correcta y una secuencia de señales verificable, no un volumen determinado de datos modelizados que depende del sistema de Google y de que la propiedad correspondiente cumpla sus requisitos. El resultado de la auditoría es, así, una configuración reproducible y una comprobación de las señales, no una promesa sobre un volumen de datos que el proveedor del servicio no controla.

7. La prueba termina en la primera página y el primer día

La página de inicio rara vez abarca todo el inventario de seguimiento: una etiqueta de vídeo puede cargarse solo después de pulsar «Reproducir»; un mapa, únicamente en la página de contacto; una conversión publicitaria, después de enviar un formulario; una herramienta de pago, en el último paso del carrito; y un script de chat o personalización, tras un tiempo determinado. Un auditor que abre una URL, espera unos segundos y cierra el escáner puede redactar un informe técnicamente correcto sobre esa vista y, al mismo tiempo, peligrosamente incompleto sobre el conjunto del sitio web. Cada uno de estos estados debe activarse mediante la acción que realmente lo desencadena, no dando por hecho que el inventario de la página de inicio representa automáticamente todas las plantillas y recorridos de usuario.

Construimos los escenarios a partir de recorridos reales y plantillas del sitio web, cubriendo una página pública, un artículo, un formulario de contacto, el área de cuenta, el proceso de compra, el contenido incrustado y cada versión importante por idioma o región; también hay que revisar el diseño móvil, donde los botones de la CMP pueden solaparse o el enlace de preferencias quedar fuera de alcance aunque todo funcione en el escritorio. Un rastreo automatizado aporta amplitud y un escenario manual abre los estados que un robot sin cuenta, clic ni datos introducidos nunca verá. Las versiones lingüísticas y regionales, igual que el diseño móvil, no son duplicados decorativos cuando en ellas cambia la carga de integraciones o las opciones disponibles para el usuario.

Una auditoría puntual no cubre los cambios posteriores: una etiqueta nueva de marketing, otra plantilla de CMP o un contenedor de Google Tag Manager importado pueden alterar una secuencia que antes era correcta sin producir cambios visibles en el banner; por ello, cada herramienta nueva necesita una prueba antes de publicarse y una comparación posterior. Es una disciplina que conviene prever ya en el contrato de desarrollo del sitio web, como explicamos en el artículo sobre 10 errores al encargar el desarrollo web. Nuestro proceso de auditoría incluye un nuevo escaneo a los 30 y 180 días de la implantación, con los mismos escenarios y campos probatorios, para comprobar si la corrección resiste el ritmo real de publicación y si han aparecido nuevas herramientas o desviaciones de configuración. El primer plazo muestra si la implantación ha soportado el trabajo cotidiano y el segundo descubre cambios posteriores; en cada repetición comparamos la solicitud, el almacenamiento y el estado de consentimiento concretos con el hallazgo inicial, en lugar de limitarnos a la impresión de que «ahora parece estar mejor».

Qué recibe en una auditoría técnica de cookies y seguimiento

El primer resultado es un inventario comprobado de cookies, sistemas de almacenamiento, etiquetas y solicitudes a terceros, en el que cada hallazgo está relacionado con una página, una acción del usuario y un estado de consentimiento; junto a él se indica la prueba y sus límites: una entrada de Network, un intento de Set-Cookie, una cookie realmente presente en Application, una entrada de localStorage o un evento de la CMP. El desarrollador recibe así un error reproducible, no una indicación vaga como «arregle el RGPD», y la persona responsable de la privacidad ve qué hechos todavía requieren una decisión jurídica. Cada hallazgo conserva además el recorrido para repetirlo, de modo que después de la implantación se puedan comprobar exactamente la misma página, la misma elección, la misma solicitud y la misma consecuencia en el almacenamiento.

La segunda parte es la implantación: ordenamos las categorías de la CMP y la secuencia de valores predeterminados y actualizaciones de Google Tag Manager, configuramos las comprobaciones de consentimiento de Google Analytics 4, Google Ads, Meta Pixel y otras herramientas, y preparamos la declaración de cookies y el texto de la política de privacidad. Elegimos el modo básico o avanzado de Consent Mode en función de su evaluación jurídica y sus necesidades analíticas, sin presentar el avanzado como una opción correcta en todos los casos ni prometer datos modelizados cuando la propiedad concreta no cumple las condiciones de Google. Probamos el resultado de la implantación en los mismos estados de consentimiento en los que se registró el hallazgo inicial, para fundamentar el cambio de configuración con pruebas comparables.

El precio del servicio es a partir de 800 € y el plazo de ejecución, de 1 a 4 semanas, según el tamaño del sitio web, el número de idiomas y plantillas, la complejidad de la CMP y de los contenedores de etiquetas y la cantidad de integraciones necesarias. Antes de empezar distinguimos claramente en el precio y en el calendario entre las pruebas de auditoría, las correcciones técnicas y las cuestiones que debe decidir el abogado o el profesional de la protección de datos de la empresa; a los 30 y 180 días repetimos el escaneo utilizando los escenarios fijados. Así, el precio y el plazo corresponden a un alcance técnico definido, no a una promesa indeterminada de ordenar toda la protección de datos de la empresa.

Si necesita una «auditoría RGPD de un sitio web», primero acordamos que aquí esa expresión se limita a las cookies, el seguimiento, la CMP y Consent Mode, no a una comprobación completa del cumplimiento del RGPD en toda la organización; por eso prometemos únicamente lo que podemos demostrar técnicamente: el comportamiento del sitio web antes de la elección, después del rechazo, después del consentimiento y tras retirarlo, las señales enviadas a las herramientas y los puntos donde la prueba aún no permite extraer una conclusión jurídica. Esta distinción permite cerrar el trabajo técnico con un resultado verificable y trasladar las cuestiones jurídicas a quien responda del tratamiento más amplio de datos personales. Puede solicitar una auditoría de cookies y seguimiento enviándonos la dirección del sitio web y el nombre de la CMP o del gestor de etiquetas que utiliza.