Benchmark des robots d'exploration Web pour alimenter l'IA en sites Web

Nous avons comparé quatre API de crawl sur trois domaines de difficulté variable à trois niveaux de profondeur maximale (5, 10, 20) avec une limite de 1 000 pages, en mesurant la couverture du crawl, le temps d’exécution, la découverte de liens, la qualité des liens markdown et la précision de l’extraction des titres.

Si vous souhaitez :

• Transformer des pages Web en données structurées, consultez notre guide sur le web scraping.
• Explorer des sites Web entiers, poursuivez votre lecture.

Benchmark des robots d’exploration Web

Vous pouvez lire notre méthodologie de benchmark.

Nombre moyen de pages explorées par rapport au coût par 1 000 pages

Pages explorées par domaine selon la profondeur maximale

Firecrawl a constamment exploré environ 100 pages sur theregister.com quelle que soit la profondeur maximale, environ 90 pages sur entrepreneur.com à tous les niveaux de profondeur, et seulement environ 30 pages sur amazon.com, probablement en raison de la protection anti-bots agressive d’Amazon. Il est notable que l’augmentation de la profondeur maximale n’a eu pratiquement aucun impact sur le nombre de pages que Firecrawl a pu explorer sur n’importe quel domaine.

Apify a démontré la performance la plus constante, atteignant la limite de crawl maximale de 1 000 pages sur chaque domaine à chaque niveau de profondeur sans difficulté apparente, même sur des sites fortement protégés comme Amazon.

Cloudflare a montré un comportement irrégulier au cours des tests :

• Sur theregister.com à une profondeur maximale de 5, il n’a exploré que 100 pages, mais à une profondeur maximale de 20, il a atteint près de 1 000 pages.
• Comme nous l’avons observé lors de tests précédents, Cloudflare explore parfois une seule page puis termine complètement la tâche. Nous avons confirmé que ce n’était pas un problème de cache (le cache était désactivé) et avons testé avec des temps d’attente entre les exécutions allant jusqu’à 1 minute, mais le comportement a persisté. À une profondeur maximale de 10 sur theregister.com, ce problème précis s’est produit : Cloudflare n’a exploré qu’une seule page avant de s’arrêter.
• Sur entrepreneur.com, Cloudflare a exploré 780 pages à une profondeur de 5, est passé à 885 à une profondeur de 10, puis a chuté brutalement à seulement 172 pages à une profondeur de 20. Cette baisse peut être liée au planificateur de crawl de Cloudflare qui dépriorise ou expire les chaînes de liens plus profondes, ou elle pourrait refléter une limite de concurrence interne qui provoque l’arrêt prématuré de la tâche lorsque la frontière de crawl devient trop importante à des profondeurs plus élevées.
• Sur amazon.com, Cloudflare a exploré 905 pages à une profondeur de 5, mais ce nombre a régulièrement diminué à mesure que la profondeur maximale augmentait, chutant à 809 à une profondeur de 10 et à 795 à une profondeur de 20, ce qui suggère que les configurations de crawl plus profondes peuvent amener Cloudflare à passer plus de temps sur la découverte de liens plutôt que sur la récupération réelle des pages.

Nimble a atteint ou approché la limite de 1 000 pages sur theregister.com à tous les niveaux de profondeur (1 000 / 1 000 / 999). Sur entrepreneur.com, il a exploré 1 000 pages à une profondeur de 5, mais a montré de légères baisses à des profondeurs plus élevées (896 à une profondeur de 10, 983 à une profondeur de 20), peut-être en raison de son délai d’expiration de 7 heures atteint avant de terminer le crawl complet à des niveaux plus profonds ; toutes les exécutions de Nimble se sont terminées avec un statut de délai d’expiration. Amazon s’est avéré plus difficile :

• À une profondeur de 5, il n’a réussi à explorer que 319 pages, mais à une profondeur de 10, il est passé à 988 pages, puis a chuté à 906 à une profondeur de 20
• Cette irrégularité reflète probablement la combinaison des mécanismes de protection anti-bots d’Amazon et des contraintes de délai d’expiration de Nimble, où les crawls plus profonds prennent plus de temps pour traiter chaque page et peuvent rencontrer davantage de défis anti-bots en cours de route

Temps d’exécution par domaine selon la profondeur maximale

