Instalar un banner de cookies no demuestra que Google Analytics esté respetando correctamente las decisiones del visitante. En WordPress, una implementación de consentimiento necesita coordinar al menos tres piezas: la interfaz que recoge la elección, la capa que comparte ese estado con otros plugins y las etiquetas de medición que deben reaccionar a esa decisión.
El error más frecuente es añadir herramientas por capas —Site Kit, Google Tag Manager, otro plugin de Analytics y un CMP— sin comprobar qué código inserta cada una. El resultado puede ser una medición duplicada, eventos enviados antes del consentimiento o una configuración difícil de auditar.
Qué hace realmente Google Consent Mode
Google Consent Mode permite que las etiquetas de Google adapten su comportamiento según el estado de consentimiento del usuario. Entre las señales más relevantes están analytics_storage, ad_storage, ad_user_data y ad_personalization.
La documentación de Google distingue entre conceder y denegar esos estados. La implementación concreta depende del producto y de la configuración elegida, pero el principio operativo es el mismo: la decisión del usuario debe convertirse en un estado que las etiquetas puedan interpretar.
Qué papel tiene Site Kit en WordPress
Site Kit puede conectar Google Analytics y colocar automáticamente su snippet. Su documentación también permite activar Consent Mode desde los ajustes del plugin. Cuando se utiliza esta vía, Site Kit indica que necesita una capa de consentimiento compatible para obtener la elección del visitante.
Esto es importante porque un banner visible no equivale a una integración técnica correcta. El banner debe comunicar el estado y la etiqueta debe recibirlo antes de comportarse de acuerdo con esa decisión.
WP Consent API no es el banner
WP Consent API estandariza la comunicación de categorías de consentimiento entre plugins de WordPress. No sustituye al sistema que presenta el aviso al visitante. Site Kit explica que, para una configuración basada en Consent Mode, sigue siendo necesario un plugin o plataforma de gestión de consentimiento que permita aceptar o rechazar.
La ventaja de separar estas funciones es que el CMP recoge la decisión y WP Consent API facilita que otros componentes de WordPress puedan consultarla de una forma común.
El riesgo de duplicar GA4 con Site Kit y Tag Manager
Utilizar Site Kit y Google Tag Manager en la misma web no implica automáticamente un problema. El conflicto aparece cuando ambos terminan configurando la misma propiedad o el mismo Measurement ID y generan dos envíos equivalentes.
Por ejemplo, si Site Kit inserta la etiqueta base de GA4 y dentro de GTM existe además otra etiqueta de configuración para ese mismo flujo, un page_view puede llegar dos veces. También puede ocurrir con eventos personalizados si se disparan desde más de una capa.
Por eso, antes de tocar la configuración, documenta qué sistema es responsable de cada función:
- quién inserta la etiqueta base de Analytics;
- quién gestiona Consent Mode;
- quién dispara eventos personalizados;
- qué contenedor GTM está activo;
- qué Measurement ID utiliza cada etiqueta;
- qué plugin genera el banner y qué categorías expone.
Cómo comprobar el estado antes de aceptar cookies
Haz las pruebas en una sesión limpia, preferiblemente en una ventana privada y sin iniciar sesión en WordPress. Antes de interactuar con el banner:
- abre las herramientas de desarrollador;
- limpia almacenamiento y cookies si la prueba no parte de cero;
- recarga la página;
- revisa las solicitudes de red relacionadas con Google;
- comprueba el estado de consentimiento que recibe la etiqueta;
- anota qué cookies existen antes de elegir.
La presencia de una petición de red no debe interpretarse aislada del modo de consentimiento utilizado. Lo relevante es verificar el comportamiento esperado de la configuración elegida y que no se escriban o reutilicen datos en contra de la decisión del visitante.
Prueba de rechazo
Después de pulsar “Rechazar”, verifica que la elección queda registrada y que las señales relevantes cambian al estado previsto. Comprueba también que al navegar a una segunda página la decisión se conserva.
En esta fase interesa revisar al menos:
analytics_storage;ad_storage;ad_user_data;ad_personalization;- cookies creadas o modificadas;
- peticiones de Analytics y Ads;
- eventos personalizados que dependan del consentimiento.
Prueba de aceptación
Repite la prueba desde una sesión limpia y acepta las categorías configuradas. Después comprueba que las señales pasan al estado correspondiente y que GA4 recibe una sola copia de cada interacción.
No basta con ver un evento en Realtime. Si una acción aparece dos veces, hay que determinar si la duplicidad procede del snippet base, de GTM, de un plugin o de un listener personalizado.
Cómo detectar un page_view duplicado
Una comprobación práctica consiste en filtrar las solicitudes de red de GA4 y recargar una sola página. Si observas dos envíos equivalentes asociados a la misma navegación, inspecciona qué script los origina.
Después compara con la configuración de WordPress:
- Site Kit: ¿tiene activada la inserción del snippet?
- GTM: ¿existe una etiqueta de Google o GA4 con el mismo identificador?
- Tema o código personalizado: ¿hay un
gtag.jsañadido manualmente? - Otro plugin: ¿está insertando Analytics de forma independiente?
La solución correcta no es “bloquear uno” al azar, sino decidir cuál será la fuente de verdad para la etiqueta base y eliminar únicamente la duplicación confirmada.
Eventos personalizados y consentimiento
Si la web mide clics en CTA, acciones de contacto o envíos correctos de formulario, esos eventos también deben respetar la política definida. Un listener propio puede comprobar el estado de consentimiento antes de emitir el evento.
Además, evita enviar información personal a Analytics. Un evento de formulario puede incluir identificadores técnicos, página de origen o tipo de acción, pero no debería transportar nombre, correo, teléfono ni el contenido escrito por el usuario.
generate_lead debe dispararse tras el éxito real
Una conversión de formulario no debería medirse al pulsar el botón “Enviar”. En ese momento aún pueden existir errores de validación, fallos de red o respuestas rechazadas. La señal útil es el evento que confirma que el formulario terminó correctamente.
Esto permite que generate_lead represente un envío real en lugar de un intento. Después, en GA4, conviene comprobar que aparece una sola vez por envío y marcarlo como evento clave únicamente cuando esa configuración se haya validado.
Checklist de validación completa
- Identifica todos los plugins y scripts que pueden insertar Google tags.
- Confirma el Measurement ID real de la propiedad.
- Decide qué sistema inserta la etiqueta base.
- Comprueba qué herramienta gestiona Consent Mode.
- Verifica que el CMP permite aceptar, rechazar y configurar.
- Prueba una sesión nueva antes de elegir.
- Prueba rechazo y revisa señales, cookies y red.
- Prueba aceptación y revisa de nuevo.
- Comprueba una sola emisión de
page_view. - Prueba eventos personalizados individualmente.
- Envía un formulario de prueba controlado y confirma un solo
generate_lead. - Valida recepción en GA4 Realtime o DebugView.
- Documenta qué componente es responsable de cada parte.
No midas bien solo para “tener números”
Una implementación de Analytics tiene valor cuando permite responder preguntas de negocio sin deteriorar privacidad ni calidad técnica. En una web de servicios interesa relacionar canal, landing page, contenido, CTA y generación de lead, pero esa lectura solo es fiable si la base de medición está limpia.
Si estás revisando la arquitectura SEO y la medición de una web, puedes consultar el servicio de posicionamiento SEO y utilizar el analizador HTML SEO para revisar parte del marcado on-page. Para una revisión concreta de Analytics, consentimiento o conversiones, puedes contarme cómo está montado tu stack.
