El tráfico orgánico secuestrado · Serpion 015

El proyecto llevaba meses con una trayectoria sólida. Un SaaS de gestión empresarial que había trabajado bien su posicionamiento, con contenido orientado a decisores de empresa, una arquitectura limpia y un histórico de crecimiento orgánico constante. No era un proyecto con problemas evidentes. Precisamente por eso, cuando algo empezó a no encajar, costó más verlo.

El síntoma llegó desde la analítica. El tráfico orgánico mostraba un pico notable, una subida de sesiones que, sobre el papel, parecía buena noticia. Pero las conversiones seguían planas. No bajaban, no subían: simplemente no reaccionaban. En un SaaS donde el canal orgánico estaba directamente vinculado a registros de prueba y solicitudes de demo, ese silencio era demasiado llamativo para ignorarlo. Cuando el tráfico crece y el negocio no nota nada, o el tráfico no vale, o los datos no son lo que parecen.

Esto no me cuadraba. Si las sesiones orgánicas crecían y las conversiones no se movían, había dos posibilidades: o el tráfico nuevo no era cualificado, o el tráfico nuevo no era real. Cualquiera de las dos tenía implicaciones distintas. Antes de tocar nada, necesitaba entender qué estaba midiendo exactamente.

El tráfico orgánico que subía sin dejar huella

Lo primero que hice fue abrir Google Search Console y comparar los clics orgánicos del periodo con las sesiones orgánicas que reportaba GA4. Esta comparación no siempre cuadra al céntimo; hay diferencias metodológicas entre ambas plataformas que explican ciertos desfases. Pero cuando la brecha es estructural y sistemática, es una señal que obliga a investigar.

Y aquí había una brecha de ese tipo. Search Console mostraba un crecimiento moderado en clics procedentes de la Búsqueda de Google, coherente con la tendencia anterior del proyecto. GA4, en cambio, registraba un volumen de sesiones orgánicas aproximadamente un 68% superior a esos clics durante el mismo periodo. Esa diferencia, por sí sola, no demuestra que hubiera sesiones falsas o tráfico automatizado; ambas herramientas miden cosas distintas y una discrepancia considerable puede tener varias causas. Lo que sí justificaba era abrir una investigación sobre la composición real de esas sesiones y descartar posibles problemas de medición o atribución.

Antes de ir más lejos, revisé una hipótesis que parecía plausible: que parte de ese tráfico extra fuera en realidad tráfico de campañas o de newsletter sin etiquetas UTM correctas. Si alguien había enviado un correo con un enlace sin parámetros, o si alguna acción de paid no estaba bien marcada, GA4 podría estar clasificando esas visitas en un canal distinto al esperado. Era una causa razonable y bastante frecuente en proyectos de este tamaño.

Revisé el historial de campañas activas durante el periodo del pico. Todas las acciones de email, las creatividades de paid search y los accesos desde redes sociales estaban correctamente etiquetados. Los UTMs estaban en su sitio. La hipótesis de la campaña sin etiquetar no se sostenía. Ese volumen extra no venía de ahí.

El problema no estaba en las campañas mal atribuidas. Estaba en algo que GA4 estaba contando sin que ningún equipo humano lo hubiera generado.

Por qué el tráfico orgánico sumaba sin convertir

Cambié el enfoque y fui directamente a los datos de comportamiento dentro de GA4. No a los totales, sino a los patrones. Lo que vi era difícil de ignorar: las sesiones que formaban el pico tenían una tasa de participación prácticamente nula. Tiempo medio en página de apenas un par de segundos, sin eventos de interacción, sin desplazamiento, sin clics en ningún elemento. Cero conversiones, cero registros, cero solicitudes de demo.

Para un SaaS orientado a decisores, ese perfil no tiene ningún sentido. Alguien que llega desde una búsqueda orgánica con intención real, aunque sea para informarse, puede generar señales de comportamiento: lee, desplaza la página o abre una sección. Pero esas señales no aparecen necesariamente en todos los casos, y su ausencia no demuestra por sí sola que la visita sea automatizada. Estas sesiones no hacían absolutamente nada. Entraban y desaparecían.

Periodo analizado: 14 días con pico anómalo

Sesiones orgánicas totales (GA4):          4.890
Clics orgánicos (GSC / Búsqueda de Google): 2.910
Diferencia sin justificar:                 1.980 sesiones
Diferencia sobre base GSC:                 ~68%

Tasa de participación (sesiones del pico): 1,4 %
Conversiones generadas:                    0
Duración media de sesión:                  1–3 segundos
Páginas de entrada concentradas:           3 URLs específicas del blog

Aquí había ruido, pero no era ruido cualquiera. Esas casi dos mil sesiones entraban de forma concentrada, en momentos concretos del día, siempre en las mismas tres URLs del blog, sin interacción alguna y sin dejar ninguna conversión. El tráfico orgánico que los informes presentaban como crecimiento podía estar mezclando sesiones de distinta naturaleza. Los patrones observados apuntaban a una posible contaminación automatizada, pero todavía no permitían determinar qué parte del volumen registrado en GA4 correspondía a esos accesos ni cuánto explicaban de la diferencia detectada. Lo que quedaba claro era que los datos mezclaban señales de naturaleza muy distinta, y esa mezcla hacía imposible leer la tendencia real del canal con los informes en ese estado.

Que un informe muestre crecimiento no significa que el proyecto esté creciendo. A veces los datos suben precisamente cuando algo empieza a fallar.

Lo que se escondía detrás del pico