Firecrawl a été le fournisseur le plus rapide sur tous les domaines, terminant les crawls en moins de 5 minutes, généralement entre 75 et 265 secondes. Cette vitesse se fait au détriment de la couverture, car Firecrawl a également exploré le moins de pages. Essentiellement, il termine rapidement parce qu’il s’arrête tôt.

Apify a mis environ 2 200 à 2 400 secondes (~40 minutes) sur theregister.com, quelle que soit la profondeur. Sur entrepreneur.com et amazon.com, les temps d’exécution ont été nettement plus longs, de 8 300 à 15 900 secondes (2 à 4 heures), reflétant des structures de site plus vastes et plus complexes. Malgré ces temps plus longs, Apify a systématiquement atteint la limite de 1 000 pages, ce qui en fait le plus fiable en termes de rapport couverture/temps.

Cloudflare a montré des temps qui reflètent ses nombres de pages explorées irréguliers :

• Sur theregister.com à une profondeur de 10, il a terminé en seulement 1 seconde, car il n’a exploré qu’une seule page avant de s’arrêter.
• Sur entrepreneur.com à une profondeur de 20, il a terminé en 10 secondes après n’avoir exploré que 172 pages.
• Lorsque Cloudflare termine un crawl complet, les temps varient de 3 500 à 25 200 secondes.
• À mesure que la profondeur maximale augmente, Cloudflare semble privilégier l’atteinte de pages plus profondes au détriment de l’étendue, explorant moins de pages mais terminant plus rapidement. Sur amazon.com, le temps d’exécution est passé de 25 200 secondes (délai d’expiration) à une profondeur de 5 à seulement 5 660 secondes à une profondeur de 20, tandis que le nombre de pages explorées a également diminué, passant de 905 à 795. Cela suggère que le crawler de Cloudflare change de stratégie à des profondeurs plus élevées, consacrant moins de temps à la découverte large et plus à la traversée en profondeur.

Nimble a atteint le délai d’expiration de 7 heures (25 200 secondes) à chaque exécution, sur tous les domaines et tous les niveaux de profondeur. C’est notable car lors de nos tests rapides précédents avec une profondeur maximale de 1, Nimble avait terminé sans dépasser le délai. Dans le benchmark complet avec des profondeurs de 5 à 20 et une limite de 1 000 pages, il a systématiquement continué à s’exécuter jusqu’à atteindre le délai d’expiration. Malgré cela, Nimble a tout de même réussi à explorer un grand nombre de pages dans la plupart des cas (~900 à 1 000 sur theregister.com et entrepreneur.com), ce qui signifie qu’il explore activement pendant les 7 heures mais ne signale simplement jamais la fin.

Taux de remplissage du texte des liens par fournisseur selon la profondeur maximale

Pour évaluer la qualité de la sortie markdown, nous avons mesuré le pourcentage de liens dans le markdown de chaque fournisseur qui contiennent un texte d’ancrage, la partie de texte cliquable d’un lien. Un texte d’ancrage manquant (par exemple, [](/about) au lieu de [About Us](/about)) signifie que le crawler n’a pas réussi à extract l’étiquette du lien.

• Nimble : 100 % à toutes les profondeurs
• Cloudflare : 91-94 %
• Firecrawl : 90 %
• Apify : 77-78 %, soit environ 1 lien sur 5 sans texte d’ancrage

La profondeur de crawl a eu un impact minime sur les taux de remplissage pour tous les fournisseurs, ce qui suggère qu’il s’agit d’une caractéristique du moteur d’analyse de chaque fournisseur plutôt que d’un paramètre de crawl.

Taux de remplissage du texte des liens par fournisseur selon le domaine

L’examen des taux de remplissage sur différents domaines révèle comment la complexité du site affecte la qualité d’extraction des liens de chaque fournisseur.

• Nimble a maintenu 100 % sur tous les domaines.
• Apify a montré le plus de variations, avec 89 % sur amazon.com mais une baisse à 66 % sur entrepreneur.com, ce qui signifie qu’un tiers de ses liens sur ce site n’avaient pas de texte d’ancrage. Cela suggère que Apify éprouve plus de difficultés avec les sites riches en contenu et aux structures de navigation complexes.
• Firecrawl a obtenu les meilleurs résultats sur theregister.com (98 %), mais a chuté à 81 % sur entrepreneur.com, suivant un schéma similaire à celui d’Apify.
• Cloudflare a été le plus constant après Nimble, restant entre 89 et 94 % quel que soit le domaine.

