Voici les meilleurs parametres Cloudflare /crawl pour tout type de site web

Le endpoint /crawl de Cloudflare Browser Rendering est l’un des moyens les plus rapides d’extraire le contenu d’un site web a grande echelle, mais les parametres par defaut ne sont pas optimaux pour la plupart des cas d’utilisation. Apres avoir execute des crawls sur des dizaines de sites, des boutiques Shopify aux SPA React en passant par les sites de documentation, voici les parametres qui donnent systematiquement les meilleurs resultats.

Ce guide explique ce que fait chaque parametre, quand le modifier et les commandes specifiques qui fonctionnent le mieux pour les types de sites courants.

La decision la plus importante : le mode de rendu

Chaque crawl commence par un choix : Cloudflare doit-il charger la page dans un navigateur headless ou simplement recuperer le HTML brut ?

render: false (--no-render) recupere le HTML sans executer JavaScript. C’est rapide, gratuit pendant la periode beta, et produit une sortie propre pour tout site qui fournit le contenu dans la reponse HTML initiale.

render: true (la valeur par defaut) charge chaque page dans une instance Chromium headless, execute JavaScript, attend que la page se stabilise, puis extrait le contenu. C’est plus lent, consomme des heures de navigateur et coute de l’argent apres les 10 heures gratuites par mois.

Quand chaque mode est pertinent

Lors de nos tests, les sites Shopify ont renvoye un contenu identique a environ 90 % entre les deux modes de rendu. Le contenu supplementaire provenant du rendu etait principalement des elements d’interface dynamiques comme les tiroirs de panier et les widgets de recommandation, et non des donnees produit significatives. Nous couvrons la comparaison complete des modes de rendu avec des benchmarks face a face dans Avantages et inconvenients du endpoint Cloudflare Crawl avec les boutiques Shopify.

La regle generale : commencez avec --no-render. Si les resultats ne contiennent pas le contenu dont vous avez besoin, passez au mode rendu.

Decouverte d’URL : Sitemaps vs liens

Le flag --source controle la facon dont Cloudflare trouve les pages a crawler.

--source sitemaps lit le fichier sitemap.xml du site et ne crawle que les URL qui y sont listees. C’est previsible, couvre les pages que le proprietaire du site considere comme canoniques et evite de crawler les pages en double ou a faible valeur.

--source links commence a l’URL donnee et suit les liens <a href> trouves sur chaque page. Cela decouvre les pages comme le ferait un moteur de recherche, mais peut manquer les pages orphelines et peut crawler dans la pagination, les filtres ou d’autres schemas d’URL a faible valeur.

--source all (la valeur par defaut) combine les deux methodes.

Lequel utiliser

Utilisez --source sitemaps lorsque le site dispose d’un sitemap complet et bien entretenu. La plupart des sites Shopify et WordPress en ont un. C’est l’option la plus fiable pour l’extraction complete du contenu d’un site.

Utilisez --source links ou all lorsque le sitemap est manquant, incomplet ou que vous souhaitez specifiquement auditer la structure de liens internes du site.

Blocage de ressources pour les crawls en render-true

C’est l’optimisation la plus impactante pour les crawls en render-true. Par defaut, le navigateur headless charge chaque image, police, feuille de style et fichier media sur chaque page. C’est du gaspillage lorsque vous n’avez besoin que du contenu textuel.

Ajoutez --block-resources image media font stylesheet a tout crawl en render-true. L’effet est significatif :

• Vitesse : le temps de crawl passe d’environ 7 secondes par page a environ 2 secondes par page
• Cout : les heures de navigateur consommees sont reduites de 60 a 70 %
• Fiabilite : les pages qui se bloqueraient indefiniment en attendant des ressources CDN lentes se terminent desormais normalement

Le navigateur execute toujours JavaScript et construit le DOM. Il saute simplement le telechargement des ressources qui n’affectent pas le contenu textuel.

La condition d’attente

Le flag --wait-until indique au navigateur quand arreter d’attendre et extraire le contenu. La valeur par defaut attend que toute l’activite reseau soit terminee, ce qui est lent et inutile pour l’extraction de contenu.

