🤖Cómo detectar bots que se hacen pasar por usuarios reales en tu sitio

Hace diez años, un bot era un script en Python con requests y beautifulsoup. Detectarlo era fácil: ausencia de JavaScript, user-agent genérico, patrón de request uniforme. Hoy el juego es distinto. Los bots modernos corren navegadores Chrome headless con plugins de stealth, rotan por proxies residenciales (IPs de usuarios reales con conexión comprometida), y usan LLMs para simular conversación humana en formularios. Distinguirlos del usuario real requiere combinar capas que ningún control individual resuelve.

El problema escala. Según reportes de la industria, en 2026 aproximadamente el 40-50% del tráfico total de internet es bot, y de ese, la mitad es malicioso (scraping agresivo, credential stuffing, inventory hoarding, ad fraud, spam). Cualquier sitio con algo que proteger — login, carrito, formulario, API — recibe tráfico bot significativo.

Este artículo explica cómo son los bots modernos realmente, qué señales los delatan, y cómo armar un stack de detección efectivo sin romper la experiencia del usuario legítimo ni el SEO.

La evolución del bot

Entender contra qué estás peleando ayuda a elegir defensas. La trayectoria:

Generación 1: scripts simples (pre-2015)

Python + requests + beautifulsoup. Sin JavaScript, sin cookies, sin estado. Fácil de detectar por ausencia de browser features. Todavía existen — mayoría del scraping de bajo volumen.

Generación 2: navegadores headless básicos (2015-2020)

Selenium + Chromedriver. Corre navegador real pero con marcadores de automation evidentes (navigator.webdriver = true, etc). Detección trivial con fingerprint básico.

Generación 3: headless con stealth (2020-presente)

Puppeteer o Playwright con plugins de stealth (puppeteer-extra-plugin-stealth) que remueven marcadores de automation. Usan proxies datacenter rotativos. Detectables con fingerprint avanzado y análisis de comportamiento, pero requiere esfuerzo.

Generación 4: stealth premium + residencial + LLM (2024-presente)

Stack actual:

• Headless Chrome con stealth custom (no solo plugins públicos).
• Proxies residenciales (IPs de usuarios reales vendidas/alquiladas, típicamente a través de SDKs en apps móviles baratas).
• LLM para generar respuestas contextuales en formularios, CAPTCHAs de texto, conversaciones con humanos.
• Simulación de movimiento de mouse con modelos entrenados en datos humanos reales.
• Rotación de fingerprints para evadir tracking.

Esta generación es cara (USD 0.50-5 por request vs centavos por las anteriores), pero es la que se usa para ataques de alto valor: credential stuffing contra targets específicos, inventory hoarding de productos caros, fraud sofisticado.

Generación 5 (emergente 2026): agentes autónomos

LLMs con capacidad de navegar por objetivo (AutoGPT-like). Menos deterministas, más adaptables. Todavía en etapa temprana pero apuntan a romper defensas basadas en patrones rígidos.

Los 4 tipos por motivación

Los bots no son todos iguales. Su comportamiento y señales cambian según objetivo:

Tipo 1: scrapers

Extraen contenido del sitio (precios, catálogo, posts, datos). Pueden ser legítimos (comparadores de precio autorizados, indexadores) o maliciosos (competencia copiando catálogo, agregadores sin permiso).

Señales típicas: requests GET masivos, patrón sistemático (recorren todas las URLs), baja interacción con forms.

Impacto: consumo de bandwidth, contenido copiado, daño a SEO.

Tipo 2: credential attackers

Ejecutan credential stuffing (probar listas grandes de credenciales) o brute force contra endpoints de login.

Señales típicas: POSTs masivos a endpoints de login, errores 401/403 en volumen, IPs rotativas, patrones de temporización automatizados.

Impacto: cuentas comprometidas, daño reputacional si se ejecuta ATO exitoso.

Tipo 3: inventory / commerce abusers

Bots que acaparan stock limitado (sneakers, entradas, productos calientes) para revender. Ejecutan add-to-cart + checkout automatizado. Los más sofisticados de la categoría.

Señales típicas: pico súbito al drop de producto, patrón de checkout velocísimo, direcciones IP premium residenciales, cuentas nuevas con comportamiento limpio (muchas veces "aged accounts" compradas).

Impacto: pérdida directa de ingresos (cliente real no pudo comprar), daño a marca (experiencia frustrante), mercado secundario rentable sobre tu producto.