Entrepreneur.com s’est avéré être le domaine le plus difficile pour l’extraction du texte des liens, Apify (66 %) et Firecrawl (81 %) y affichant tous deux leurs scores les plus bas, probablement en raison de l’utilisation intensive par le site de menus de navigation imbriqués et d’éléments de contenu dynamiques plus difficiles à convertir proprement en markdown.

Nombre total de liens dans la sortie markdown par domaine selon la profondeur maximale

La variance du nombre de liens entre les fournisseurs a été constamment élevée (74-97 %), indiquant que les fournisseurs extract des nombres très différents de liens à partir des mêmes pages. Pour obtenir une vue plus détaillée de cette disparité, nous avons mesuré le nombre total de liens markdown par fournisseur.

• Apify a renvoyé le plus de liens au total, en particulier sur amazon.com avec plus de 420K liens à une profondeur de 5 (~423 par page). Sur entrepreneur.com, il s’est stabilisé autour de 63K quelle que soit la profondeur. Sa sortie comprend des traceurs publicitaires et des pixels de suivi en plus des liens de contenu des pages.
• Cloudflare a atteint un pic de 303K sur entrepreneur.com à une profondeur de 10, mais a chuté à 53K à une profondeur de 20. Sur la même page d’accueil d’entrepreneur.com, Cloudflare a extrait 434 liens contre 143 pour Apify, en capturant tous les menus et sous-menus de navigation.
• Firecrawl a constamment renvoyé entre 5 et 9K liens dans toutes les configurations, limité par son faible nombre de pages explorées.
• Nimble a renvoyé entre 3 et 40K liens au total, avec une moyenne de 5 à 28 liens par page, contre 60 à 420 pour les autres fournisseurs. Sur la page d’accueil d’entrepreneur.com, Nimble a renvoyé 13 liens, contre 434 pour Cloudflare, limités aux principaux titres d’articles. Son taux de remplissage de 100 % reflète le fait que tous les liens qu’il a inclus avaient un texte d’ancrage, plutôt qu’une couverture complète des liens. Nimble ne génère pas de liens markdown standard. Son décompte inclut des liens HTML échappés trouvés dans la sortie markdown.

Taux de présence des titres par fournisseur

La similarité des titres entre fournisseurs a montré un écart inférieur à 1 % sur tous les tests et domaines, confirmant que lorsque les fournisseurs extract un titre, ils renvoient systématiquement le même résultat. Le taux de présence des titres est également resté entre 98 et 100 % à tous les niveaux de profondeur maximale, montrant que la profondeur de crawl n’a pas d’impact significatif sur l’extraction des titres.

Lorsqu’on ventile par domaine, certaines différences sont apparues :

Sur entrepreneur.com et theregister.com, la plupart des fournisseurs ont atteint des taux de présence de titres de 99 à 100 %. Amazon.com a été le seul domaine où des différences significatives sont apparues : Firecrawl a chuté à 93 % et Nimble à 95,9 %, tandis qu’Apify a maintenu 99,6 %. Cela correspond à la protection anti-bots plus lourde d’Amazon, qui peut bloquer ou déformer les réponses des pages, amenant certains fournisseurs à renvoyer des pages sans titres extractibles.

Caractéristiques des meilleures API de robots d’exploration Web

Decodo fournit l’exploration via /crawl, un endpoint de son API Web Data. Tous les endpoints de l’API Web Data fonctionnent sous une seule API et une seule clé d’API. Une tâche /crawl collecte jusqu’à 10 000 pages et renvoie chaque page en Markdown ou HTML.

• Les utilisateurs définissent la profondeur maximale, filtrent les chemins avec des expressions régulières et limitent le crawl à un hôte, à ses sous-domaines ou à tous les domaines.
• Le crawler utilise le sitemap, les liens de page ou les deux, et demande les pages depuis un pays et une locale choisis.
• Une durée maximale arrête la tâche et conserve les pages collectées jusqu’à présent.
• Une page qui échoue sans JavaScript bénéficie d’un nouvel essai avec rendu JavaScript.

L’endpoint /map liste jusqu’à 147 000 URL à partir d’une page et du sitemap de premier niveau du site sans récupérer le contenu, afin qu’un crawl puisse cibler uniquement les chemins sélectionnés. Le gratuit plan comprend 10 000 requêtes par mois sans carte de crédit.

