Ventajas y desventajas del endpoint Cloudflare Crawl con tiendas Shopify

Que es el endpoint /crawl de Cloudflare?

El endpoint /crawl de Cloudflare es parte de su API de Browser Rendering, actualmente en beta abierta. Extrae contenido de una URL de inicio, sigue enlaces a traves del sitio hasta una profundidad o limite de paginas configurable, y devuelve los resultados como HTML, Markdown o JSON estructurado impulsado por Workers AI. Cloudflare lo posiciona como una herramienta para entrenar modelos, construir pipelines RAG e investigar o monitorear contenido en un sitio.

El endpoint opera como un agente firmado que respeta robots.txt y el AI Crawl Control de Cloudflare por defecto, lo cual es una decision de diseno notable. Esta pensado para facilitar que los desarrolladores cumplan con las reglas del sitio web y dificultar que los rastreadores ignoren las directrices del propietario del sitio.

El endpoint se encuentra en:

https://api.cloudflare.com/client/v4/accounts/<account_id>/browser-rendering/crawl

Necesitas un token de API de Cloudflare con permiso de Browser Rendering Edit para usarlo.

Como funciona

El rastreo se ejecuta como un trabajo asincrono en dos pasos:

1. Inicia el rastreo con una solicitud POST que contiene una URL de inicio. La API devuelve un ID de trabajo inmediatamente.
2. Consulta los resultados con solicitudes GET usando ese ID de trabajo. Cuando el estado del trabajo cambia de running a completed, tus datos rastreados estan listos.

Los trabajos pueden ejecutarse hasta siete dias. Los resultados se almacenan durante 14 dias despues de completarse.

Que envias

Como minimo, envias una URL:

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/{account_id}/browser-rendering/crawl' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com"
  }'

Parametros clave

Que obtienes de vuelta

Cada pagina rastreada se devuelve como un registro con la URL, el estado, el contenido en el formato elegido y metadatos basicos (codigo de estado HTTP, titulo de la pagina, URL final despues de redirecciones). Con render: true, tambien obtienes etiquetas Open Graph. La respuesta tambien incluye browserSecondsUsed para visibilidad de facturacion, y un cursor para paginar resultados que excedan 10 MB.

Aqui esta la respuesta real a nivel de trabajo de un rastreo renderizado de 24 paginas de una tienda Shopify en produccion:

{
  "job_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "status": "completed",
  "total": 24,
  "finished": 24,
  "browserSecondsUsed": 58.38,
  "record_count": 24,
  "records": [
    {
      "url": "https://www.example-store.com/products/premium-widget-bundle",
      "status": "completed",
      "metadata": {
        "status": 200,
        "title": "Premium Widget Bundle | Example Store",
        "url": "https://www.example-store.com/products/premium-widget-bundle",
        "lastModified": "",
        "og:type": "product",
        "og:site_name": "Example Store",
        "og:title": "Premium Widget Bundle | Example Store",
        "og:image": "https://www.example-store.com/cdn/shop/files/product-image.jpg",
        "og:description": "Our best-selling bundle with everything you need..."
      },
      "markdown": "Store\n\nexample-store\n\nURL\n\nhttps://www.example-store.com\n\nCurrency\n\nUSD\n\n# Premium Widget Bundle\n\nOur best-selling bundle with everything you need..."
    }
  ]
}

Con render: true, el objeto de metadatos incluye el conjunto completo de campos Open Graph: tipo, nombre del sitio, titulo, URL de imagen y descripcion. Estos se extraen de las metaetiquetas OG de la pagina durante el renderizado del navegador. Con render: false, los metadatos solo contienen el codigo de estado HTTP, el titulo de la pagina y la URL final. No se extraen campos Open Graph.

El campo markdown contiene la salida completa de la pagina, no solo el contenido principal. Los menus de navegacion, mega menus, pies de pagina y bloques de plantilla repetidos se incluyen en cada registro. En nuestras pruebas, la pagina promedio devolvio aproximadamente 158 KB de markdown, con aproximadamente el 90% siendo boilerplate repetido. Si estas alimentando esto en un LLM o pipeline RAG, necesitaras tu propia logica de extraccion de contenido para eliminar la plantilla y aislar el contenido real de la pagina.

Aqui esta lo que devolvio la misma tienda cuando ejecutamos render: false:

