Cloudflare : `/crawl`, un seul appel API pour crawler un site web entier

• Cloudflare propose en bêta publique le nouvel endpoint /crawl de Browser Rendering, capable de crawler un site web entier avec un seul appel API
• En soumettant une URL de départ, il explore automatiquement les pages, les rend avec un navigateur headless et renvoie les résultats aux formats HTML, Markdown et JSON
• Il offre diverses fonctionnalités, dont une sortie JSON structurée basée sur Workers AI, des contrôles de portée comme la profondeur de crawl, les limites de nombre de pages et les motifs génériques, ainsi que le crawl incrémental et un mode statique
• Il respecte les règles de robots.txt et prend aussi en charge crawl-delay pour éviter un trafic anormal
• Il peut être utilisé pour l’entraînement de modèles, la mise en place de pipelines RAG, ainsi que la recherche et la surveillance de contenus à l’échelle d’un site

---

Aperçu de l’endpoint /crawl

• Le nouvel endpoint /crawl ajouté au service Browser Rendering de Cloudflare permet d’explorer un site web entier et d’en collecter le contenu avec un seul appel API
  • L’utilisateur soumet une URL de départ, puis le système suit automatiquement les liens, rend les pages et renvoie les résultats
  • Le format de sortie peut être choisi parmi HTML, Markdown et JSON structuré
• Cette fonctionnalité est disponible en bêta publique (open beta) et accessible aussi bien sur les offres Workers Free que Paid
• Les tâches de crawl sont exécutées de façon asynchrone
  • Après soumission de l’URL, un job ID est attribué, puis les résultats peuvent être consultés une fois le traitement terminé
  • Les pages sont traitées séquentiellement, et les résultats finalisés peuvent être consultés au fur et à mesure

Fonctionnalités principales

• Prise en charge de plusieurs formats de sortie
  • Les résultats peuvent être renvoyés dans divers formats, notamment HTML, Markdown et JSON
  • Le format JSON fournit des données structurées via Workers AI
• Contrôle de la portée du crawl (crawl scope controls)
  • Il est possible de définir la profondeur de crawl, la limite du nombre de pages et l’inclusion/exclusion de motifs d’URL
• Découverte automatique des pages (automatic page discovery)
  • Les URL sont découvertes automatiquement à partir du sitemap, des liens de page ou des deux
• Crawl incrémental (incremental crawling)
  • Les paramètres modifiedSince et maxAge permettent d’ignorer les pages inchangées afin de réduire le temps et les coûts
• Mode statique (static mode)
  • Avec le paramètre render: false, le navigateur n’est pas lancé et seul le HTML statique est récupéré, ce qui permet un crawl rapide des sites statiques
• Bot au comportement correct (well-behaved bot)
  • Il respecte les consignes de robots.txt et reconnaît aussi le paramètre crawl-delay

Cas d’usage et documentation

• Cet endpoint est utile pour la collecte de données d’entraînement de modèles, la mise en place de pipelines RAG et la recherche ainsi que la surveillance de contenu de site
• Les utilisateurs peuvent s’appuyer sur la documentation de l’endpoint crawl pour la configuration
• Si vous définissez votre propre site comme cible de crawl, il faut consulter les bonnes pratiques robots.txt et sitemap

Offres disponibles

• Disponible sur les offres Workers Free et Paid

[hmmhmmhm]

Je l’ai essayé rapidement, mais on dirait que ça ne parvient pas à contourner le blocage des bots ; pour l’instant, je pense que je vais continuer à privilégier apify ou zyte... haha

[xguru]

Est-ce que ça contourne aussi la fonction de blocage des bots de Cloudflare ?
Ils vendent à la fois la lance et le bouclier ??
Il y a un truc qui me paraît bizarre, haha

[eoeoe]

On dirait le début de Tout le monde's Marble hahaha
Un truc qui neutralise une capacité spéciale qui annule la capacité de défense d’une certaine carte...

[cnaa97]

Haha, c’est assez drôle d’une certaine façon.

[GN⁺]

Commentaires sur Hacker News

• D’après mon expérience, cela ne fonctionne pas sur les pages protégées par Cloudflare
  Malheureusement, on a l’impression qu’ils créent eux-mêmes le problème avant de revendre la solution

  • Tant que ça passe la protection anti-bot d’Azure, ça ira peut-être