Apify explore des sites Web via Website Content Crawler, un Actor sur la plateforme Apify. Par défaut, il récupère les pages statiques en HTTP simple et bascule vers un navigateur sans tête pour les pages qui nécessitent JavaScript. Les utilisateurs peuvent également l’exécuter en mode navigateur uniquement ou en mode HTTP uniquement.

• Les utilisateurs définissent les URL de départ, la profondeur maximale, le nombre maximal de pages et les motifs d’URL à inclure ou exclure, et peuvent ajouter des sitemaps pour la découverte.
• Une date « modifié depuis » limite les recrawls aux pages modifiées.
• Un sélecteur CSS supprime la navigation, les en-têtes et les pieds de page avant la conversion.
• Le crawler renvoie du texte, du Markdown, du HTML et des captures d’écran, et peut télécharger les fichiers PDF, Word et Excel liés.

Apify connecte la sortie à LangChain, LlamaIndex, Pinecone et Qdrant, et propose le crawler comme outil MCP.

Cloudflare propose un endpoint /crawl dans son service Browser Rendering. Une tâche couvre jusqu’à 100 000 pages et s’exécute jusqu’à sept jours, et les résultats restent disponibles pendant 14 jours.

• Le crawler trouve les pages via les sitemaps, les liens de page ou les deux, et filtre les URL avec des motifs génériques.
• Il rend les pages dans un navigateur sans tête par défaut et peut à la place récupérer du HTML brut sans JavaScript.
• La sortie est en HTML, Markdown ou JSON.

Le crawler respecte robots.txt, y compris crawl-delay, et s’identifie avec un user agent fixe. Cloudflare déclare qu’il ne contourne pas les CAPTCHA ni les protections anti-bots.

L’endpoint /crawl de Firecrawl découvre et scrape les sous-pages d’une URL de départ et renvoie du Markdown, du HTML ou du JSON pour chaque page.

• Les utilisateurs définissent une limite de pages, une profondeur de découverte et des filtres de chemin par expressions régulières.
• Le crawl peut s’étendre aux chemins parents, aux sous-domaines ou à un saut de liens externes.
• Le crawler combine le sitemap avec les liens de page, ou utilise l’un des deux seulement.
• Un paramètre prompt transforme une instruction en langage naturel en paramètres de crawl.

Les résultats arrivent par interrogation, par événements webhook par page ou par un watcher SDK, et restent disponibles pendant 24 heures.

Nimble Crawl exécute chaque crawl comme une tâche d’arrière-plan pouvant aller jusqu’à 10 000 pages et 20 sauts de liens, et renvoie du HTML ou du Markdown pour chaque page.

• Les utilisateurs filtrent les chemins avec des expressions régulières et choisissent de suivre ou non les sous-domaines.
• Le crawler utilise le sitemap, les liens de page ou les deux comme source.
• Les URL qui ne diffèrent que par les paramètres de requête peuvent être comptées comme une seule page.
• Chaque crawl peut être exécuté depuis un pays et une locale choisis.

Un appel de statut indique combien de pages sont en attente, terminées ou en échec, et le contenu de chaque page provient de son propre appel de résultat. Les callbacks se déclenchent au démarrage du crawl, pour chaque page et à la fin.

Méthodologie du benchmark des robots d’exploration Web

Nous avons testé quatre API de crawl (Apify, Nimble, Cloudflare, Firecrawl) sur trois domaines de difficulté variable : amazon.com (forte protection anti-bots), entrepreneur.com (site de contenu complexe) et theregister.com (site d’actualités).

Configuration commune

Tous les fournisseurs ont reçu des paramètres de base identiques pour garantir une comparaison équitable :

• Sitemap : désactivé, les fournisseurs doivent découvrir les pages uniquement via les liens HTML.
• Liens externes : désactivés, les crawlers restent dans le domaine cible.
• Sous-domaines : activés, les pages des sous-domaines sont suivies (par exemple, india.entrepreneur.com).
• Rendu JavaScript : activé, tous les fournisseurs utilisent un navigateur sans tête.
• Cache : désactivé
• Limite de pages : 1 000 pages par exécution
• Délai d’expiration : 7 heures (25 200 secondes)
• Gestion des limites de débit : attente de 20 secondes avec jusqu’à 3 nouvelles tentatives en cas de HTTP 429