Tipo 4: fraud / ad abuse

Clics automáticos en ads (propios o de terceros), vistas artificiales, registros falsos para aprovechar promociones.

Señales típicas: patrón de interacción repetitivo, engagement sin conversión real, IPs de datacenters específicos, consistencia sospechosa.

Impacto: distorsión de métricas, gasto en ads desperdiciado, promociones agotadas por cuentas ficticias.

Las 8 señales técnicas que delatan automation

Ninguna sola es definitiva — el combo es lo que detecta:

Señal 1: user-agent y headers

• UA que no coincide con comportamiento (dice "Chrome Windows" pero falta header sec-ch-ua).
• Headers faltantes o inconsistentes.
• Accept-Language genérico (en-US,en) en sitios de mercado no inglés.

Señal 2: IP reputation

• Datacenter IPs (AWS, Azure, GCP) cuando debería ser residencial.
• Proxies conocidos (listas públicas, feeds comerciales).
• Tor exits.
• IPs con historial reciente de abuso.

Señal 3: TCP/TLS fingerprint (JA3, JA4)

Cada cliente TCP/TLS tiene "firma" por cómo negocia la conexión. Browsers reales tienen firmas conocidas. Herramientas como Python requests, Go http.Client, curl tienen firmas distintas — un UA "Chrome" con firma de Python libraria es bot casi seguro.

Señal 4: navigator properties

Del lado cliente con JS:

• navigator.webdriver === true → Selenium/Chromedriver sin stealth.
• navigator.plugins.length === 0 → sospechoso (browsers reales tienen plugins).
• navigator.languages vacío o inconsistente con Accept-Language.
• Timezone del browser inconsistente con IP geo.

Señal 5: canvas / WebGL fingerprint

Browsers reales generan canvas fingerprints consistentes con hardware real. Headless con virtualización genera fingerprints anómalos (GPU software, ausencia de extensions específicas de hardware).

Señal 6: comportamiento de mouse y teclado

Humanos generan movimientos con curvas naturales, pausas, corrections. Bots generan movimientos rectos o con patrones repetitivos. Modelos modernos distinguen con alta precisión.

Teclado: humanos tienen distribución de timing entre keypresses variable y característica; bots típicamente uniforme.

Señal 7: velocidad e temporización

• Tiempo entre page load y primera acción (humanos: 2-10 segundos; bots: menos de 500ms).
• Velocidad de fill de formularios (humanos: 2-30 segundos; bots: menos de 100ms).
• Consistencia de temporización (humanos variables; bots a menudo uniformes).

Señal 8: session behavior

• Sesión corta con acción única (bot con objetivo específico).
• Navegación sin exploración (va directo al target).
• Ausencia de errores humanos (misclicks, backtrack, pausas).
• Patrón de navegación sistemático (recorre URLs en orden alfabético/numérico).

Device fingerprinting vs behavior analysis

Los dos enfoques son complementarios:

Device fingerprinting (quién es el dispositivo)

• Qué mide: características del device y del cliente (hardware, software, browser, red).
• Ventajas: señal inmediata (primera request), difícil de falsear completamente, estable entre sesiones.
• Límites: bots premium usan fingerprint rotation y spoofing. No detecta cuando un humano real opera el bot.
• Técnicas: canvas, WebGL, audio context, fonts, plugins, hardware specs, TCP/TLS JA3/JA4.

Behavior analysis (cómo se comporta)

• Qué mide: patrones de interacción durante la sesión (mouse, teclado, navegación, temporización).
• Ventajas: detecta bots incluso con fingerprint perfecto porque el comportamiento es más difícil de imitar.
• Límites: requiere sesión activa (no detecta en primera request), vulnerable a LLMs avanzados que generan comportamiento realista.
• Técnicas: modelos ML sobre mouse trajectories, keystroke dynamics, navigation patterns.

Lo óptimo 2026: combinación. Device fingerprint asigna score inicial en primera request. Behavior analysis refina el score durante la sesión. Decisión compuesta final.

Verificación de crawlers legítimos (no rompas SEO)

Este es error costoso: bloquear Googlebot por confundirlo con bot malicioso. Tu sitio desaparece de resultados por semanas. Evitarlo requiere proceso explícito.

Método: reverse DNS verification

Los crawlers legítimos publican rangos IP y métodos de verificación. El proceso estándar:

1. Recibís request con UA "Googlebot".
2. Haces reverse DNS lookup sobre la IP origen.
3. Verificás que el hostname termina en dominio del crawler (.googlebot.com, .bing.com, .applebot.apple.com, etc).
4. Haces forward DNS lookup sobre el hostname obtenido.
5. Verificás que la IP resultante coincide con la IP origen.

Si pasan los 5 pasos, es crawler legítimo. Si solo coincide el user-agent pero no el DNS, es bot mintiendo.

Whitelisting explícito

Lista estándar a pasar sin fricción:

• Google (Googlebot, Googlebot-Image, AdsBot, etc).
• Bing (Bingbot, MSNBot).
• DuckDuckGo, Yandex, Baidu, Naver.
• Applebot, Apple-PubSub.
• Facebook External, Twitter, LinkedIn (para link previews).
• Ahrefs, Moz, Semrush si usás sus servicios y los autorizaste.

Mantener la lista actualizada. Los proveedores cambian rangos de tanto en tanto.

Crawl rate limits

Incluso crawlers legítimos pueden abrumar tu infraestructura si están mal configurados del otro lado. Aplicar rate limit específico para crawlers (más laxo que bots maliciosos, pero no ilimitado) evita problemas.

Política escalonada de respuesta

Binario "bloquear o permitir" no funciona. La política efectiva es gradiente:

Nivel 1: score bajo (menos de 0.3)

• Permitir sin fricción.
• Log para análisis.

Nivel 2: score medio (0.3-0.6)

• Permitir con rate limiting agresivo.
• Desafío invisible (Turnstile, reCAPTCHA v3 score).
• Log estructurado.

Nivel 3: score alto (0.6-0.85)

• Desafío visible (captcha interactivo).
• Si falla, bloqueo temporal (minutos a horas).
• Alerta al equipo si persiste.

Nivel 4: score crítico (sobre 0.85)

• Bloqueo inmediato.
• Si IP está en feed de abuso: bloqueo extendido.
• Si patrón es masivo desde múltiples IPs: investigación dedicada.

Consideraciones por tipo de endpoint

Thresholds varían por sensibilidad del endpoint:

• Home/lectura pública: muy laxos, solo bloquear obvio.
• Login: estrictos, rate limit bajo, 2FA obligatorio en sospecha.
• Checkout: estrictos, verificación adicional ante score medio.
• API autenticada: moderados, con focus en patrón vs request individual.
• API pública: muy estrictos, con tokens y quotas.

Integración con el resto del stack

Bot detection aislado es silo — integrado multiplica valor:

• Con WAF: bloqueo efectivo al nivel de red antes de tocar aplicación.
• Con rate limiter: reglas diferenciadas por tipo de tráfico detectado.
• Con UBA: score bot influye en score UBA de sesión.
• Con fraud engine: bot detection es input de modelos de scoring de transacciones.
• Con SIEM: eventos bot estructurados para correlación con otros events.
• Con business logic: ciertas acciones (checkout de stock limitado, bulk operations) pueden requerir score humano alto sin importar autenticación.

Errores frecuentes

• Bloquear por user-agent solo: UA es mentible. Nunca confiar solo en eso.
• No whitelistear crawlers: daño SEO garantizado.
• Confiar en CAPTCHA como control único: resoluble por servicios automáticos.
• Thresholds iguales en todos los endpoints: ignora diferencia de sensibilidad.
• No tener whitelisting de usuarios legítimos edge-case: empresas con VPN propia que todas comparten IP, usuarios con ad-blocker agresivo, accessibility users — se bloquean por error.
• Respuesta solo binaria: elimina gradación, maximiza falsos positivos.
• No revisar periódicamente: bots evolucionan, tu detección tiene que evolucionar.

Cierre

El juego del bot vs detección es carrera permanente. En 2026 los bots usan Chrome headless con stealth premium, proxies residenciales y LLM para simular humanos — y esa capacidad sigue mejorando. Ningún control individual es suficiente. La defensa realista es combinar device fingerprinting, análisis de comportamiento, IP reputation, verificación de crawlers legítimos, y política escalonada de respuesta. Ese stack bien calibrado bloquea el 95%+ de bots maliciosos sin romper SEO ni experiencia del usuario real. Sin stack, tu sitio es parte de la superficie que mantiene el ecosistema de bots rentable.