{
  "job_id": "f9e8d7c6-b5a4-3210-fedc-ba9876543210",
  "status": "completed",
  "total": 266,
  "finished": 266,
  "browserSecondsUsed": 0,
  "record_count": 256,
  "records": [
    {
      "url": "https://www.example-store.com/products/classic-knit-sweater",
      "status": "completed",
      "metadata": {
        "status": 200,
        "title": "Classic Knit Sweater | Example Store",
        "url": "https://www.example-store.com/products/classic-knit-sweater",
        "lastModified": ""
      },
      "markdown": "Skip to content\n\nFree Shipping $150+\n\n# Classic Knit Sweater\n\nOur best-selling sweater made from premium natural fibers..."
    }
  ]
}

Cero segundos de navegador, 256 registros de 266 paginas. Los metadatos son minimos comparados con la version renderizada: sin campos Open Graph, solo el estado HTTP, titulo de la pagina y URL. Pero el markdown sigue conteniendo el contenido completo de la pagina incluyendo navegacion, detalles de productos y pie de pagina. Para tiendas Shopify renderizadas en el servidor, el HTML estatico ya tiene todo lo que necesitas.

Descubrimiento de URLs

El rastreador descubre URLs a traves de tres fuentes (cuando source esta configurado como all):

1. La URL de inicio que proporcionas
2. Enlaces de sitemap encontrados en el dominio
3. Enlaces internos encontrados en las paginas rastreadas

Puedes restringir esto solo a sitemaps o solo a enlaces de pagina usando el parametro source. excludePatterns siempre tiene prioridad sobre includePatterns, asi que puedes lanzar una red amplia y luego recortar secciones que no necesites.

Renderizado vs. obtencion rapida

render: true (el predeterminado) inicia un navegador headless, ejecuta JavaScript y espera a que la pagina cargue completamente. Esto es necesario para aplicaciones de pagina unica y contenido renderizado por JavaScript, pero usa segundos de navegador que se facturan.

render: false hace una obtencion rapida de HTML sin ejecutar JavaScript. Durante la beta, estas obtenciones no se facturan. Esta es la opcion correcta para sitios estaticos o paginas renderizadas en el servidor donde el contenido ya esta en el HTML inicial.

Facturacion y disponibilidad

El endpoint esta disponible tanto en los planes Workers Free como Paid. Los rastreos renderizados se facturan bajo el precio de Browser Rendering de Cloudflare a $0.09 por hora de navegador mas alla de tu asignacion incluida.

Workers Free: 10 minutos de tiempo de navegador por dia. El endpoint /crawl esta limitado a 5 trabajos por dia, 100 paginas por rastreo y 6 solicitudes de API por minuto.

Workers Paid ($5/mes): 10 horas de tiempo de navegador por mes incluidas. Sin limites de paginas por rastreo. 600 solicitudes de API por minuto. Las horas adicionales de navegador cuestan $0.09 cada una.

Los rastreos con render: false usan cero tiempo de navegador. Son gratuitos durante la beta pero eventualmente estaran bajo el precio estandar de Workers.

Que es el tiempo real (Wall Clock Time)?

El tiempo real es el tiempo total transcurrido desde que un rastreo comienza hasta que termina, medido de la misma manera que lo cronometrarias con un cronometro. Incluye todo: latencia de red, tiempo de cola interno de Cloudflare, busquedas DNS, tiempo de respuesta del servidor y (si el renderizado esta habilitado) tiempo de ejecucion del navegador.

El tiempo real es diferente del tiempo de navegador. El tiempo de navegador solo cuenta los segundos que el navegador headless de Cloudflare pasa activamente renderizando paginas. Un rastreo podria usar 22 minutos de tiempo de navegador pero tomar 25 minutos de tiempo real debido a la sobrecarga de cola y red. Los rastreos sin renderizado usan cero tiempo de navegador pero aun tienen tiempo real por el proceso de obtencion y cola.

En nuestros benchmarks, reportamos ambos numeros para que puedas ver por que estas pagando (tiempo de navegador) versus cuanto tiempo realmente estas esperando (tiempo real).

La letra pequena

