Cómo detectar las trampas de detección de bots y evitarlas

¿Le gustaría probar Octo Browser con descuento?
Use el código promocional OCTOSCRAPER para obtener un 30% de descuento en cualquier suscripción. Esta oferta solo es válida para nuevos usuarios.

Trampas de honeypot invisibles: enlaces y campos ocultos

Uno de los trucos más comunes utilizados para capturar bots son los llamados campos honeypot: elementos de página especialmente preparados y ocultos. Una persona real nunca los verá ni hará clic en ellos, pero un bot sencillo podría hacerlo.

Un ejemplo básico es un enlace invisible (creado con estilos CSS como display: none o posicionado fuera de la pantalla) que conduce a una URL de trampa especial. Un usuario normal no hará clic en dicho enlace porque ni siquiera sabe que existe, pero un scraper que rastrea sistemáticamente cada enlace lo seguirá y se expondrá. Tan pronto como el script carga esa página, el servidor puede añadir su dirección IP a una lista negra y bloquear el acceso futuro.

Una idea similar se aplica a los formularios web. Se añade un campo oculto a un formulario (por ejemplo, un formulario de registro o de contacto). Un humano no lo verá, pero un bot puede encontrarlo y rellenarlo. Estos campos honeypot señalan la actividad de los bots. Si un formulario enviado contiene texto en un campo oculto, es una señal de alerta. La solicitud se rechaza o la sesión se marca como tráfico de bots. En cualquier caso, el trabajo posterior se vuelve imposible.

Cómo evitarlo: en primer lugar, al rastrear páginas, analice las propiedades de los elementos antes de hacer clic o navegar por ellos. Compruebe los estilos de los enlaces: si un enlace o botón está marcado como invisible (display:none, opacity: 0, tamaño 1×1 píxel, etc.), ignórelo. Del mismo modo, antes de enviar un formulario, asegúrese de no haber rellenado ningún campo oculto (se pueden identificar por nombres o atributos inusuales como aria-hidden, tabindex="-1", estilos de ocultación, etc.). Los principiantes pueden pensar que tales detalles son insignificantes, pero esta es una de las formas más fáciles de ser detectado. Un solo clic innecesario en un enlace trampa es suficiente para exponer a su bot.

Naturalmente, los propietarios de sitios web y servicios conocen las contramedidas, y los bots modernos ya pueden detectar elementos honeypot por características CSS sospechosas, por lo que este método a menudo se combina con otras técnicas de protección. Aun así, filtrar enlaces y campos invisibles es un requisito obligatorio para cualquier parser profesional.

CAPTCHAs y desafíos de JavaScript

Una forma más obvia de evitar el acceso automatizado es el CAPTCHA, esas molestas ventanas emergentes con selección de imágenes, casillas de verificación de "No soy un robot" y variaciones similares. Esta es una forma directa y efectiva de distinguir a los humanos de los scripts o bots. A diferencia de los honeypots ocultos, los CAPTCHAs requieren explícitamente completar una tarea que se espera que un bot no resuelva. En la práctica, los CAPTCHAs sencillos se pueden omitir con relativa facilidad porque existen muchas soluciones de código abierto gratuitas, mientras que los más complejos requieren servicios de resolución de terceros.

Si un bot encuentra un CAPTCHA, hay pocas opciones: o bien resolverlo automáticamente a través de un servicio de terceros o cambiar el hilo y cambiar a otro perfil. La resolución de CAPTCHA de pago ralentiza el scraping y aumenta los costes. Otra estrategia es evitar activar el CAPTCHA por completo, por ejemplo, reduciendo la intensidad de las solicitudes para evitar activar las medidas de protección o utilizando cachés de motores de búsqueda (como Google Cache) para obtener datos.

Una categoría separada es el desafío de JavaScript. Muchos sitios web (especialmente aquellos que están detrás de la protección de una CDN como Cloudflare) pueden devolver una página de verificación en lugar de contenido cuando el tráfico parece sospechoso. Esta página ejecuta código JS del lado del cliente que calcula un token, comprueba el entorno del navegador, establece cookies y solo entonces redirige al visitante al contenido real. El objetivo es confirmar que la solicitud proviene de un navegador real con soporte para JS en lugar de un cliente HTTP sencillo. Un bot que no pueda ejecutar JavaScript fallará esta prueba y no obtendrá acceso.

