El responsable de una tienda online mira el informe de la mañana: a las tres de la madrugada el número de visitantes se multiplicó por cuatro, las adiciones al carrito no se movieron y la página de acceso registra miles de intentos fallidos. ¿Cuánto de ese tráfico es un buscador, cuánto un servicio de comparación de precios, cuánto un script que prueba contraseñas robadas? La detección de bots es el intento del dueño del sitio de responder a esa pregunta en cada solicitud y en milisegundos.
En este artículo contamos la detección de bots desde el lado del dueño del sitio: por qué capas pasa una solicitud, qué mide cada capa, cómo se convierten las señales en una única puntuación y quién paga el precio cuando esa puntuación se equivoca. Resumimos seis capas en orden y dejamos el detalle al artículo propio de cada una. También encontrarás aquí cómo se reconocen los navegadores headless, cómo demuestran su identidad los bots buenos y cuál es la vía legítima para quien opera una automatización. Las formas de saltarse las protecciones no son el tema de este artículo.
¿Qué es la detección de bots?
La detección de bots es el trabajo de distinguir si una solicitud que llega a un sitio viene del navegador que usa una persona o de un programa automático. El software que hace esto se llama sistema anti-bot, protección contra bots o gestión de bots; la mayor parte no corre en el código del propio sitio, sino en la CDN o el cortafuegos de aplicaciones web (WAF) que tiene delante. Cloudflare, Akamai y DataDome son proveedores que suenan con frecuencia en este campo. El sistema busca respuesta a dos preguntas: ¿la solicitud es automática y, si lo es, es del tipo que se quiere?
¿Qué es el tráfico de bots: cómo se separan los bots buenos de los malos?
El tráfico de bots es toda solicitud producida por la decisión de un programa y no por el clic de una persona. En los registros conviven tres tipos:
- Los bots que el sitio quiere. Rastreadores de buscadores, servicios que vigilan la disponibilidad, aplicaciones de mensajería que generan vistas previas de enlaces, la propia automatización de pruebas del sitio.
- Los bots que el sitio sopesa. Servicios de comparación de precios, herramientas de archivo, rastreadores de IA, scripts de investigación. Unos sitios abren la puerta y otros los aceptan con un límite de velocidad.
- La automatización que el sitio no quiere. El proyecto de amenazas automatizadas de OWASP cataloga este grupo poniéndole nombre: la prueba masiva de contraseñas robadas (credential stuffing), la validación de números de tarjeta robados (carding), la compra automatizada de existencias limitadas (scalping) y la copia masiva de contenido (scraping) están en esa lista.
La dificultad está en que los tres se parecen en la red. Por eso el sistema no mira una señal única, sino la suma de las capas.
¿En qué orden se evalúa una solicitud?
- Llega la conexión. Antes de leer ningún contenido se conoce la IP de origen; se consultan su reputación, su país y su red.
- Se hace el handshake TLS. El primer mensaje (ClientHello) lleva una pista sobre qué software está hablando.
- Se establece la conexión HTTP. En HTTP/2 el cliente anuncia sus ajustes de conexión; luego llegan el método, la dirección y las cabeceras.
- Se calcula la puntuación del lado del servidor. Las señales de los tres primeros pasos se unen al historial reciente de la dirección; la solicitud ya puede rechazarse aquí.
- La página llega al navegador. Un pequeño script en la página examina el entorno del navegador e informa del resultado.
- Se vigila la sesión. La frecuencia de las solicitudes, el orden de navegación y la interacción actualizan la puntuación mientras dura la sesión.
- Si se pasa el umbral, llega la acción. Un límite de velocidad, una pantalla de verificación o un bloqueo.
Los cuatro primeros pasos ocurren en el servidor sin que el visitante note nada; el quinto y el sexto solo producen datos en clientes que ejecutan JavaScript.
Las capas en una tabla: ¿qué mide cada capa?
| Capa | ¿Qué mide? | Su fuerza | Riesgo de falso positivo |
|---|---|---|---|
| Red | Reputación de la IP, ASN, país, denuncias previas | Trabaja barato, sin leer ningún contenido | IP compartidas: CGNAT, red corporativa, VPN |
| Protocolo | ClientHello de TLS, ajustes de HTTP/2 | Muestra el software cliente al margen de las cabeceras | Dispositivos antiguos, redes con inspección TLS corporativa |
| Cabecera | User-Agent, Client Hints, conjunto y coherencia de cabeceras | Compara lo declarado con lo real | Extensiones de privacidad, navegadores poco conocidos |
| Navegador | Entorno JavaScript, banderas de automatización, huella | Separa un navegador real de su imitación | Bloqueadores de scripts, herramientas de accesibilidad |
| Comportamiento | Ritmo de solicitudes, orden de navegación, interacción | Mira la sesión entera, no una solicitud suelta | Usuarios reales muy rápidos, navegación con teclado |
| Verificación | Prueba visible o invisible | Da una segunda oportunidad al tráfico sospechoso | Toda prueba crea fricción en clientes reales |
La última columna lleva la idea central del artículo: cada capa tiene un grupo de personas con el que se equivoca, y los umbrales se ajustan sabiendo ese coste.
La capa de red: ¿qué dicen la reputación de la IP y el ASN?
La dirección IP es el dato más temprano de una solicitud. El sistema mira el historial de abuso de la dirección, su país y, a través del ASN (número de sistema autónomo), a qué red está registrada. Una solicitud que sale de la red de una empresa de alojamiento y otra que sale de un bloque que un operador reserva a sus abonados domésticos no reciben el mismo trato: los usuarios de casa no salen a internet desde un centro de datos. Cómo clasifican los sitios una dirección como «operador» o «alojamiento» lo contamos en Proxy ISP y proxy residencial: diferencias.
La reputación viene de dos fuentes: listas negras que registran si la dirección se ha denunciado antes como origen de spam o de ataques (listas negras de IP) y servicios de puntuación de riesgo que reducen a una sola cifra el tipo de dirección y si es una salida de proxy o VPN (IP Fraud Score). La debilidad de la capa es que mide la dirección, no a la persona. Los operadores móviles y muchos proveedores ponen a muchísimos abonados detrás de la misma dirección (CGNAT); un script que funcione desde ahí baja la reputación de todos los que comparten esa dirección.
La capa de protocolo: huella TLS y ajustes de HTTP/2
En el primer mensaje de una conexión HTTPS, el cliente envía de forma abierta las suites de cifrado que admite, las extensiones y el orden de ambas. La lista cambia de navegador a navegador y de biblioteca a biblioteca; cuando el servidor la convierte en un resumen corto (JA3 y JA4 son formatos habituales), tiene una marca independiente de las cabeceras. Una solicitud cuya cabecera User-Agent dice Chrome pero cuyo handshake se parece al de una biblioteca de Python destaca por esa incoherencia. El detalle del cálculo y sus límites están en Huella TLS y JA3.
RFC 9113 obliga a que las dos partes envíen una trama SETTINGS al comienzo de una conexión HTTP/2. Los valores de esa trama y el orden en que se envían las pseudocabeceras (:method, :authority, :scheme, :path) son distintos en cada pila HTTP. El valor de la capa está en que no depende de lo declarado; su riesgo es que los empleados que están detrás de equipos de seguridad corporativos, que abren y rehacen el tráfico TLS, llegan con un handshake que no concuerda con su navegador.
La capa de cabeceras: User-Agent y coherencia
Las cabeceras son lo que el cliente declara sobre sí mismo: User-Agent indica el navegador y el sistema operativo, las cabeceras de Client Hints (la familia Sec-CH-UA) repiten la misma información de forma estructurada y Accept-Language anuncia la preferencia de idioma. Nadie verifica esa declaración; cualquier programa puede escribir el valor que quiera. Cómo se lee esa cadena está en ¿Qué es el User-Agent?.
Por eso el sistema anti-bot no mira la declaración en sí, sino su encaje con las demás capas. ¿La versión de navegador declarada envía de verdad ese conjunto de cabeceras y en ese orden? ¿La preferencia de idioma cuadra con el país de la IP y la zona horaria con la que informa el navegador? Ninguna incoherencia es prueba por sí sola (quien vive en el extranjero se conecta desde otro país con el navegador en su idioma), pero cada una baja un poco la puntuación.
La capa del navegador: señales de JavaScript
Cuando la página se abre, la protección accede a un terreno que no veía desde el servidor: el navegador mismo. Un script añadido a la página lee las medidas de la pantalla, las fuentes instaladas, el resultado de dibujo del hardware gráfico, la zona horaria y las API admitidas; la combinación de esos valores es la huella del navegador. La huella sirve para dos cosas: reconocer al mismo cliente aunque cambie la IP y comprobar si el entorno declarado es real. Un entorno que dice ser Chrome sobre Windows pero informa de un controlador gráfico que solo existe en servidores Linux se cae en esa prueba. La lista completa de señales está en Huella del navegador.
Los clientes que nunca ejecutan el script (bibliotecas HTTP como cURL o Python Requests) no producen datos en esta capa. En un punto final de API eso es lo esperable; en una página HTML, que el resultado del script no llegue nunca basta para que el cliente no cuente como navegador.
¿Qué es un navegador headless y cómo lo reconocen los sitios?
Un navegador headless es un navegador real que funciona sin abrir ventana en pantalla: carga la página, ejecuta el JavaScript y entrega el resultado al código. Se usa en pruebas de extremo a extremo, en la generación de PDF, en la supervisión de sitios y en la recogida de datos permitida; las herramientas habituales son Playwright, Puppeteer y Selenium. Cuándo hace falta lo contamos en Páginas estáticas y dinámicas, y la diferencia entre las dos herramientas en Playwright y Selenium.
Los sitios reconocen un navegador dirigido por automatización por tres marcas:
| Señal | ¿De dónde viene? | ¿Cómo la interpreta el dueño del sitio? |
|---|---|---|
Que navigator.webdriver valga true | Estándar W3C WebDriver: si el navegador se controla a distancia, la bandera se activa | Es la declaración del propio navegador; la automatización de pruebas también la lleva |
| Diferencias de entorno | Efectos secundarios de funcionar sin ventana: medidas de la ventana, lista de complementos, algunas API | Débil por sí sola, significativa junto a otras señales |
| Forma de interacción | Eventos producidos por código y no por una mano humana | Se traslada a la capa de comportamiento |
La bandera de la primera fila no es un truco de detección, sino parte del estándar: el texto del W3C la define como la manera normalizada de que el navegador comunique al documento que lo está controlando WebDriver.
El peso de la segunda fila ha bajado con el tiempo. Según la documentación headless de Chrome, el modo headless antiguo era una aplicación aparte que no compartía el código del navegador; desde Chrome 132 solo se ofrece como un binario independiente llamado chrome-headless-shell, mientras que --headless ejecuta el código real de Chrome. A medida que las diferencias de entorno se redujeron, el peso se desplazó al comportamiento.
La lección para el dueño del sitio es esta: detectar un navegador headless no es detectar mala intención. Tu equipo de calidad y tu servicio de supervisión llevan las mismas marcas; separar ese tráfico con una IP conocida o una regla de solicitud firmada hace menos daño que mirar la bandera y bloquear en bloque.
La capa de comportamiento: ritmo y patrón de navegación
Las capas anteriores miran de quién viene la solicitud; la de comportamiento mira qué hace. La medida más simple es el ritmo: cuántas solicitudes llegan en un periodo dado desde la misma dirección, sesión o cuenta. Cuando se pasa el límite, el servidor devuelve 429 Too Many Requests. Sobre qué se llevan los contadores y cómo funcionan los algoritmos de ventana fija, ventana deslizante y token bucket lo contamos en 429 Too Many Requests.
Más allá del ritmo está el patrón de navegación. Una persona pasa de la portada a una categoría y de ahí a un producto, y su navegador descarga también las imágenes y las hojas de estilo; una sesión que recorre solo direcciones de producto a intervalos constantes, sin pedir ni un archivo secundario, se ve distinta. Las solicitudes a enlaces ocultos que un visitante nunca podría ver también son señal de esta capa (trampas honeypot). Los sistemas más nuevos vigilan la interacción dentro de la página (movimiento del cursor, si la pestaña está visible) a lo largo de la sesión; un ejemplo actual lo analizamos en Cloudflare Precursor.
Esta capa dice poco sobre una solicitud y mucho sobre cien. Su precio es el retraso: hacen falta datos acumulados para decidir.
Cómo se convierten las señales en decisión: puntuación y verificación
Ninguna capa dice por sí sola «esto es un bot». Sus resultados se unen en una puntuación. La documentación de Cloudflare sobre la puntuación de bots es un ejemplo claro de este enfoque: cada solicitud recibe un valor entre 1 y 99, donde 1 indica bastante certeza de que la solicitud era automática y 99 de que venía de una persona; por debajo de 30 se considera «probablemente automática». Según la documentación, alimentan esa puntuación las reglas heurísticas, el aprendizaje automático, la detección de anomalías y las comprobaciones de JavaScript.
La puntuación no es una acción. La acción la fija la regla que escribe el dueño del sitio, y las opciones forman una escalera:
- Permitir. La puntuación es alta o la solicitud viene de un bot verificado.
- Limitar la velocidad. La solicitud se acepta y se recorta su frecuencia.
- Mostrar verificación. Al navegador se le presenta una prueba invisible o al visitante una casilla; qué significa esa pantalla del lado del visitante está en Cloudflare «Verify You Are Human».
- Bloquear. La solicitud se rechaza con un
403o con una página de bloqueo.
La escalera se ajusta según el punto final: en una página de blog, dejar pasar una solicitud de baja puntuación cuesta unos kilobytes de tráfico; en la página de acceso, cuesta una cuenta robada.
El coste del falso positivo: ¿qué pasa si un visitante real se toma por un bot?
La detección de bots tiene dos tipos de error. Tomar un bot por una persona (falso negativo) vuelve como carga, cuentas falsas o contenido robado. Tomar a una persona por un bot (falso positivo) es pérdida de ingresos: el cliente que se rinde ante la pantalla de verificación, el pago que no se completa. El segundo error no aparece en los informes, porque el visitante bloqueado no llega nunca a la herramienta de analítica.
Sus fuentes principales son estas:
- Direcciones IP compartidas. Los abonados de operadores móviles y quienes usan redes de residencias, cafeterías y empresas pagan por el comportamiento de otros.
- VPN y herramientas de privacidad. Como la dirección parece de un centro de datos, la capa de red baja la puntuación (VPN o proxy detectado).
- Bloqueadores de scripts, herramientas de accesibilidad, navegación con teclado. La capa del navegador no recibe datos y la de comportamiento no encuentra el patrón que espera.
Del lado del visitante, eso se traduce en mensajes como «detectado como bot» o «se ha detectado tráfico inusual»: dos ejemplos los tratamos en error «tráfico inusual» de Google y «Sorry, You Have Been Blocked».
La conclusión práctica: muestra una verificación antes de bloquear y vigila qué proporción la supera. Cada solicitud que pasa es constancia de que la regla estaba deteniendo a la persona equivocada.
Bots verificados: ¿cómo reconoce un sitio a un bot bueno?
Escribir «Googlebot» en la cabecera User-Agent es cosa de una línea; por eso a un bot bueno se le reconoce por su prueba y no por su declaración. Hoy se usan tres métodos.
Verificación por DNS inverso. La documentación de Google sobre verificar a Googlebot da el método: se hace una consulta DNS inversa para la IP del registro, se comprueba que el nombre devuelto está bajo googlebot.com, google.com o googleusercontent.com y después ese nombre se resuelve de nuevo a una IP y se confirma que coincide con la primera dirección.
Listas de bots verificados. Los servicios de gestión de bots hacen esa comprobación en nombre del dueño del sitio; la documentación de Cloudflare sobre bots verificados enumera dos condiciones: que el bot se identifique con honestidad (con una firma criptográfica, una lista de IP publicada o DNS inverso) y que no abuse de esa confianza, es decir, que respete robots.txt y mantenga un ritmo de solicitudes razonable. No respetar la directiva crawl-delay o generar tráfico que no encaje con el propósito declarado son motivos para salir de la lista.
Solicitudes firmadas (Web Bot Auth). En el enfoque más nuevo el bot firma cada solicitud con su clave privada, publica su clave pública en su propio dominio y el sitio verifica la firma. El estándar de base es RFC 9421 HTTP Message Signatures, y para adaptarlo a los bots se creó en el IETF un grupo de trabajo Web Bot Auth. El grupo considera insuficientes las soluciones actuales, como las listas de IP, las cadenas de User-Agent y las claves de API compartidas; la identidad del agente que hace solicitudes en nombre de un usuario entra en el alcance, y la del usuario final que está detrás del agente queda fuera. Las cabeceras de la firma las contamos en Por qué los agentes de compra con IA acaban bloqueados.
En los tres casos la identidad se construye con una prueba (registro DNS, propiedad de la IP, clave privada) y no con lo que declara el cliente.
Si operas una automatización, ¿cuál es la vía legítima?
El mapa lleva al mismo resultado para quien opera una automatización: el sistema está montado para dejar paso al tráfico que se identifica y se comporta con mesura.
- Usa la API oficial si existe. El acceso se apoya en un acuerdo y la detección de bots no entra en juego.
- Respeta robots.txt. Su formato y cómo comprobarlo en Python están en ¿Qué es el archivo robots.txt?.
- Limita tu ritmo por sitio. Respeta las respuestas
429yRetry-After. - Ponle nombre a tu bot. El nombre del bot y una dirección de contacto en el
User-Agentle dan al administrador la opción de escribirte en lugar de bloquearte. - Pide permiso para accesos de gran volumen. Si operas un rastreador que presta un servicio público, solicita entrar en los programas de bots verificados.
- Para cuando veas una pantalla de verificación. Esa pantalla es la preferencia clara del sitio; no recomendamos los servicios de resolución de CAPTCHA.
La puesta en práctica de estos pasos (concurrencia, solicitudes condicionales, la diferencia entre rotación y sesión fija) está con código probado en Cómo recoger datos sin acabar bloqueado.
Casos de uso: ¿quién debería conocer este mapa y para qué?
- Equipos de marketing y analítica: para separar el origen de los picos de tráfico y proteger el presupuesto publicitario del clic falso. El lado publicitario está en fraude de clics en Google Ads y en nuestra página de solución de verificación de anuncios.
- Equipos de datos: para entender qué comportamiento parece sospechoso y por qué al recoger datos de páginas públicas; el planteamiento general está en nuestra página de solución de extracción de datos y, para contenido que cambia según la ubicación, se usa un Proxies residenciales.
- Equipos de calidad y pruebas: la protección contra bots de tu propio sitio puede detener tu propia automatización de pruebas. Saca el tráfico de pruebas por una dirección fija y escribe una regla de permiso para ella; para esto se usa un Proxies ISP o tu propia IP estática (solución de pruebas de aplicaciones).
- Equipos de protección de marca: los rastreos de tiendas falsas y anuncios de imitación también son automatización y pasan por las mismas capas; el alcance está en nuestra página de solución de protección de marca.
Errores frecuentes
- Bloquear por una sola señal. Una regla que solo mira el ASN de un centro de datos o la bandera
navigator.webdriverdetiene también los servicios de supervisión y tus propias pruebas. - Fiarse del
User-Agenty abrirle la puerta a «Googlebot». La declaración no es prueba; usa DNS inverso o una lista de bots verificados. - Poner el mismo umbral en todos los puntos finales. La página de acceso y una entrada de blog no tienen el mismo riesgo.
- No medir los falsos positivos. Si no se sigue qué proporción de solicitudes supera la verificación, no se sabe a quién está deteniendo la regla.
- Del lado de la automatización: ver el bloqueo como un acertijo técnico. La pantalla de verificación no es un error, sino la respuesta del dueño del sitio; revisa tu ritmo, tu alcance y tu situación de permiso.
Guía de decisión
| Tu situación | Recomendación |
|---|---|
| Tienes tráfico sin explicación en tu sitio | Reparte los registros por ASN y punto final; primero límite de velocidad, después verificación |
| Ves intentos masivos de contraseña en la página de acceso | Umbral bajo y verificación en ese punto final; límite de intentos por cuenta |
| Temes bloquear por error a los bots de buscadores | Lista de bots verificados o verificación por DNS inverso |
| Los clientes se quejan de la pantalla de verificación | Mira qué proporción la supera y relaja el umbral |
| Tu propia automatización de pruebas acaba bloqueada | Saca las pruebas por una dirección fija y escríbele una regla de permiso |
| Recoges datos públicos con regularidad | Primero la API; si no, robots.txt, ritmo bajo e identidad de bot con nombre |
| Operas un rastreador o agente de servicio público | Programa de bots verificados, solicitudes firmadas |
| Como visitante ves el mensaje «bot detectado» | Prueba con la VPN y las extensiones apagadas; si sigue, tu red sale por una dirección compartida |
Preguntas frecuentes
¿Qué es un anti-bot y para qué sirve?
Un anti-bot es la capa de software que clasifica el tráfico automático que llega a un sitio y, según las reglas del dueño, lo permite, lo ralentiza, le pide verificación o lo bloquea. Su objetivo no es parar todos los bots, sino separar la automatización dañina de los bots que se quieren, como los de los buscadores.
¿Qué significa «detectado como bot»?
Significa que la capa de protección del sitio le ha dado una puntuación baja a tu solicitud; no quiere decir que hayas usado un programa. Las causas más frecuentes son una VPN o una IP compartida, extensiones que bloquean scripts y abrir muchas páginas en poco tiempo. El primer paso es apagar la VPN y las extensiones y recargar la página.
¿Por qué Selenium y Playwright caen en la detección de bots?
Estas herramientas dirigen el navegador con WebDriver o un protocolo parecido, y el estándar obliga al navegador a anunciarlo con la bandera navigator.webdriver. A eso se suman las diferencias de entorno y un ritmo que no se parece a la interacción humana. Si estás probando tu propio sitio, la solución es escribir una regla de permiso para el tráfico de pruebas en el lado de la protección.
¿La detección de bots solo mira la dirección IP?
No. La IP es la señal más temprana, no la única: el handshake TLS, la coherencia de las cabeceras, el entorno del navegador y el comportamiento durante la sesión se evalúan por separado. Por eso cambiar solo la IP no afecta a las demás capas.
¿Cómo detecto tráfico de bots en Google Analytics?
Un pico repentino desde una sola ciudad o red, un tiempo de interacción cercano a cero y sesiones sin relación con las conversiones son marcas típicas. Para una separación segura no basta la herramienta de analítica; revisa la misma franja horaria en los registros del servidor o de la CDN, desglosada por IP, ASN y User-Agent.
¿Por dónde se empieza para proteger de bots un sitio pequeño?
Empieza con tres pasos: pon límites de velocidad en los puntos finales caros como acceso, registro y búsqueda, activa la protección básica contra bots de tu CDN en modo verificación en lugar de bloqueo, y comprueba que los bots de los buscadores pasan por la lista de verificados.
En resumen
La detección de bots no es un muro, sino una serie de mediciones puestas una detrás de otra: la capa de red lee la reputación y el ASN de la dirección, la de protocolo el rastro de TLS y HTTP/2, la de cabeceras la coherencia de lo declarado, la del navegador la autenticidad del entorno y la de comportamiento el patrón de navegación. Todo se une en una puntuación y el dueño del sitio elige permitir, limitar la velocidad, verificar o bloquear según el riesgo del punto final. Como cada capa se equivoca con usuarios reales, un sistema bien montado verifica primero y bloquea después. Los bots buenos demuestran su identidad con DNS inverso, listas de bots verificados y firmas basadas en RFC 9421; para quien opera una automatización, la vía duradera pasa por la API oficial, robots.txt, un ritmo mesurado y una identidad abierta. Para tus trabajos de recogida de datos conforme a las reglas, encontrarás los tipos de proxy en nuestros servicios de proxy.
