El problema ya no es detectar bots: el tráfico automatizado empezó a parecerse demasiado a tus usuarios
Durante mucho tiempo fue fácil sentirse listo frente a un bot.
Hacía demasiadas requests. Repetía patrones absurdos. Mandaba user agents ridículos. Intentaba logins en ráfaga. Caminaba por una app como si nunca hubiera visto a un humano usar una app. Detectarlo no siempre era trivial, pero al menos sabías más o menos qué estabas buscando.
Ese escenario ya se quedó viejo.
Hoy una parte importante del tráfico automatizado no entra pateando la puerta. Entra usando rutas normales, credenciales válidas, ritmos más creíbles y endpoints que de por sí ya estaban diseñados para hablar con máquinas. Por eso el trabajo ya no es solo identificar si algo es un bot. El trabajo es entender qué está intentando hacer y si ese comportamiento le sirve o le pega a tu producto.
El tráfico web ya no se deja leer igual
Hay una costumbre bastante mala en equipos web: seguir leyendo el tráfico como si todo lo importante fuera humano y lo demás fuera ruido periférico.
Ya no alcanza con ese mapa mental.
Hoy conviven en el mismo espacio:
- usuarios reales
- crawlers legítimos
- bots buenos
- scrapers comerciales
- automatizaciones internas
- agentes que ejecutan tareas
- tráfico hostil que aprendió a verse razonable
Ese último grupo es el que complica todo. No porque sea invisible, sino porque muchas señales que antes te ayudaban a detectarlo ya no bastan por sí solas.
Si una automatización ya no se comporta como caricatura de automatización, tus reglas viejas empiezan a quedarse cortas.
La web lleva rato hablando con máquinas
Aquí conviene poner un poco de orden.
La web no se llenó de tráfico no humano ayer. Siempre ha habido crawlers, indexadores, scrapers, monitores, integraciones y procesos automáticos. Eso no es noticia. La infraestructura moderna depende de eso.
Lo que sí cambió es esto:
- hay más automatización
- es más barata
- está mejor distribuida
- entiende mejor los flujos de una app
- ya no necesita verse escandalosamente rara para hacer daño
La IA aquí no inventó una especie nueva de amenaza. Lo que hizo fue volver más eficientes cosas que ya existían: más volumen, mejor camuflaje y menos fricción para ajustar comportamiento.
Si tu producto tiene APIs, el problema ya te queda más cerca
A muchos equipos todavía les gana una intuición medio engañosa: piensan la interfaz como el producto y la API como una tubería técnica que vive atrás.
Pero cuando el tráfico automatizado crece, la API deja de ser una tubería invisible y se vuelve una de las superficies más sensibles del sistema.
Porque ahí vive lo que de verdad importa:
- autenticación
- cuentas
- perfiles
- inventario
- precios
- búsquedas
- dashboards
- pagos
- operaciones internas
- integraciones móviles
Y además, seamos honestos: las APIs están hechas para que las consuman máquinas. Ese es el punto. Entonces, cuando una automatización quiere ir directo al valor real de un producto, casi siempre termina queriendo hablar con ese layer.
Caso 1: el login que se ve normal
Este caso es más común de lo que varios quisieran aceptar.
No hay una ráfaga grotesca de requests. No hay un patrón obvio de fuerza bruta. No hay una IP haciendo 800 intentos por minuto. Lo que hay es tráfico bastante mejor portado:
- intentos distribuidos
- secuencias razonables
- credenciales válidas o semiválidas
- rutas normales
- timings que no parecen absurdos
Desde fuera, se parece mucho más a uso real que a ataque escandaloso.
Si sigues dependiendo solo de reglas tipo “si hace demasiados intentos, bloqueo”, te van a pasar varias cosas por debajo del radar. Sobre todo en productos donde una cuenta tiene valor económico o acceso a información útil.
Caso 2: scraping que no quiere llamar la atención
El scraping también cambió de tono.
Antes era más común ver bots pesados que golpeaban una web con cero sutileza. Hoy te puedes topar con automatizaciones que hacen menos ruido, distribuyen mejor carga, se mueven con más paciencia y van por datos muy concretos.
Eso afecta muchísimo a productos donde el dato visible tiene valor comercial:
- catálogos
- marketplaces
- medios
- travel
- inmobiliario
- comparadores
- directorios
- dashboards públicos
El golpe no siempre es solo “me copiaron contenido”. A veces el costo real aparece en otro lado: infraestructura, degradación de rendimiento, analítica contaminada, uso abusivo de búsqueda o decisiones de negocio tomadas con datos torcidos.
Un filtro básico en .htaccess que sí puede ayudarte
Si quieres frenar bots evidentes o crawlers que ya sabes que no quieres en tu servidor, puedes empezar con una regla sencilla en tu .htaccess. No te va a resolver scraping serio ni tráfico hostil bien camuflado, pero sí sirve como capa inicial para bots básicos y user agents conocidos.
RewriteEngine On
# Bloquea algunos bots y crawlers problemáticos por user-agent
RewriteCond %{HTTP_USER_AGENT} (AhrefsBot|SemrushBot|MJ12bot|DotBot|Bytespider|DataForSeoBot|BLEXBot|PetalBot|MegaIndex) [NC]
RewriteRule ^ - [F,L]
# Bloquea requests sin user-agent
RewriteCond %{HTTP_USER_AGENT} ^-?$
RewriteRule ^ - [F,L]Esto no sustituye rate limiting, protección por endpoint, análisis de comportamiento ni controles sobre autenticación. Sirve como filtro rápido para tráfico automatizado poco sofisticado o crawlers que ya tienes identificados como no deseados.
Y aquí conviene no mezclar herramientas. robots.txt da instrucciones a crawlers que deciden portarse bien. .htaccess, en cambio, sí puede bloquear tráfico a nivel servidor. Si quieres revisar mejor esa diferencia, te conviene leer también este artículo sobre para qué sirve robots.txt y cómo ocultar tu página web de Google.
El captcha ya no es esa respuesta mágica que varios creen
Hay equipos que siguen pensando en captcha como si fuera talismán.
No digo que no sirva nunca. Digo que usarlo como respuesta reflejo ya se queda corto demasiadas veces.
Si el problema es de comportamiento, intención y abuso sobre endpoints sensibles, meter fricción visual en un punto visible de la interfaz no necesariamente te arregla el fondo. A veces solo maquilla la sensación de control.
La defensa útil suele ser bastante menos glamorosa:
- segmentar endpoints críticos
- entender patrones por identidad y sesión
- combinar límites con contexto
- endurecer autenticación donde de verdad duele
- separar automatización tolerable de automatización hostil
El error de varios equipos no es técnico. Es de modelo mental.
A muchos productos no les falta herramienta. Les falta una lectura más fina del problema.
Todavía piensan en defensa web como si todo se resolviera con:
- WAF
- bloqueo por IP
- rate limiting básico
- captcha
- reglas genéricas
Eso sigue teniendo lugar. Pero si el tráfico automatizado ya puede parecerse bastante a un usuario normal, la pregunta útil cambió.
Ya no es solo “¿esto es humano o no?”. Ahora es más bien “¿esta interacción tiene sentido para este endpoint, para esta cuenta, para esta sesión y para este momento del producto?”.
Qué sí haría un equipo web con dos dedos de frente
No hace falta ser una empresa monstruosa para mejorar mucho aquí. Pero sí hace falta dejar de pensar en el sitio entero como una sola superficie plana.
1. Clasificar endpoints por riesgo real
No todos valen lo mismo. No merece la misma protección una home pública que un login, recuperación de cuenta, una API de precios o una operación financiera.
2. Medir sesiones, no solo volumen
El volumen bruto dice poco si no sabes qué camino recorrió una identidad dentro del sistema. Vale más detectar secuencias improbables, navegación demasiado perfecta y abuso repetido sobre recursos valiosos.
3. Limpiar tu analítica
Si parte del tráfico que miras ya no es humana, varios dashboards de negocio empiezan a perder pureza. No solo se tuercen métricas de tráfico; también funnels, conversión, engagement, capacidad y atribución.
4. Subir fricción solo donde sí importa
No toda pantalla necesita paranoia. Pero donde hay dinero, cuenta, datos sensibles o abuso histórico, conviene endurecer más.
5. Dejar de pensar que “parece normal” equivale a “está bien”
Hay tráfico hostil que ya entendió que verse exagerado es mala estrategia. Si tu lectura del sistema no evolucionó al mismo ritmo, el problema no es que el atacante haga magia. El problema es seguir esperando un disfraz viejo.
Entonces, ¿qué haces con esto?
Si tu producto depende de cuentas, APIs, inventario, precios, contenido o cualquier flujo con valor claro, este tema ya te pega. A veces se nota en fraude. A veces en scraping. A veces en métricas contaminadas. A veces en infraestructura que se encarece sin que quede tan claro por qué.
No hace falta leer todo esto como alarma roja. Sí conviene revisar mejor qué endpoints son sensibles, qué tráfico estás tratando como normal y qué parte de tu analítica mezcla usuarios reales con automatización.
En conclusión
El punto no es solo que haya más bots. El punto es que una parte del tráfico automatizado ya no se delata tan fácil como antes.
Si mantienes un sitio, una app o una API, eso te obliga a mirar mejor qué pasa en autenticación, búsquedas, inventario, scraping y métricas. Varias defensas siguen sirviendo, pero ya no alcanza con reglas demasiado simples ni con asumir que todo lo raro se va a ver raro.