Cómo evitarlo: si sabe que un sitio web de destino muestra CAPTCHAs, decida de antemano cómo los evitará, tanto técnica como financieramente. Si es imposible evitar el CAPTCHA (algunos sitios web lo muestran por defecto), deberá integrar una solución de resolución de terceros. Para desafíos de JS, la solución alternativa más obvia es utilizar un navegador headless que ejecute el escenario requerido. Las herramientas de automatización populares (Puppeteer, Playwright, etc.) permiten ejecutar un navegador en segundo plano, pero no se olvide de la suplantación, ya que las huellas de automatización siempre deben ocultarse.

Ignorar la verificación de JS no es una opción: si existe, debe pasarla o no obtendrá los datos. Asegúrese de que su scraper cargue los scripts relacionados, los ejecute y almacene las cookies o tokens para solicitudes posteriores.

Análisis de comportamiento: velocidad, secuencia, interacciones

Incluso si un bot supera obstáculos directos como los CAPTCHAs y otros métodos antibot visibles, los patrones de comportamiento no humanos aún pueden ser fatales. Un usuario típico pasa varios segundos en la página de un producto, se desliza, hace clic en imágenes y luego navega más allá. Un script, sin embargo, puede cargar páginas instantáneamente y en un orden perfectamente repetible. Los sitios web modernos rastrean tales anomalías. Las velocidades de navegación extremadamente altas, los intervalos sospechosamente regulares entre solicitudes y patrones similares indican claramente la automatización.

Otro marcador es un orden de navegación inusual; por ejemplo, rastrear URLs alfabéticamente o siguiendo estrictamente un mapa del sitio, lo cual los visitantes reales rara vez hacen. Un indicador simple es la ausencia de interacciones similares a las de los humanos. Si los registros muestran una sesión que ve 100 páginas sin un solo desplazamiento o movimiento del ratón, es probable que la sesión sea tráfico de bots.

También existen trampas basadas en el tiempo. Los formularios pueden imponer un tiempo mínimo de finalización. La mayoría de los humanos tardan al menos 5 o 10 segundos en introducir las credenciales, mientras que un bot puede enviarlas en milisegundos. Si un formulario se envía casi instantáneamente, existe una alta probabilidad de automatización, y el sitio web puede rechazar la solicitud. Un enfoque similar se aplica a la navegación: avanzar demasiado rápido al siguiente paso, especialmente uno complejo como el pago, despierta sospechas en los sistemas antibot.

Cómo evitarlo: el principio principal es imitar el comportamiento del usuario real. Introduzca aleatoriedad y patrones naturales en el flujo de trabajo de su scraper.

En primer lugar, no busque la velocidad máxima de scraping. Si la velocidad no es crítica, trabajar un poco más despacio pero con más cuidado es más seguro. Inserte pausas entre las solicitudes, no fijas, sino aleatorias dentro de un rango. Añada retrasos en cada página para simular el tiempo de lectura.

En segundo lugar, evite secuencias de navegación estrictas. Si es posible, introduzca la aleatoriedad en el orden de scraping (por ejemplo, cambie el orden de las secciones o elija enlaces al azar en una página en lugar de iterar secuencialmente).

En tercer lugar, añada señales de interacción natural en escenarios headless. Las secuencias de comandos avanzadas pueden incluir desplazamientos, movimientos del cursor, apertura de elementos de interfaz y pequeñas micropausas entre pasos. Estas acciones no afectan directamente a la recopilación de datos, pero hacen que el flujo de trabajo sea más humano, especialmente en páginas largas y flujos de varios pasos (inicio de sesión → selección → pago), donde un ritmo perfectamente consistente parece poco natural.

Considere también la perspectiva del sitio web: muchos sistemas combinan el análisis de comportamiento con la telemetría y la analítica web. Los rastreadores de una página pueden registrar eventos de interacción y el tiempo de la sesión. Si los registros muestran una sesión vacía sin señales típicas, eso por sí solo parece sospechoso. Por lo tanto, es importante evaluar no solo las acciones de su scraper, sino también qué datos de sesión se generan realmente y cómo se interpretan en el lado de la monitorización.

Límites de volumen y tasa de solicitudes