--wait-until domcontentloaded indique au navigateur d’extraire le contenu des que le DOM est pret. Pour l’extraction de texte, c’est presque toujours suffisant. Le JavaScript qui charge le contenu aura ete execute, mais les pings d’analytics en arriere-plan et les appels aux reseaux publicitaires ne retarderont pas le crawl.

Commandes recommandees par type de site

Boutique Shopify (site complet)

python crawl.py run https://example.com \
  --limit 500 \
  --format markdown \
  --no-render \
  --source sitemaps \
  -o results.json

Rapide, gratuit et couvre l’ensemble du catalogue de produits. Les sitemaps Shopify sont complets, donc --source sitemaps offre une couverture complete sans crawler dans les collections paginées ou les pages de resultats de recherche.

Boutique Shopify (produits uniquement)

python crawl.py run https://example.com \
  --limit 1000 \
  --format markdown \
  --no-render \
  --include-patterns "https://example.com/products/**" \
  -o products.json

Le flag --include-patterns restreint le crawl aux URL correspondant au modele donne. Utile lorsque vous n’avez besoin que des pages produits et souhaitez ignorer les collections, les articles de blog et les pages de politique.

WordPress ou blog statique

python crawl.py run https://example.com \
  --limit 500 \
  --format markdown \
  --no-render \
  --source sitemaps \
  -o results.json

Memes parametres que Shopify. Les sites WordPress sont rendus cote serveur et disposent de sitemaps fiables. Les generateurs de sites statiques (Hugo, Jekyll, Eleventy, Astro) produisent du HTML pre-construit, donc render-false capture tout.

SPA React ou Vue

python crawl.py run https://example.com \
  --limit 500 \
  --format markdown \
  --source sitemaps \
  --block-resources image media font stylesheet \
  --wait-until domcontentloaded \
  -o results.json

Render-true est la valeur par defaut, donc aucun flag n’est necessaire. Les ajouts essentiels sont --block-resources et --wait-until domcontentloaded. Sans ceux-ci, le crawl sera lent et couteux.

Si la SPA n’a pas de sitemap, passez a --source links.

Site de documentation

python crawl.py run https://docs.example.com \
  --limit 500 \
  --format markdown \
  --no-render \
  --depth 5 \
  --exclude-patterns "*/changelog/**" "*/archive/**" \
  -o docs.json

Les sites de documentation ont souvent des structures de liens profondes. Augmentez --depth pour suivre les hierarchies de pages imbriquees. Utilisez --exclude-patterns pour ignorer les pages de changelog, les versions archivees ou tout autre contenu dont vous n’avez pas besoin.

Benchmarks de performance

Ces chiffres proviennent de crawls reels effectues sur des boutiques Shopify et des sites e-commerce en mars 2026. Les noms des sites ont ete anonymises.

Points cles issus des donnees :

• No-render est 5 a 10 fois plus rapide que render-true pour le meme site
• No-render ne consomme aucun temps de navigateur (gratuit pendant la beta)
• Le temps reel evolue lineairement avec le nombre de pages pour les crawls no-render
• Les sites avec des directives crawl-delay dans robots.txt seront lents independamment des parametres, car le crawler les respecte

Optimisation des couts

Le plan Workers Paid coute 5 $/mois. Au-dela, les couts proviennent des heures de navigateur consommees par les crawls en render-true.

Niveau gratuit : 10 heures de navigateur par mois. Un crawl en render-true de 500 pages avec blocage de ressources utilise environ 15 a 20 minutes de temps de navigateur. Vous pouvez executer plus de 30 crawls optimises par mois dans le cadre du niveau gratuit.

Sans blocage de ressources : le meme crawl de 500 pages pourrait utiliser plus de 60 minutes de temps de navigateur, reduisant votre capacite gratuite a environ 10 crawls par mois.

Les crawls no-render sont gratuits pendant la periode beta. Pour les sites rendus cote serveur, il n’y a aucune raison d’utiliser render-true.

Formule de cout

Cout navigateur = (pages x secondes_par_page) / 3600 x 0,09 $

A 2 secondes par page (render-true optimise) : 500 pages = 0,28 heures = 0,025 $

A 7 secondes par page (non optimise) : 500 pages = 0,97 heures = 0,087 $

