Benchmark de web crawlers para alimentar sitios web a la IA

Comparamos cuatro APIs de rastreo en tres dominios de dificultad variable en tres niveles de profundidad máxima (5, 10, 20) con un límite de 1.000 páginas, midiendo la cobertura del rastreo, el tiempo de ejecución, el descubrimiento de enlaces, la calidad de los enlaces en markdown y la precisión de la extracción de títulos.

Si su objetivo es:

• Convertir páginas web en datos estructurados; consulte nuestra guía sobre web scraping.
• Para rastrear sitios web completos, siga leyendo.

Benchmark de web crawlers

Puede leer nuestra metodología del benchmark.

Promedio de páginas rastreadas vs. costo por 1.000 páginas

Páginas rastreadas por dominio según profundidad máxima

Firecrawl rastreó de manera consistente alrededor de 100 páginas en theregister.com independientemente de la profundidad máxima, aproximadamente 90 páginas en entrepreneur.com en todos los niveles de profundidad, y solo alrededor de 30 páginas en amazon.com, probablemente debido a la agresiva protección contra bots de Amazon. Cabe destacar que aumentar la profundidad máxima prácticamente no tuvo impacto en la cantidad de páginas que Firecrawl pudo rastrear en ningún dominio.

Apify demostró el rendimiento más consistente, alcanzando el límite máximo de rastreo de 1.000 páginas en todos los dominios y en todos los niveles de profundidad sin dificultad aparente, incluso en sitios fuertemente protegidos como Amazon.

Cloudflare mostró un comportamiento inconsistente en las pruebas:

• En theregister.com con profundidad máxima 5, rastreó solo 100 páginas, pero con profundidad máxima 20 alcanzó casi 1.000 páginas.
• Como observamos en pruebas anteriores, Cloudflare ocasionalmente rastrea solo 1 página y luego finaliza el trabajo por completo. Confirmamos que no se trata de un problema de caché (la caché estaba desactivada) y probamos con tiempos de espera de hasta 1 minuto entre ejecuciones, pero el comportamiento persistió. Con una profundidad máxima de 10 en theregister.com, se produjo exactamente este problema: Cloudflare rastreó solo 1 página antes de detenerse.
• En entrepreneur.com, Cloudflare rastreó 780 páginas con profundidad 5, aumentó a 885 con profundidad 10, pero luego cayó bruscamente a solo 172 páginas con profundidad 20. Esta caída puede estar relacionada con que el planificador de rastreo de Cloudflare reduzca la prioridad o agote el tiempo de espera de las cadenas de enlaces más profundas, o podría reflejar un límite de concurrencia interno que hace que el trabajo finalice prematuramente cuando la frontera de rastreo crece demasiado en profundidades mayores.
• En amazon.com, Cloudflare rastreó 905 páginas con profundidad 5, pero la cifra disminuyó de manera constante a medida que aumentaba la profundidad máxima, cayendo a 809 con profundidad 10 y a 795 con profundidad 20, lo que sugiere que las configuraciones de rastreo más profundas pueden hacer que Cloudflare dedique más tiempo a la sobrecarga de descubrimiento de enlaces que a la recuperación real de páginas.

Nimble alcanzó o se acercó al límite de 1.000 páginas en theregister.com en todos los niveles de profundidad (1.000 / 1.000 / 999). En entrepreneur.com, rastreó 1.000 páginas con profundidad 5, pero mostró ligeras caídas en profundidades mayores (896 con profundidad 10, 983 con profundidad 20), posiblemente porque se alcanzó el tiempo de espera de 7 horas antes de completar el rastreo completo en niveles más profundos; todas las ejecuciones de Nimble finalizaron con estado de tiempo de espera. Amazon resultó más difícil:

• Con profundidad 5 solo consiguió 319 páginas, pero con profundidad 10 saltó a 988 páginas y luego bajó a 906 con profundidad 20
• Esta inconsistencia probablemente refleja la combinación de los mecanismos de protección contra bots de Amazon y las limitaciones de tiempo de espera de Nimble, ya que los rastreos más profundos tardan más en procesar cada página y pueden encontrar más desafíos anti-bots en el camino

Tiempo de ejecución por dominio según profundidad máxima

