Las cookies siguen definiéndose después de Reject

Por qué es importante

Un botón Reject que no bloquea realmente el tratamiento opcional es una de las señales más claras de que el mecanismo de consentimiento no se está aplicando correctamente.

Cómo verificarlo manualmente

1. Rechace el tratamiento opcional en una sesión limpia y recargue la página.
2. Inspeccione cookies y solicitudes de red tras Reject.
3. Compare el comportamiento antes y después de Reject para confirmar si el almacenamiento opcional realmente se detiene.

Causas típicas

• Reject solo actualiza el estado visual del banner, pero no propaga un estado denied.
• Las etiquetas opcionales vuelven a dispararse tras el reload pese a la elección rechazada.
• Los valores de consentimiento guardados se leen mal o se ignoran tras navegar.

Corrección en GTM

1. Asegúrese de que el estado denied se lee antes de que las etiquetas puedan arrancar tras el reload.
2. Aplique controles de consentimiento a todas las etiquetas opcionales, no solo a eventos de primera carga.
3. Compruebe en GTM Preview que Reject persiste correctamente a través de recargas.

Corrección en WordPress o plugins CMP

1. Revise integraciones de plugins que sigan cargando etiquetas opcionales después de Reject.
2. Verifique que el plugin CMP guarda y aplica el estado denied en todas las cargas de página.
3. Elimine plugins de tracking redundantes que ignoren el estado del CMP.

Corrección genérica para desarrolladores

1. Trate Reject como un estado runtime ejecutable y no solo como una acción de UI.
2. Bloquee cargadores opcionales en cada página cuando el consentimiento almacenado sea denied.
3. Pruebe reload, revisit y navegación entre páginas, no solo el primer cargado.

Cómo confirmar que la corrección funciona

• Reject y reload: confirme que las cookies opcionales siguen ausentes.
• Reject y reload: confirme que las solicitudes opcionales siguen bloqueadas.
• Lance un nuevo escaneo y verifique que desaparecen los hallazgos relacionados con Reject.