Cloudflare acaba de lanzar un endpoint /crawl y todos están perdiendo la cabeza.

Cálmense. Déjame decirte qué es realmente, qué no es, y por qué probablemente no lo necesites.

El endpoint /crawl es un envoltorio. Le das una URL, ejecuta navegadores headless en la infraestructura de Cloudflare, sigue enlaces, renderiza JavaScript y te devuelve markdown o JSON. Todo con 1 llamada API.

Es genial pero no es revolucionario.

Firecrawl hace esto. Crawl4AI hace esto. Spider hace esto. Lo han estado haciendo durante meses. Cloudflare simplemente lo agregó a su producto Browser Rendering existente y todos actuaron como si hubieran inventado el web scraping.

Lo que SÍ es interesante: es Cloudflare. Eso significa que es barato ($0.09/hora).

Pero la cosa es que probablemente ni siquiera necesitas un crawler.

Hay 8 formas en que un agente de IA puede leer una página web. La mayoría salta directamente a las complejas cuando una solicitud HTTP de 50ms habría hecho el trabajo. Así que desglosémoslas todas, de la más simple a la más exagerada.

1. HTTP fetch sin procesar
Tu agente envía una solicitud, obtiene HTML. Eso es todo.

Como leer el código fuente de un libro en lugar de la página impresa. Funciona muy bien para sitios simples, blogs, wikis, documentos. Se rompe en cualquier cosa que use JavaScript para cargar contenido.

Velocidad: ~50ms. Costo: gratis.

2. Readability parser
Lo mismo, pero con un paso de limpieza. Elimina barras de navegación, anuncios, pies de página, banners de cookies. Te da solo el texto del artículo en markdown limpio.

No maneja contenido renderizado con JavaScript. Pero para artículos y documentos, es perfecto, y es lo que uso diariamente.

Velocidad: ~100ms. Costo: gratis.

3. Navegador headless (local)
Lanza un Chrome invisible que carga la página como lo haría un humano. JavaScript se ejecuta, el contenido se renderiza, todo se carga. Puedes hacer clic, desplazarte, completar formularios, iniciar sesión.

El problema: lento (2-10s), consume ~200MB de RAM por instancia y mantienes la infraestructura.

Herramientas: Playwright, Puppeteer, Selenium.

4. API de navegador en la nube
Lo mismo que #3 pero alguien más ejecuta el navegador. Envías una URL, obtienes la página renderizada. Aquí es donde vive el /crawl de Cloudflare, junto con Browserbase y Steel.

Sin dolores de cabeza de infraestructura, escala fácilmente, barato. Compensación: menos control sobre las interacciones.

5. API de web scraping gestionada
Esta es la capa de guerra anti-bots. ScrapingBee, Bright Data, proxies rotatorios, resolución de CAPTCHA, IPs residenciales. Para cuando el sitio te combate activamente.

Funciona. Cuesta $49-499+/mes.

6. Crawler nativo de IA
Firecrawl, Crawl4AI, Spider. crawl + render + conversión automática a markdown/JSON limpio. Construido para tuberías RAG. Define esquemas de extracción en lenguaje natural.

La "nueva ola" con la que Cloudflare ahora compite.

7. Extracción con LLM
Omite el código completamente. Vuelca el contenido de la página en un LLM, pregunta "¿cuál es el precio?" en inglés simple. Sin selectores CSS, sin regex, sin mantenimiento cuando el sitio se rediseña.

Desventaja: costoso a escala (los tokens se acumulan rápidamente). Mejor como paso final después de limpiar con métodos 1-6.

8. APIs oficiales
La que todos olvidan. X, Reddit, la mayoría de SaaS, tienen APIs. Datos estructurados, sin análisis, sin juegos anti-bots. Cuando existe una API, siempre es la opción correcta.

Las buenas configuraciones combinan 2-3:

→ fetch → readability → LLM para extracción de artículos barata
→ navegador en la nube → LLM para sitios con mucho JavaScript
→ detectar la API real en DevTools → llamarla directamente, el santo grial, gratis, más rápido, más confiable
→ AI crawler → vector DB para bases de conocimiento completas

Costos reales en 10,000 páginas/mes

• HTTP Fetch: gratis
• Jina Reader: gratis
• Navegador Cloudflare: ~$3
• Spider: ~$4.80
• Firecrawl: $47/mes
• ScrapingBee: $49-147/mes
• Bright Data: $499+/mes

2 reglas que sigo:

Comienza simple. API > fetch > readability > browser. Solo añade complejidad cuando el método más simple falla. Veo gente ejecutando Playwright para sitios donde curl funciona perfectamente.

La mayoría de los sitios no necesitan renderizado de JS. 60%+ de la web es estático o renderizado en el servidor. Prueba primero con un fetch simple.