Firecrawl fue el proveedor más rápido en todos los dominios: completó los rastreos en menos de 5 minutos, normalmente entre 75 y 265 segundos. Esta velocidad tiene el costo de la cobertura, ya que Firecrawl también rastreó la menor cantidad de páginas. Básicamente, termina rápido porque se detiene antes.

Apify tardó alrededor de 2.200 a 2.400 segundos (~40 minutos) en theregister.com independientemente de la profundidad. En entrepreneur.com y amazon.com, los tiempos de ejecución fueron significativamente mayores, entre 8.300 y 15.900 segundos (2 a 4 horas), lo que refleja estructuras de sitio más grandes y complejas. A pesar de los tiempos más largos, Apify alcanzó de manera consistente el límite de 1.000 páginas, lo que lo convierte en el más fiable en términos de relación cobertura-tiempo.

Cloudflare mostró tiempos que reflejan su conteo inconsistente de rastreos:

• En theregister.com con profundidad 10, completó en solo 1 segundo porque solo rastreó 1 página antes de detenerse.
• En entrepreneur.com con profundidad 20, finalizó en 10 segundos después de rastrear solo 172 páginas.
• Cuando Cloudflare sí completa un rastreo completo, los tiempos oscilan entre 3.500 y 25.200 segundos.
• A medida que aumenta la profundidad máxima, Cloudflare parece priorizar llegar a páginas más profundas en lugar de la amplitud: rastrea menos páginas pero completa más rápido. En amazon.com, el tiempo de ejecución cayó de 25.200 segundos (tiempo de espera agotado) con profundidad 5 a solo 5.660 segundos con profundidad 20, mientras que las páginas rastreadas también disminuyeron de 905 a 795. Esto sugiere que el rastreador de Cloudflare cambia su estrategia en profundidades mayores: dedica menos tiempo al descubrimiento amplio y más a la exploración profunda.

Nimble alcanzó el tiempo de espera de 7 horas (25.200 segundos) en todas y cada una de las ejecuciones en todos los dominios y niveles de profundidad. Esto es notable porque en nuestras pruebas rápidas anteriores con profundidad máxima 1, Nimble completó sin agotar el tiempo de espera. En el benchmark completo con profundidades de 5 a 20 y un límite de 1.000 páginas, se ejecutó de manera consistente hasta que se alcanzó el tiempo de espera. A pesar de ello, Nimble consiguió rastrear un alto número de páginas en la mayoría de los casos (~900 a 1.000 en theregister.com y entrepreneur.com), lo que significa que rastrea activamente durante las 7 horas pero simplemente nunca indica la finalización.

Tasa de relleno de texto de enlace por proveedor según profundidad máxima

Para evaluar la calidad de la salida en markdown, medimos qué porcentaje de enlaces en el markdown de cada proveedor contiene texto de anclaje, la parte de texto clicable de un enlace. La falta de texto de anclaje (por ejemplo, [](/about) en lugar de [About Us](/about)) significa que el rastreador no pudo extract la etiqueta del enlace.

• Nimble: 100 % en todas las profundidades
• Cloudflare: 91 a 94 %
• Firecrawl: 90 %
• Apify: 77 a 78 %, aproximadamente 1 de cada 5 enlaces sin texto de anclaje

La profundidad de rastreo tuvo un impacto mínimo en las tasas de relleno de todos los proveedores, lo que sugiere que es una característica del motor de análisis de cada proveedor más que una configuración de rastreo.

Tasa de relleno de texto de enlace por proveedor según dominio

Observar las tasas de relleno en distintos dominios revela cómo la complejidad del sitio afecta la calidad de extracción de enlaces de cada proveedor.

• Nimble mantuvo 100 % en todos los dominios.
• Apify mostró la mayor variación: 89 % en amazon.com, pero bajó a 66 % en entrepreneur.com, lo que significa que un tercio de sus enlaces en ese sitio carecían de texto de anclaje. Esto sugiere que Apify tiene más dificultades con sitios con mucho contenido y estructuras de navegación complejas.
• Firecrawl obtuvo su mejor resultado en theregister.com (98 %), pero bajó a 81 % en entrepreneur.com, siguiendo un patrón similar al de Apify.
• Cloudflare fue el más consistente después de Nimble, manteniéndose entre 89 y 94 % independientemente del dominio.