El endpoint respeta las directivas de robots.txt incluyendo crawl-delay. Se identifica como CloudflareBrowserRenderingCrawler/1.0. No evade CAPTCHAs, desafios Turnstile ni otras protecciones contra bots. Si estas rastreando tu propio sitio y te estan bloqueando, necesitas crear una regla de omision de WAF para incluir al rastreador en la lista permitida.

Como se comporta Cloudflare /crawl en cinco tiendas Shopify

Ejecutamos el endpoint /crawl contra cinco tiendas Shopify en produccion para medir velocidad, tasa de exito, costo y como el rastreador interactua con cada sitio. Cada nombre de tienda esta anonimizado. Estos son numeros reales de rastreos reales. Los tiempos reales son estimaciones aproximadas. Algunas pruebas iniciales usaron scripts con manejo de errores limitado, lo que puede haber afectado las tasas de exito reportadas en ciertas tiendas. Donde esto aplica, lo indicamos a continuacion.

Este no es un endpoint de configurar y olvidar. Cada tienda respondio de manera diferente a las solicitudes del endpoint. Algunas necesitaron bloqueo de recursos para completar un rastreo renderizado. Otras devolvieron errores 429 en un modo pero funcionaron bien en el otro. Las directivas de crawl-delay, el conteo de paginas y la arquitectura de la tienda cambiaron el resultado. Planea probar y ajustar la configuracion para cada sitio que rastrees.

Prueba 1: catalogo de e-commerce grande (Store A)

Apuntamos el endpoint /crawl a una tienda Shopify grande con casi 3,000 paginas. El contenido regreso rapido, el markdown era utilizable y el endpoint no tuvo problemas para obtener paginas de productos, paginas de colecciones y contenido de blog. Sin problemas de proxy, sin bloqueos, sin limitacion de velocidad.

Ejecutamos multiples rastreos a diferentes escalas:

Rastrear sin renderizado de JavaScript logro 100% de exito en ambas escalas. El renderizado completo del navegador devolvio 4 de 5 paginas en una prueba de muestra pequena. En una muestra tan pequena, la unica pagina faltante podria ser un timeout del navegador, un error transitorio o un problema del script.

Prueba 2: tienda Shopify pequena (Store D, 24 paginas)

Una tienda mas pequena donde probamos el flujo de trabajo completo:

Rastrear sin renderizado devolvio errores. Nuestra prueba inicial devolvio respuestas 429 en la obtencion de HTML plano. No hemos vuelto a probar esta tienda con manejo de errores mejorado, por lo que no podemos confirmar si los 429 se originaron por la limitacion de velocidad de la tienda o por problemas transitorios durante la prueba.

El renderizado completo con descubrimiento basado en sitemaps fue un exito total. 24 de 24 paginas rastreadas, 100% de completitud.

Un descubrimiento importante: el modo de descubrimiento de URLs predeterminado solo encontro 1 pagina porque la pagina de inicio tenia casi ningun enlace interno. Cambiar al descubrimiento basado en sitemaps encontro las 24. Si tu pagina de inicio es minimalista o tiene mucho JavaScript, el rastreador puede no encontrar paginas solo a traves de enlaces.

Prueba 3: tienda de ropa mediana (Store B, 256 paginas), con y sin renderizado

Nuestra prueba mas detallada. Una tienda de ropa mediana con 256 paginas indexables: productos, colecciones, publicaciones de blog y paginas informativas. Ejecutamos ambos modos en todo el sitio para medir la diferencia real.

Prueba 4: minorista de salud y suplementos (Store C), exito parcial a escala

Un gran minorista de productos de salud con un catalogo masivo. Ejecutamos dos rastreos sin renderizado a diferentes escalas:

La tasa de exito parcial podria indicar que la infraestructura de esta tienda descarta algunas solicitudes sin navegador, pero nuestra prueba inicial carecia de recuperacion robusta de errores, por lo que algunos de estos fallos pueden haber sido recuperables con mejor manejo de reintentos de nuestra parte. La tasa de exito mejoro del 40% al 89% a mayor escala. No hemos vuelto a probar esta tienda con manejo de errores mejorado para aislar la causa.

Prueba 5: tienda grande multi-categoria (Store E, ~1,200 paginas)

Nuestra prueba mas grande y reveladora. Una tienda Shopify con aproximadamente 1,200 URLs distribuidas en cuatro sitemaps: 521 productos, 626 colecciones, 22 paginas y 31 publicaciones de blog.