Chaque fournisseur a été testé à trois niveaux de profondeur maximale (5, 10, 20) sur les trois domaines, soit un total de 36 exécutions de crawl. Les fournisseurs ont été testés séquentiellement (pas en parallèle), chaque combinaison n’a été exécutée qu’une seule fois, et le statut du crawl a été interrogé toutes les 1 seconde.

Apify a été configuré avec l’actor website-content-crawler en utilisant Playwright/Firefox comme navigateur sans tête. L’accès aux sous-domaines a été contrôlé via des motifs glob, et le proxy intégré d’Apify a été utilisé pour toutes les requêtes.

Nimble, Cloudflare et Firecrawl ont été configurés à l’aide de leurs API REST respectives avec les paramètres communs décrits ci-dessus. Aucune configuration supplémentaire spécifique au fournisseur n’a été appliquée au-delà des paramètres standardisés.

Pour Cloudflare, nous avons utilisé le plan Workers Paid. Le coût indiqué reflète ce que nous avons dépensé pour explorer 1 000 pages avec ce plan. Cloudflare facture en fonction du temps de rendu du navigateur plutôt que du nombre de pages.

Pour Firecrawl, nous avons utilisé le plan Hobby. Le coût indiqué est le montant au prorata pour 1 000 crédits sur les crédits fournis dans ce plan. Le coût effectif par page varie selon le niveau du plan et selon l’achat éventuel de packs de crédits supplémentaires.

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Şipi, Nazlı},
  title  = {{Benchmark  des robots d'exploration Web pour alimenter l'IA en sites Web}},
  year   = {2026},
  month  = oct,
  howpublished    = {\url{https://aimultiple.com/web-crawler}},
  note   = {AIMultiple. Consulté le 22 octobre 2026}
}

Journal des modifications

9 mises à jour

Toutes9Général8Méthodologie1

202620242023

1. 7 avr

   Suppression des sections sur les tendances du secteur, les types de crawlers et les exemples de crawl web.

2. 6 avr

   Ajout d'un benchmark de quatre API de crawl sur trois domaines et trois niveaux de profondeur, avec graphiques de couverture, vitesse, liens et titres.

3. 6 avr

   Ajout d'une section méthodologie détaillant la configuration de crawl sur quatre fournisseurs, trois domaines et trois niveaux de profondeur.

4. 25 fév

   Une section, Les robots d'exploration web sont-ils légaux ?, a été ajoutée à l'article.

5. 11 fév

   Mise à jour de la section « Qu'est-ce qu'un robot d'exploration Web ? » avec les nouvelles tendances et modes de fonctionnement.

Cem Dilmegani

Analyste principal

Suivre

Cem est analyste principal chez AIMultiple depuis 2017.

Le travail de Cem chez AIMultiple a été cité par des publications mondiales de premier plan, notamment Business Insider, Forbes, Morning Brew et Washington Post, par des entreprises mondiales comme Deloitte et HPE, par des ONG comme World Economic Forum et par des organisations supranationales comme European Commission. [1], [2], [3], [4], [5]

Tout au long de sa carrière, Cem a été consultant en technologies, acheteur de technologies et entrepreneur technologique. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus de dix ans. Il a également publié un rapport McKinsey sur la digitalisation.

Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité du PDG. Il a également dirigé la croissance commerciale de l'entreprise de technologie profonde Hypatos, qui a atteint un revenu récurrent annuel à 7 chiffres et une valorisation à 9 chiffres, passant de 0 à ce résultat en deux ans. Le travail de Cem chez Hypatos a été couvert par des publications technologiques de premier plan comme TechCrunch et Business Insider.

Cem intervient régulièrement lors de conférences technologiques internationales. Il est diplômé de Bogazici University en tant qu'ingénieur informatique et titulaire d'un MBA de la Columbia Business School.

Voir le profil complet

Examiné techniquement par

Nazlı Şipi

Chercheuse en IA

Suivre

Nazlı est analyste de données chez AIMultiple. Elle a une expérience préalable en analyse de données dans divers secteurs, où elle a travaillé à transformer des datasets complexes en informations exploitables.

Voir le profil complet

Commentaires 1

Partagez vos idées

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire

Aggeliki

Jan 12, 2022 at 16:15

Hi Cem, I think there is a misunderstanding regarding the robots.txt role in the crawling context. The web bots can crawl any website when indexing is allowed without having the robots.txt somewhere on their top domain, subdomains and ports and so on. The role of a robots.txt is to keep control of the traffic from web bots so the website is not overloaded by requests.

Répondre