Otro criterio obvio utilizado para distinguir una máquina de un humano es la frecuencia de las solicitudes. Incluso el usuario más rápido no puede enviar docenas de solicitudes por segundo, pero un script sí. Es por eso que se implementan límites en el lado del servidor: por ejemplo, no más de N solicitudes desde una sola dirección IP por minuto. Si se supera el límite, se activa un bloqueo temporal o permanente. A nivel del servidor web o CDN, esto se implementa rastreando el número de solicitudes y filtrando las ráfagas que superan el umbral. Las cifras exactas dependen de la política del sitio web: en algunos lugares 5 solicitudes por segundo pueden ser aceptables, mientras que en otros incluso 1 solicitud por segundo se considerará excesiva. Esto es fácil de implementar: con Nginx, puede configurar un límite de 1 solicitud por segundo por IP y rechazar cualquier cosa por encima de eso.

Además de la frecuencia, también se controla la concurrencia. Es poco probable que un usuario habitual abra 20 páginas de un sitio web simultáneamente en pestañas diferentes, mientras que un scraper puede generar fácilmente muchos hilos paralelos. Esto también se rastrea: demasiadas sesiones simultáneas desde una dirección son motivos suficientes para sospechar de una red de bots o scraper.

Cómo evitarlo: en primer lugar, limite el nivel de concurrencia en su script. Sí, es muy tentador paralelizar el rastreo de un catálogo en 50 hilos y recopilar datos en un minuto, pero en el 99% de los casos esto atraerá de inmediato atención no deseada. Es mejor trabajar con pocos hilos (o incluso uno) si ve que el sitio web es sensible a la carga.

En segundo lugar, encargue de la rotación de sus direcciones IP. La mayoría de los sitios web registran la IP de cada visitante y bloquean toda la dirección cuando se detecta actividad sospechosa. Es por eso que el uso de proxies es una práctica estándar para un scraping serio. Tiene sentido usar la rotación de IP: después de un cierto número de solicitudes o al cambiar de sección, cambie la dirección del punto de salida. Idealmente, use siempre proxies residenciales o móviles. Es importante configurar el scraper para que una IP no realice demasiadas solicitudes consecutivas. Por ejemplo, envíe no más de 5 a 10 solicitudes desde una dirección, luego cambie. Si su grupo de proxies es limitado, al menos intente alternarlos y mantener pausas.

Además, monitorice siempre las cabeceras de respuesta y los códigos de estado de sus solicitudes. Si comienza a recibir el código HTTP 429 Too Many Requests o ve algo como "Demasiadas solicitudes, inténtelo de nuevo más tarde" en el contenido de la página, esta es una señal clara de que se ha activado el límite de solicitudes. Tal situación requiere reducir la velocidad de scraping, aumentar el número de proxies o utilizar otras técnicas. Como opción, si el límite se establece por dirección IP y el sitio web es accesible a través de HTTP y permite cambiar User-Agent y Referrer sin comprobaciones adicionales, rotarlos puede ayudar.

En general, la regla principal es no destacar: cuanto más se mezcle sin problemas en el tráfico de fondo de los usuarios habituales, más tiempo funcionará su scraper sin bloqueos.

Cabeceras y huellas digitales del navegador

Los sitios web pueden detectar un scraper en la etapa de conexión analizando los parámetros técnicos de la solicitud. Cada solicitud HTTP lleva un conjunto de cabeceras (User-Agent, Accept, Accept-Language, Cookie, etc.), que juntas forman un perfil de navegador. Para los navegadores habituales, estos perfiles son bastante predecibles: por ejemplo, al visitar un sitio web con Chrome, envía un conjunto característico de cabeceras que comienzan con User-Agent: Mozilla/5.0 … Chrome/versión …, además de una lista de idiomas compatibles (Accept-Language), banderas de obtención (cabeceras Sec-Fetch-*), y así sucesivamente. Un bot, sin embargo, puede enviar un conjunto de cabeceras inusual o incompleto. Muchos sitios web bloquean instantáneamente solicitudes con cadenas de User-Agent sospechosas como Scrapy, curl, Wget, Python y similares, a nivel de firewall. E incluso si no se le bloquea por enviar tales cadenas, el hecho en sí se considerará como parte de la puntuación de riesgo general.