• Il est surprenant que Cloudflare n’héberge pas une version pré-scrapée des sites web qui utilisent son proxy
  Par exemple, ils pourraient proposer quelque chose comme https://www.example.com/cdn-cgi/cached-contents.json, et comme le contenu est déjà dans le cache, il ne devrait pas être nécessaire de passer par un service ou une API de scraping
  Bien sûr, il y a sûrement des raisons pour lesquelles ils ne le font pas, mais c’est étonnant que ce ne soit pas proposé par défaut

  • Rendre public un tel dump du cache détruirait complètement les hypothèses de confidentialité et de droit d’auteur autour de l’original
    On pourrait ajouter des contrôles d’accès, mais ce serait au final recréer une API CDN complexe dont personne ne voulait, avec en plus des problèmes juridiques
    Entre un « JSON pratique » et « livrer tout le site à des scrapers IA », il n’y a qu’un pas
  • La conversion en JSON consomme du CPU, et stocker le résultat double l’espace de cache
    Le faire uniquement à la demande permettrait de réduire les requêtes à l’origine tout en conservant l’efficacité du cache
    Quand je travaillais dans un CDN, on utilisait le second hit caching pour améliorer le taux de hit du cache — on ne mettait en cache qu’à partir de la deuxième requête
  • Ce n’est pas exactement la même chose, mais Cloudflare propose déjà une fonctionnalité similaire
    Si on active Markdown for Agents, lorsqu’un système d’IA demande du text/markdown, le HTML est converti en Markdown en temps réel
  • En réalité, il est possible qu’en interne ils fournissent déjà le contenu public via le cache de cette manière
  • En revanche, cette approche peut fonctionner pour les sites simples, mais pour les sites complexes comme les SPA, un service de scraping nécessitant un rendu navigateur restera nécessaire

• Le fait que Cloudflare vende des contre-mesures anti-scraping tout en vendant en même temps un service de scraping fait un peu mafia
  C’est rendu possible par son influence sur l’ensemble d’Internet

  • Ce n’est pas le cas. C’est expliqué dans la documentation officielle
  • Le DNS gratuit ne représente qu’une partie de l’ensemble, et le vrai pouvoir vient des services de cache, de routage et de protection DDoS
    Le DNS sert à collecter des données et à entretenir une « bonne image »
  • Ils n’ont pas simplement vendu de la protection anti-scraping, ils ont vendu de la protection DDoS pour le web
  • Cloudflare semble vouloir jouer le rôle d’intermédiaire entre les éditeurs et les entreprises d’IA
    Les éditeurs seraient derrière Cloudflare, et si une entreprise d’IA veut les données, elle passerait par Cloudflare avec un accès payant
    Le principal segment de clientèle ne serait pas l’utilisateur ordinaire, mais les entreprises d’IA
  • Le endpoint /crawl respecte robots.txt
    Autrement dit, les URL interdites au crawl sont indiquées dans la réponse avec "status": "disallowed"

• Exposer un crawl endpoint structuré ressemble à une évolution naturelle de robots.txt ou des sitemap
  Si davantage de sites proposaient ce type de point d’entrée lisible par machine, l’indexation serait bien plus efficace
  Aujourd’hui, les crawlers gaspillent beaucoup de ressources à redécouvrir sans cesse les mêmes structures

  • Si on avait continué à utiliser REST, le gaspillage lié à l’indexation serait probablement bien moindre
    Je préfère concevoir les API pour les humains, puis laisser les fournisseurs de LLM optimiser au-dessus
  • En réalité, le HTML sémantique remplit déjà ce rôle
    Le HTML et le DOM sont par essence une structure destinée à être lue par des machines
    Il n’y a pas besoin d’inventer quelque chose de nouveau, il suffit de mieux utiliser les technologies existantes
  • Les seuls à profiter d’un crawling inefficace sont les éditeurs de solutions anti-bot
  • Mais cette structure pourrait aussi aggraver les attaques de la chaîne d’approvisionnement
    Elle pourrait être détournée pour montrer une page normale aux humains et une autre aux bots
  • Au final, montrer des contenus différents aux crawlers et aux humains crée un problème fondamental

• Cela aurait pu servir à l’archivage du web, et c’est dommage qu’il n’y ait pas de prise en charge du format WARC
  Cela aurait été utile pour les journalistes et les chercheurs

• Le serveur d’origine peut toujours détecter et bloquer les requêtes Browser Rendering de Cloudflare
  On peut les distinguer via l’en-tête CF-Worker, et les filtrer avec des règles WAF ou dans un middleware
  Toutefois, ces requêtes viennent de l’ASN 13335 de Cloudflare et ont un bot score faible, donc une défense fondée uniquement sur le score ne suffit pas
  Au final, les limitations de débit au niveau applicatif et l’analyse comportementale sont plus efficaces
  Il y a bien un conflit structurel, mais c’est similaire à la situation où les moteurs de recherche fournissent des outils pour les webmasters

  • Comme ils respectent robots.txt, c’est la méthode la plus simple

• Je me demandais si ce crawler fonctionne avant ou après la logique de blocage des bots

  • Il fonctionne en amont — voir la documentation officielle

• Je me suis dit qu’il serait bien de pouvoir fournir une version bien crawlée de mon site
  Si on donnait cette fonctionnalité aux administrateurs du site, les crawlers pourraient simplement y accéder en ne payant que les frais de transfert
  On pourrait aussi l’implémenter en lançant un job de crawl sur son propre site puis en le servant via un sous-domaine static.

  • Mais je ne vois pas très bien à quoi cela servirait
    Si le site est statique, il suffit de le rendre en HTML et de l’héberger, et s’il est dynamique, on peut se demander quelle valeur aurait un snapshot
    Ajouter du cache serait peut-être une meilleure approche

• On a l’impression que Cloudflare récupère en ce moment toutes les fonctionnalités cool
  Je me demande ce que fait AWS

• Cette fonctionnalité est vraiment impressionnante
  Cloudflare avance déjà dans la direction du futur