Entrepreneur.com resultó ser el dominio más difícil para la extracción de texto de enlace: tanto Apify (66 %) como Firecrawl (81 %) obtuvieron allí sus puntuaciones más bajas, probablemente debido al uso intensivo de menús de navegación anidados y elementos de contenido dinámico que son más difíciles de convertir limpiamente a markdown.

Total de enlaces en la salida de markdown por dominio según profundidad máxima

La varianza en el número de enlaces entre proveedores fue consistentemente alta (74 a 97 %), lo que indica que los proveedores extract cantidades muy diferentes de enlaces de las mismas páginas. Para obtener una visión más detallada de esta disparidad, medimos el número total de enlaces de markdown por proveedor.

• Apify devolvió la mayor cantidad de enlaces en general, especialmente en amazon.com con más de 420K enlaces con profundidad 5 (~423 por página). En entrepreneur.com se estabilizó en torno a 63K independientemente de la profundidad. Su salida incluye rastreadores de anuncios y píxeles de seguimiento junto con enlaces de contenido de página.
• Cloudflare alcanzó un máximo de 303K en entrepreneur.com con profundidad 10, pero bajó a 53K con profundidad 20. En la misma página de inicio de entrepreneur.com, Cloudflare extrajo 434 enlaces, frente a los Apify’s 143, capturando menús de navegación completos y submenús.
• Firecrawl devolvió de manera consistente entre 5 y 9K enlaces en todas las configuraciones, limitado por su bajo número de páginas.
• Nimble devolvió entre 3 y 40K enlaces en total, con un promedio de 5 a 28 enlaces por página, frente a 60 a 420 de otros proveedores. En la página de inicio de entrepreneur.com, Nimble devolvió 13 enlaces, frente a los Cloudflare’s 434, limitados a los titulares de los artículos principales. Su tasa de relleno del 100 % refleja que todos los enlaces que incluyó tenían texto de anclaje, en lugar de indicar una cobertura integral de enlaces. Nimble no genera enlaces de markdown estándar. Su recuento incluye enlaces HTML escapados que se encuentran dentro de la salida de markdown.

Tasa de presencia de título por proveedor

La similitud de títulos entre proveedores mostró una desviación inferior al 1 % en todas las pruebas y dominios, lo que confirma que, cuando los proveedores extract un título, devuelven de manera consistente el mismo resultado. La tasa de presencia de título también se mantuvo entre 98 y 100 % en todos los niveles de profundidad máxima, lo que demuestra que la profundidad de rastreo no tiene un impacto significativo en la extracción de títulos.

Al desglosar por dominio, surgieron algunas diferencias:

En entrepreneur.com y theregister.com, la mayoría de los proveedores alcanzaron tasas de presencia de título de 99 a 100 %. Amazon.com fue el único dominio donde aparecieron diferencias significativas: Firecrawl bajó a 93 % y Nimble a 95,9 %, mientras que Apify se mantuvo en 99,6 %. Esto coincide con la mayor protección contra bots de Amazon, que puede bloquear o distorsionar las respuestas de las páginas, provocando que algunos proveedores devuelvan páginas sin títulos extraíbles.

Características de las mejores APIs de web crawler

Decodo ofrece rastreo a través de /crawl, un endpoint de su API de Web Data. Todos los endpoints de la API de Web Data se ejecutan bajo una única API y una única clave de API. Un trabajo /crawl recopila hasta 10.000 páginas y devuelve cada página como Markdown o HTML.

• Los usuarios configuran la profundidad máxima, filtran rutas con expresiones regulares y mantienen el rastreo en un host, sus subdominios o todos los dominios.
• El rastreador usa el sitemap, los enlaces de la página o ambos, y solicita las páginas desde un país y una configuración regional elegidos.
• Una duración máxima detiene el trabajo y conserva las páginas recopiladas hasta ese momento.
• Una página que falla sin JavaScript recibe un intento adicional con renderizado de JavaScript.

El endpoint /map enumera hasta 147.000 URLs de una página y del sitemap de nivel superior del sitio sin recuperar contenido, de modo que un rastreo puede dirigirse solo a rutas seleccionadas. El gratis plan incluye 10.000 solicitudes al mes sin tarjeta de crédito.