Al reemplazar el User-Agent con una cadena de navegador común, aún puede fallar en los detalles. Por ejemplo, Headless Chrome solía revelarse porque la cadena de User-Agent contenía la palabra HeadlessChrome. Otro ejemplo: el bot no envía la cabecera Accept-Language (los navegadores reales siempre envienen preferencias de idioma).

Otro indicador: el orden de las cabeceras o sus valores no coinciden con el navegador declarado. Los sistemas antibot mantienen grandes bases de datos de huellas digitales de navegadores: plantillas con diferentes cabeceras y valores de diferentes versiones de Chrome, Safari y Firefox. Si finge ser Chrome 120+ y envía el User-Agent correspondiente, pero no incluye las cabeceras típicas de Chromium UA Client Hints modernas (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform), o están en el formato incorrecto, o una solicitud de navegación activada por un clic del usuario no incluye Sec-Fetch-User: ?1 mientras que hay otras cabeceras Sec-Fetch-* presentes, tales pequeñas inconsistencias pueden revelar la automatización (este es solo un ejemplo ilustrativo).

Además, más allá de las cabeceras HTTP, el navegador puede revelarse a través del objeto navigator y el entorno de JS. Los modos headless suelen incluir una propiedad navigator.webdriver, que normalmente es true para navegadores automatizados. Los sitios web pueden entonces ejecutar un script simple en el lado del cliente: if (navigator.webdriver) { /* Bot detectado */ } — y este enfoque simple es lo suficientemente bueno como para atrapar a los principiantes. Otros comprueban objetos específicos dejados por Selenium o Playwright. Por ejemplo, Playwright inserta ciertas variables de servicio en window (__playwright__binding__ y otras), y los scripts de la página pueden buscar tales signos de control externo.

Comprobaciones más avanzadas incluyen pruebas de Canvas API o WebGL, donde se renderiza una imagen oculta y se recopila una huella digital de canvas que puede coincidir con la firma de un emulador típico.

En resumen, hay muchas comprobaciones disponibles para los sitios web, y la suplantación de entorno se puede detectar incluso a través de discrepancias menores en la implementación de JS.

Cómo evitarlo: disfrácese de un dispositivo/navegador real tanto como sea posible. Establezca siempre un User-Agent realista que corresponda a un navegador popular y manténgalo actualizado. Pero una cabecera no es suficiente: ajuste las demás también. Añada Accept-Language (teniendo en cuenta la región de la IP), Accept con tipos de contenido típicos para un navegador común, Connection, Upgrade-Insecure-Requests, cabeceras Sec-Fetch-*, y así sucesivamente. La forma más fácil es comprobar qué cabeceras envía su navegador al visitar el sitio web de destino (a través de las herramientas de desarrollo o un proxy) y emularlas. Preste atención a la coherencia: si afirma ser Chrome en Windows, debe tener un User-Agent orientado a Windows y, cuando sea necesario, una cabecera Sec-CH-UA-Platform: "Windows".

Si trabaja con un navegador headless, use bibliotecas o configuraciones que habiliten automáticamente el enmascaramiento de automatización (por ejemplo, Puppeteer tiene el paquete puppeteer-extra-plugin-stealth, que deshabilita navigator.webdriver y otros marcadores reveladores, o versiones modificadas de playwright/puppeteer de rebrowser que ocultan muchas debilidades estándar de tales bibliotecas). Si está creando un scraper de bajo nivel, modifique manualmente navigator a través de DevTools Protocol para establecer propiedades que coincidan con un navegador real.

Por supuesto, no hay necesidad de emular absolutamente todo hasta el ruido aleatorio de Canvas. La mejor práctica es comenzar con lo básico: cabeceras y JS simples. No envíe cadenas obviamente sospechosas, actualice regularmente las plantillas de cabecera para que coincidan con los navegadores actuales, habilite la emulación de interacciones menores y, si es posible, pruebe su bot contra herramientas de antidetección. Herramientas como BrowserScan o FingerprintJS pueden mostrar qué señales expone su script.

Otros trucos: desde “laberintos infinitos” hasta servicios de terceros

Además de lo anterior, hay trampas más exóticas que vale la pena conocer. Algunos recursos crean deliberadamente estructuras de enlaces “infinitas”: una especie de laberinto para un scraper.