El rastreo sin renderizado logro 100% de exito en las 1,200 paginas con cero costo de navegador. El rastreo renderizado se ejecuto en una muestra de 100 paginas con optimizaciones de bloqueo de recursos habilitadas.

El bloqueo de recursos marco la diferencia entre un rastreo atascado y uno limpio. Sin bloquear recursos, el rastreo renderizado se quedo en 99 de 100 paginas indefinidamente y consumio 649 segundos de tiempo de navegador para esas 99 paginas. Habilitar el bloqueo de recursos (imagenes, medios, fuentes, hojas de estilo) con una condicion de espera domcontentloaded completo las 100 paginas en 475 segundos, una reduccion del 27% en tiempo de navegador sin atascos.

El crawl-delay en robots.txt creo estancamientos visibles. El robots.txt de Store E especifica un crawl-delay de 10 segundos para ciertos bots. En nuestros datos de sondeo sin renderizado, esto aparecio como mesetas de varios minutos donde el conteo de paginas se estancaba antes de reanudarse. El rastreador de Cloudflare respeta las directivas de crawl-delay, lo que extiende directamente el tiempo real en sitios que las configuran.

Que acepta realmente el endpoint /crawl

El endpoint toma una URL de inicio, no una lista. Descubre paginas rastreando hacia afuera desde esa URL a traves de sitemaps, enlaces de pagina, o ambos. Si ya tienes una lista de URLs de un rastreo de Scrapy y quieres usar Cloudflare para la conversion a markdown, necesitarias llamar a los endpoints separados /markdown o /scrape individualmente por URL.

Que hace realmente Cloudflare /crawl en el lado del servidor?

Extrajimos los registros completos del servidor durante un rastreo completamente renderizado de Store D (25 paginas) para analizar la huella real de trafico. Los resultados revelan diferencias fundamentales entre el rastreo con renderizado de navegador y el rastreo tradicional de bots, con efectos secundarios no intencionados para analiticas, carga del servidor y monitoreo de trafico de bots.

Cuanto trafico genera realmente un Cloudflare /crawl completamente renderizado?

El hallazgo mas importante: solo el 1.1% de las 2,234 solicitudes fueron contenido de pagina real. El otro 98.9% fueron JavaScript, CSS, beacons de analiticas, pixeles de seguimiento y precargas de checkout disparadas por el navegador al cargar cada pagina como lo haria un visitante real.

Un bot sin renderizado como Amazonbot o ChatGPT-User genera 1 solicitud por pagina. El renderizador de navegador de Cloudflare genera 89.

Infla Cloudflare /crawl las analiticas de Shopify?

Las 163 solicitudes POST en nuestros registros fueron completamente endpoints de analiticas y seguimiento de Shopify disparandose durante el rastreo. Estos son los mismos eventos que se disparan cuando un cliente real visita tu tienda. Desde la perspectiva de Shopify Analytics, el rastreador de Cloudflare parece un visitante navegando cada pagina de tu sitio en 2 minutos.

A que velocidad golpea Cloudflare /crawl tu servidor?

Las 2,234 solicitudes llegaron en una ventana de 134 segundos. El rendimiento maximo alcanzo 82 solicitudes por segundo. El rastreador renderizo todo el sitio de 25 paginas en poco mas de 2 minutos, pero el servidor vio una rafaga sostenida de trafico que no se parece en nada a los patrones de navegacion organica.

Para tiendas pequenas, esto es manejable. Para tiendas mas grandes con miles de paginas, la amplificacion de solicitudes (89x por pagina) combinada con rendimiento sostenido podria crear una carga significativa en el servidor de origen, especialmente si estas en un plan de hosting compartido o tienes limitacion de velocidad agresiva.

De donde viene Cloudflare /crawl?

El rastreo se distribuyo en 5 centros de datos de Cloudflare en EE.UU.:

Esto no es un solo servidor haciendo solicitudes. Cloudflare distribuye la carga de trabajo de renderizado a traves de su red edge. Las 23 IPs cayeron en el rango 104.28.x.x, y el user-agent fue CloudflareBrowserRenderingCrawler/1.0 en cada solicitud.

Que huella digital de navegador deja Cloudflare /crawl?