Apify rastrea sitios web mediante Website Content Crawler, un Actor en la plataforma Apify. De forma predeterminada, obtiene páginas estáticas a través de HTTP simple y cambia a un navegador headless para las páginas que necesitan JavaScript. Los usuarios también pueden ejecutarlo en modo solo navegador o solo HTTP.

• Los usuarios definen las URLs de inicio, la profundidad máxima, el máximo de páginas y los patrones de URL a incluir o excluir, y pueden añadir sitemaps para el descubrimiento.
• Una fecha de “modificado desde” limita los re-rastreos a las páginas modificadas.
• Un selector de CSS elimina la navegación, los encabezados y los pies de página antes de la conversión.
• El rastreador devuelve texto, Markdown, HTML y capturas de pantalla, y puede descargar archivos PDF, Word y Excel vinculados.

Apify conecta la salida a LangChain, LlamaIndex, Pinecone y Qdrant, y ofrece el rastreador como herramienta MCP.

Cloudflare ofrece un endpoint /crawl en su servicio Browser Rendering. Un trabajo cubre hasta 100.000 páginas y se ejecuta hasta siete días, y los resultados permanecen disponibles durante 14 días.

• El rastreador encuentra páginas a través de sitemaps, enlaces de página o ambos, y filtra las URLs con patrones de comodín.
• Renderiza las páginas en un navegador headless de forma predeterminada y, en su lugar, puede obtener HTML simple sin JavaScript.
• La salida es HTML, Markdown o JSON.

El rastreador obedece robots.txt, incluido crawl-delay, y se identifica con un agente de usuario fijo. Cloudflare afirma que no elude CAPTCHAs ni la protección contra bots.

El endpoint /crawl de Firecrawl descubre y extrae las subpáginas de una URL inicial y devuelve Markdown, HTML o JSON por cada página.

• Los usuarios definen un límite de páginas, una profundidad de descubrimiento y filtros de ruta con regex.
• El rastreo puede extenderse a rutas principales, subdominios o un salto de enlaces externos.
• El rastreador combina el sitemap con los enlaces de la página, o usa solo uno de los dos.
• Un parámetro de prompt convierte una instrucción en lenguaje natural en configuraciones de rastreo.

Los resultados llegan mediante sondeo, eventos de webhook por página o un observador de SDK, y permanecen disponibles durante 24 horas.

Nimble Crawl ejecuta cada rastreo como un trabajo en segundo plano de hasta 10.000 páginas y 20 saltos de enlace, y devuelve HTML o Markdown por cada página.

• Los usuarios filtran rutas con expresiones regulares y eligen si seguir subdominios.
• El rastreador usa el sitemap, los enlaces de la página o ambos como fuente.
• Las URLs que difieren solo en parámetros de consulta pueden contarse como una sola página.
• Cada rastreo puede ejecutarse desde un país y una configuración regional elegidos.

Una llamada de estado informa cuántas páginas están pendientes, completadas o fallidas, y el contenido de cada página proviene de su propia llamada de resultado. Las devoluciones de llamada se activan cuando comienza el rastreo, por cada página y al final.

Metodología del benchmark de web crawlers

Probamos cuatro APIs de rastreo (Apify, Nimble, Cloudflare, Firecrawl) en tres dominios de dificultad variable: amazon.com (protección intensa contra bots), entrepreneur.com (sitio de contenido complejo) y theregister.com (sitio de noticias).

Configuración compartida

Todos los proveedores recibieron configuraciones básicas idénticas para garantizar una comparación justa:

• Sitemap: desactivado; los proveedores deben descubrir páginas solo mediante enlaces HTML.
• Enlaces externos: desactivados; los rastreadores permanecen dentro del dominio objetivo.
• Subdominios: activados; se siguen las páginas de subdominios (por ejemplo, india.entrepreneur.com).
• Renderizado de JavaScript: activado; todos los proveedores usan un navegador headless.
• Caché: desactivada
• Límite de páginas: 1.000 páginas por ejecución.
• Tiempo de espera: 7 horas (25.200 segundos).
• Gestión del límite de velocidad: espera de 20 segundos con hasta 3 reintentos ante HTTP 429

