Probé Crawl4AI (74K ⭐ en GitHub) para scrapear 500 páginas y esto es lo que aprendí

25 julio, 2026 · Sección: Guías y Tutoriales

Llevaba meses usando Firecrawl para alimentar mi segundo cerebro con documentación técnica. Funcionaba bien. Pero la factura de julio llegó a 47 dólares por 3.200 páginas scrapeadas — y encima 14 de esas páginas volvieron con el contenido cortado a mitad. No es que Firecrawl sea malo. Es que para lo que yo necesito (scrapear docs técnicas, nada de JavaScript pesado, todo a Markdown limpio) me pareció demasiado. Así que el miércoles pasado —22 de julio— me senté a probar Crawl4AI, la librería open source de unclecode que lleva 74.000 estrellas en GitHub. Spoiler: no he vuelto a abrir Firecrawl.

Qué es Crawl4AI (y qué no es)

Crawl4AI es un crawler web que convierte cualquier página en Markdown limpio, listo para meter en un LLM. No es una API SaaS como Firecrawl o Jina AI. Es una librería de Python que instalas con pip install crawl4ai y corre en tu máquina. Sin límites de créditos, sin suscripciones, sin que un tercero vea lo que scrapeas.

Lo que hace por debajo: lanza un navegador headless con Playwright, carga la página, ejecuta JavaScript si hace falta, y luego aplica filtros para extraer solo el contenido relevante — quitando menús, banners de cookies, sidebars, footers. El resultado es un .md que puedes pasar directamente a Claude, GPT, o tu base de datos vectorial.

Lo instalé en mi Raspberry Pi 5 (8 GB), que es donde tengo corriendo Hermes Agent y mi stack de automatización. La instalación fue un pip install crawl4ai y un crawl4ai-setup para bajar los binarios de Playwright. 3 minutos. Cero drama.

El experimento: 500 páginas de documentación

Mi caso de uso es bastante concreto: cada semana mi agente de IA necesita indexar documentación de librerías nuevas. Normalmente son docs técnicas — React, Next.js, LangChain, cosas así. Páginas estáticas, poco JavaScript cliente, a veces generadas con Docusaurus o Nextra. Nada de SPAs pesadas ni infinite scroll.

Cogí 500 URLs de documentación que ya tenía en mi cola de indexación. 487 eran sitios estáticos. 13 tenían carga dinámica parcial. Las metí en un script que lanza Crawl4AI con concurrencia controlada (5 workers simultáneos, para no reventar la Pi 5 ni hacerme banear de ningún lado).

El código que usé:

import asyncio
from crawl4ai import AsyncWebCrawler, CrawlerRunConfig

async def scrape_urls(urls):
    config = CrawlerRunConfig(
        word_count_threshold=10,
        exclude_tags=["nav", "footer", "header"],
        remove_overlay_elements=True,
        cache_mode="ENABLED"
    )
    
    async with AsyncWebCrawler() as crawler:
        results = await crawler.arun_many(
            urls=urls,
            config=config,
            max_concurrent=5
        )
    return results

urls = [...]  # 500 URLs de documentación
results = asyncio.run(scrape_urls(urls))

Resultados reales

De las 500 URLs:

• 470 páginas (94%) se scrapearon completas, con Markdown limpio y usable.
• 18 páginas (3.6%) volvieron con contenido parcial — típicamente porque el sitio bloqueó el headless browser con Cloudflare o similar.
• 12 páginas (2.4%) fallaron completamente: 8 por timeouts, 4 porque las URLs devolvían 404 (eran viejas, culpa mía).

Tiempo total: 39 segundos. Eso son 12.8 páginas por segundo con 5 workers en una Raspberry Pi 5. Para comparar: Firecrawl me habría costado unos 3.50 dólares por este mismo lote y tardado unos 2-3 minutos (por los rate limits del plan hobby).

El Markdown generado es sorprendentemente bueno. No es perfecto — a veces mete saltos de línea de más en tablas, y los fragmentos de código inline a veces pierden el backtick — pero el 90% de las páginas salieron listas para indexar sin editar una sola línea. Para RAG, funciona.

Lo que falló (y cómo lo arreglé)

No todo fue perfecto. Aquí van las cosas que me hicieron sudar:

1. Cloudflare y WAFs. Crawl4AI usa Playwright por debajo, y algunos sitios detectan navegadores headless. Para los 18 casos que fallaron parcialmente, probé a añadir headless=False (más lento pero más difícil de detectar) y rotar user agents. En 11 de esos 18 funcionó. Los otros 7 simplemente no se dejan scrapear sin una API key — y eso no es culpa de Crawl4AI.

2. La caché no hace magia. Crawl4AI tiene un sistema de caché en SQLite. La primera tanda fue rapidísima porque las páginas eran nuevas. Cuando reintenté las 18 fallidas, el modo caché a veces devolvía la versión vacía anterior. Tuve que limpiar la caché manualmente (crawl4ai-cache --clear) antes de cada reintento. Pequeña molestia.

3. Documentación aceptable, no excelente. El README de GitHub está bien, pero algunas opciones avanzadas (filtros de contenido personalizados, extracción con esquemas JSON) las tuve que sacar de los issues de GitHub. Hay 74K estrellas pero la documentación no está al mismo nivel. Es un proyecto que se mueve rápido y los docs van por detrás.

Crawl4AI vs Firecrawl vs Jina AI

He usado los tres. Mi opinión:

• Firecrawl: El más pulido. Extracción con schemas, mapas de sitio automáticos, UI bonita. Pero cuesta dinero y tienes que confiar en que no van a leer tus datos. Para una empresa con presupuesto, probablemente la mejor opción.
• Jina AI Reader: Gratis para uso ligero, la calidad del Markdown es excelente, pero el rate limit te estrangula en cuanto scrapeas más de 200 páginas al día. Buena opción para proyectos pequeños.
• Crawl4AI: Gratis, self-hosted, rápido, y el output es suficientemente bueno para RAG. La contrapartida: tú montas la infraestructura, tú gestionas los reintentos, tú lidias con los WAFs. Si eso no te da pereza, es la mejor opción calidad-precio con mucha diferencia.

Mi veredicto: me quedé con Crawl4AI. Para mi caso de uso (docs técnicas, ~500 URLs por semana, presupuesto ajustado), no hay color. Firecrawl me salía a 40-50 dólares al mes. Crawl4AI me cuesta los ciclos de CPU de la Pi 5, que ya está encendida 24/7 de todas formas.

Lo que no te cuentan los benchmarks

Hay algo que ninguna comparativa menciona y que me parece importante: la propiedad de los datos. Cuando usas Firecrawl o Jina, tus URLs pasan por servidores de terceros. Para documentación pública no es grave. Pero si estás scrapeando datos internos, páginas tras login, o cosas que no quieres que nadie vea, un scraper self-hosted es la única opción sensata.

Crawl4AI corre en mi red local. Las páginas entran y salen sin tocar internet más allá de la petición HTTP original. Si mañana Firecrawl cambia sus términos de servicio o duplica sus precios — que ha pasado con otras APIs — a mí no me afecta. Esa independencia vale más que los 47 dólares que me ahorro al mes.

Dicho esto, no es para todo el mundo. Si tu sitio scrapeado tiene SPAs complejas, infinite scroll, o auth basada en captchas, Crawl4AI va a sufrir. Como sufre cualquier scraper que no tenga un equipo de ingenieros dedicado a evadir protecciones. Para eso existen las APIs de pago.

El setup que uso ahora

Así quedó mi stack de scraping después de esta semana:

• Crawl4AI para el 95% de páginas (docs técnicas, blogs, artículos).
• Playwright vanilla (sin Crawl4AI) para las 5-10 páginas que necesitan interacción (clicks, scroll infinito). Crawl4AI no maneja bien interacciones complejas.
• Un script de reintentos con user-agent rotation para los casos que fallan por WAF. Nada sofisticado: 3 user agents rotando, delay de 2-5 segundos entre intentos.

El agente de IA que indexa todo esto — Hermes Agent — recibe el Markdown, lo trocea, lo mete en ChromaDB, y ya está listo para consultas semánticas. De la URL al embedding en menos de un minuto. Todo automatizado con cron.

Si estás en una situación parecida — necesitas scrapear documentación, no quieres pagar APIs, y te da igual ensuciarte las manos con Python — Crawl4AI merece mucho la pena. Las 74.000 estrellas no son hype. Es genuinamente bueno.