El renderizador envia cabeceras Sec-Fetch apropiadas que imitan un navegador Chrome real:

Dos brechas de huella digital destacan: el renderizador omite completamente las cabeceras sec-ch-ua Client Hints (un navegador Chrome real siempre las envia), y todas las solicitudes usan HTTP/1.1 en lugar de HTTP/2 o HTTP/3. Si estas construyendo reglas de deteccion de bots, estas son senales confiables para distinguir el renderizador de navegador de Cloudflare del trafico real de visitantes.

Como se compara Cloudflare /crawl con otros bots de IA en los registros del servidor?

Comparamos el rastreo de Cloudflare contra otros bots que visitaron la misma tienda en la misma ventana de 12 horas:

Amazonbot y ChatGPT-User obtienen HTML sin procesar: una solicitud, una pagina, sin ejecucion de JavaScript. AhrefsBot rastrea sitemaps para descubrimiento. El renderizador de navegador de Cloudflare ejecuta un storefront Shopify completo en cada pagina, disparando cada script, pixel y precarga como si un cliente real estuviera navegando.

Velocidad y costo de Cloudflare /crawl: el benchmark completo

Cada rastreo que ejecutamos, en una tabla. Todas las tiendas anonimizadas, todos los numeros de pruebas reales. Los tiempos reales son aproximados. Las tasas de exito para las tiendas C y D pueden haberse visto afectadas por el manejo de errores limitado en nuestros scripts de prueba iniciales.

Que tan rapido es Cloudflare /crawl con vs. sin renderizado?

La comparacion mas clara viene de Store B, donde ejecutamos ambos modos en exactamente las mismas 256 paginas:

El patron en los once rastreos es consistente: rastrear sin renderizado es dramaticamente mas rapido. El tiempo real sin renderizado es mayormente la sobrecarga interna de cola y obtencion de Cloudflare. El renderizado completo agrega aproximadamente 5 segundos de tiempo de navegador por pagina sobre esa linea base.

Cuanto cuesta un rastreo Cloudflare completamente renderizado por pagina?

El precio de Browser Rendering de Cloudflare se basa en horas de navegador, el tiempo que su navegador headless pasa activamente renderizando tus paginas. Rastrear sin renderizado usa cero horas de navegador y es gratuito durante la beta.

Plan Workers Free: 10 minutos de tiempo de navegador por dia. El endpoint /crawl esta ademas limitado a 5 trabajos de rastreo por dia, con un maximo de 100 paginas por rastreo.

Plan Workers Paid ($5/mes): 10 horas de tiempo de navegador por mes incluidas. Mas alla de eso, pagas $0.09 por hora adicional de navegador. Sin limites por rastreo. Hasta 600 solicitudes de API por minuto.

Esto es lo que costaron nuestros rastreos de prueba realmente a $0.09/hr:

A aproximadamente 5 segundos de tiempo de navegador por pagina, todos estos costos caen bien dentro de las 10 horas incluidas en el plan pagado. Un rastreo renderizado de 3,000 paginas usaria aproximadamente 4 de tus 10 horas incluidas, lo que significa que podrias ejecutar dos rastreos completos por mes antes de pagar algo mas alla de los $5 base. Rastrear sin renderizado es gratuito y no tiene costo de tiempo de navegador en ningun plan.

Cuando deberias omitir el renderizado vs. usar renderizado completo en Cloudflare /crawl?

La conclusion

Para la mayoria de las tiendas Shopify con contenido renderizado en el servidor, rastrear sin renderizado te da mas del 90% del contenido util a costo cero en una fraccion del tiempo.

Lo que aprendimos probando Cloudflare /crawl en tiendas Shopify

Despues de ejecutar 11 rastreos en 5 tiendas Shopify en produccion y analizar registros completos del servidor, estos son los hallazgos que mas importan.

El 90% del contenido llega sin renderizado

Para tiendas Shopify con paginas estandar renderizadas en el servidor, rastrear sin renderizado de JavaScript capturo mas del 90% del contenido util. El aumento del 14% en contenido del renderizado completo provino casi en su totalidad de elementos cargados por JavaScript en paginas de inicio y paginas de indice. Las paginas de productos individuales y los articulos del blog fueron casi identicos en cualquier caso. A menos que tu tienda este construida como una aplicacion de pagina unica, probablemente no necesites renderizado completo.

