Tony Wang7 min de lecturaCómo los sitios web previenen el web scraping en 2026 (y qué sigue funcionando)
El 53.5% de los sitios del top 1M usa un muro anti-bot. Cómo detectan scrapers TLS, IP y Cloudflare — y qué sigue funcionando.
La mayoría de las guías de web scraping hablan de cómo extraer datos. Esta trata del muro que hay delante — porque en 2026 ese muro es lo que realmente determina si tu scraper funciona. Hicimos los números: en un escaneo del top 1.000.000 de sites de Tranco, el 53,5% de los alcanzables ejecuta un sistema anti-bot managed. Así es como esos sistemas detectan scrapers, quién los construye, qué cambió en 2026, y qué sigue permitiendo pasar a una recolección legítima.
¿Qué tan común es la protección anti-bot?
De los ~818.600 sites alcanzables en nuestro escaneo del top-1M, 437.857 — el 53,5% — están detrás de un muro anti-bot managed. El mercado está extraordinariamente concentrado: Cloudflare está delante del 45% de todos los sites, cerca del 84% de cada site protegido. Todo lo demás es una long tail.
| Proveedor anti-bot | Cuota de todos los sites | Notas |
|---|---|---|
| Cloudflare | ~45% | El muro dominante; sube con la oscuridad |
| Google reCAPTCHA | 7,5% | Por lejos el CAPTCHA más común |
| hCaptcha | 3,5% | CAPTCHA posicionado en privacidad |
| Cloudflare Turnstile | 1,3% | Widget que reemplaza al CAPTCHA |
| Imperva (Incapsula) | 0,6% | WAF + bot maduro |
| Akamai Bot Manager | 0,6% | Enterprise; más fuerte en la cabeza del tráfico |
| DataDome | 0,1% | Raro pero de alta sofisticación, basado en ML |
Dos hallazgos sorprenden a la gente. Primero, la protección sube a medida que bajas de rango — el 44,2% de los top 1.000 sites está amurallado frente al 53,6% de la cola — porque el tier gratuito de Cloudflare defiende millones de sites pequeños mientras que el bot-management enterprise (Akamai) se adelgaza. Segundo, los homepages la subestiman: en un censo de páginas profundas, las páginas de producto, listing y perfil estuvieron amuralladas el 48,4% de las veces frente al 40,5% de los homepages, y fue mucho más probable que estuvieran detrás de un login. La página que realmente quieres está mejor defendida que la puerta principal.
Cómo detectan los sites a los scrapers en 2026
La detección ya no es una sola verificación — es una pila de señales evaluadas en conjunto. Arreglar una mientras otra te delata es la razón más común por la que un scraper que «funciona» de repente empieza a devolver 403.
| Señal | Cómo funciona | Qué la vence |
|---|---|---|
| Fingerprinting TLS (JA3 → JA4) | Hashea tu handshake TLS. El handshake de un cliente HTTP simple no coincide con el del browser que su User-Agent dice ser — un «Chrome con forma incorrecta». JA4 ya lo usan Cloudflare, Akamai y AWS WAF. | Una pila de impersonación TLS (curl-impersonate, curl-cffi, utls) que replica el handshake de un browser real — y headers que coinciden con el UA. |
| Fingerprinting HTTP/2 | Los frame settings, el orden de headers y el orden de pseudo-headers se evalúan junto con la capa TLS. | Automatización con browser real, o un cliente HTTP/2 que refleja los frame settings y el orden de headers de un browser. |
| Reputación de IP | Los sistemas clasifican la red de la IP: datacenter/comercial = baja confianza; residencial/móvil/ISP = alta confianza. Las IP de datacenter ven un 40–60% de éxito en sites protegidos frente a 90%+ para residenciales. | Proxies residenciales, móviles o de ISP con rotación sensata; evita rangos de datacenter ya quemados. |
| Fingerprinting de browser | Renderiza una escena canvas/WebGL oculta y la hashea; el renderizado headless produce un hash distinto. Las fuentes, el audio y el hardware añaden entropía. | Chromium real con aceleración por GPU y fingerprints consistentes y no anómalos. |
| Detección de headless y CDP | Chrome headless define navigator.webdriver, carece de plugins/codecs y filtra artefactos de control del DevTools Protocol. | Parches stealth para el webdriver y las señales de headless, además de drivers que no filtran CDP — la capa más revisada. |
| Análisis de comportamiento | Las trayectorias del mouse, el ritmo de scroll y el timing entre requests alimentan modelos de ML. No se puede parchear en la capa de la API. | Ritmo humano, delays aleatorizados y tasas de request bajas. |
| robots.txt / reglas de UA | Reglas disallow para user-agents nombrados (GPTBot, CCBot, ClaudeBot), cada vez más aplicadas en el edge. | Respétalas donde sea necesario; presenta un UA honesto y recolecta solo datos permitidos. |
El punto que sostiene todo: la falsificación aislada falla. Una IP residencial con una forma TLS que no coincide, o un browser con stealth pero timing robótico, igual dispara la correlación. Los proveedores evalúan el request completo, así que la evasión tiene que ser holística — exactamente por eso tantos equipos enrutan los targets difíciles a través de un unblocker managed en lugar de mantener todo esto ellos mismos.
Quién construye los muros
- Cloudflare Bot Management + Turnstile — por lejos el más desplegado, basado en el edge, con scoring JA4 y el familiar challenge «Just a moment». También quien marca la política sobre crawlers de AI (más abajo).
- DataDome — capa de aplicación, ML en tiempo real; sensores fuertes de comportamiento y fingerprint. Raro en números absolutos pero de alta sofisticación.
- HUMAN (antes PerimeterX) — analítica de comportamiento avanzada, consolidando anti-bot y anti-fraude; enterprise.
- Akamai Bot Manager — enterprise y edge, más fuerte en la cabeza del tráfico, se adelgaza hacia la cola.
- Kasada — resistencia máxima a headless y emulación mediante challenges del lado del cliente ofuscados y rotados con frecuencia.
El tipo de despliegue importa tanto como el proveedor: los sistemas de edge (Cloudflare, Akamai) bloquean antes de que tu request llegue al origen; los sistemas de capa de aplicación (DataDome, HUMAN) ven el contexto de negocio y aplican lógica después.
El giro de 2026: bloquear a los crawlers de AI
El gran cambio de este año no es un nuevo fingerprint — es hacia quién apuntan los muros. Según Cloudflare Radar, los requests automatizados se convirtieron en la mayoría del tráfico web en 2026 (57,5% frente a 42,5% humano), y los crawlers de AI son una porción grande y creciente de eso. Los publishers respondieron:
- El 9,33% del top 1M ahora bloquea por completo al menos un crawler de AI importante en robots.txt — el 14,8% de los sites que publican un robots.txt. Está concentrado por categoría: el 80,6% de los sites de noticias & medios bloquea un crawler de AI, frente a ~11% del e-commerce. GPTBot y CCBot son los más bloqueados, prácticamente empatados. (Desglose completo y el dataset abierto: nuestro índice de bloqueo de crawlers de AI.)
- Cloudflare anunció que a partir del 15 de septiembre de 2026 bloqueará por defecto a los crawlers de entrenamiento y de agentes de AI en sites monetizados, dividiendo los bots por propósito (entrenamiento vs. búsqueda vs. agente) para que cada uno sea controlable de forma independiente, y construyendo sobre su marketplace de «pay-per-crawl», que permite a los publishers cobrar a los crawlers mediante una respuesta HTTP 402.
Para cualquiera que construya sobre datos web, la conclusión es que la capa de permiso se está endureciendo incluso donde el muro técnico sigue igual — el tráfico de AI y de agentes cada vez necesita más una vía de acceso explícita y honesta, no solo un fingerprint que funcione.
Qué sigue funcionando para el scraping legítimo
Los sistemas anti-bot están construidos para detener el abuso, no para hacer que los datos públicos sean imposibles de recolectar. Para una recolección legítima y respetuosa con las tasas, esto es lo que realmente mueve las tasas de éxito en 2026:
- Proxies residenciales / móviles / de ISP — la palanca individual más grande, que mueve la confianza de la IP de «datacenter» a «residencial» (40–60% → 90%+ en sites protegidos). Rota de forma sensata.
- Impersonación TLS — iguala el fingerprint JA4/HTTP-2 de un browser real con curl-impersonate, curl-cffi o utls, con headers coherentes con el UA que presentas.
- Automatización con browser real con aceleración por GPU y parches stealth — necesaria para el ~15% de los sites que realmente requieren un browser.
- Ritmo humano — el timing aleatorizado y las tasas de request bajas vencen la capa de comportamiento, algo que la falsificación no puede lograr.
- Enruta los targets difíciles a través de una API de scraping / unblocker managed — que combina todo lo anterior y se adapta a medida que los proveedores cambian, de modo que un desajuste en una capa no hunda el request.
Esa última opción es el propio enfoque de Crawlora: maneja los proxies, los fingerprints, el renderizado y el ritmo detrás de un solo endpoint, y — porque la facturación es pay-on-success — se te cobra solo cuando un request realmente devuelve datos, no cuando gana un muro. Antes de construir cualquiera de esto tú mismo, revisa contra qué te enfrentas.
Fuentes
Dónde encaja esto
Revisa cualquier site en segundos, gratis: el Anti-Bot Checker te dice si un target bloquea bots y cómo, y el AI-Crawler Access Checker muestra qué le permite un site hacer a los crawlers de AI — sin registro.
Una vez que sabes qué ejecuta un target, la pregunta práctica es cómo recolectarlo. Consulta por qué tu scraper funciona en local pero devuelve 403 en un servidor para la versión más común de este problema, cómo elegir una API de web scraping para enrutar targets difíciles, y el Anti-Bot Index y el AI-Crawler Blocking Index para todos los datos detrás de este post.
Preguntas frecuentes
What percentage of websites use anti-bot protection?
In Crawlora's scan of the Tranco top 1,000,000 sites, 53.5% of the reachable ones run a managed anti-bot wall. Cloudflare alone sits in front of about 45% of all sites — roughly 84% of every protected site — followed distantly by Google reCAPTCHA (7.5%), hCaptcha (3.5%), and enterprise vendors like Akamai and DataDome. Protection is heavier in the long tail (44% of the top 1,000 vs 54% of the tail) and deeper than homepages suggest.
How do websites detect web scrapers?
By scoring several signals together, not one check: TLS/JA4 and HTTP/2 fingerprinting (your handshake doesn't match the browser your User-Agent claims), IP reputation (datacenter IPs are low-trust vs residential), browser and headless fingerprinting (canvas/WebGL, navigator.webdriver, CDP artifacts), and behavioral models (mouse and timing patterns). Because the signals are correlated, spoofing one layer while another mismatches still flags the request.
How do I scrape a website protected by Cloudflare?
For legitimate, rate-respectful collection: use residential or mobile proxies (which move IP trust from datacenter to residential and lift success from ~40–60% to 90%+ on protected sites), impersonate a real browser's TLS/HTTP-2 fingerprint (curl-impersonate, curl-cffi, utls), pace requests to defeat behavioral detection, and use a real browser for the ~15% of sites that require one. Most teams route hard targets through a managed scraping API that combines all of these and adapts as vendors change.