La difference est faible par crawl, mais s’accumule lorsque vous executez des crawls quotidiens ou hebdomadaires sur plusieurs sites.

Limites a connaitre

Problemes courants et solutions

Erreurs 403 sur la plupart des pages : le site dispose d’une protection anti-bot (Cloudflare Bot Management, Akamai, Datadome). Cela ne peut pas etre contourne via le endpoint /crawl. Le crawl se terminera mais la plupart des pages renverront des erreurs.

Le crawl en render-true se bloque vers la fin : une ou plusieurs pages ont des ressources a chargement lent qui bloquent le navigateur. Ajoutez --block-resources image media font stylesheet et --wait-until domcontentloaded.

Contenu manquant en mode no-render : le site charge le contenu via JavaScript. Passez a render-true avec les optimisations de blocage de ressources et d’attente.

Le script plante en cours de crawl : le job de crawl continue de s’executer sur les serveurs de Cloudflare. Verifiez le statut et recuperez les resultats quand il est termine :

python crawl.py status <job_id>
python crawl.py results <job_id> -o out.json

Resultats vides avec la source sitemaps : le sitemap du site est peut-etre manquant ou bloque. Passez a --source links ou --source all.

Limitations connues

Avant de construire un workflow autour du endpoint /crawl, soyez conscient de ces contraintes :

• Resolution defectueuse des URL relatives : le convertisseur markdown de Cloudflare resout incorrectement les URL relatives comme //www.example.com/path en ajoutant l’URL de la page en prefixe. Cela cree des chemins malformes dans la sortie, en particulier sur les sites Shopify.
• Contenu repetitif sur chaque page : les menus de navigation, les mega menus et les pieds de page apparaissent dans le markdown de chaque page. Pour un site Shopify typique, environ 90 % du contenu par page est du contenu de template repete. Consultez notre analyse des ratios de contenu repetitif sur de vrais crawls Shopify.
• Pas d’extraction de donnees structurees : les donnees JSON-LD, schema.org et OpenGraph ne sont pas analysees en mode no-render. Le mode render-true capture les balises OG de base dans les metadonnees, mais pas le schema complet.
• Pas de detection des 404 : le crawl ne traite que les URL actives. Les liens morts et les liens internes casses ne sont pas signales.
• URL de depart unique : l’API accepte une seule URL et explore a partir de celle-ci. Elle n’accepte pas de liste d’URL. Pour la recuperation d’URL par lots, utilisez plutot les endpoints /markdown ou /scrape.

Questions frequemment posees

Faut-il utiliser render true ou render false avec Cloudflare /crawl ?

Utilisez render false (--no-render) pour les sites rendus cote serveur comme Shopify, WordPress et les sites statiques. Utilisez render true uniquement pour les applications monopage construites avec React, Vue ou Angular ou le contenu se charge via JavaScript. Lors de nos tests, les sites Shopify ont renvoye un contenu identique a environ 90 % dans les deux modes.

Combien coute Cloudflare Browser Rendering /crawl ?

Un plan Workers Paid coute 5 $/mois. Les crawls en render-false ne consomment aucun temps de navigateur et sont gratuits pendant la beta. Les crawls en render-true utilisent des heures de navigateur : 10 heures/mois sont gratuites, puis 0,09 $/heure. Le blocage des images, polices et feuilles de style lors des crawls en render-true reduit considerablement le temps de navigateur.

Quelle est la meilleure source de decouverte d’URL pour Cloudflare /crawl ?

Utilisez --source sitemaps pour les sites avec des sitemaps complets comme Shopify et WordPress. Cela offre une couverture previsible et complete. Utilisez --source links ou all lorsque le sitemap peut etre incomplet ou que vous souhaitez decouvrir les pages comme le ferait un moteur de recherche.

Pourquoi mon crawl Cloudflare en render-true se bloque-t-il sur les dernieres pages ?

Les pages avec des ressources a chargement lent comme les grandes images ou les scripts tiers peuvent bloquer le navigateur headless pendant plus de 60 secondes. Corrigez cela en ajoutant --block-resources image media font stylesheet et --wait-until domcontentloaded a votre commande de crawl.