Cada proveedor se probó en tres niveles de profundidad máxima (5, 10, 20) en los tres dominios, con un total de 36 ejecuciones de rastreo. Los proveedores se probaron de forma secuencial (no en paralelo), cada combinación se ejecutó una vez y el estado del rastreo se consultó cada 1 segundo.

Apify se configuró con el actor website-content-crawler usando Playwright/Firefox como navegador headless. El acceso a subdominios se controló mediante patrones glob, y se usó el proxy integrado de Apify para todas las solicitudes.

Nimble, Cloudflare y Firecrawl se configuraron mediante sus respectivas APIs REST con los ajustes compartidos descritos anteriormente. No se aplicaron configuraciones adicionales específicas del proveedor más allá de los parámetros estandarizados.

Para Cloudflare, utilizamos el plan Workers Paid. El costo reportado refleja lo que gastamos para rastrear 1.000 páginas con este plan. Cloudflare cobra en función del tiempo de renderizado del navegador, no del número de páginas.

Para Firecrawl, utilizamos el plan Hobby. El costo reportado es el importe prorrateado de 1.000 créditos de los créditos incluidos en este plan. El costo efectivo por página varía según el nivel del plan y si se compran paquetes de créditos adicionales.

Cita este benchmark

Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Şipi, Nazlı},
  title  = {{Benchmark de web crawlers  para alimentar sitios web a la IA}},
  year   = {2026},
  month  = oct,
  howpublished    = {\url{https://aimultiple.com/web-crawler}},
  note   = {AIMultiple. Recuperado el 22 de octubre de 2026}
}

Registro de cambios

9 actualizaciones

Todas9General8Metodología1

202620242023

1. 7 de abr

   Se eliminaron las secciones de tendencias del sector, tipos de rastreadores y ejemplos de rastreo web.

2. 6 de abr

   Añadido un benchmark de cuatro API de rastreo en tres dominios y tres niveles de profundidad, con gráficos de cobertura, velocidad, enlaces y títulos.

3. 6 de abr

   Añadida una sección de metodología que detalla la configuración de rastreo con cuatro proveedores, tres dominios y tres niveles de profundidad.

4. 25 de feb

   Se añadió una sección, ¿Son legales los rastreadores web?, al artículo.

5. 11 de feb

   Se actualizó la sección "¿Qué es un rastreador web?" con nuevas tendencias y modos de operación.

Cem Dilmegani

Analista Principal

Síguenos

Cem ha sido el analista principal en AIMultiple desde 2017.

El trabajo de Cem en AIMultiple ha sido citado por publicaciones líderes mundiales como Business Insider, Forbes, Morning Brew y Washington Post, empresas globales como Deloitte y HPE, ONG como World Economic Forum y organizaciones supranacionales como European Commission. [1], [2], [3], [4], [5]

A lo largo de su carrera, Cem trabajó como consultor tecnológico, comprador de tecnología y emprendedor tecnológico. Asesoró a empresas en sus decisiones tecnológicas en McKinsey & Company y Altman Solon durante más de una década. También publicó un informe de McKinsey sobre digitalización.

Dirigió la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando al CEO. También lideró el crecimiento comercial de la empresa de deep tech Hypatos, que alcanzó unos ingresos recurrentes anuales de 7 dígitos y una valoración de 9 dígitos desde 0 en 2 años. El trabajo de Cem en Hypatos fue cubierto por publicaciones tecnológicas líderes como TechCrunch y Business Insider.

Cem participa habitualmente en conferencias internacionales de tecnología. Se graduó en Bogazici University como ingeniero informático y tiene un MBA de Columbia Business School.

Ver perfil completo

Revisado técnicamente por

Nazlı Şipi

Investigadora de IA

Síguenos

Nazlı es analista de datos en AIMultiple. Tiene experiencia previa en análisis de datos en diversas industrias, donde trabajó transformando datasets complejos en información procesable.

Ver perfil completo

Comentarios 1

Comparte tus ideas

Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario

Aggeliki

Jan 12, 2022 at 16:15

Hi Cem, I think there is a misunderstanding regarding the robots.txt role in the crawling context. The web bots can crawl any website when indexing is allowed without having the robots.txt somewhere on their top domain, subdomains and ports and so on. The role of a robots.txt is to keep control of the traffic from web bots so the website is not overloaded by requests.

Responder