Con el patrón de comportamiento claro, la investigación apuntaba en una dirección concreta. Los dos fenómenos convergían: un pico anómalo de sesiones en GA4 sin ninguna señal de interacción real, y accesos automatizados detectados en los registros del servidor durante el mismo periodo y en las mismas URLs. Eso no probaba todavía que ambos fenómenos correspondieran exactamente al mismo tráfico, pero sí era suficiente para tratar la contaminación automatizada como la hipótesis más sólida y actuar en consecuencia.

La tasa de participación tan baja y las conversiones a cero encajaban con ese patrón: accesos que llegaban al sitio sin generar ninguna señal de interacción real. El efecto práctico era demoledor desde el punto de vista analítico: la dirección del proyecto podía estar tomando decisiones basadas en datos de crecimiento distorsionados por una posible contaminación automatizada.

Para profundizar en el origen del tráfico sospechoso, cruzé los datos de sesiones con los registros del servidor durante el mismo periodo. El patrón resultante era un indicio fuerte: múltiples peticiones repetidas desde rangos de IP concretos, con intervalos regulares y con agentes de usuario que no correspondían a ningún navegador habitual.

Fragmento de log del servidor — accesos concentrados
(IPs sustituidas por direcciones reservadas para documentación; agentes de usuario reales del caso)


203.0.113.44 - - [09/Oct/2024:03:14:02 +0000] "GET /blog/gestion-tareas-empresas/ HTTP/1.1" 200 18432 "-" "python-requests/2.28.1"
203.0.113.44 - - [09/Oct/2024:03:14:04 +0000] "GET /blog/gestion-tareas-empresas/ HTTP/1.1" 200 18432 "-" "python-requests/2.28.1"
198.51.100.87 - - [09/Oct/2024:03:14:09 +0000] "GET /blog/automatizacion-procesos/ HTTP/1.1" 200 22110 "-" "Go-http-client/1.1"
198.51.100.87 - - [09/Oct/2024:03:14:11 +0000] "GET /blog/automatizacion-procesos/ HTTP/1.1" 200 22110 "-" "Go-http-client/1.1"

Agentes como python-requests o Go-http-client son clientes HTTP habituales en scripts automatizados, no en navegadores. Combinados con la repetición de peticiones, los intervalos regulares y la concentración en las mismas URLs que acumulaban el pico, los logs apuntaban con consistencia hacia tráfico automatizado. No era posible afirmar, solo con estos datos, que ese volumen de logs explicaba exactamente las 1.980 sesiones de diferencia entre GA4 y Search Console, porque los registros del servidor y las sesiones de GA4 se miden de formas distintas. Pero sí reforzaban el diagnóstico de contaminación y orientaban hacia dónde había que actuar.

Los bots no habían demostrado haber roto el SEO del sitio. Los indicios apuntaban a una posible contaminación de los informes, y eso era suficiente para investigar antes de tomar decisiones. Y eso es igual de peligroso, porque si no puedes leer bien lo que está pasando, no puedes actuar bien sobre ello.

Reconstruir los datos antes de tocar el sitio

Antes de plantear cualquier acción sobre el contenido o la estrategia, había que recuperar la capacidad de leer los datos con claridad. De nada servía optimizar páginas o revisar posicionamientos si existía la posibilidad de que el informe estuviera mezclando tráfico orgánico real con accesos automatizados. La primera corrección no era técnica en sentido SEO: era analítica.

Filtrar sin destruir el histórico

La tentación inmediata era aplicar un filtro de IP directamente en GA4 y dar el tema por cerrado. Pero eso tenía un problema serio: las IPs de los bots no eran fijas. Rotaban. Bloquear un rango concreto no garantizaba que el siguiente ciclo de accesos no llegara desde otro rango diferente. Una solución rígida iba a quedarse obsoleta en días.

El enfoque que mejor encajaba con lo que había fue construir en GA4 una comparación de segmentos entre sesiones con participación y sesiones sin ella. Esto no separaba con precisión quirúrgica el tráfico humano del automatizado, porque la participación no es un criterio definitivo de humanidad, pero sí permitía estudiar los dos comportamientos por separado y ver con más claridad qué parte del tráfico generaba señales reales. Era una herramienta de exploración, no de limpieza.

Para documentar el periodo afectado sin alterar los datos ya recogidos, se añadieron anotaciones en GA4 que marcaban el inicio y el alcance del pico anómalo. Es importante distinguir aquí dos cosas: las anotaciones documentan un acontecimiento en el tiempo, pero no modifican ni depuran los datos históricos. Los datos del periodo contaminado siguen estando ahí. Lo que las anotaciones hacen es dejar constancia de que ese tramo requiere interpretación diferente, para que cualquier análisis comparativo futuro tenga ese contexto disponible.

Lo que se descartó fue aplicar bloqueos a nivel de servidor sin análisis previo. Bloquear rangos de IP de forma masiva puede afectar a rastreadores legítimos, incluido el propio Googlebot, si no se hace con mucho cuidado. En este caso, la limpieza analítica era el primer paso necesario. La protección a nivel de infraestructura, si se decidía aplicar, vendría después y con más información sobre el origen concreto del tráfico automatizado.

Una vez aplicada la comparación de segmentos y contrastados los datos con Search Console, quedó claro que los informes anteriores no bastaban para interpretar el canal orgánico con fiabilidad. El volumen total podía estar inflado por accesos automatizados, pero todavía era necesario determinar qué parte de las sesiones correspondía a esos accesos.

Recuperar la capacidad de leer bien los datos no resuelve el problema SEO, pero sí devuelve la posibilidad de actuar sobre él. Sin datos limpios, cualquier decisión es una apuesta.