Un scraper qui fonctionne une fois n'a prouvé qu'une seule chose : qu'une requête, depuis une sortie, à un instant donné, a renvoyé du contenu. Il ne vous a pas dit à quelle fréquence cette cible répond, combien de temps elle met, ce que coûte une page, si un navigateur fait le moindre travail, ni autour de quelles formes d'URL du site les échecs se concentrent. Ce sont ces chiffres qui décident si un pipeline vaut la peine d'être construit, et on les découvre généralement une fois le pipeline en place.
Le Crawlbase Web Scraping Cookbook les publie d'emblée. C'est une page par site, et chaque page est mesurée sur du trafic Crawlbase réel avant la moindre ligne écrite : taux de succès, temps de réponse médian, prix en crédits, part du trafic réussi ayant utilisé un navigateur, route pays définie par les appels gagnants, motifs d'URL qui concentrent les succès, et nature réelle des échecs. Il couvre actuellement 17 739 sites mesurés et 356 recettes, sur les chiffres d'août 2026, actualisés chaque mois.
- Un taux de succès seul n'est pas un profil. Deux sites à 98 % peuvent différer d'un facteur 20 en latence et d'un facteur 20 en prix.
- Le rendu navigateur est une mesure, pas une valeur par défaut. Sur quatre des six sites ci-dessous, le token standard l'emporte et un navigateur n'apporte rien.
- Le routage par pays est une question du même ordre. Il fait gagner quatre points à Trustpilot et ne change rien du tout pour les autres.
- Les classes d'échec sont des instructions. Un 429 signifie qu'il faut espacer les appels, un 403 qu'il faut corriger la sortie, un 5xx qu'il faut attendre.
- Les chiffres décrivent une fenêtre mesurée, pas une garantie, et c'est pourquoi ils sont recalculés chaque mois.
Ce que mesure une recette
Chaque page est construite à partir du trafic observé vers ce site, pas d'un test effectué pour l'occasion. Les mesures sont celles autour desquelles un pipeline doit réellement se planifier.
| Mesure | Ce qu'elle répond | Ce qu'elle change |
|---|---|---|
| Taux de succès | À quelle fréquence les appels vers ce site renvoient du contenu | Le budget de retry et si la cible mérite un pipeline |
| Réponse médiane | Combien de temps prend un appel typique | Concurrence, ordonnancement, timeouts client |
| Prix en crédits | Ce que coûte une page, selon la complexité du domaine, doublé lors d'une récupération JavaScript | L'économie unitaire avant le passage à l'échelle, pas après |
| Part navigateur | Quelle part du trafic gagnant a utilisé le JavaScript token | Si le rendu est nécessaire ou seulement coûteux |
| Pays | Quelle sortie ont utilisée les appels réussis | Si country=XX se justifie |
| Motifs d'URL | Dans quelles formes de page les succès se concentrent | Ce qu'il faut implémenter et valider en premier |
| Classes d'échec | Ce qu'a répondu le site lorsqu'il a refusé | Une logique de retry adaptée au refus |
Un détail du comptage des succès mérite d'être dit clairement, parce qu'il change le sens du taux. Un site qui répond 200 avec une page de blocage ou un mur de consentement n'a pas renvoyé de contenu : le Cookbook le compte donc comme un échec et non comme un succès. Sur Google, cette classe est le premier poste d'échec, à 33,8 %.
Six sites, six profils différents
Le moyen le plus rapide de voir pourquoi un seul chiffre ne suffit pas est de mettre six recettes réelles côte à côte. Tous les chiffres ci-dessous sont les mesures d'août 2026 publiées sur chaque page, les motifs et les échecs étant lus dans le journal des requêtes depuis le 14 août 2026.
Google : rapide, assez bon marché, sans navigateur
La recette google.com mesure 97,0 % de succès, une réponse médiane de 1,9 seconde, et 2 crédits par page. Les appels en token standard réussissent à 96,9 % et représentent 99,8 % du trafic : un navigateur n'est donc ici qu'un coût. Les pages de recherche dominent : /search représente 98,3 % des requêtes réussies, et 6,3 % des appels demandent le scraper google-serp pour obtenir du JSON structuré au lieu de HTML. Les échecs se répartissent presque également entre les pages de blocage ou de consentement renvoyées en 200 (33,8 %) et les requêtes qui n'ont jamais répondu dans le timeout (33,5 %), les limitations de débit atteignant 23,5 %.
LinkedIn : fiable, lent, et le plus cher
La recette linkedin.com mesure 98,0 % de succès, une réponse médiane de 14,7 secondes, et 20 crédits par page, le palier tarifaire Extreme II. Les appels en token standard réussissent à 99,9 % et représentent 96,0 % du trafic. Les succès se concentrent sur les pages d'offres d'emploi (41,5 %), les pages d'entreprise (27,3 %) et les profils (18,5 %). Les échecs sont dominés par le statut de refus propre au site, 999, à 58,5 %, les réponses 591 atteignant 27,1 %.
LinkedIn est l'argument le plus net en faveur de la lecture du profil complet. Jugé sur le taux de succès, c'est le deuxième site le plus fiable du groupe. Jugé sur le coût par page, il vaut vingt fois Target, et jugé sur la latence, neuf fois Google.
Allegro : presque parfait, et sans hâte
La recette allegro.pl mesure 99,7 % de succès, une réponse médiane de 16,5 secondes, et 2 crédits par page. La totalité du trafic réussi utilise le token standard. Les pages produit sous /produkt/{slug} représentent 77,3 % des succès. Les échecs sont menés par les timeouts (44,3 %), puis les refus 403 (36,9 %) et les réponses 400 (12,8 %).
Target : le site bon marché et rapide qui se fait limiter
La recette target.com mesure 96,4 % de succès, une réponse médiane de 1,6 seconde, et 1 crédit par page. Les appels en token standard réussissent à 97,7 % et représentent 97,2 % du trafic, et deux formes d'URL produit couvrent à elles deux 99,3 % des succès. Le profil d'échec est la partie intéressante : 48,1 % sont des limitations de débit 429, suivies des 403 à 32,4 % et des timeouts à 13,3 %. Bon marché et rapide, mais le site résiste au rythme, ce qui est un problème d'ordonnancement plutôt que de configuration.
Trustpilot : celui où le rendu et le pays comptent tous les deux
La recette trustpilot.com mesure 90,9 % de succès, une réponse médiane de 32,0 secondes, et 1 crédit par page, 2 crédits avec le JavaScript token dont cette recette a besoin. C'est le site du groupe où la configuration change à la fois le résultat et la facture. Les appels en JavaScript token réussissent à 94,0 % contre 29,5 % pour le token standard, et 94,0 % des appels l'utilisent. Le routage par pays change aussi le résultat : 46,2 % des appels réussis définissent la sortie US et réussissent à 92,4 %, contre 88,2 % sans pays défini. Les avis sous /review/{slug} représentent 97,5 % des succès. Les échecs sont menés par les 403 à 45,9 %.
C'est l'appel que la recette recommande, et c'est celui qu'il vaut la peine de copier, parce qu'il porte les deux décisions à la fois :
curl "https://api.crawlbase.com/?token=YOUR_JS_TOKEN&country=US&url=https%3A%2F%2Fwww.trustpilot.com%2Freview%2Fsd.se"
QQ.com : presque parfait, et il a quand même besoin du navigateur
La recette qq.com mesure 99,9 % de succès, une réponse médiane de 6,1 secondes, et 1 crédit par page, 2 crédits avec le JavaScript token dont cette recette a besoin. C'est le site le plus fiable du groupe et il a pourtant besoin du rendu : les appels en JavaScript token réussissent à 100 % contre 86,8 % pour le token standard, et 98,9 % des appels l'utilisent. Les pages de tag représentent 99,8 % des succès. La plupart des échecs sont les réponses 5xx du site lui-même, 72,4 % à elles seules.
QQ.com et Trustpilot illustrent le même point par les deux extrêmes. Un taux de succès affiché ne vous dit pas si un navigateur est nécessaire, parce que ce taux reflète déjà le fait que les appelants en utilisent un.
Les six côte à côte
| Site | Succès | Réponse médiane | Prix | Navigateur | Pays | Le profil |
|---|---|---|---|---|---|---|
| google.com | 97,0 % | 1,9 s | 2 crédits | Non | Aucun | Rapide et simple |
| linkedin.com | 98,0 % | 14,7 s | 20 crédits | Non | Aucun | Fiable, lent, cher |
| allegro.pl | 99,7 % | 16,5 s | 2 crédits | Non | Aucun | Fiable mais lent |
| target.com | 96,4 % | 1,6 s | 1 crédit | Non | Aucun | Bon marché, rapide, limité en débit |
| trustpilot.com | 90,9 % | 32,0 s | 2 crédits en JS | Oui | US aide | La configuration décide |
| qq.com | 99,9 % | 6,1 s | 2 crédits en JS | Oui | Aucun | Fiable, dépendant du rendu |
Lire une recette avant d'écrire le scraper
L'intérêt pratique du profil est qu'il supprime la phase de devinettes au début d'une intégration, là où se trouve l'essentiel de l'effort perdu.
Partir de la configuration qui fonctionne déjà
Chaque recette indique le token et le pays qu'a utilisés le trafic réussi, de sorte que le premier appel est informé plutôt qu'exploratoire. Pour un site en token standard comme Google, c'est toute la configuration :
from crawlbase import CrawlingAPI api = CrawlingAPI({'token': 'YOUR_TOKEN'}) r = api.get('https://www.google.com/search') html = r['body']
N'ajouter un navigateur que là où la mesure le demande
Le rendu est le réflexe le plus courant et le gaspillage le plus courant. Google, LinkedIn, Allegro et Target sont tous traités en token standard dans le trafic observé : un navigateur y ajoute donc du coût et de la latence à un appel qui fonctionnait déjà. Trustpilot et QQ.com sont le cas inverse, où le rendu fait la différence entre 94,0 % et 29,5 %, ou entre 100 % et 86,8 %. Sur la Crawling API vous pouvez le demander de deux façons : appeler avec le JavaScript token, ou appeler avec le Normal token et ajouter javascript=true, qui bascule vers votre clé JavaScript avant le crawl, de sorte qu'une seule clé couvre tout. Avec Smart AI Proxy le réglage est javascript=true dans l'en-tête CrawlbaseAPI-Parameters de la requête. Les deux voies sont facturées comme une requête JavaScript, ce qui explique le prix en crédits doublé sur ces deux sites.
Laisser la classe d'échec choisir le retry
La répartition des échecs est la partie qui paie après le lancement, parce que chaque classe appelle une réponse différente. Réessayer immédiatement après un 429 le reproduit. Réessayer un 403 sans changer de sortie le reproduit aussi.
- 429 signifie que le site vous impose un rythme. Espacez les appels, ou confiez-les au Crawler, qui les cadence pour vous. La moitié des échecs de Target sont de ce type.
- 403 signifie que la sortie est refusée. Définissez le pays qu'utilisent les appels réussis et réessayez une fois ; un second refus signifie généralement que l'URL elle-même est protégée.
- 5xx signifie que c'est le site qui échoue, pas la récupération. Attendez et réessayez plus tard. Sur QQ.com, cela représente près des trois quarts de tous les échecs.
- Les timeouts signifient que la page n'a pas terminé dans la limite. Gardez le timeout de votre client au-dessus de la réponse médiane du site, ce qui est précisément la raison pour laquelle la recette la publie.
- Un 200 porteur d'une page de blocage ou de consentement est un échec déguisé en statut de succès. Il n'est pas facturé, et c'est la raison de vérifier le contenu plutôt que le statut.
Les recettes y sont mesurées : un seul endpoint, le rendu navigateur et la gestion anti-bot à l'intérieur de la récupération, et cb_status qui vous indique si la page est revenue. Les requêtes échouées ne sont pas facturées. Commencez gratuitement avec jusqu'à 5 000 requêtes, sans carte.
De la recette au pipeline
Le profil s'applique au début d'un développement, là où les inconnues sont les moins coûteuses à lever.
Pour une équipe qui choisit une infrastructure plutôt que d'écrire la récupération, les mêmes chiffres répondent à une autre question. Fiabilité, latence et prix sont des propriétés de la cible, pas de la plateforme : « pouvez-vous scraper ce site » est donc moins utile que « combien coûte ce site, à quel point est-il lent, et que fait-il quand il refuse ». Les six sites ci-dessus vont de 1 à 20 crédits par page et de 1,6 à 32,0 secondes, sur une seule plateforme. La modélisation des coûts part du prix de la cible :
100,000 pages x 1 credit = 100,000 credits (target.com) 100,000 pages x 20 credits = 2,000,000 credits (linkedin.com)
Le calculateur de prix convertit ces crédits en un montant mensuel. Le point important est que le multiplicateur est connaissable avant que le pipeline existe, et non après la première facture.
Ce que les chiffres ne prétendent pas
Une recette décrit le trafic mesuré sur une fenêtre donnée. Ce n'est pas une promesse sur demain, ni une affirmation que chaque page du site se comporte comme celles de l'échantillon. Les sites changent de protection, font tourner leur infrastructure et réajustent leurs limites de débit : c'est pourquoi chaque page porte le mois où elle a été mesurée et une date de dernier test, et pourquoi l'ensemble est actualisé tous les mois plutôt que laissé vieillir. Quand un site cesse de répondre, sa recette est retirée au lieu d'être conservée comme documentation de quelque chose qui ne fonctionne plus.
Les motifs et les classes d'échec proviennent du journal des requêtes depuis le 14 août 2026 : ils décrivent donc les formes de page que les comptes Crawlbase récupèrent réellement. Une forme d'URL que personne ne demande n'apparaîtra pas, même si le site la sert.
Conclusion
La plupart des décisions de scraping sont prises deux fois : une première fois par hypothèse, une seconde après que le trafic a montré ce que le site fait réellement. Le Cookbook avance la seconde version. Avant d'écrire un extracteur, vous pouvez voir à quelle fréquence la cible répond, combien de temps elle met, ce que coûte une page, si le navigateur fait le moindre travail, quelle sortie utilisent les appels gagnants, quelles formes d'URL portent les succès, et ce qu'étaient les refus.
Trouvez votre cible dans le Cookbook, partez de l'appel que les mesures appuient, et créez un compte gratuit pour le tester sur votre propre charge de travail.
Questions fréquentes (FAQ)
D'où viennent les chiffres du Cookbook ?
Du trafic Crawlbase vers ce site : toutes les requêtes de tous les comptes sur le mois indiqué pour le taux de succès, et le journal des requêtes depuis le 14 août 2026 pour les motifs, les pays et les classes d'échec. Ce sont des mesures du trafic observé sur cette fenêtre, pas des garanties de performances futures, et aucun client ni aucun compte n'est identifié où que ce soit dans les données.
« Navigateur requis » signifie-t-il que je dois exécuter un navigateur moi-même ?
Non. Cela signifie que la cible a besoin d'un rendu JavaScript, et c'est Crawlbase qui effectue ce rendu. Avec la Crawling API et le Crawler, vous le demandez soit avec le JavaScript token soit avec votre Normal token plus javascript=true, qui bascule les clés avant le crawl ; avec Smart AI Proxy vous transmettez javascript=true dans l'en-tête CrawlbaseAPI-Parameters de la requête. Les deux comptent comme une requête JavaScript pour la facturation.
Puis-je estimer ce qu'une cible coûtera avant de construire ?
Oui, et c'est en grande partie l'intérêt. La recette publie le prix en crédits d'une page sur ce site, fixé par la complexité du domaine, de sorte que le nombre de pages multiplié par le prix donne le total en crédits, et le calculateur le convertit. Surveillez la colonne navigateur en le faisant : un site qui a besoin du rendu est facturé au tarif JavaScript doublé, ce qui explique que Trustpilot et QQ.com coûtent 2 crédits par page plutôt que 1. La consommation réelle dépend encore de votre configuration et du produit par lequel vous faites passer le trafic.
Pourquoi une réponse 200 est-elle parfois comptée comme un échec ?
Parce qu'une page de blocage ou un mur de consentement servi avec un 200 n'est pas le contenu que vous avez demandé. Le compter comme un succès gonflerait tous les taux du site et masquerait la façon la plus courante dont les cibles modernes refusent. Ces réponses ne sont pas facturées non plus.
À quelle fréquence une recette est-elle actualisée ?
Tous les mois. Chaque page indique le mois de ses mesures et la date de son dernier test, de sorte qu'un profil obsolète est visible plutôt que silencieux. Les recettes des sites qui cessent de répondre sont retirées plutôt que laissées en place.
Crawlez n'importe quel site à grande échelle, sans combattre l'infrastructure.
Crawlbase gère les proxies, les empreintes et les CAPTCHA afin que votre équipe livre des pipelines de données au lieu de maintenir la plomberie de crawl. 1 000 requêtes gratuites, sans carte requise.