El renderizado completo crea un multiplicador de trafico de 89x

Renderizar 25 paginas genero 2,234 solicitudes al servidor. Solo 25 de ellas fueron contenido de pagina real. El otro 98.9% fueron archivos JavaScript (75%), beacons de analiticas (6.3%), CSS (4.3%), pixeles de seguimiento (3.4%) y precargas de checkout (3.3%). Cada pagina renderizada dispara la pila completa del lado del cliente de Shopify como si un cliente real estuviera navegando.

Tus analiticas de Shopify probablemente estan siendo infladas

Los rastreos renderizados disparan la pila completa de analiticas de Shopify: beacons monorail, eventos de seguimiento, precargas de Shop Pay y scripts de web-pixel. Creemos que esto significa que Shopify Analytics esta contando estas como sesiones de visitantes reales. Si ese es el caso, un solo rastreo renderizado podria inflar tus conteos de sesiones, vistas de pagina y datos del embudo de conversion. No hemos confirmado esto directamente en los informes de Shopify, pero los registros del servidor muestran todos los mismos eventos de analiticas disparandose como lo harian para un cliente real.

El renderizado completo puede evadir los limites de velocidad de la tienda

Store D devolvio errores 429 en cada pagina sin renderizado. Cambiar a renderizado completo en la misma tienda produjo 100% de exito. Si encuentras limites de velocidad sin renderizado, el renderizado completo es tu solucion.

El descubrimiento por sitemaps es mas confiable que el descubrimiento por enlaces

El descubrimiento basado en enlaces predeterminado no encontro casi nada en Store D porque la pagina de inicio tenia muy pocos enlaces internos. Cambiar al descubrimiento basado en sitemaps encontro las 24 paginas. Siempre usa el descubrimiento por sitemaps.

El rastreador proviene de 5 centros de datos en EE.UU.

Cloudflare distribuye la carga de trabajo de renderizado a traves de su red edge. Nuestro rastreo provino de 23 IPs unicas en Atlanta (38%), Chicago (25%), Miami (23%), Newark (9%) y Washington DC (5%). Todas las IPs caen en el rango 104.28.x.x.

Dos brechas de huella digital lo identifican como bot

El renderizador omite las cabeceras sec-ch-ua Client Hints (Chrome real siempre las envia) y usa HTTP/1.1 en lugar de HTTP/2 o HTTP/3. Si estas construyendo reglas de deteccion de bots, estas son senales confiables.

El renderizado puede devolver menos contenido

En Store E, el rastreo sin renderizado devolvio 6.8% mas contenido por pagina que el rastreo renderizado. Bloquear imagenes, fuentes y hojas de estilo para optimizar el tiempo de navegador tambien evito que algunos scripts de JavaScript poblaran elementos dinamicos. El HTML estatico ya tenia todo. Para tiendas Shopify renderizadas en el servidor, no se garantiza que el renderizado capture mas contenido.

El bloqueo de recursos previene rastreos atascados

Sin bloqueo de recursos, el rastreo renderizado en Store E se quedo en 99 de 100 paginas y nunca se completo. Habilitar el bloqueo para imagenes, medios, fuentes y hojas de estilo con una condicion de espera domcontentloaded completo las 100 paginas y redujo el tiempo de navegador en un 27%. Si tus rastreos renderizados se atascan antes de terminar, el bloqueo de recursos es la solucion.

El crawl-delay de robots.txt extiende el tiempo real

El robots.txt de Store E especifica un crawl-delay de 10 segundos. En nuestros datos de sondeo sin renderizado, esto aparecio como mesetas de varios minutos donde el conteo de paginas se estancaba antes de reanudarse. El rastreador de Cloudflare respeta las directivas de crawl-delay, por lo que los sitios con retrasos agresivos tendran tiempos reales significativamente mas largos de lo que el conteo de paginas solo sugeriria.

El costo es bajo pero el plan gratuito tiene limites

Renderizar 256 paginas costo aproximadamente $0.03 a $0.09 por hora de navegador. Renderizar 24 paginas costo aproximadamente $0.002. El plan Workers Free limita el tiempo de navegador a 10 minutos por dia con un maximo de 5 trabajos de rastreo y 100 paginas por rastreo. El plan Workers Paid ($5/mes) incluye 10 horas de tiempo de navegador por mes sin limites por rastreo. Un rastreo renderizado de 3,000 paginas usaria aproximadamente 4 de esas 10 horas incluidas, asi que la mayoria de las tiendas caben comodamente en el plan pagado sin excedentes. Rastrear sin renderizado usa cero tiempo de navegador y es gratuito en cualquier plan durante la beta.