Un ejemplo clásico son las páginas de calendario infinitas generadas dinámicamente o las URLs parametrizadas que conducen a bucles. Un bot sin las condiciones de parada adecuadas puede quedarse atascado intentando atravesar un flujo infinito de enlaces. Como resultado, desperdicia sus recursos y también se revela a los sistemas antibot a través de un comportamiento inusual. Para los usuarios reales, tales enlaces suelen ser inalcanzables, pero un bot puede caer en esa trampa.

Cómo evitarlo: en primer lugar, analice siempre la verosimilitud de los datos recopilados. Si su scraper siguió de repente una cadena de enlaces a algún lugar a donde no se suponía que debía ir y descargó toneladas de textos que parecen frases aleatorias, es posible que haya entrado en un laberinto. Es útil implementar una lógica de detección de bucle: rastrear las URLs visitadas, limitar la profundidad de rastreo, verificar que los nuevos enlaces pertenezcan al mismo dominio o sección que necesita.

En segundo lugar, considere siempre el contexto: si realiza scraping, por ejemplo, en un sitio de reseñas y el bot comienza de repente a descargar páginas con texto generado por IA claramente no relacionado o incoherente, esta es una razón para ser cauteloso y detener esa sesión.

Tenga también en cuenta que los servicios de terceros también ayudan a los sitios web a detectar bots. Productos como Cloudflare Bot Management, Datadome, PerimeterX y otros se especializan en detectar tráfico automatizado. Utilizan una combinación de métodos que van desde el análisis de comportamiento y la toma de huellas digitales hasta bases de datos de bots conocidos e incluso aprendizaje automático para identificar visitantes inusuales.

Si su bot encuentra un potente sistema antibot, la tarea se vuelve más compleja, ya que la detección puede ocurrir en función de una combinación de pequeñas señales. En tales casos, se aplica todo lo discutido anteriormente, y también debe tener en cuenta las constantes mejoras de reglas en el lado del scraping. A veces resulta más barato cambiar de táctica de scraping o limitar el volumen de solicitudes a un nivel que no active los sistemas de protección. Al usar proxies, puede intentar imitar a diferentes usuarios reales y cambiar no solo la dirección IP sino también la geolocalización, los agentes de usuario y el tiempo de solicitud (imitando visitas a diferentes horas del día en lugar de una actividad continua sin interrupciones).

Conclusión

Como puede ver, no hay un único botón mágico que elimine de forma permanente el riesgo de bloqueo. Necesita una combinación de métodos técnicos y una ejecución cuidadosa para un scraping exitoso:

• Detecte e ignore los elementos honeypot: antes de hacer clic en un enlace o rellenar un campo, asegúrese de que el elemento no esté oculto a la vista humana. No siga URLs sospechosas y no rellene campos de formulario invisibles.

• Imite a un usuario real: use cabeceras reales y valores típicos de navegadores normales (User-Agent, Accept-Language, etc.). Siempre que sea posible, ejecute el scraping a través del núcleo del navegador de navegadores antidetección para pasar las comprobaciones de JS y asegurar un entorno realista (navigator, cookies, localStorage, etc.).

• Limite la velocidad y la concurrencia: configure retrasos y pausas entre solicitudes, use intervalos aleatorios. No supere los límites de solicitudes, escale gradualmente y monitorice las reacciones del sitio web (códigos HTTP 429, CAPTCHAs, etc.).

• Rote las direcciones IP y los identificadores de sesión: use un grupo de proxies o VPN, alterne las IPs, especialmente para el rastreo a gran escala. Asegúrese de que no se use una sola IP con demasiada frecuencia. Opte siempre por IPs residenciales, ya que son menos sospechosas para los sistemas antibot.

• Introduzca aleatoriedad en su comportamiento de scraping: emule las acciones del usuario, por ejemplo, pequeños desplazamientos, movimientos del ratón, tiempo dedicado a leer una página. Evite rutas totalmente secuenciales y varíe los patrones de acción para no demostrar un algoritmo rígido.

La confrontación en el web scraping continúa, ya que los sitios web inventan nuevos métodos de detección y los desarrolladores de bots buscan formas de evitarlos. En este juego, el ganador es el que es más atento e inventivo. Deje que su bot sea exactamente eso: cuidadoso, flexible y humanamente impredecible.