Casi todos los resúmenes de “mejor raspador de código abierto” arrastran un fallo silencioso: nadie prueba las herramientas en las mismas páginas. A Scrapy la evalúan con un artículo de noticias, a Playwright con algún demo de e-commerce, a Colly con lo que el autor tenía a mano, y luego las comparan cara a cara como si esos números significaran lo mismo. Ese ranking te habla de las páginas, no de las herramientas.
Así que hice lo obvio y aburrido que esas listas suelen saltarse. Monté un único conjunto de pruebas y pasé por él las nueve herramientas: un catálogo estático, un catálogo renderizado con JavaScript, un artículo perdido entre navegación y pie de página, un error HTTP 500 a propósito, un pequeño grafo de enlaces internos y dos sitios públicos de práctica. Mismo objetivo, mismas métricas, en cada ejecución. Los scripts y el resultado en bruto están en un repositorio público de benchmarks para que puedas repetir cualquier prueba por tu cuenta. Lo que salió no fue el ranking limpio que prometen los resúmenes: no existe un ganador único. Hay tres trabajos distintos, y las nueve herramientas se reparten casi solas.
Prueba Thunderbit para extraer datos web
Cómo funcionó el banco de pruebas, y la única limitación que voy a decir en voz alta
Todas las herramientas se enfrentaron a los mismos tipos de prueba: 12 productos estáticos repartidos en dos páginas, 8 productos inyectados por JavaScript tras una pausa, un artículo rodeado de basura de navegación y pie de página alrededor de tres párrafos reales, un servidor que devolvía 500 a propósito y un grafo de enlaces internos. Ese diseño es lo que hace que los resultados tengan sentido: “8/8 productos dinámicos” significa exactamente lo mismo tanto si lo produjo Puppeteer como Crawlee.
Aquí va la limitación que la mayoría de los resúmenes omite. Cada paquete de pruebas de cada herramienta replica sus propios fixtures, así que los conteos absolutos de caracteres no son estrictamente comparables entre herramientas; léelos como señales dentro de la misma herramienta, nunca como puntuaciones cruzadas. Los números que sí son comparables son el recall (tómalo como una tasa), el aprobado/suspenso en JavaScript y el comportamiento estructural. Un apunte de alcance en la misma línea: la ejecución estática de Crawl4AI cubrió solo la página uno, así que su 6/6 es recall total sobre un corte más pequeño, mientras que las demás herramientas rastrearon ambas páginas para 12/12; un alcance menor, no un fallo parcial. El razonamiento completo, fixture por fixture, está en la explicación de metodología.
Una advertencia más antes de ver los números. Cada paquete también incluye una puntuación provisional de investigación, pero a propósito no la presento como tabla ordenada. Eran ayudas internas para comprobar cada herramienta contra su propia evidencia, no una liga oficial; publicarlas como tal recrearía exactamente el problema de falsa precisión que este ejercicio intenta evitar. Esto es una síntesis de lo que mostró el banco, no un marcador.
Todo el campo, en un solo banco de pruebas
Lee las dos columnas de esta tabla —“¿Renderiza JS?” y “Cola de rastreo integrada”— y los tres trabajos prácticamente se explican solos.
| Herramienta | Lenguaje | ¿Renderiza JS? | Recall estático | Salida estructurada | Cola de rastreo integrada | Peso de configuración | Licencia |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Sí (navegador) | 6/6 (página 1) | Esquema CSS | BFS/DFS integrada | Pesado (2 stacks de navegador) | Apache-2.0 |
| Firecrawl | Autoalojado | Sí (playwright-service) | Markdown completo | Sí | /v1/crawl | El más pesado (6 contenedores) | AGPL-3.0 |
| trafilatura | Python | No | 3/3 artículo | No (solo texto) | No | Ligero | Apache-2.0 |
| Crawlee | Node/TS | Opcional según motor | 12/12 | Mediante extracción | Sí (RequestQueue) | Medio (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multilenguaje | Sí | 12/12 | Manual | No (BFS escrito a mano) | Medio (navegador) | Apache-2.0 |
| Puppeteer | Node | Sí (Chrome) | 12/12 | Manual | No (BFS escrito a mano) | Medio (Chrome) | Apache-2.0 |
| Scrapy | Python | No | 12/12 | Exportación feed (JSON/CSV/XML) | Sí (integrada) | Medio (dependencias de Twisted) | BSD-3 |
| Colly | Go | No | 12/12 | Mediante callbacks | Control de profundidad | Ligero (1 binario + Go) | Apache-2.0 |
| Scrapling | Python | No (fetcher HTTP) | 12/12 | Sí | No | Medio ([fetchers]) | BSD-3 |
Una nota sobre los metadatos de esa tabla y de todo lo que sigue: los recuentos de estrellas y las versiones se capturaron a comienzos de julio de 2026, y ambos cambian rápido. Compruébalos en GitHub y en la página del paquete de cada proyecto antes de tomarlos como actuales.
Índice de reseñas de cada herramienta
Cada proyecto de este resumen tiene su análisis en profundidad correspondiente:
- Reseña de Crawl4AI
- Reseña de Firecrawl
- Reseña de trafilatura
- Comparativa Playwright vs Puppeteer
- Reseña de Crawlee
- Reseña de Scrapy
- Reseña de Colly
- Reseña de Scrapling
Aquí tienes sus portadas, además de dos capturas reales de la prueba de renderizado JavaScript, para que la afirmación de “8/8 dinámicos” no sea solo un número en una página.
Trabajo 1: convertir una página en texto listo para LLM
Si lo que quieres es Markdown limpio para alimentar un pipeline RAG, compiten tres herramientas, y no podrían ser más distintas.
Crawl4AI es, más allá del marketing, un generador de Markdown apoyado en navegador. Conviene desmontar la historia del “selector que se autoaprende con inteligencia adaptativa” que lo acompaña por los buscadores: no tiene nada de eso; ese truco pertenece a otra biblioteca (volveremos a ello cuando hablemos de Scrapling). Pero lo que sí hace, lo hace bien. En el sitio de práctica Books to Scrape emitió 13.476 caracteres de Markdown, maneja extracción con esquema CSS para capturas estructuradas y su BFS de rastreo profundo integrado recorrió 5 páginas en el grafo de rastreo mientras renderizaba una página JavaScript y sacaba una captura. Aun así, tiene dos puntos débiles. Su Markdown bruto arrastra el relleno de la página si no activas un filtro de contenido, y el 500 intencional volvió como success=false —no porque Crawl4AI detectara limpiamente el error HTTP, sino porque su propio heurístico de contenido miró el cuerpo mínimo del error y lo etiquetó como minimal_text ... blocked. Además, la configuración añade dos stacks de navegador al disco. Versión 0.9.0, Apache-2.0, unas 71k estrellas a comienzos de julio.
Firecrawl es el peso pesado, y autoalojarlo funciona de verdad; digo “de verdad” porque la pila de seis contenedores (api, playwright-service, redis, rabbitmq, nuq-postgres y foundationdb) arrancó y produjo 9.222 caracteres de Markdown listo para LLM a partir de la misma página Books to Scrape. Renderizó una página JavaScript a través de su playwright-service incluido, y la cita de Einstein que aparece después del script salió en el resultado, lo que demuestra que el render fue real. Dos problemas que encontré fueron culpa del entorno, no de Firecrawl, y quiero ser preciso para que nadie copie la solución equivocada: una compilación desde código fuente tropezó con una falla puntual de containerd snapshotter bajo colima (cambié a las imágenes preconstruidas), y el rango DNS 198.18.x.x de colima activó la defensa SSRF de Firecrawl, que resolví con ALLOW_LOCAL_WEBHOOKS=true —un apaño para desarrollo local, no algo que deba desactivarse en producción. El núcleo autoalojado tampoco incluye Fire-engine, la capa antiblqueo en la nube, y no probé la API cloud. La advertencia más importante es la licencia: el núcleo autoalojado de Firecrawl es AGPL-3.0, algo que exige una revisión legal real antes de cualquier uso comercial, no una nota al pie. Unas 148k estrellas a comienzos de julio.
trafilatura es la voz contraria del grupo, y la que las listas infladas por IA siguen olvidando. Sin navegador. Sin filas estructuradas. Solo texto de artículo rápido y limpio en puro Python. En el fixture del artículo extrajo el título y los 3 de los 3 párrafos reales, eliminó por completo el relleno —no se coló ningún “Login”, “Subscribe” ni “Copyright”— y además recuperó el autor y la fecha. En una página pública de producto devolvió 1.324 caracteres de texto limpio. Su límite es exactamente el que su diseño sugiere: si lo apuntas a un catálogo, te devuelve 12 nombres de producto como texto, pero 0 filas estructuradas; el texto está, la estructura no, y no renderiza JavaScript. Versión 2.1.0 (la actual), Apache-2.0, unas 6.2k estrellas. Para extracción pura de artículos, sería mi primera opción.
Esos dos conteos de caracteres de Markdown —13.476 de Crawl4AI y 9.222 de Firecrawl— salieron de la misma página pública, pero no deben leerse como una diferencia de calidad. Reflejan distintas estrategias de Markdown (cuánto relleno de la página conserva cada una), no un veredicto sobre cuál salida es mejor. Esa regla de la señal dentro de la misma herramienta, de antes, aquí se ve claramente.
Trabajo 2: renderizar JavaScript de forma fiable
Algunos datos simplemente no están en el HTML hasta que se ejecutan los scripts, y ahí es cuando un navegador real deja de ser opcional. Tres herramientas cubren este trabajo, y dos de ellas resultaron ser casi la misma herramienta.
Playwright y Puppeteer empataron en todas las pruebas que les lancé. Ambos renderizaron 8/8 productos dinámicos en el fixture local y 10 en el sitio público Quotes JS, ambos alcanzaron 12/12 de recall estático, y ambos gestionaron el 500 limpiamente (Puppeteer devuelve un objeto response en lugar de lanzar excepción). Ninguno trae cola de rastreo, así que en los dos casos hubo que escribir un BFS a mano para recorrer el grafo de 12 páginas. La única diferencia real es el alcance: Playwright controla Chromium, Firefox y WebKit y funciona con Python y .NET, mientras que Puppeteer está centrado en Chrome y solo usa Node. Dos aclaraciones, porque aquí las versiones cambian rápido: probé Playwright 1.56.0 frente a la actual 1.61.1 y solo con Chromium, y Puppeteer 24.16.0 frente a la actual 25.3.0; tómalo con ese contexto. Ambos con Apache-2.0; aproximadamente 92k y 95k estrellas, respectivamente.
Crawlee es el que resuelve el problema de la cola que los otros dos dejan abierto. Envuelve un motor Cheerio (HTTP) y un motor Playwright (navegador) tras una sola API, y el contraste en una sola página resume toda la propuesta: el motor Cheerio vio 0 elementos inyectados por JavaScript, el motor Playwright vio 8/8 en local (y 10 en el sitio público), y cambiar de uno a otro es una modificación de una línea. También te da una RequestQueue real, que es lo que le gana un lugar en este trabajo y no en el siguiente. El matiz que nadie pone en el titular: el motor de navegador requiere un npx playwright install aparte, unos 80 MiB que npm install crawlee no descarga por ti. Versión 3.17.0, TypeScript, Apache-2.0, unas 24.6k estrellas.
Trabajo 3: rastrear rápido sin navegador
Si la página no tiene JavaScript, usar un navegador es un despilfarro caro. Aquí compiten tres herramientas HTTP-first, una por filosofía de lenguaje, y discrepan de forma interesante.
Scrapy es el framework de nivel ingenieril del grupo: spiders, exportación a feeds JSON/CSV/XML, AutoThrottle y todo lo demás. Logró 12/12 de recall estático, extrajo los 3/3 párrafos del artículo, recorrió 11 páginas entre profundidad 0 y 2 en el grafo de rastreo y capturó el 500 mediante handle_httpstatus_list. Su manera de ver el mundo es lo interesante: no renderiza, reproduce la petición. Si lo enfrentas a la página JavaScript obtuvo 0 nodos, y luego la API JSON detrás de esa misma página le devolvió 8/8. Esa es la filosofía de Scrapy en un solo dato: encuentra la petición que hace la página y repítela; no conduzcas un navegador. El coste es una pila de dependencias considerable (Twisted, lxml, parsel), y solo la probé con fixtures pequeños. Versión 2.17.0, BSD-3-Clause, unas 63k estrellas.
Colly es la respuesta en Go, y dice con bastante franqueza lo que es: un binario estático, basado en callbacks a través de OnHTML, OnResponse y OnError, con control de profundidad. Clavó 12/12 en recall estático, sacó 8/8 desde la API JSON mediante OnResponse, capturó el 500 con OnError y llegó a 17 páginas en un rastreo de profundidad 2; y lo formulo exactamente así porque ese conteo de páginas es el medidor del harness, no una garantía de completitud que Colly prometa. Lo que no hace es JavaScript: el fixture dinámico y el sitio Quotes JS devolvieron 0, por diseño. Necesitarás un toolchain de Go para compilarlo, y la versión del módulo (v2.3.0) va actualmente por delante de la versión etiquetada (v2.2.0). Apache-2.0, unas 25k estrellas.
Scrapling es la especialista, y se gana el nombre. Sus selectores adaptativos están pensados para volver a localizar un elemento cuando cambia el marcado; así que cuando renombré la clase HTML de un objetivo de product-name a product-title, un selector normal marcó 0, pero el reencuentro adaptativo recuperó el elemento rastreado igualmente. En extracción HTTP pura alcanzó 12/12 en estático y 8/8 en la API JSON. La parte que sus propios docs no esconden: en una prueba sintética con varios elementos recuperó 1 de 3; esto es seguimiento resistente de elementos, no recuperación total, así que no lo sobrevendamos mentalmente. Su instalación base pip install scrapling también necesita el extra [fetchers] para arrancar, y su StealthyFetcher es una advertencia de cumplimiento, no una función que yo pondría en una diapositiva. Versión 0.4.10 (la actual), BSD-3-Clause, unas 68.7k estrellas.
El patrón detrás de los tres trabajos
Si alineas las nueve herramientas, aparece algo muy claro. El recall estático total —un plano 12/12— es el requisito mínimo para cualquier herramienta HTTP-first; ninguna falló en el caso fácil, así que no diferencia a unas de otras. Las herramientas de navegador solo justifican su peso extra cuando de verdad hay JavaScript en juego, y todas pagan ese precio en configuración: un stack de navegador, una instalación adicional o una granja de contenedores completa. Y la columna de “cola de rastreo integrada” marca realmente la frontera entre un framework y un motor: Scrapy y Crawlee traen orquestación, mientras que Playwright y Puppeteer te obligan a escribir el BFS a mano. Esa es la forma del campo. Nadie gana en términos absolutos porque nadie está jugando al mismo juego.
Entonces, ¿cuál deberías elegir de verdad?
El banco se niega a coronar a un ganador porque la respuesta correcta no es una herramienta, sino una pregunta: ¿qué de los tres trabajos estás haciendo?
- ¿Necesitas Markdown listo para LLM? Elige trafilatura si buscas texto de artículo limpio; Crawl4AI si además quieres extracción CSS y renderizado JavaScript en una sola biblioteca; y Firecrawl si específicamente quieres un servicio autoalojado y puedes asumir tanto la licencia AGPL-3.0 como el peso de seis contenedores.
- ¿Necesitas renderizar JavaScript? Usa Playwright o Puppeteer para el render puro —elige por motor y lenguaje, porque en lo demás empatan— y Crawlee cuando además quieras que la orquestación de rastreo te la den hecha en vez de escribirla a mano.
- ¿Vas a rastrear páginas estáticas o APIs reproducibles a escala? Scrapy si quieres un framework completo en Python, Colly si prefieres velocidad bruta en Go en un solo binario, y Scrapling cuando tu dolor recurrente sea sobrevivir al cambio de marcado.
Si eliges la herramienta adecuada para el trabajo, todas son opciones defendibles. Si eliges de la categoría equivocada —un navegador para páginas estáticas, o un parser HTTP para una app JavaScript—, la biblioteca mejor valorada de internet también te va a fallar.
Dónde encaja en cambio una API de IA gestionada
Todas las herramientas anteriores son gratuitas, de código abierto y tuyas para ejecutar. Esa también es la contrapartida común que el banco deja al descubierto: tú te encargas del entorno de navegador, del código de rastreo, de la guerra contra los bots y de todo el mantenimiento. Para muchos equipos, ese control es exactamente el objetivo, y el mapa de licencias importa cuando lo asumes: la mayoría del campo es permisiva (Apache-2.0 en Crawl4AI, Crawlee, Playwright, Puppeteer y Colly; BSD-3 en Scrapy y Scrapling), con el núcleo autoalojado de Firecrawl en AGPL-3.0 como el único que necesita una revisión seria antes de uso comercial.
Pero fíjate en lo que también muestra el banco: lo que estas herramientas no hacen. Renderizar, rastrear, estructurar y sortear bloqueos —rara vez todo a la vez, y nunca sin mantenimiento por tu parte. Una API gestionada de scraping con IA comprime toda esa pila en una sola llamada. Nuestra propia superficie para desarrolladores en Thunderbit es una opción ahí, y para un público técnico lo importante es la API, el servidor MCP y la CLI, no la extensión del navegador. POST /distill devuelve Markdown limpio y POST /extract devuelve JSON definido por esquema, con el renderizado JavaScript y la protección anti-bot gestionados en el servidor, no en tu máquina. Hay un servidor MCP oficial para agentes y asistentes de código: thunderbit_suggest_fields se ejecuta gratis para planificar una extracción, luego thunderbit_distill (1 crédito) y thunderbit_extract (20 créditos) hacen el trabajo; y también una CLI que puedes instalar con npx @thunderbit/thunderbit-cli para terminal y tareas cron. Para los no desarrolladores del equipo, además existe una extensión de Chrome sin código, y la tarificación cubre ambas dimensiones.
La decisión es la misma que recorre todo este banco: ejecutar y mantener hasta nueve bibliotecas por tu cuenta sin coste por llamada, o delegar la infraestructura y pagar por solicitud. Ninguna de las dos opciones es incorrecta. Todo depende de cuánto de la pila quieras realmente asumir. Si prefieres ver cómo queda la extracción en la práctica, el canal de YouTube de Thunderbit la explica paso a paso.
{{INTERNAL_BLOG_LINKS}}
Veredicto
No existe el mejor raspador de código abierto, y cualquier lista que te entregue uno con total seguridad está ocultando la pregunta que realmente decide: ¿qué trabajo estás haciendo?
Convertir una página en texto, renderizar JavaScript o rastrear rápido sin navegador: el campo se divide con claridad en esos grupos, y dentro de cada uno la elección depende del lenguaje y del peso de la configuración, no de un campeón universal.
Si te quedas con un hábito de todo esto, que sea este: prueba en tus propias páginas antes de comprometerte con nada. Todos los números de aquí se pueden reproducir en el repositorio del benchmark precisamente por eso: porque la herramienta que lidera un resumen genérico y la que sobrevive a tus objetivos reales no siempre es la misma.
Prueba Thunderbit para extraer datos web Get Started Free
Preguntas frecuentes
¿Cuál es el mejor raspador web de código abierto? No hay uno solo; depende del trabajo. Para texto listo para LLM, trafilatura o Crawl4AI; para renderizado JavaScript, Playwright, Puppeteer o Crawlee; para rastreo HTTP rápido, Scrapy o Colly. En un banco de pruebas compartido, cada herramienta fue más fuerte dentro de su propia categoría y bastante más débil fuera de ella, por eso los rankings de talla única confunden.
¿Qué raspadores de código abierto renderizan JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer y el motor Playwright de Crawlee renderizan JavaScript. Scrapy, Colly, trafilatura y el fetcher HTTP por defecto de Scrapling no lo hacen: o bien necesitan una API reproducible detrás de la página (el enfoque de Scrapy, que obtuvo 8/8 desde el endpoint JSON), o un modo de navegador aparte.
¿Necesito un navegador headless para extraer un sitio? Solo si los datos aparecen después de ejecutar JavaScript. Si una petición HTTP normal más un parser pueden llegar al contenido, un navegador es un exceso caro; Scrapy, Colly o Scrapling serán mucho más ligeros y rápidos en ese caso.
¿Cuál de estas opciones tiene la licencia más favorable para uso comercial? La mayoría son permisivas: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) o BSD-3-Clause (Scrapy, Scrapling). La excepción es el núcleo autoalojado de Firecrawl, que usa AGPL-3.0 y merece una revisión legal seria antes de construir un producto comercial sobre él.
¿Son reproducibles estos números del benchmark? Sí. Cada runner, fixture y resultado bruto está en un repositorio público con licencia MIT. El único matiz que conviene recordar: el recall y los resultados estructurales sí son comparables entre herramientas, pero los conteos absolutos de caracteres solo valen dentro de cada herramienta, porque cada paquete replica los fixtures en lugar de compartir una copia canónica única; así que compara tasas y aprobado/suspenso, no totales brutos de caracteres.
