El web scraping es la recopilación automatizada de datos de sitios web: precios de la competencia, contenido, contactos, anuncios, existencias. En sí mismo es legal cuando se trata de datos de acceso público, pero se convierte en un problema cuando sobrecarga la infraestructura, roba contenido original, alimenta el dumping o sirve para preparar fraudes (ataques de fuerza bruta contra cuentas, acaparamiento de productos escasos). Según distintas estimaciones, el tráfico automatizado supone hoy cerca de la mitad de todo el tráfico de internet, por lo que la protección frente al scraping no deseado se ha convertido en una industria propia.
La idea central sobre la que se sostiene toda la protección moderna: es posible distinguir un programa de una persona, y un cliente automatizado de otro, incluso antes de que el servidor entregue un solo byte de contenido. La decisión de bloqueo se toma a menudo en los primeros milisegundos de la conexión. A continuación — qué se monitoriza exactamente, con qué métodos se defienden los sitios, en qué conviene fijarse, cómo esquivan los scrapers las restricciones y qué soluciones existen ya en el mercado.
Qué parámetros se monitorizan
Los sistemas modernos no se fían de un único indicio. Reúnen decenas de señales en distintos niveles de la pila de red y las condensan en una única «puntuación de confianza» (trust score / bot score). Cuanto más baja es la puntuación, mayor es la probabilidad de recibir un captcha, una ralentización o un bloqueo. A grandes rasgos, las señales se reparten en varias capas.
1. Nivel de red e IP
La capa más básica. Se analiza la reputación de la dirección IP, su pertenencia (ASN) y el tipo de red. Las peticiones desde centros de datos de AWS, GCP o Azure destacan al instante — los usuarios normales no navegan así. Se vigilan la frecuencia y el ritmo de las peticiones de una misma dirección (rate limiting), los picos bruscos y los accesos a URL atípicas. Los buenos sistemas mantienen sus propias bases de IP «sucias», detectadas cometiendo abusos en toda su red.
2. Huella TLS (JA3 / JA4 / JA4+)
Una de las señales más fiables y más difíciles de falsificar, porque opera a nivel de red — antes de que se ejecute JavaScript alguno. Al establecer la conexión HTTPS, el cliente envía un mensaje ClientHello en el que enumera los cifrados, las extensiones, las curvas elípticas, las versiones de protocolo y los valores ALPN que admite — en un orden estrictamente definido. Ese conjunto se transforma mediante hash en una huella corta:
- JA3 (2017) — el método clásico, un hash MD5 de los campos del ClientHello. El problema: TLS 1.3 introdujo los valores aleatorios GREASE, que hacen que el hash «fluctúe» de una petición a otra.
- JA4 / JA4+ (FoxIO, 2023) — el reemplazo moderno: ordena las extensiones alfabéticamente y elimina GREASE, de modo que la huella se mantiene estable incluso con el orden aleatorizado. JA4+ es una familia de huellas (incluida la respuesta del servidor JA4S, HTTP/2, etc.).
La principal fortaleza del método es la comprobación de coherencia: si el User-Agent afirma ser Chrome 120 pero la huella TLS se corresponde con la biblioteca requests de Python o con curl, el cliente se bloquea de inmediato. A esto se añaden las huellas de HTTP/2 (orden y valores de los frames SETTINGS, priorización) y de los parámetros de transporte de HTTP/3 (QUIC). La tendencia reciente es tener en cuenta las firmas post-cuánticas y las nuevas extensiones TLS que aparecen en las compilaciones actuales de Chromium.
3. Cabeceras HTTP
No solo se comprueban los valores en sí, sino también su composición, su orden y su coherencia mutua:
- el
User-Agenty su correspondencia con el comportamiento real del cliente; - la presencia y corrección de
Accept,Accept-Language,Accept-Encoding,Referer; - los Client Hints modernos (
Sec-CH-UA, plataforma, condición móvil); - el orden de las cabeceras — cada navegador tiene el suyo, propio y estable.
Que la configuración regional de la cabecera Accept-Language no coincida con el país de la IP de salida — es un motivo frecuente de sospecha.
4. Huella del navegador
Si el cliente ejecuta JavaScript, el sitio compone una «huella del dispositivo» a partir de cientos de características:
- Canvas fingerprint — el resultado de renderizar una imagen oculta, único para la combinación GPU/driver/SO;
- WebGL / WebGPU — revelan el modelo de la tarjeta gráfica y la versión del driver;
- AudioContext — microdiferencias en el procesamiento de la señal de audio;
- la lista de fuentes instaladas, la resolución y los parámetros de la pantalla, la zona horaria, el idioma;
- las propiedades del objeto
navigator, los plugins, las API disponibles.
Y de nuevo lo esencial es la coherencia. Si el Canvas se renderiza como si fuera una potente GPU dedicada, pero WebGL informa de una gráfica integrada Intel — es una configuración «imposible», una bandera inmediata. Los sistemas también comprueban si la huella cambia demasiado a menudo (indicio de aleatorización) o si es demasiado estática entre sesiones (indicio de falsificación).
5. Indicios de automatización
Marcadores directos de navegadores headless y de herramientas de automatización: la bandera navigator.webdriver, rastros del protocolo CDP (Chrome DevTools Protocol), plugins y API ausentes, renderizado por software (SwiftShader) en lugar de una GPU por hardware, tamaños de ventana atípicos. La generación demasiado rápida de la huella Canvas (más rápida de lo que lograría un navegador real) — también es una señal.
6. Biometría del comportamiento
La capa más «humana», que cada vez decide más el resultado. Los modelos de ML analizan cómo interactúa el visitante con la página: las trayectorias del ratón, el ritmo y la velocidad del scroll, las pausas, el ritmo de las pulsaciones y de la escritura, la secuencia de navegación. Una persona real mueve el cursor de forma caótica, se desplaza de manera irregular y a veces falla el objetivo. Un bot se mueve en líneas rectas, se desplaza a velocidad constante y no se equivoca. La ausencia total de movimientos del ratón durante la navegación — ya es sospechosa de por sí.
Qué métodos de protección existen
La protección se construye como un pastel de capas: cada nivel filtra una parte del tráfico no deseado y, en conjunto, elevan el coste del ataque. Enfoques principales:
Rate limiting y throttling. Limitar el número de peticiones por IP/sesión y unidad de tiempo, y ralentizar cuando se superan los umbrales. Una capa base sencilla pero imprescindible.
robots.txt. Un archivo declarativo que indica qué secciones puede rastrear cada bot. Solo funciona con los rastreadores «honestos»: un bot que actúa de buena fe lo respeta; uno malintencionado — lo ignora. Es una herramienta de acuerdo, no de coacción. Según datos de Cloudflare, solo alrededor de un tercio de los dominios más importantes tiene robots.txt.
WAF y listas de reputación. El firewall de aplicaciones web bloquea patrones maliciosos conocidos y el tráfico procedente de IP/ASN con mala reputación.
CAPTCHA y scoring invisible. La evolución ha ido del texto distorsionado y la selección de imágenes («semáforos», «pasos de peatones») a los sistemas invisibles que evalúan el comportamiento en segundo plano sin decir nada (reCAPTCHA v3, Cloudflare Turnstile, hCaptcha). El challenge visible ahora — es ya la consecuencia de una puntuación de confianza baja, no la primera línea.
Proof-of-work (prueba de trabajo). El navegador resuelve, sin que se note, un problema criptográfico. Para un usuario real es gratis, pero para la automatización a gran escala genera un coste de cómputo asimétrico que hace el ataque económicamente inviable. Este enfoque es la base de Kasada y Friendly Captcha.
Challenges de JavaScript. El servidor entrega un script que debe ejecutarse en un entorno de navegador completo; los clientes HTTP sin motor de JS se quedan fuera.
Fingerprinting + scoring con ML. Recogida de todas las señales anteriores y su evaluación mediante modelos de aprendizaje automático en tiempo real. Los sistemas más avanzados mantienen miles de modelos entrenados para sitios concretos.
Honeypots y trampas. Enlaces y campos invisibles para una persona a los que solo reaccionan los bots. La evolución de la idea — los «laberintos» y los tarpits: páginas señuelo generadas sin fin en las que los infractores se atascan y malgastan recursos (los enlaces se marcan con nofollow para no perjudicar el SEO).
Ofuscación dinámica y polimorfismo. Cambiar constantemente el maquetado, los nombres de las clases, la estructura de las respuestas y el propio código de protección para que los scrapers no puedan «fijarse» a una plantilla concreta y para que los atacantes no puedan aplicar ingeniería inversa a la protección una sola vez y para siempre.
Despliegue en el edge o del lado de la aplicación. La protección en el edge (en la CDN) atrapa a los bots antes, antes de llegar al servidor de origen, y reduce la carga. La protección a nivel de aplicación ve más contexto de negocio y puede aplicar la lógica de escenarios concretos. Las grandes empresas suelen usar ambas capas.
Verificación de bots «buenos» y agent trust. Mecanismos que permiten a los rastreadores legítimos (buscadores, monitorización) autenticarse para no ser bloqueados. Una línea reciente — los estándares con los que los agentes de IA pueden identificarse y declarar sus intenciones (entrenamiento, inferencia, búsqueda), y el propietario del sitio — decidir a quién deja pasar.
En qué fijarse al montar la protección
Algunos principios prácticos que distinguen una protección que funciona de una meramente formal:
Múltiples capas. Una sola señal no es fiable. Una IP residencial no salva a nadie si la huella TLS grita «Python» y navigator.webdriver delata la automatización. La fuerza está en la comprobación cruzada de la coherencia de muchas capas a la vez.
Equilibrio con los falsos positivos (false positives). Una protección demasiado agresiva golpea a los usuarios reales: personas tras un NAT corporativo, una VPN, en modo privado o con un navegador poco común pueden parecer sospechosas. Un comprador bloqueado — es una conversión perdida y más tickets de soporte. La calidad de una solución se mide en buena medida precisamente por un FPR bajo (False Positive Rate — la proporción de falsos positivos, es decir, el porcentaje de usuarios reales que se toman por bots por error).
No bloquear a los bots útiles. Googlebot, Bingbot, la monitorización y los bots de vista previa de las redes sociales deben pasar. Por eso hacen falta listas de permitidos y verificación. Bloquear del todo a los rastreadores de IA, por cierto, hace que el sitio sea invisible para la búsqueda con IA (ChatGPT, Perplexity, etc.) — es una decisión de negocio, no solo técnica.
Protección específica de la API y de los endpoints móviles. A menudo los datos no se extraen de las páginas, sino directamente de la API, donde no hay huella de navegador. Para las aplicaciones móviles se usan la attestation del dispositivo y los SDK móviles.
Priorizar lo más valioso. Conviene reforzar la protección en los puntos más valiosos y más atacados — listas de precios, buscador, fichas de producto, login, checkout — en lugar de repartir comprobaciones pesadas por todo el sitio.
Monitorización y actualización. Es una carrera armamentística. Los proveedores anti-bot actualizan la detección cada semana; una protección configurada «una sola vez» queda obsoleta. Hacen falta paneles de análisis del tráfico de bots y una revisión periódica de las reglas.
Cómo esquivan los scrapers las restricciones
Entender el lado del ataque es útil — muestra contra qué se construye exactamente la protección. El scraping profesional hoy no es «cambiar el User-Agent», sino imitar de forma coherente a un cliente real en todas las capas a la vez.
Rotación de proxies. Las IP de centros de datos son baratas, pero se detectan con facilidad. Los proxies residenciales encaminan el tráfico a través de redes domésticas reales y parecen usuarios normales; los proxies móviles son aún más fiables, pero más caros. Las IP se rotan entre peticiones, eligiendo la geolocalización según el público objetivo del sitio. Pero cambiar de IP por sí solo no sirve de nada — no arregla la huella TLS ni la huella del navegador.
Impersonación TLS. Bibliotecas como curl-impersonate y curl_cffi reproducen la pila TLS de un navegador real para que JA3/JA4 coincida con el User-Agent declarado. El principio clave de los atacantes — no intentar parecer «mejor» que un navegador, sino ser lo más coherente posible con él: cualquier incongruencia entre capas es peor que una huella «del montón».
Navegadores headless reforzados (fortified). Un Selenium/Puppeteer puros se delatan con las banderas de automatización. Por eso se usan: - nodriver y undetected-chromedriver — eliminan los rastros de WebDriver y no usan el protocolo clásico; - SeleniumBase en modos UC/CDP; - Camoufox — un navegador antidetección basado en Firefox con inyección de la huella a nivel de C++; - plugins stealth para Puppeteer/Playwright (aunque van por detrás de las actualizaciones de la detección y con el tiempo «caducan»).
Encontrará un análisis detallado y una comparación de estas herramientas en el artículo 11 Best Anti-Bot Bypass Tools for Web Scraping.
Navegadores antidetección. Multilogin, GoLogin, NestBrowser, AdsPower y similares crean perfiles aislados con huellas únicas pero coherentes (Canvas, WebGL, fuentes) — pensados en origen para la gestión de múltiples cuentas, pero muy usados también en el scraping.
Imitación del comportamiento. Retardos aleatorios, trayectorias del ratón «humanas», scroll irregular, pausas, navegación de calentamiento antes de la acción objetivo — para superar el análisis del comportamiento.
Resolución de captchas. Servicios como 2Captcha, Anti-Captcha o CapSolver devuelven un token para reCAPTCHA, hCaptcha o Turnstile (del orden de $1--2 por cada 1000 resoluciones). Pero cuesta tiempo y dinero, así que los profesionales apuestan por la prevención — no dejar que la puntuación de confianza baje hasta el punto en que aparezca el captcha.
Servicios gestionados. Las scraping API llave en mano (Scrapfly, Bright Data Web Unlocker, ScraperAPI, Scrapeless) asumen toda la complejidad: una única pila de Chrome parcheada, rotación de proxies residenciales, ajuste de TLS/HTTP/2/Canvas a las compilaciones reales del navegador y resolución de challenges. Para el atacante, esto traslada al proveedor la carga de sostener la «carrera armamentística».
La conclusión principal es la misma para ambos bandos: no gana quien se enmascara de forma más agresiva, sino quien tiene todas las capas coherentes entre sí. Precisamente en la búsqueda de incongruencias se basa la detección.
Qué soluciones existen
El mercado del bot management es maduro y está muy poblado. A continuación — los actores clave. Los precios casi siempre son personalizados (enterprise), así que conviene consultar las cifras concretas con los proveedores; las referencias que se dan proceden de datos públicos y tienen carácter orientativo.
Cloudflare Bot Management. Forma parte de la mayor plataforma de CDN/seguridad del mundo, que da servicio a cerca del 20 % de la web. Usa ML y análisis del comportamiento entrenados con datos de decenas de millones de sitios, lo que le da una enorme visibilidad de red. En su ecosistema entran Turnstile (captcha invisible), Bot Analytics y también las líneas de IA más recientes: bloqueo de rastreadores de IA (desde julio de 2025 — por defecto en los dominios nuevos, «Content Independence Day»), gestión mediante AI Crawl Control, control del cumplimiento de robots.txt, un «laberinto» para los infractores y el marketplace Pay Per Crawl, donde los editores pueden cobrar a las empresas de IA por el rastreo (respuesta 402 Payment Required). La gestión de bots básica está disponible desde los planes de pago; las capacidades completas — en Business/Enterprise. Su mayor fortaleza es formar parte de la plataforma global de Cloudflare.
DataDome. Uno de los líderes del mercado, orientado al e-commerce, los marketplaces, los viajes, la fintech y los medios. Apuesta por el ML en tiempo real: según datos públicos, mantiene decenas de miles de modelos para clientes concretos. Sus puntos fuertes — la protección de API y aplicaciones móviles (attestation del dispositivo, SDK móviles), un porcentaje bajo de falsos positivos gracias a la combinación de señales de comportamiento y de contexto, y modos de respuesta flexibles, desde challenges «suaves» hasta el bloqueo tajante. Los usuarios lo valoran de forma sistemática por su facilidad de implantación. Según las referencias públicas, los presupuestos arrancan en torno a los $2000--4000/mes para un tráfico moderado y ascienden hasta $12 000--25 000/mes o más en grandes proyectos multirregionales.
HUMAN (antes PerimeterX, fusionada con HUMAN Security). Fuerte en análisis del comportamiento y en su ecosistema antifraude: protección frente al acaparamiento de productos escasos (bots scalper), el credential stuffing y el robo de cuentas. Una buena opción cuando hace falta unir anti-bot y antifraude con informes avanzados y una analítica madura.
Akamai Bot Manager. Un peso pesado corporativo para tráfico grande y de alta carga. Opera en el edge a través de Akamai Intelligent Edge, usa análisis del comportamiento, ML e inteligencia de amenazas global, ofrece políticas granulares (block / challenge / retardo / entrega de contenido alternativo) y separa los bots «buenos» de los «malos». Su mayor sentido lo tiene para quien ya está sobre la pila de Akamai.
Imperva Advanced Bot Protection. Una solución madura con una fuerte protección de API y buena analítica; a menudo se valora junto con el WAF de Imperva como una protección corporativa integral de aplicaciones.
Kasada. Apuesta por los challenges criptográficos de proof-of-work y la ofuscación dinámica: el objetivo — disparar el coste del ataque para los bots headless y los emuladores, y hacerlo sin captchas visibles (mínima fricción para las personas). Es especialmente eficaz contra los bots que ya han aprendido a esquivar la detección imitando el comportamiento, y contra la emulación/automatización. Bueno para equipos a los que les importa la resistencia frente al reequipamiento constante de los atacantes.
Arkose Labs. Combina el scoring de riesgo con challenges interactivos y el enfoque de «hacer que el ataque no sea rentable»; fuerte en escenarios de protección frente al fraude y al registro masivo de cuentas falsas.
Netacea. Enfoque agentless: se despliega del lado del servidor/edge sin JS de cliente ni SDK, por lo que es invisible para los atacantes. Usa analítica de intención (evalúa la intención, no las firmas) e integración con SIEM/SOAR.
Fastly Bot Management. Protección en el edge frente a ATO, scraping, DDoS de capa de aplicación, credential stuffing y abuso de la lógica de negocio — una elección lógica para quien ya está en Fastly.
Proveedores de CAPTCHA como capa aparte. Google reCAPTCHA (v2 — casilla de verificación con reserva a imágenes; v3 — scoring invisible sin interacción), hCaptcha (no atado al ecosistema de Google), Cloudflare Turnstile (comprobaciones en segundo plano sin challenge visible en la mayoría de los casos), Friendly Captcha (proof-of-work). Se integran tanto por su cuenta como dentro de plataformas de bot management más grandes.
A grandes rasgos, el mercado se puede repartir así: Cloudflare, Akamai y Fastly — fuertes en el edge y para consolidar la seguridad web en una sola pila; DataDome y HUMAN — más a fondo en la capa de aplicación, la API y el móvil; Kasada y Arkose — centrados en encarecer el ataque de forma asimétrica; Imperva y Netacea — protección corporativa madura de aplicaciones y API.
Hacia dónde se mueve el mercado
La protección anti-scraping — es una carrera armamentística sin fin en la que ambos bandos evolucionan a la par. Algunas tendencias destacadas:
- Desplazamiento de las firmas hacia el comportamiento y el ML. La detección se apoya cada vez menos en reglas estáticas y cada vez más — en la biometría del comportamiento y en modelos entrenados para un sitio concreto.
- Las señales de red como cimiento. Las huellas de TLS/HTTP-2/HTTP-3 son difíciles de falsificar y actúan antes del JS, por lo que siguen siendo la capa base y más fiable; aparecen señales nuevas como el TLS post-cuántico.
- Challenges «suaves» y proof-of-work en lugar de los captchas molestos — para no romper la experiencia de usuario a las personas reales.
- Los rastreadores de IA como categoría nueva. La aparición de la monetización (pay-per-crawl), de estándares de identificación de bots y del concepto de «agent trust»: la pregunta pasa de «¿persona o bot?» a «¿a qué bot y con qué fin le permitimos el acceso?».
- La attestation de dispositivos y las raíces de confianza por hardware — sobre todo en escenarios móviles.
No existe la protección perfecta: un scraper suficientemente motivado y financiado, con proxies residenciales, una pila de navegador parcheada y resolutores de captchas, superará casi cualquier barrera. El objetivo realista de la protección — no es hacer el scraping imposible, sino hacerlo tan caro, lento y frágil que deje de ser rentable, sin afectar por ello a los usuarios reales ni a los bots útiles.