Casi todos los recopilatorios de “mejores scrapers de código abierto” tienen un fallo silencioso: nadie ejecuta las herramientas sobre las mismas páginas. Scrapy se prueba con un artículo de noticias, Playwright con una demo de comercio electrónico, Colly con lo que el autor tenía a mano… y luego se comparan cara a cara, como si esos números significaran lo mismo. Ese ranking te habla más de las páginas que de las herramientas.
Así que hice lo obvio, aunque sea lo más tedioso, y justo lo que estas listas suelen saltarse. Preparé un único conjunto de casos de prueba y pasé las nueve herramientas por él: un catálogo estático, un catálogo renderizado con JavaScript, un artículo escondido entre menús y pies de página, un HTTP 500 provocado a propósito, un pequeño grafo de enlaces internos, y además dos sitios públicos de práctica. La misma verdad de referencia, las mismas métricas, en cada ejecución. Los scripts y la salida en bruto están en un repositorio público de benchmark para que puedas repetir cualquier prueba por tu cuenta. Lo que salió no fue el ranking limpio que prometen los recopilatorios: no hay un ganador único. Hay tres trabajos distintos, y las nueve herramientas se reparten casi de forma natural entre ellos.
Prueba Thunderbit para extracción de datos web
Cómo se hizo el benchmark y la única limitación que diré en voz alta
Cada herramienta pasó por las mismas clases de fixture: 12 productos estáticos repartidos en dos páginas, 8 productos inyectados por JavaScript tras un retraso, un artículo rodeado de contenido sobrante de navegación y pie de página alrededor de tres párrafos reales, un error 500 intencional del servidor 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 si lo produjo Crawlee.
Aquí va el límite que la mayoría de recopilatorios pasa por alto. Cada paquete de resultados de cada herramienta refleja sus propias copias de esos fixtures, así que los conteos absolutos de caracteres no son estrictamente comparables entre herramientas: léelos como señales dentro de una misma herramienta, nunca como una puntuación entre herramientas. Las cifras que sí se pueden comparar son el recall (tómalo como una tasa), el aprobado/suspendido de JavaScript y el comportamiento estructural. Una nota de alcance en el mismo espíritu: la ejecución de Crawl4AI sobre el catálogo estático cubrió solo la página 1, así que su 6/6 es recall completo sobre un tramo más reducido, mientras que las demás herramientas rastrearon ambas páginas para llegar a 12/12: un alcance menor, no una omisión parcial. El razonamiento completo, fixture por fixture, está en la explicación de metodología.
Una advertencia más antes de los números. Cada paquete también incluye una puntuación provisional de investigación, pero a propósito no la presento como tabla de clasificación. Eran ayudas internas para verificar cada herramienta frente a su propia evidencia, no una liga oficial; publicarlas como tal recrearía exactamente el problema de falsa precisión que todo este ejercicio intenta evitar. Esto es una síntesis de lo que mostró el benchmark, no una tabla de posiciones.
Todo el panorama, sobre 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 integrado | 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/multi | 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 de feed (JSON/CSV/XML) | Sí (integrada) | Medio (dependencias 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: el número de estrellas y las versiones se capturaron a principios de julio de 2026, y ambos cambian rápido. Revísalos en GitHub y en la página del paquete de cada proyecto antes de tomarlos como actuales.
Índice de reseñas individuales
Cada proyecto de este recopilatorio tiene su análisis en profundidad correspondiente:
- Reseña de Crawl4AI
- Reseña de Firecrawl
- Reseña de trafilatura
- Comparación entre Playwright y Puppeteer
- Reseña de Crawlee
- Reseña de Scrapy
- Reseña de Colly
- Reseña de Scrapling
Aquí tienes sus portadas, más dos capturas reales de la prueba de renderizado con JavaScript, para que la afirmación de “8/8 dinámicos” no sea solo un número en la 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 entre sí.
Crawl4AI es, más allá del marketing, un generador de Markdown apoyado en navegador. Conviene desmontar la narrativa del “selector de inteligencia adaptativa que aprende solo” que suele aparecer en los resultados de búsqueda: no existe tal cosa; ese truco pertenece a otra biblioteca distinta (más sobre eso cuando lleguemos a Scrapling). Lo que realmente 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 obtenciones estructuradas, y su BFS de rastreo profundo integrado recorrió 5 páginas en el fixture del grafo de rastreo mientras renderizaba una página con JavaScript y sacaba una captura. Dos pegas reales, eso sí. Su Markdown bruto arrastra el contenido de relleno de la página salvo que actives un filtro de contenido, y el 500 intencional volvió como success=false —no porque Crawl4AI capturara limpiamente el error HTTP, sino porque su propio heurístico de contenido miró el cuerpo mínimo del error y lo marcó como minimal_text ... blocked. Además, la configuración deja dos stacks de navegador ocupando espacio en disco. Versión 0.9.0, Apache-2.0, unas 71k estrellas a principios de julio.
Firecrawl es el peso pesado, y autoalojarlo funciona de verdad —digo “de verdad” porque el stack 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 de Books to Scrape. Renderizó una página con JavaScript a través de su playwright-service integrado, y la cita de Einstein añadida por script apareció en la salida, lo que confirmó que el render era real. Los dos tropiezos que tuve 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 chocó con un fallo puntual del snapshotter de containerd en colima (cambié a las imágenes preconstruidas), y el rango DNS 198.18.x.x de colima activó la protección SSRF de Firecrawl, que resolví con ALLOW_LOCAL_WEBHOOKS=true —un apaño para desarrollo local, no algo que debas desactivar en una instalación real. El núcleo autoalojado tampoco incluye Fire-engine, la capa anti-bloqueo de la nube, y no probé la API cloud. El aviso 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 principios de julio.
trafilatura es el inconformista del grupo, y precisamente el que las listas infladas por la IA suelen pasar por alto. Sin navegador. Sin filas estructuradas. Solo texto de artículo rápido y limpio, en Python puro. 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 filtró ni “Login”, ni “Subscribe”, ni “Copyright”— y además recuperó autor y fecha. En una página pública de producto devolvió 1.324 caracteres de texto limpio. Su límite es justo 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, es la primera opción a la que acudiría.
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 estrategias distintas de Markdown (cuánto “vestido” de la página conserva cada uno), no un veredicto sobre cuál salida es mejor. Es la regla de la señal dentro de la herramienta que mencioné antes, aplicada abiertamente.
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 donde un navegador real deja de ser opcional. Tres herramientas cubren este trabajo, y dos 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 resolvieron el 500 correctamente (Puppeteer devuelve un objeto response en lugar de lanzar una excepción). Ninguno incluye cola de rastreo, así que ambos necesitaron un BFS escrito a mano, que alcanzó 12 páginas en profundidad 0–2 sobre el grafo de rastreo. La única diferencia real es el alcance: Playwright controla Chromium, Firefox y WebKit, y habla Python y .NET, mientras que Puppeteer está orientado primero a Chrome y solo funciona con Node. Dos aclaraciones, porque aquí las versiones cambian rápido: probé Playwright 1.56.0 frente a una actual 1.61.1 y solo ejercité Chromium; y Puppeteer 24.16.0 frente a una actual 25.3.0: repítelo o descuéntalo en consecuencia. Ambos con Apache-2.0; unas 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) bajo una única API, y el contraste en una sola página es toda su 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 entre ambos es cuestión de una sola línea. Además te da una RequestQueue real, y eso es lo que le gana su sitio en este trabajo y no en el tercero. La trampa que nadie pone en el titular: el motor de navegador necesita 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, alrededor de 24.6k estrellas.
Trabajo 3: rastrear rápido sin navegador
Si no hay JavaScript en la página, usar un navegador es un despilfarro. Aquí compiten tres herramientas centradas en HTTP, una por filosofía de lenguaje, y no están de acuerdo en cosas interesantes.
Scrapy es el framework de nivel ingeniería del grupo: spiders, exportación de feeds a 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 en profundidad 0–2 sobre el grafo de rastreo y capturó el 500 mediante handle_httpstatus_list. Lo interesante es su filosofía: no renderiza, reproduce la petición. Si lo lanzas contra la página JavaScript, obtuvo 0 nodos; pero 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 reprodúcela, no conduzcas un navegador. El coste es una pila de dependencias considerable (Twisted, lxml, parsel), y solo lo probé con fixtures pequeños. Versión 2.17.0, BSD-3-Clause, unas 63k estrellas.
Colly es la respuesta de Go, y es refrescantemente literal sobre lo que es: un binario único, basado en callbacks a través de OnHTML, OnResponse y OnError, con control de profundidad. Clavó 12/12 de recall estático, extrajo 8/8 desde la API JSON mediante OnResponse, capturó el 500 con OnError y alcanzó 17 páginas en un rastreo de profundidad 2 —y lo diré exactamente así, porque ese conteo de páginas es el 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 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 el especialista, y se gana esa etiqueta. Sus selectores adaptativos están pensados para volver a localizar un elemento después de que cambie el marcado: así que cuando renombré la clase HTML de un objetivo de product-name a product-title, un selector normal encontró 0, y el reemparejamiento adaptativo recuperó igualmente el elemento rastreado. En extracción HTTP simple alcanzó 12/12 en estático y 8/8 en la API JSON. Lo que sus propias docs no esconden: en una prueba sintética con varios elementos recuperó 1 de 3; esto es seguimiento resiliente de elementos, no recuperación total, así que no conviene venderlo como algo que no es. Además, su pip install scrapling base necesita el extra [fetchers] para arrancar, y su StealthyFetcher es más una advertencia de cumplimiento que una función para presumir en una diapositiva. Versión 0.4.10 (la actual), BSD-3-Clause, unas 68.7k estrellas.
El patrón que hay debajo de los tres trabajos
Si alineas las nueve herramientas, aparece una lectura bastante clara. El recall estático total —un plano 12/12— es el mínimo esperable para cualquier herramienta centrada en HTTP; ninguna falló el caso fácil, así que no diferencia. Las herramientas con navegador solo justifican su peso extra cuando JavaScript entra de verdad en juego, y todas lo pagan en configuración: un stack de navegador, una instalación adicional o toda una flota de contenedores. Y la columna “cola de rastreo integrada” marca realmente la diferencia entre un framework y un motor: Scrapy y Crawlee aportan orquestación, mientras que Playwright y Puppeteer te obligan a escribir el BFS a mano. Esa es la forma del sector. Nadie gana en global porque nadie está jugando al mismo juego.
Entonces, ¿cuál deberías elegir de verdad?
El benchmark se niega a coronar un ganador porque la respuesta correcta no es una herramienta, sino una pregunta: ¿cuál de los tres trabajos estás haciendo?
- ¿Necesitas Markdown listo para LLM? Usa 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 aceptar tanto la licencia AGPL-3.0 como el peso de seis contenedores.
- ¿Necesitas renderizado de JavaScript? Playwright o Puppeteer para el render puro: elige por motor y lenguaje, porque por lo demás están empatados; y Crawlee cuando además quieres la orquestación del rastreo ya resuelta y no escrita a mano.
- ¿Rastrear páginas estáticas o APIs reproducibles a escala? Scrapy para un framework Python completo, Colly para velocidad bruta en Go en un solo binario, y Scrapling cuando tu dolor específico y recurrente es sobrevivir al cambio de marcado.
Ajusta la herramienta al trabajo y cualquiera de estas opciones es defendible. Coge la categoría equivocada —una herramienta con navegador para páginas estáticas, o un parser HTTP para una app con JavaScript— y ni siquiera la biblioteca mejor valorada de Internet te salvará.
Dónde encaja una API de IA gestionada en su lugar
Todas las herramientas anteriores son gratuitas, de código abierto y las puedes ejecutar tú mismo. Ese es también el compromiso común que el benchmark deja al descubierto: tú te ocupas del entorno de navegador, del código de rastreo, de la carrera armamentística contra los antibots y de todo el mantenimiento. Para muchos equipos, precisamente ese control es el objetivo, y el mapa de licencias importa cuando lo asumes: la mayor parte del sector es permisiva (Apache-2.0 en Crawl4AI, Crawlee, Playwright, Puppeteer y Colly; BSD-3 en Scrapy y Scrapling), con el núcleo autoalojado AGPL-3.0 de Firecrawl como la única opción que merece una revisión seria antes de uso comercial.
Pero fíjate en lo que también dejó claro el benchmark: lo que estas herramientas no hacen. Renderizar, rastrear, estructurar y sortear bloqueos rara vez ocurre 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 importan 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 renderizado de JavaScript y anti-bloqueo gestionados del lado del servidor en lugar de en tu máquina. Hay un servidor MCP oficial para agentes y asistentes de programación: thunderbit_suggest_fields se ejecuta gratis para planificar una extracción, y luego thunderbit_distill (1 crédito) y thunderbit_extract (20 créditos) hacen el trabajo; además de una CLI que puedes instalar con npx @thunderbit/thunderbit-cli para terminal y tareas cron. Para los miembros no técnicos del equipo también hay una extensión de Chrome sin código, y los precios cubren ambas dimensiones.
La disyuntiva es la misma que atraviesa todo este benchmark: ejecutar y mantener hasta nueve bibliotecas por tu cuenta sin coste por llamada, o delegar la infraestructura y pagar por petición. Ninguna opción es incorrecta. Todo depende de cuánto de la pila quieres realmente asumir. Si prefieres ver cómo se ve la extracción en la práctica, el canal de YouTube de Thunderbit lo muestra paso a paso.
Veredicto
No existe el mejor scraper de código abierto en singular, y cualquier lista que te entregue uno con seguridad está ocultando en silencio la pregunta que de verdad lo decide: ¿qué trabajo estás haciendo?
Si te llevas un hábito de todo esto, que sea este: prueba en tus propias páginas antes de comprometerte con nada. Cada número de aquí se puede reproducir en el repositorio del benchmark precisamente por esa razón: porque la herramienta que lidera un recopilatorio genérico y la que sobrevive a tus objetivos reales no siempre es la misma.
Prueba Thunderbit para extracción de datos web Get Started Free
Preguntas frecuentes
¿Cuál es el mejor scraper 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 destacó dentro de su propia categoría y rindió claramente peor fuera de ella, por eso los rankings de talla única inducen a error.
¿Qué scrapers 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 consiguió 8/8 desde el endpoint JSON), o bien un modo de navegador aparte.
¿Necesito un navegador sin interfaz para rastrear un sitio? Solo si los datos aparecen después de ejecutar JavaScript. Si una simple petición HTTP más un parser puede llegar al contenido, un navegador es un exceso caro; Scrapy, Colly o Scrapling serán mucho más ligeros y rápidos para ese caso.
¿Cuál de estas opciones tiene la licencia más amigable 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 es AGPL-3.0 y merece una revisión legal seria antes de construir un producto comercial sobre él.
¿Son reproducibles estos números de benchmark? Sí. Cada runner, fixture y resultado en bruto está en un repositorio público con licencia MIT. La única salvedad 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/suspendido, no totales brutos de caracteres.