Las ventajas

Velocidad

Paginas obtenidas casi instantaneamente versus un rastreo de Scrapy de varias horas con autothrottle. Sin colas, sin retrasos de cortesia, sin esperar a que tu spider trabaje a traves de miles de solicitudes a un ritmo respetuoso.

Salida en Markdown

El endpoint devuelve HTML-a-Markdown pre-convertido para cada pagina. Esto es directamente util para ingestion en LLM, pipelines RAG y analisis de contenido sin ningun post-procesamiento. Te saltas toda la capa de extraccion y vas directamente a texto limpio. Para equipos que construyen aplicaciones de IA sobre contenido web, esto elimina un paso del pipeline.

Opcion de modo de renderizado

Configurar render: true ejecuta JavaScript y extrae automaticamente metadatos Open Graph (og:title, og:description, og:image, og:site_name). Para sitios con mucho JavaScript donde el contenido se renderiza del lado del cliente, esta es la diferencia entre ver la pagina real y ver un cascaron vacio.

Sin dolores de cabeza con proxies o limites de velocidad

Cloudflare maneja las medidas anti-bot y la limitacion de velocidad en su propia infraestructura. No necesitas gestionar pools de proxies, rotar user agents ni lidiar con CAPTCHAs. Una sola llamada API.

Rastreo incremental

Los parametros modifiedSince y maxAge te permiten omitir paginas que no han cambiado o que se obtuvieron recientemente. Para rastreos recurrentes donde estas monitoreando cambios de contenido, esto ahorra tanto tiempo como costo al procesar solo paginas que realmente son nuevas o actualizadas.

Simplicidad

Una sola llamada API. Respuesta JSON. Sin codigo de spider, sin middleware, sin pipelines de items, sin archivos de configuracion.

Bot bien comportado por defecto

El rastreador es un agente firmado que respeta robots.txt, crawl-delay y el AI Crawl Control de Cloudflare. Se identifica como CloudflareBrowserRenderingCrawler/1.0 y no puede evadir proteccion contra bots ni CAPTCHAs. Obtienes cumplimiento etico de rastreo sin construir la logica tu mismo.

Lo que no soporta el endpoint Cloudflare Crawl

Como se diferencia Cloudflare /crawl de un pipeline de rastreo completo?

La tabla a continuacion muestra exactamente que capacidades estan presentes en el endpoint /crawl de Cloudflare versus un pipeline de produccion de Scrapy. Esto se basa en nuestras pruebas reales contra tiendas Shopify.

Que datos estructurados extrae Cloudflare /crawl?

Con render: false, ninguno. Sin JSON-LD, sin Microdata, sin analisis de OpenGraph.

Con render: true, solo etiquetas OG basicas (og:title, og:description, og:image, og:site_name). JSON-LD y el markup de schema.org no se analizan, extraen ni validan.

Para comparacion, nuestro pipeline de Scrapy produce schemas_found, issues (contactPoint faltante, address, etc.), top_level_schemas y nested_schemas para cada URL. Puedes ver que paginas tienen esquema Product, cuales les falta el markup de Organization y cuales tienen errores de validacion que harian que los sistemas de IA lean mal el contenido.

Que codigos de estado HTTP devuelve Cloudflare /crawl?

Solo respuestas 200. Nuestro rastreo de Scrapy del mismo sitio capturo 2,547 errores 404, mas respuestas 403 y errores de conexion. La deteccion de 404 es critica para el analisis de paginas fantasma, la remediacion de enlaces rotos y el mapeo de redirecciones. Sin ella, te estan faltando las paginas que estan activamente fugando link equity y confundiendo a los rastreadores de IA.

Cuantas URLs puede procesar Cloudflare /crawl?

Hasta 100,000 por trabajo. Esto cubre la mayoria de los sitios, pero los catalogos grandes de e-commerce con cientos de miles de paginas de productos, URLs de variantes y paginas de colecciones filtradas excederan el limite. Scrapy no tiene limite inherente de URLs.

