Pico de bots en GA4: frénalo sin perjudicar el SEO
Respuesta rápida
El panel no significaba que hubiera 319 personas conectadas al mismo tiempo: GA4 Realtime usa una ventana móvil de 30 minutos. Al cruzar GA4, Cloudflare y los logs del servidor, el patrón encajó con automatización abusiva distribuida o tráfico similar al scraping. Aplicamos un Managed Challenge muy limitado que mantuvo accesibles a usuarios normales, recursos, API y rastreadores verificados. No encontramos indicios de compromiso.
GA4 mostró 319 usuarios activos en los últimos 30 minutos, mientras una tarjeta separada del país mostraba Singapur: 301. Las tarjetas de Realtime pueden actualizarse en momentos distintos, así que no calculamos un porcentaje ni hablamos de conexiones simultáneas.
Esta guía cubre todo el incidente: distinguir personas y automatización, separar Google/Bing/OpenAI, comprobar que la carga llegó al hosting, evaluar SEO y AdSense, aplicar una solución de bajo impacto y probar los caminos legítimos.
La evidencia sostiene automatización distribuida de navegador con IP rotativas. No identifica al operador, su origen físico o intención, ni demuestra DDoS, hackeo, robo de datos o una campaña de rastreo de IA.
Qué significaban realmente los 319 usuarios activos
Realtime cuenta actividad registrada durante los 30 minutos anteriores; no es un contador de conexiones de red abiertas. Los eventos previos siguen visibles después de mitigar hasta que salen de la ventana.
Un país no prueba demanda real ni abuso. Usuarios legítimos, VPN, proxies y navegadores automáticos pueden compartir atribución. Tratamos Singapur como pista analítica, no como identidad ni motivo para bloquear todo el país.
Cómo identificamos automatización sin fiarnos solo de GA4
El agregado de Singapur presentaba cero sesiones con interacción, casi una página por sesión, origen directo/vacío, concentración de navegador de escritorio y un barrido amplio de páginas de entrada. Eran señales fuertes, pero no bastaban para una regla de firewall.
Cloudflare registró 5.675 solicitudes concentradas en tres minutos, además de navegadores headless y firmas repetidas. El origen confirmó carga real: 3.869 solicitudes desde 1.101 IP en nueve minutos. La cadena GA4 → edge → origen fue la prueba útil.
Cadena de evidencia en tres capas
| Capa | Observación | Conclusión prudente |
|---|---|---|
| Comportamiento GA4 | Cero interacción, origen directo/vacío y barrido de páginas | Señal fuerte, no suficiente sola |
| Edge de Cloudflare | Minutos agrupados, headless y firmas repetidas | Las solicitudes llegaron al edge |
| Logs del origen | IP rotativas, solicitudes y bytes reales | Hubo carga y transferencia del hosting |
| Rastreadores conocidos | Google, Bing, OpenAI y otros separados y pequeños | No impulsaron el pico |
| Rutas de seguridad | Sin patrón de exploit, login o administración | Sin evidencia de compromiso |
¿Era Googlebot, un rastreador de IA, scraping o un ataque?
Los rastreadores reconocidos de Google, Bing, OpenAI, Meta y verificación publicitaria aparecieron aparte y con poco volumen. No impulsaron el pico. Un texto de user-agent se puede falsificar; los bots buenos deben verificarse y protegerse.
La descripción prudente es automatización abusiva distribuida o tráfico de navegador similar al scraping. No vimos un patrón de login, administración, fuerza bruta, archivos sensibles o exploits en la muestra. No encontramos evidencia de compromiso, pero se desconocen operador y motivo.
Qué podía ocurrir sin actuar: hosting, ranking y AdSense
En 35 minutos, Cloudflare contó 10.038 solicitudes y 166.891.967 bytes de respuesta en el edge. La caché absorbió parte, pero el origen recibió 2.126 solicitudes y 63.296.919 bytes de cuerpo en unos 32 minutos.
Si la tasa anómala se hubiera mantenido, habría añadido unos 1,4 GB al día. Es una proyección condicional, no consumo final ni factura. usar nuestra calculadora de ancho de banda para estimar la transferencia sostenida permite modelar otra tasa; no detecta bots.
Un pico en GA4 no produce una penalización automática. El riesgo SEO indirecto aparece si la carga causa latencia o 5xx reales, o si una regla amplia bloquea Googlebot. También ensucia informes y puede entrar en el ámbito de tráfico no válido de AdSense. La oleada podía acabar sola al terminar un inventario de rastreo, pero la recurrencia hace que esperar no sea una defensa duradera.
La solución de bajo impacto: un Managed Challenge preciso
No bloqueamos Singapur. La red era distribuida, el país no era identidad y un bloqueo geográfico dañaría a personas legítimas mientras la automatización cambia de salida.
Usamos Managed Challenge antes que un bloqueo duro. La regla solo cubrió el comportamiento sospechoso observado y excluyó bots verificados, métodos distintos de GET, API, recursos estáticos, PWA/service worker y rutas internas de Cloudflare. No publicamos la expresión, huellas o IDs reales.
El reto sí puede tener costes: una persona puede ver una comprobación, las herramientas de privacidad pueden interferir y un alcance incorrecto puede romper API, AJAX, webhooks, embeds, PWA o rastreadores. Empieza estrecho, prueba, vigila falsos positivos y conserva rollback. Nuestro caso de failover de hosting compartido con Cloudflare Workers resuelve caídas del origen, no clasifica tráfico.
Resultados: retos en el edge y menos trabajo en el origen
Cloudflare registró 128 solicitudes sometidas al reto después de activarlo. No representan 128 bots, personas o atacantes únicos; un cliente puede generar varias respuestas al reto.
Las dos muestras siguientes del origen bajaron a 8 solicitudes en un minuto y 17 en el siguiente. Tras el ajuste final, ninguna solicitud nueva con el patrón vigilado de carga de páginas llegó al origen. Las páginas normales de escritorio y móvil, una herramienta japonesa, el manifest, el service worker, un embed público, Googlebot y OAI-SearchBot siguieron en HTTP 200; la prueba HTML sospechosa coincidente recibió HTTP 403 con el marcador del reto.
Durante la verificación inmediata, la tarjeta móvil de GA4 pasó de 319 en total y 301 en la fila de Singapur a 241 en total y 224 para Singapur. Una comprobación posterior del 31 de julio mostró 23 usuarios activos. El descenso concuerda con la mitigación y con la salida de sesiones de la ventana de 30 minutos, pero no demuestra que una sola regla causara toda la caída.
Qué siguió accesible después de la regla
| Control | Resultado | Por qué importa |
|---|---|---|
| Páginas normales de escritorio y móvil | 200 | Las visitas normales siguieron disponibles |
| Herramienta japonesa localizada | 200 | La regla respetó idioma y ruta |
| Manifest, service worker y embed | 200 | PWA y contenido incrustado siguieron bien |
| Googlebot y OAI-SearchBot | 200 | Los rastreadores verificados conservaron acceso |
| Prueba HTML sospechosa coincidente | 403 + marcador de reto | El edge interceptó el patrón |
Plan seguro ante un pico repentino de GA4
1. Guarda captura, hora, zona, patrón por minuto, fuente, páginas, interacción, dispositivo y navegador; anota que Realtime cubre 30 minutos.
2. Contrasta GA4 con CDN, códigos, bytes, caché y logs del origen. Si edge y servidor no ven tráfico, revisa spam de medición, hostname o etiquetado antes del WAF.
3. Clasifica conducta: rastreador verificado, monitorización, automatización, abuso de endpoint o exploit. Empieza con la medida reversible más pequeña y usa reto antes de bloqueo amplio.
4. Prueba escritorio, móvil, idiomas clave, API, recursos, PWA, embeds, bots buenos y el patrón sospechoso. Supervisa falsos positivos, origen, 5xx, GSC y AdSense; endurece solo con nueva evidencia.
Cuándo observar, retar, limitar o bloquear
Solo un pico de GA4 exige investigar, no bloquear. Para una ráfaga confirmada de navegación sospechosa, usa un reto estrecho; si golpean un endpoint, limita ese endpoint.
Ante exploits, abuso de login/formularios o agotamiento real, suma reglas WAF gestionadas, controles de endpoint, rate limiting, Turnstile cuando corresponda y revisión del host. No es solo ruido analítico.
| Estado de evidencia | Primera acción | Evita |
|---|---|---|
| Solo pico en GA4 | Revisar analítica y contrastar CDN/servidor | Bloquear país por una tarjeta |
| Solicitudes reales, poco impacto | Vigilar, segmentar y guardar referencia | Regla permanente para anomalía corta |
| Ráfaga sospechosa de páginas | Managed Challenge estrecho con exclusiones | Bloqueo duro de toda la web |
| Un endpoint golpeado | Límite/reto específico del endpoint | Retar recursos y API no relacionados |
| Exploit, login o formularios | WAF, controles, límites, Turnstile y host | Tratarlo solo como ruido |
| 5xx o throttling real | Mitigar en edge, hablar con host y vigilar crawling | Esperar solo a que GA4 baje |
Tutorial oficial de reglas WAF de Cloudflare
El vídeo oficial muestra el flujo para crear reglas WAF personalizadas. Úsalo para la interfaz y aplica después el análisis, las exclusiones y las pruebas de este caso, no la expresión de otra web.
Fuentes primarias y límites de la conclusión
Las cifras proceden de la investigación de KBT en GA4, Cloudflare y logs del origen del 30–31 de julio. El comportamiento del producto y de rastreadores se apoya en documentación oficial.
- Google Analytics: usuarios activos en tiempo real
- Google Analytics: exclusión de bots conocidos
- Cloudflare: reglas WAF personalizadas
- Cloudflare: permitir bots verificados
- Desafíos de Cloudflare
- Preguntas de Cloudflare WAF: protección de rastreadores
- Google Search Central: verificar Googlebot
- Google Search Central: capacidad de rastreo y salud del servidor
- Google AdSense: tráfico no válido
Continúa el flujo
Preguntas frecuentes
- ¿Pueden los bots aparecer como usuarios activos en GA4?
Sí. GA4 excluye algunos bots conocidos, pero un navegador automático no identificado puede ejecutar la etiqueta. Confirma con CDN y servidor.
- ¿Puedo desconectar los usuarios activos directamente desde GA4?
No. GA4 informa actividad medida; no mantiene una sesión de red que puedas cerrar. Mitiga nuevas solicitudes en CDN/WAF/origen y espera a que los eventos salgan de la ventana móvil.
- ¿Por qué GA4 seguía mostrando usuarios tras mitigar?
Realtime cubre los últimos 30 minutos. Los eventos previos permanecen hasta expirar y las visitas legítimas continúan.
- ¿El tráfico de bots consume ancho de banda?
Sí cuando misses de caché, páginas dinámicas o recursos llegan al origen. Nuestro log confirmó solicitudes y bytes reales.
- ¿Puede perjudicar al SEO?
El pico analítico no es una penalización automática. Sí puede dañar indirectamente si causa latencia/5xx reales o si una regla amplia bloquea Googlebot.
- ¿Fue Googlebot, un rastreador de IA o un hackeo?
Los bots reconocidos eran separados y pequeños. La evidencia apuntó a automatización distribuida; no vimos exploits ni compromiso. Operador y motivo siguen desconocidos.
- ¿Puede parar sola la oleada?
Puede terminar al agotar una lista, pero no hay garantía. Puede regresar con otras IP o firmas; esperar no es una defensa duradera.
- ¿Managed Challenge tiene efectos negativos?
Sí. Una persona puede ver verificación y un alcance incorrecto puede romper API, embeds, PWA o rastreadores. Empieza estrecho, prueba, vigila y conserva rollback.
Un pico de GA4 es una señal, no un veredicto. Conserva la ventana, demuestra el impacto en edge y origen, protege tráfico verificado y aplica la medida reversible más pequeña.
