Tony Wang17 min de lectura¿Cuánto del web ejecuta anti-bot? Escaneamos el top 1.000.000 de sites
Escaneamos el top 1M: 53,5% del web alcanzable ejecuta un anti-bot o WAF managed, casi todo Cloudflare — los sites más concurridos ejecutan menos.
La mayoría de los proyectos de «esto lo scrapeo en un rato» no mueren al parsear el HTML. Mueren cuando la página resulta estar detrás de Cloudflare o DataDome y necesita un enfoque completamente distinto del que construiste. Así que medimos qué tan común es eso en realidad — dos veces. Escaneamos el Tranco top 1.000.000 completo para obtener la foto a escala web, y luego seleccionamos a mano 1.005 sites reales y públicos en 28 categorías — el tipo de sites que la gente realmente scrapea — y les hicimos correr toda la flota de transporte. La versión corta: poco más de la mitad del web alcanzable ejecuta defensa anti-bot managed, se concentra en un solo proveedor, los sites más concurridos son los que menos la ejecutan, y la dificultad está distribuida de forma muy desigual.
El dataset completo y buscable — cada site, filtrable por proveedor, dificultad y categoría — vive en el Anti-Bot Adoption Index.
¿Cuánto del web ejecuta un anti-bot o una WAF?
En todo el top 1.000.000, alcanzamos 818.614 sites (el resto era irresoluble, hizo timeout o bloqueó directamente nuestro punto de vista de datacenter — cerca del 18%, excluido de los porcentajes). De los que alcanzamos, el 53,5% expone una WAF managed, un bot-management o un proveedor de control de acceso — sin contar solo un widget de CAPTCHA o rate-limiting:
| Tipo de protección | Cuota de alcanzables |
|---|---|
| WAF managed | 47,6% |
| Widget CAPTCHA (reCAPTCHA, hCaptcha, Turnstile…) | 12,7% |
| Control de acceso | 2,1% |
| Bot-management dedicado | 0,8% |
| Cualquier anti-bot / WAF managed | 53,5% |
Esto no es un mercado fragmentado. Cloudflare por sí solo cubre el 45% de cada site alcanzable — el 84% de todos los sites protegidos — y la siguiente capa con nombre más grande son los widgets de CAPTCHA de consumo. Los proveedores puros de bot-management apenas registran a escala web: Akamai Bot Manager 0,6%, DataDome 0,16%, PerimeterX/HUMAN 0,09%.
Estos números coinciden con mediciones independientes. W3Techs (junio de 2026) sitúa a Cloudflare en 23,2% de todos los sitios web y aproximadamente 48,7% del top 1M — nosotros encontramos su postura activa de anti-bot en el 45% del top 1M alcanzable, el mismo orden de magnitud desde un método distinto. Y el Imperva 2025 Bad Bot Report encuentra que el tráfico automatizado ya es 51% de todo el tráfico web (bad bots 37%) — la presión de demanda que explica por qué tantos sites tienen un muro en primer lugar. (Para una metodología comparable de medición a escala web, ver el HTTP Archive Web Almanac.)
Los sites más concurridos ejecutan menos anti-bot
El número a escala web esconde el hallazgo más útil. Divide el millón por rango de tráfico y tres curvas se mueven juntas — protección, Cloudflare y los proveedores especializados:
| Banda de rango Tranco | Protegido | Cloudflare | Bot-mgmt enterprise¹ |
|---|---|---|---|
| Top 1.000 | 44,2% | 23,4% | 7,6% |
| 1k–10k | 50,7% | 34,0% | 5,3% |
| 10k–100k | 52,3% | 40,2% | 2,6% |
| 100k–1M | 53,6% | 45,6% | 0,6% |
¹ Akamai Bot Manager + DataDome + PerimeterX, como cuota de sites alcanzables en la banda.
Dos cosas se invierten a medida que bajas de rango. Cloudflare escala (23% del top-1.000 al 46% de la long-tail): su dominio a escala web es una historia de long-tail — los gigantes ejecutan su propia infraestructura o infraestructura enterprise y mantienen los homepages abiertos por SEO, mientras que los millones de sites más pequeños recurren al Cloudflare llave en mano. Mientras tanto, el bot-management enterprise cae (7,6% a 0,6%): DataDome, PerimeterX y Akamai Bot Manager son un fenómeno de cabeza, comprado por los sites de alto valor donde los datos automatizados tienen un costo en dólares directo. Así que la cabeza y la cola no solo están protegidas a tasas distintas — están vigiladas por proveedores distintos. (W3Techs ve la misma dirección: Cloudflare es más bajo en el top-1.000 absoluto que en el top-1M más amplio.)
Deja a Cloudflare de lado (escala en todos los tramos) y los guardianes especializados intercambian lugares por rango — Akamai vigila la cima absoluta, mientras que la long-tail recurre al CAPTCHA llave en mano:
Si haces zoom a los ~1.005 sites de alto valor que la gente realmente scrapea, el perfil de la cabeza se afila aún más: ahí, el bot-management enterprise se sitúa en el 15,5% de los sites, y la capa de CAPTCHA barato de la cola casi desaparece. Adopción y sofisticación son ejes distintos: más del web está «protegido» de lo que pensarías, pero mucho menos de él es difícil.
La mayoría de esos muros están dormidos
Aquí está la parte que más nos sorprendió. «53,5% protegido» cuenta cada site que expone un proveedor managed — pero exponer uno no es lo mismo que usarlo. De los 818.614 sites alcanzables, solo 79.835 (9,8%) realmente desafiaron nuestro request al homepage; los otros 358.022 sites amurallados ejecutaron el proveedor de forma pasiva, devolviendo un 200 limpio a un request coincidente. Sigue al millón hasta el final, hasta los pocos que realmente contraatacan:
Show the flows
| Escaneados → Alcanzables | 818,614 (36.3%) |
| Alcanzables → Tiene muro | 437,857 (19.4%) |
| Alcanzables → Sin muro | 380,757 (16.9%) |
| Tiene muro → Presente pasivamente | 358,022 (15.9%) |
| Escaneados → Inalcanzables | 179,883 (8%) |
| Tiene muro → Desafiado activamente | 79,835 (3.5%) |
Qué muro está «despierto» depende mucho del proveedor. Cloudflare está delante del 45% del web alcanzable pero solo desafió activamente ~16% de esos homepages; Google reCAPTCHA casi nunca se dispara en un homepage (3%); el pequeño grupo de WAF no identificadas es lo opuesto — presente rara vez, pero desafiando el 76% de las veces.
La conclusión práctica: el fingerprint de un proveedor te dice a qué te enfrentarías si el muro se dispara — pero la mayoría de los homepages no se disparan en absoluto, que es exactamente por qué recurrir a un browser completo por defecto desperdicia tiempo y presupuesto. Revisa la página, no el logo.
Zoom in: los ~1.005 sites que la gente realmente scrapea
Para los sites que importan a un scraper, vamos más allá de los headers: cualquier site que bloquea un GET de datacenter se vuelve a probar a través de la flota de transporte completa (HTTP con impersonación de browser → browser headless → browser stealth + IP residencial), de modo que el tier refleje lo que realmente alcanza la página, no una suposición de headers. Con ese criterio, 575 de los 1.005 (57,2%) ejecutan defensa anti-bot managed, y dos proveedores la dominan:
| Proveedor | Tipo | Sites | Cuota |
|---|---|---|---|
| Cloudflare | WAF + challenge | 333 | 33,1% |
| Akamai Bot Manager | Bot management | 111 | 11,0% |
| Akamai (edge) | CDN/WAF | 53 | 5,3% |
| DataDome | Bot management | 30 | 3,0% |
| Imperva (Incapsula) | WAF | 15 | 1,5% |
| PerimeterX (HUMAN) | Bot management | 15 | 1,5% |
| Cloudflare Turnstile | CAPTCHA | 12 | 1,2% |
Cloudflare y Akamai juntos representan el 77% de cada site protegido en este set. Lo que separa a los proveedores es qué inspeccionan: Akamai y las rutas abiertas de Cloudflare se apoyan sobre todo en fingerprinting TLS/JA3-JA4 — un cliente HTTP coincidente a menudo los alcanza — mientras que DataDome y PerimeterX añaden ML de comportamiento en tiempo real, así que un fingerprint limpio por sí solo no basta.
La dificultad es muy desigual — la mayor parte NO es un trabajo de browser
La pregunta más útil no es «¿está protegido?» — es «¿qué hace falta para obtener la página pública de forma confiable?». Corriendo la flota real contra el set curado:
| Tier | Qué hace falta | Sites | Cuota |
|---|---|---|---|
| T1 | Cliente HTTP simple | 608 | 60,5% |
| T2 | HTTP con impersonación de browser (TLS coincidente) | 246 | 24,5% |
| T3 | Browser headless que ejecuta JavaScript | 148 | 14,7% |
| T4 | Browser stealth + IP residencial + comportamiento | 3 | 0,3% |
El 85% de estos sites no necesita ningún browser — un GET HTTP simple o un fingerprint TLS coincidente los alcanza. Solo ~15% realmente necesita un browser headless o más. Recurrir a un browser por defecto es el error de scraping más común (y más caro); los datos dicen que solo debes escalar cuando un site te obliga.
Por esto también son ciertos al mismo tiempo «57% protegido» y «85% no necesita browser»: detectar un proveedor es binario, pero que un proveedor esté presente no es lo mismo que esté desafiando activamente. De los 575 sites protegidos, solo 74 desafiaron activamente nuestro request — el resto ejecuta su proveedor en modo CDN/WAF pasivo (un fingerprint coincidente devuelve 200).
El extremo difícil: unos pocos sites firman cada request con una VM cerrada
La clase más dura no es un CAPTCHA — es una VM de bytecode propietaria dentro del browser que firma cada request, así que el tooling de transporte genérico no puede acuñar un token válido. Cuatro sites en el set curado incluyen una: la VM webmssdk de TikTok (las firmas X-Bogus / X-Gnarly, encima de Akamai) y la VM de proof-of-work de Kasada (el token x-kpsdk-ct, en marketplaces inmobiliarios). Para estos, «envía un request más inteligente» no aplica; necesitas un contexto de ejecución de browser genuino. Son raros, pero son los sites sobre los que la gente más pregunta «¿por qué no puedo scrapear esto?». (Deliberadamente no contamos una cookie de load-balancer F5 BIG-IP como una VM — eso es balanceo de carga en el servidor, no defensa anti-bot.)
Un bloqueo no es un bloqueo — lee por qué te detuvieron
Cuando un request no pasa, la razón te dice el arreglo — y el arreglo es completamente distinto cada vez. Después de escalar a través de la flota, solo 74 de los 1.005 (7,4%) todavía no pasaron limpiamente, y se desglosan así:
| Por qué se detuvo | Sites | Qué significa | El arreglo |
|---|---|---|---|
| Challenge de bot (interstitial JS) | 55 | El «Just a moment» de Cloudflare, un challenge JS | Ejecútalo en un browser real |
| CAPTCHA | 18 | Se sirvió un puzzle interactivo | Un browser (+ servicio de CAPTCHA) |
| Geo-bloqueado | 1 | Restringido por país/región | Una IP en una región permitida |
El titular es lo que los fallos no son. Una vez que traes el transporte correcto, los rate limits genuinos y las prohibiciones de IP directas son extremadamente raras en la puerta principal — el muro es casi siempre un problema de fingerprint/JS, no de proxy. Fuimos deliberadamente conservadores con las etiquetas: un 401 solo cuenta como muro de login si trae WWW-Authenticate (WSJ y Reuters devuelven 401 como bloqueo de bot de DataDome, no como autenticación), y un 403 genérico es «bloqueado», no «IP prohibida», a menos que la página lo diga.
El homepage es un mal proxy — la protección cambia por página
La mayor advertencia en cualquier estudio como este: un dominio protege tipos de página completamente distintos de forma completamente distinta. En LinkedIn, el homepage es ligero, una página /company/ está en gran medida abierta, pero un perfil /in/ y la búsqueda están amurallados por login. En Amazon, el homepage está abierto mientras que la búsqueda sirve fácilmente un «Robot Check». Por eso cada página de site en el index incluye un plan de prueba de páginas profundas orientativo — qué tipos de página revisar y qué esperar en cada una — para que pruebes la página que realmente quieres, no la puerta principal.
El gradiente de defensa: crypto y comercio son fortalezas, la búsqueda está abierta
Divide el set curado por categoría y aparece un gradiente de dinero claro — mientras más cerca está una página de una transacción, más duro está defendida:
| Categoría | % anti-bot / WAF managed |
|---|---|
| Crypto | 86% |
| Marketplaces | 81% |
| Herramientas de AI | 78% |
| Finanzas y mercados | 75% |
| Foros y comunidad | 75% |
| E-commerce | 72% |
| Bienes raíces | 72% |
| Viajes y hospitalidad | 72% |
| … | |
| Noticias y medios | 39% |
| Deportes | 33% |
| Redes sociales | 25% |
| Motores de búsqueda | 18% |
Crypto y marketplaces pelean más duro — precios, inventario y libros de órdenes son los datos más scrapeados del web. Los números bajos de social, noticias y búsqueda son en parte un artefacto del método: esos homepages están deliberadamente abiertos, pero las páginas profundas (un perfil, un archivo de artículos, una página de resultados) pasan a protegidas en el momento en que navegas hacia adentro.
Qué significa esto si estás construyendo un scraper
- Revisa antes de construir. Saber si una página está detrás de Cloudflare, DataDome, una VM cerrada o nada cambia todo el enfoque — y cambia por URL. Una revisión de 30 segundos te ahorra una tarde entera preguntándote por qué tus requests devuelven
403. Consulta la guía complementaria sobre cómo scrapear sites que bloquean bots para ver qué hace realmente cada proveedor. - Escala solo hasta donde el site lo exija, y paga solo cuando funcione. El 85% de los sites que la gente scrapea no necesita ningún browser. El patrón más rentable es probar primero el transporte más ligero y escalar, que es exactamente cómo se factura el web scraping para AI y pipelines de datos de Crawlora — pay-on-success, no por intento.
Nada de esto trata de vencer un CAPTCHA o pasar un login. Se trata de saber, antes de invertir tiempo de ingeniería, qué páginas públicas necesitan qué enfoque.
Pruébalo tú mismo
- Revisa cualquier URL ahora mismo con el anti-bot checker gratuito — pega una página de perfil o listing, no solo el homepage, y mira el proveedor y el transporte más ligero que funciona.
- Explora el dataset completo — busca cada site, filtra por dificultad, proveedor o categoría — en el Anti-Bot Adoption Index.
- Lee exactamente cómo lo medimos, incluyendo las firmas y la heurística de dificultad.
Cómo funciona realmente el check (transparencia total)
Sin magia — este es un check deliberadamente simple, pasivo y reproducible, ejecutado en dos escalas.
Las muestras. Las cifras a escala web vienen del Tranco top 1.000.000 completo (una lista de top sites agregada y citable con un ID permanente), de las cuales 818.614 fueron alcanzables. Las cifras del deep-dive vienen de 1.005 dominios recorridos desde la cima del mismo ranking hacia sites reales, públicos y con contenido en 28 categorías, saltando dominios de infraestructura/CDN puros, de publicidad/tracking y para adultos.
El request. El homepage de cada site se obtiene con un User-Agent real de Chrome, siguiendo redirects, desde una IP de datacenter — el punto de vista honesto de «lo que ve un scraper de nube básico». Nunca enviamos un formulario, resolvemos un CAPTCHA, iniciamos sesión ni obtenemos nada detrás de un muro. El escaneo del top-1M es este único GET de datacenter. Para el set curado vamos más allá: cualquier site que bloquea el GET de datacenter se vuelve a probar a través de la flota de transporte completa (impersonación de browser → headless → stealth + residencial), de modo que su tier de dificultad refleje lo que realmente alcanza la página en lugar de una suposición de headers.
Qué capturamos (y qué no). De la respuesta guardamos el código de estado, los headers de respuesta, los nombres de cualquier cookie Set-Cookie — solo nombres, nunca valores, así que no se almacenan tokens de sesión ni PII — y un fragmento acotado del body. No se retiene nada más.
Nombrar al proveedor. El proveedor se identifica comparando esa evidencia contra una base de datos de fingerprints públicos y documentados — nombres de header (cf-ray, x-datadome, x-iinfo, akamai-grn), prefijos de nombre de Set-Cookie (__cf_bm/cf_clearance, _abck/bm_sz, datadome, _px*, incap_ses_) y marcadores en el body en los que solo se confía en una respuesta con forma de challenge. Las coincidencias de header y cookie son de alta confianza; los marcadores de body, media.
Límites. Cada resultado es una cota inferior — los homepages son más abiertos que las páginas profundas que la gente realmente scrapea, y una IP de datacenter ve más challenges que una residencial. El escaneo del top-1M es solo de headers y no califica la dificultad (un site que bloquea un GET de datacenter ahí bien podría abrirse para un browser); los tiers calificados y el gradiente por categoría vienen del run curado con la flota completa. Los despliegues de anti-bot cambian continuamente, así que trata cada resultado como una señal direccional, no una garantía. Instantánea: junio de 2026.
Abierto y reproducible. El clasificador y la metodología están publicados en su totalidad — lee la metodología completa, o explora el index buscable. Cítalo como «Crawlora Anti-Bot Adoption Index» con un enlace.
Preguntas frecuentes
¿Cuánto del web está protegido por anti-bot?
Lo medimos dos veces. En el Tranco top 1.000.000 completo (818.614 alcanzables), el 53,5% expone un anti-bot, WAF o proveedor de control de acceso managed — abrumadoramente Cloudflare (45% de los sites alcanzables). En 1.005 sites de alto valor seleccionados a mano y probados con la flota de transporte completa, el 57,2% está protegido. Ambas son cotas inferiores: las páginas profundas (perfiles, listings, búsqueda) están más defendidas que los homepages que probamos, y la protección es más dura en crypto (86%) y marketplaces (81%), y más ligera en búsqueda, social y noticias.
¿Realmente necesitas un browser para scrapear la mayoría de los sites?
No — y ese es el error más caro. De los sites curados, el 85% no necesita ningún browser: cerca del 60% responde a un simple GET HTTP y otro 25% solo pide un fingerprint TLS coincidente. Solo ~15% realmente necesita un browser headless o más. El patrón más rentable es escalar solo hasta donde un site te obligue, en vez de recurrir por defecto al browser headless.
¿Cuál es el proveedor de anti-bot más común?
Cloudflare, por mucho margen — en el top 1.000.000 cubre el 45% de los sites alcanzables y el 84% de cada site protegido. En el set curado lidera con 33%, seguido de Akamai (Bot Manager 11% más su CDN de edge 5%). Los proveedores especializados de bot-management DataDome (3%) y PerimeterX/HUMAN (1,5%) se concentran en verticales de alto valor como marketplaces, viajes y bienes raíces, donde los datos automatizados tienen un costo directo.
¿Qué tipo de anti-bot es el más difícil de manejar?
Una VM de JavaScript propietaria y cerrada dentro del browser que firma cada request — como el webmssdk de TikTok (las firmas X-Bogus/X-Gnarly) o Kasada (el token x-kpsdk-ct); cuatro sites en el set curado incluyen una. A diferencia de un CAPTCHA, el tooling de transporte genérico no puede generar un token válido, así que estos necesitan un contexto de ejecución de browser real en vez de un request más inteligente. Son raros, pero son los sites sobre los que la gente más pregunta por qué no puede scrapearlos.
¿Cómo midieron el anti-bot de cada site?
De dos formas. El escaneo del top 1.000.000 es un único GET pasivo al homepage desde una IP de datacenter, que compara headers de respuesta (cf-ray, x-datadome), nombres de Set-Cookie (_abck, datadome, _px) y marcadores de challenge contra fingerprints de proveedores documentados — las mismas firmas que el anti-bot checker de Crawlora. Para el set curado vamos más allá: cualquier site que bloquea el GET de datacenter se vuelve a probar a través de la flota de transporte completa (impersonación de browser → headless → stealth + residencial), de modo que su tier de dificultad refleje lo que realmente alcanza la página, no una suposición de headers. Cada resultado es una cota inferior.