Tiene Cloudflare /crawl un error de resolucion de URLs?

Encontramos 233 de 908 enlaces en una sola pagina de producto con rutas rotas. El convertidor de markdown resuelve URLs relativas contra la URL de la pagina incorrectamente, produciendo URLs de doble ruta como /products/slug//www.example.com/.... Este es un error confirmado en el convertidor de Cloudflare que afecta cualquier analisis de enlaces posterior.

Cuanto boilerplate hay en la salida de markdown de Cloudflare /crawl?

La pagina promedio devolvio 158 KB de markdown. Aproximadamente el 90% es contenido de plantilla repetido: navegacion completa, mega menu y pie de pagina en cada registro. Para el analisis de contenido esto significa mucho trabajo de deduplicacion, y para el uso de tokens de LLM el costo se acumula rapido. Necesitas tu propia logica de extraccion de contenido sobre el markdown para aislar el contenido real de la pagina.

Que no clasifica Cloudflare /crawl?

No hay etiquetado de tipo de contenido. Las paginas de productos, paginas de colecciones, publicaciones de blog y paginas de inicio regresan como registros indiferenciados. Scrapy clasifica cada URL por tipo, lo cual es esencial para entender la cobertura de rastreo por categoria de pagina y para identificar que tipos de contenido priorizan los bots de IA.

Que funciones de finalizacion faltan en Cloudflare /crawl?

Sin capturas de paginas fantasma. Sin comparacion de renderizado de JavaScript (lo que el bot ve versus lo que el navegador ve). Sin analisis de bots de IA en robots.txt. Sin informe de calidad de rastreo. Sin manifiesto de cliente. Sin sincronizacion CDN. Los datos de Cloudflare son solo contenido sin procesar. Cada pieza del pipeline de informes y analisis tendria que construirse por separado.

Cuanto cuesta Cloudflare /crawl para sitios grandes?

En nuestras pruebas, render: true promedió aproximadamente 5 segundos de ejecucion de navegador por pagina. Un rastreo de 256 paginas uso 1,338 segundos de navegador (22 minutos) y costo aproximadamente $0.03 a $0.09 por hora de navegador. Un rastreo de 24 paginas uso 58 segundos de navegador y costo aproximadamente $0.002. Extrapolando a un catalogo de 3,000 paginas: aproximadamente 4 horas de tiempo de navegador. El plan Workers Free esta limitado a 10 minutos de tiempo de navegador por dia, 5 trabajos de rastreo por dia y 100 paginas por rastreo. El plan Workers Paid ($5/mes) incluye 10 horas de tiempo de navegador por mes sin limites por rastreo, asi que un rastreo de 3,000 paginas usaria aproximadamente 4 de esas 10 horas incluidas. render: false usa cero tiempo de navegador y es gratuito durante la beta en cualquier plan.

La conclusion final

El endpoint de rastreo de Cloudflare es excelente para:

• Instantaneas rapidas de contenido cuando necesitas texto de pagina rapido
• Markdown listo para LLM para pipelines RAG e ingestion de contenido
• Verificaciones ad-hoc de paginas donde conoces las URLs exactas que necesitas
• Extracciones rapidas de contenido de todo el sitio cuando necesitas texto en markdown sin construir un spider

No puede reemplazar un pipeline de rastreo completo porque el valor del pipeline esta en:

• Grafo de rastreo completo con topologia de enlaces, deteccion de huerfanas y cobertura de 404
• Extraccion y validacion de datos estructurados (JSON-LD, Microdata, OpenGraph)
• Clasificacion de contenido por tipo de pagina
• El pipeline de finalizacion completo incluyendo analisis de paginas fantasma, comparacion de renderizado de JavaScript, informes de esquemas y puntuacion de preparacion para LLM

El mejor enfoque hibrido

Usa Cloudflare como fuente de datos complementaria. Despues de que un rastreo completo identifique tus URLs, usa la salida de markdown de Cloudflare para alimentar la puntuacion de preparacion para LLM o el analisis de calidad de contenido donde necesites el texto real de la pagina en lugar de metadatos estructurados. El pipeline de rastreo descubre y clasifica. El endpoint de Cloudflare entrega texto limpio para las paginas que importan.

Preguntas frecuentes