Cloudflare Crawl API: rastrear un sitio web completo ya no requiere construir un crawler

Aviso por delante: esto es una primera lectura, no una crónica de uso. Todavía no he metido esta API en ningún proyecto. He leído la documentación con atención y he apuntado qué me convence, qué se queda fuera y para qué la usaría yo; cuando la haya puesto a trabajar en algo real, ya contaré si se parecía a lo que prometía.

Dicho eso: Cloudflare publicó el 10 de marzo el endpoint /crawl —la Crawl API— dentro de su servicio de navegadores gestionados, en beta abierta y disponible tanto en el plan gratuito de Workers como en los de pago. Con una llamada se lanza el rastreo de un sitio entero: se le da una URL de partida y él descubre las páginas, las visita y devuelve el contenido listo para procesar.

Una telaraña, que es de donde viene la palabra. Foto: Luc Viatour, CC BY-SA 3.0; imagen recortada y disponible bajo la misma licencia.

Qué hace exactamente

Hasta ahora, recorrer un sitio completo obligaba a combinar varias piezas: un navegador sin interfaz como Playwright o Puppeteer, la lógica para descubrir enlaces, el control de profundidad, una cola, las esperas para que renderice el JavaScript, el almacenamiento de resultados y la gestión de errores y reintentos. Ninguna de esas piezas es difícil por separado; el trabajo está en mantenerlas juntas y en producción.

El endpoint encapsula buena parte de eso. Funciona de forma asíncrona: se lanza el trabajo, se recibe un identificador y los resultados se recogen después. Descubre las páginas por los enlaces, por el sitemap.xml o por ambas cosas; el alcance se acota por número de páginas, por profundidad y por patrones de inclusión y exclusión; y admite rastreos incrementales, pidiendo solo lo modificado desde una fecha.

Devuelve el contenido en HTML, en Markdown o en JSON estructurado, y permite además pedir el rastreo sin abrir navegador, con una descarga estática, para los sitios donde no hace falta ejecutar nada. La salida en Markdown es la que más me interesa: quita el ruido de la página y deja un texto mucho más sencillo de indexar, comparar o preparar para un modelo, con bastante menos preprocesado propio. Es, de hecho, el formato en el que se escriben los ficheros llms.txt.

Por cierto, el servicio ya no se llama Browser Rendering: desde el 15 de abril es Browser Run. Si encuentras documentación con el nombre anterior, es lo mismo.

Lo que no resuelve

Aquí es donde conviene bajar el entusiasmo, porque la frase fácil —«con esto el JavaScript deja de ser un problema»— no se sostiene.

Que las páginas se rendericen en un navegador de verdad resuelve una parte importante del problema: el contenido que una aplicación de React, Vue, Angular o similar construye en el cliente aparece en la respuesta, cosa que con una descarga plana no ocurriría. Eso es mucho. Pero no es todo, y lo que queda fuera es justo lo que suele romper un rastreo real:

• Lo que hay detrás de un formulario de acceso. Admite autenticación básica, cabeceras y cookies, así que hay casos resueltos; un inicio de sesión con varios pasos o con segundo factor, no.
• Lo que solo aparece si alguien interactúa. Pestañas, acordeones, «cargar más», desplazamiento infinito. Si el contenido depende de un clic, no está.
• Lo que no está enlazado desde ninguna parte ni figura en el sitemap.xml. Un rastreador no adivina: sigue enlaces.
• Lo que tarda en aparecer. Cargas diferidas y peticiones lentas se pueden quedar fuera de la instantánea.
• Lo que te bloquea a propósito. Y este es el punto importante: el rastreador se identifica como bot y respeta robots.txt, incluido el crawl-delay. Cloudflare lo dice sin rodeos: no está pensado para saltarse detección de bots ni captchas, ni siquiera los suyos. Sirve para leer sitios que quieren ser leídos.

Esa última condición no es una carencia técnica, es una postura, y me parece la correcta. Pero conviene saberla antes de plantear el proyecto: si el caso de uso consistía en entrar donde no te llaman, esta no es la herramienta.

Límites y factura

Tampoco es infraestructura gratis. Los rastreos con navegador se facturan como cualquier otro uso de Browser Run; el modo estático está sin coste mientras dure la beta y después pasará a la tarificación de Workers; la salida en JSON se apoya en Workers AI y suma su propio consumo; y el plan gratuito tiene un tope diario de tiempo de navegador que un rastreo grande agota con facilidad.

A eso se añade lo de siempre en un servicio gestionado: los trabajos tienen duración máxima, los resultados caducan a los pocos días y las respuestas grandes se paginan. Nada de eso estorba, pero son decisiones que hay que tomar antes y no cuando el proceso lleva tres horas corriendo.

Para qué lo usaría yo

No me interesa por el scraping, que es la parte aburrida. Me interesa por dos cosas que hago a menudo y que hasta ahora requerían montar andamio:

Vigilar sitios que mantengo. Rastrear cada semana un sitio de cliente y comparar el Markdown de hoy con el de la semana pasada detecta cosas que ninguna monitorización de disponibilidad ve: una página que se quedó en blanco tras una actualización de plugin, un texto legal que alguien cambió sin avisar, un bloque que desapareció en un despliegue. La web responde 200 y está rota igualmente.

Auditar antes de tocar. Cuando entro en un sitio ajeno, lo primero que necesito es el inventario real: qué páginas hay, cuáles cuelgan de dónde, qué títulos y qué metadatos tienen. Tener eso en un JSON en cinco minutos, en lugar de en una tarde de herramientas, cambia bastante el arranque de un encargo.

Ninguna de las dos es una idea nueva. Lo nuevo es que dejan de necesitar una pieza de infraestructura propia que alguien tenga que mantener después, que es casi siempre la parte cara.

Primera impresión

Es un movimiento coherente con lo que lleva años haciendo Cloudflare: convertir en servicio lo que antes eran tres días de montaje. Y me gusta especialmente que el rastreador se identifique y obedezca robots.txt, porque el género no destaca por eso.

Lo que no voy a hacer es predecir su recorrido: está en beta, tiene condiciones que pueden cambiar y no la he probado. Me la apunto para el próximo encargo en el que necesite el mapa completo de un sitio, y de esos salen bastantes.

Referencias

• Anuncio del endpoint /crawl (10 de marzo de 2026)
• Browser Rendering pasa a llamarse Browser Run (15 de abril de 2026)
• Documentación del endpoint /crawl