Le web s'est mis à noter les crawlersBandes de confiance, le 429 comme contrat, et à quoi ressemble un bon crawler aujourd'hui

Pendant l'essentiel de l'histoire du web, un crawler était jugé une seule fois, à la porte. Un serveur regardait le user agent, peut-être l'IP, et décidait de laisser entrer la requête ou non. Ce que le crawler faisait ensuite ne regardait personne, jusqu'à ce qu'un site s'effondre, et même alors la plainte partait vers une boîte abuse que personne ne lisait.

Dans la troisième semaine d'octobre 2026, cela a changé, trois fois en quatre jours. Le 13 octobre, Google a documenté que son fetcher Google-Agent signe une partie de ses requêtes avec Web Bot Auth. Les 15 et 16 octobre, un crawler de recherche se présentant avec une adresse Roblox a lu le robots.txt de trois sites amateurs de modèles 3D, l'a ignoré et a aspiré 145,5 Go. Et le 16 octobre, Cloudflare a annoncé que les Verified bots sont désormais notés en continu sur le respect du robots.txt et sur leur ralentissement après un 429.

Mis bout à bout, ces trois événements décrivent la nouvelle règle. L'identité vous fait passer la porte. La conduite décide si vous êtes encore le bienvenu le mois prochain. Pour quiconque exploite un crawler, la question n'est plus « puis-je récupérer cette page ? » mais « que dira le dossier de ce que j'ai fait ? »

Trois choses survenues en une semaine

Le crawler d'abord. Open3DLab, SFMLab et SmutBase sont trois petits sites tenus par les mêmes personnes, qui hébergent des modèles 3D faits par leurs utilisateurs. Le 26 octobre, ils ont publié leurs logs. Sur 34 heures, les 15 et 16 octobre, un client se présentant comme trellis2-data-sourcing/1.0 (3D foundation model research; [redacted]@roblox.com) a émis 26 429 requêtes depuis une seule adresse AWS, lu les pages de 18 926 projets et téléchargé 1 027 fichiers appartenant à 712 d'entre eux. Il a récupéré robots.txt et ne l'a pas respecté. 423 de ces projets étaient sous licence non commerciale uniquement. Quand les sites l'ont bloqué le 18 octobre, il est revenu le 19, puis le 20, et, selon les mots des sites, « n'a pas réduit ses tentatives de téléchargement face à nos blocages ». Roblox, selon une déclaration rapportée plus tard, a indiqué que l'agent d'un chercheur avait scrapé les sites par erreur et avait été mis hors service.

Rien dans ce crawler n'était caché. Il avait un user agent avec une adresse e-mail dedans. Il venait d'une seule IP. Il était, selon les critères du programme Verified bots, honnête sur son identité. Il était aussi très exactement le comportement que ce programme mesure et pénalise désormais, et les sites pouvaient le prouver à partir de leurs propres logs, ce qui explique que l'histoire ait fini en première page de Hacker News plutôt que dans une boîte abuse.

L'annonce de Cloudflare, publiée le lendemain de la passe principale du crawler, est avare sur le mécanisme et précise sur l'intention. « Continuous accountability for Verified bots » décrit deux signaux initiaux. Le premier demande si le trafic observé d'un bot est cohérent dans la durée avec les préférences publiées par le site, la RFC 9309 servant de référence pour la façon dont robots.txt est lu. Le second demande ce qui se passe après qu'un site a renvoyé un 429, en ses termes : « Ralentit-il, s'arrête-t-il, ou continue-t-il d'envoyer des requêtes au même rythme ? » Les résultats alimentent une « bande de confiance explicable », une étiquette que le billet prend soin de qualifier d'historique plutôt que de verdict, parce que les « violations isolées » comptent peu et que les « schémas répétés de comportement qui ignorent les préférences du site » comptent beaucoup. Les scores seront publiés sur Radar, et les propriétaires de sites pourront choisir la bande à partir de laquelle le trafic Verified est encore laissé passer.

La contribution de Google est plus discrète et, à certains égards, plus lourde de conséquences. Sa page Web Bot Auth, mise à jour le 13 octobre, indique qu'une partie des requêtes de Google-Agent, le fetcher derrière les agents hébergés sur l'infrastructure Google, sont signées et s'authentifient comme https://agent.bot.goog. L'implémentation est marquée expérimentale. Mais la page Google-Agent figure dans la liste des fetchers déclenchés par l'utilisateur, et la consigne pour cette liste n'a pas bougé : « Parce que la récupération a été demandée par un utilisateur, ces fetchers ignorent généralement les règles du robots.txt. » Le plus gros opérateur de crawlers de la planète signe donc désormais les requêtes d'un agent qui, selon sa propre documentation, ne lit pas le fichier sur lequel tout le monde est noté. Ce n'est pas de l'hypocrisie ; c'est la forme du débat à venir. Les signatures tranchent qui a envoyé une requête. Elles ne disent rien sur le fait qu'elle était la bienvenue.

Ce qu'une bande de confiance mesure réellement

Il est utile d'être concret sur l'échelle. À Cloudflare Connect, tenu du 19 au 21 octobre, Matthew Conroy, senior director of product management de l'entreprise, a déclaré que les agents avaient émis plus de 600 milliards de requêtes sur son réseau au dernier trimestre, presque quatre fois le chiffre de fin 2025, et que « moins d'une requête automatisée sur dix provient d'un bot qui s'identifie ». La prévision de Matthew Prince dans la même session : le trafic des agents atteindra mille fois le trafic humain d'ici cinq ans, avec cette réserve que toutes ses prédictions précédentes avaient été trop prudentes. Le rapport Q3 de DataDome, publié le 15 octobre, ajoute le détail qui explique pourquoi l'identité est soudain un produit : dans un échantillon de trafic de l'agent Muse de Meta, 99,3 % des requêtes venaient de plages cloud et CDN, dont 81,2 % de celles de Cloudflare, et l'agent ne se déclare pas. La réputation IP, l'outil sur lequel tout le secteur s'est appuyé pendant vingt ans, ne sait pas distinguer un agent du réseau edge sur lequel il tourne.

La notation doit donc reposer sur la conduite, et la conduite doit être observée dans la durée. C'est cela, la bande de confiance. Lue comme une spec d'ingénierie plutôt que comme un billet de politique, elle a quatre entrées.

L'identité est la condition préalable, pas le score. Web Bot Auth, le schéma de signature Ed25519 que nous avions couvert quand il est sorti avec le pay-per-crawl, est un document de groupe de travail IETF depuis septembre et a été révisé le 29 octobre sous le nom draft-ietf-webbotauth-httpsig-protocol-01. OpenAI et AWS signent ; Google expérimente ; la propre Web Search API de Cloudflare, lancée le 2 octobre avec Ceramic.ai, Exa et Linkup derrière elle, note que les trois « se sont engagés sur les standards de crawl des verified bots de Cloudflare ». Sans identité stable, il n'y a rien à quoi rattacher un historique, et c'est pourquoi le trafic non signé n'est pas noté du tout. C'est simplement la classe refusée par défaut.

Les préférences publiées sont le premier signal, et le vocabulaire bouge encore. La RFC 9309 est la base : des groupes, Allow et Disallow, la correspondance la plus longue l'emporte. Par-dessus viennent les Content Signals de Cloudflare, qui portent une finalité plutôt qu'un chemin : search, ai-input, ai-train, et depuis le 31 août un quatrième champ, use, avec les valeurs reference et full. Le propre endpoint de crawl de Cloudflare rejette désormais une requête par un 400 quand le contentUse déclaré par le crawler est plus permissif que celui du site. L'effort parallèle de l'IETF, le vocabulaire AI Preferences, a atteint le draft 08 le 14 septembre et reste un Internet-Draft ; le jalon d'août du groupe de travail est passé sans standard. Autrement dit, la notation a commencé avant que la grammaire soit finie.

La réponse au feedback est le second signal, et celui que la plupart des crawlers ratent sans s'en apercevoir. Un 429 n'est pas une erreur à réessayer ; c'est une instruction, et quand il porte un Retry-After c'est une instruction avec un nombre dedans. Le billet de Cloudflare le dit sans détour : ralentir ou s'arrêter après un 429 « augmente la confiance, tandis qu'ignorer le signal de façon répétée la diminue ». La plupart des bibliothèques de retry font l'inverse. Elles rejouent la requête échouée après un court délai et laissent la concurrence qui a provoqué le 429 exactement là où elle était.

L'efficacité ne fait pas partie de la notation initiale, et en fera partie. Le communiqué de presse de Cloudflare en juillet affirmait que « plus de 50 % du trafic de crawl des crawlers IA est consacré à récupérer de nouveau des pages inchangées », et son pilote avec OpenAI, en cours depuis juillet sur environ 1 % de son réseau, fournit au crawler des signaux de changement et filtre les pages qui n'existent pas ou se contentent de rediriger. Le billet rapporte des centaines de millions de pages nouvellement découvertes, et une phrase à retenir : « Un signal sur une page n'accorde pas la permission d'y accéder. » Les signaux sont construits pour les crawlers qui se comportent déjà bien ; ils ne sont pas une porte d'entrée.

Derrière les quatre, il y a l'argent. Pay Per Use, en bêta depuis le 30 septembre, rémunère un éditeur quand une entreprise d'IA déclare avoir utilisé une page, pas quand elle l'a récupérée, parce que, comme le dit Cloudflare, « facturer chaque crawl fait payer l'acheteur avant qu'il sache ce dont il a besoin ». Monetization Gateway, le même jour, répond à une requête par un 402 Payment Required et un prix, réglé via le protocole x402. Les deux exigent un acheteur à l'identité vérifiable et à l'historique propre. La bande de confiance est le score de crédit de ce marché.

Ce que les sites demandent, mesuré ce matin

Combien de tout cela a atteint les fichiers robots.txt en pratique ? Le 30 octobre, nous avons récupéré robots.txt sur les 2 000 premiers domaines de la liste Tranco avec un user agent de recherche qui s'identifiait, une requête par hôte. 1 130 ont servi un fichier lisible. Le reste, c'étaient des hôtes API et CDN sans rien à dire, 434 noms qui n'ont pas répondu du tout, et 145 qui ont répondu 403 à un crawler qui s'était présenté, ce qui est en soi un petit résultat.

Deux détails comptent plus que le titre. D'abord, la finalité est déjà découpée à la main : sur les 208 sites qui bloquent GPTBot entièrement, 21 nomment OAI-SearchBot et le laissent passer, et 18 font de même pour ChatGPT-User. Les opérateurs disent « indexe-moi, cite-moi, ne m'entraîne pas dessus » avec le seul vocabulaire qu'ils ont, c'est-à-dire un user agent par finalité. Ensuite, sur les 71 sites qui déclarent Content-Signal dans leur fichier, 39 portent exactement la même ligne, search=yes, ai-train=no, use=reference, qui est la valeur par défaut gérée par Cloudflare. Le nouveau vocabulaire arrive par le CDN, pas par l'éditeur de texte des propriétaires de sites, et 35 % des fichiers que nous avons récupérés sont revenus avec un cf-ray dans leurs headers. C'est le mécanisme par lequel un tableau de score devient les règles.

Une boucle de fetch qui passe

Aucune des quatre habitudes n'est difficile. Elles sont difficiles à tenir quand un crawl est en retard et qu'une file est pleine, et c'est pourquoi leur place est dans le fetcher plutôt que dans un runbook. Ce qui suit est une boucle de référence de 226 lignes en Python bibliothèque standard, citée dans les quatre parties qui comptent, exécutée contre une origine locale qui a des opinions : un robots.txt qui interdit /private/, un ETag sur chaque page, et un 429 avec Retry-After: 2 pour tout client au-delà de deux requêtes par seconde.

Lire les règles avant la première requête

La RFC 9309 dit qu'un crawler qui lit robots.txt doit le respecter, peut le mettre en cache, et ne devrait pas garder la copie en cache plus de 24 heures. Elle dit aussi quoi faire quand le fichier ne peut pas être lu : un 4xx signifie qu'il n'y a pas de règles, un 5xx ou une panne réseau signifie qu'il faut partir du principe que vous n'êtes pas autorisé, et réessayer plus tard. Le cache ci-dessous fait exactement cela, par hôte, et expose Crawl-delay pour que le budget puisse s'en servir.

def _load(self, scheme: str, host: str) -> urllib.robotparser.RobotFileParser | None:
    url = f"{scheme}://{host}/robots.txt"
    req = urllib.request.Request(url, headers={"User-Agent": self.user_agent})
    parser = urllib.robotparser.RobotFileParser(url)
    try:
        with urllib.request.urlopen(req, timeout=10) as resp:
            parser.parse(resp.read().decode("utf-8", "replace").splitlines())
            return parser
    except urllib.error.HTTPError as e:
        if 400 <= e.code < 500:
            parser.parse([])
            return parser
        return None
    except Exception:
        return None

def allowed(self, url: str) -> bool:
    parts = urllib.parse.urlsplit(url)
    host = parts.netloc
    with self._lock:
        cached = self._cache.get(host)
        if cached is None or time.time() - cached[0] > ROBOTS_TTL:
            cached = (time.time(), self._load(parts.scheme, host))
            self._cache[host] = cached
    parser = cached[1]
    return parser is not None and parser.can_fetch(self.user_agent, url)

La première fois que nous avons lancé la démo, le serveur de test n'avait pas fini de démarrer. Chaque URL est revenue disallowed, y compris celles que les règles auraient autorisées, parce que la boucle n'avait pas pu lire les règles. C'est le bon résultat. Un crawler qui ne parvient pas à savoir ce qu'un site veut ne doit pas deviner en sa propre faveur.

Traiter un 429 comme un contrat

Le budget par hôte est un token bucket, ce qui n'a rien de remarquable. Ce qui compte, c'est ce qu'il fait quand un 429 arrive. Il honore Retry-After s'il y en a un, recule avec du jitter s'il n'y en a pas, divise son débit par deux et, la partie que la plupart des implémentations sautent, abaisse son plafond à 80 % du débit qui a provoqué le 429. Le site vient de vous dire sa limite. Remonter le sonder toutes les quelques minutes est précisément le « schéma répété » que la bande de confiance est faite pour attraper. Cinq 429, en l'espace d'une minute, ouvrent un disjoncteur et l'hôte est laissé tranquille cinq minutes, moment où un humain devrait être en train de lire le log.

def on_429(self, retry_after: float | None) -> float:
    """Honour Retry-After when given, else back off exponentially with jitter."""
    with self._lock:
        now = time.monotonic()
        self._recent_429 = [t for t in self._recent_429 if now - t < self.trip_window] + [now]
        # The rate that drew the 429 is the host's limit: cap recovery
        # below it so one 429 is a lesson, not a cycle.
        self._ceiling = max(self.rate * 0.8, 0.05)
        self.rate = max(self.rate / 2, 0.05)
        if len(self._recent_429) >= 5:
            self._open_until = now + self.cooldown
            return self.cooldown
        if retry_after is not None:
            pause = retry_after
        else:
            pause = min(60.0, 2 ** len(self._recent_429)) * random.uniform(0.5, 1.5)
        self._open_until = now + pause
        return pause

Demander si la page a changé avant de demander la page

La moitié du trafic de crawl IA consacrée à récupérer de nouveau des pages inchangées est un chiffre dans lequel Cloudflare a un intérêt commercial, mais il n'est pas invraisemblable, et le remède précède le problème de vingt-cinq ans. Retenez les validateurs qu'une page envoie, renvoyez-les, et acceptez un 304 comme réponse. Le store ci-dessous est volontairement naïf ; en production, c'est une colonne dans la table des URL.

class ConditionalStore:
    """Remember validators per URL so a re-crawl asks 'has this changed?' first."""

    def __init__(self):
        self._validators: dict[str, dict[str, str]] = {}

    def headers_for(self, url: str) -> dict[str, str]:
        v = self._validators.get(url, {})
        out = {}
        if "etag" in v:
            out["If-None-Match"] = v["etag"]
        if "last-modified" in v:
            out["If-Modified-Since"] = v["last-modified"]
        return out

    def remember(self, url: str, headers) -> None:
        v = {}
        if headers.get("ETag"):
            v["etag"] = headers["ETag"]
        if headers.get("Last-Modified"):
            v["last-modified"] = headers["Last-Modified"]
        if v:
            self._validators[url] = v

Noter chaque décision

La méthode fetch relie les trois et enregistre chaque issue sous forme d'une ligne de JSON : ce qui a été demandé, ce que les règles ont dit, ce que le site a répondu, combien de temps la boucle a attendu et à quel débit elle tournait. Quand Open3DLab a publié ses logs, la ligne la plus accablante était que le crawler « n'a pas réduit ses tentatives de téléchargement face à nos blocages ». Un journal d'audit, c'est ce qui permet d'affirmer le contraire et d'être cru. C'est aussi, et ce n'est pas un hasard, ce que l'EDPB a demandé dans les lignes directrices sur le web scraping dont la consultation s'est close aujourd'hui : des sources fiables, un horodatage par enregistrement, et une validation avant usage.

def fetch(self, url: str) -> tuple[str, int, bytes | None]:
    """Return (outcome, status, body). Outcomes: fetched, unchanged, disallowed, throttled, error."""
    if not self.robots.allowed(url):
        self._record(url=url, outcome="disallowed")
        return "disallowed", 0, None
    budget = self._budget(url)
    waited = budget.acquire()
    req = urllib.request.Request(url, headers={"User-Agent": self.user_agent, **self.store.headers_for(url)})
    try:
        with urllib.request.urlopen(req, timeout=30) as resp:
            body = resp.read()
            self.store.remember(url, resp.headers)
            budget.on_success()
            self._record(url=url, outcome="fetched", status=resp.status, bytes=len(body), waited=round(waited, 2))
            return "fetched", resp.status, body
    except urllib.error.HTTPError as e:
        if e.code == 304:
            budget.on_success()
            self._record(url=url, outcome="unchanged", status=304, waited=round(waited, 2))
            return "unchanged", 304, None
        if e.code == 429:
            pause = budget.on_429(parse_retry_after(e.headers.get("Retry-After")))
            self._record(url=url, outcome="throttled", status=429, retry_after=e.headers.get("Retry-After"), pause=round(pause, 2), rate=round(budget.rate, 3))
            return "throttled", 429, None
        self._record(url=url, outcome="error", status=e.code)
        return "error", e.code, None

À quoi ressemble la trace

Deux passes contre le site local. La passe polie, à une requête par seconde, récupère trois pages produit, se voit refuser un chemin par les règles sans qu'un paquet quitte la machine, puis récupère de nouveau les trois pages et obtient trois 304. L'impatiente démarre à cinq requêtes par seconde contre une limite de deux.

polite pass 1: ['fetched', 'fetched', 'fetched', 'disallowed']
polite pass 2: ['unchanged', 'unchanged', 'unchanged'] (4.0s for 7 fetches)
impatient run: ..T..T..T...............................
               3 x 429 in 40 tries, 33.2s, 1.11 pages/s achieved
rate trajectory: [5.0, 2.76, 0.76, 0.92, 1.12, 1.22, 1.22, 1.22, 1.22, 1.22]

{"url": ".../private/report", "outcome": "disallowed"}
{"url": ".../products/1", "outcome": "unchanged", "status": 304, "waited": 1.0}
{"url": ".../catalog/2", "outcome": "throttled", "status": 429, "retry_after": "2", "pause": 2.0, "rate": 2.5}
{"url": ".../catalog/8", "outcome": "throttled", "status": 429, "retry_after": "2", "pause": 2.0, "rate": 0.76}
{"url": ".../catalog/39", "outcome": "fetched", "status": 200, "bytes": 67, "waited": 0.82}

naive run:     ..T..T..T..T..T..T..T..T..T..T..T..T..T.

Trois 429, chacun honoré pendant les deux secondes demandées par le site, chacun divisant le débit par deux et abaissant le plafond. Après le troisième, 31 fetches consécutifs sans aucun throttling, stabilisés à 1,2 requête par seconde sous une limite de 2. La boucle de retry habituelle, qui attend la fin du Retry-After puis continue au même débit, a tiré 13 429, soit un toutes les trois requêtes sur les mêmes 40 requêtes, et a quand même récupéré moins de pages par seconde : 0,94 contre 1,11. Sur une journée, cela fait des milliers d'entrées dans l'historique de confiance de quelqu'un, chacune d'elles le schéma répété que la bande est faite pour attraper.

Ce que cela change si vous crawlez via Crawlbase

Crawlbase ne lit pas robots.txt à votre place et ne prétendra pas le faire. La politique est la vôtre, et l'historique aussi. Ce que la Crawling API fait, c'est rendre visible le côté du site dans la conversation pour que votre boucle puisse agir dessus. Chaque réponse porte le statut propre de la cible dans original_status et le verdict de Crawlbase dans cb_status. Un site qui répond 403 revient en 705, un site qui répond 429 en 706, et aucun des deux n'est facturé, donc reculer ne coûte que du temps. Avec get_headers=true les headers de réponse du site reviennent aussi, et c'est là que Retry-After, ETag et Last-Modified se trouvent. Le budget et le store de validateurs ci-dessus fonctionnent sans modification avec ces champs à la place de la réponse brute.

Côté Enterprise Crawler, la limite de concurrence (20 par défaut) et le débit de push (30 URL par seconde et par token) sont les bornes supérieures du budget par hôte, pas un substitut. Faites tourner la boucle ci-dessus comme ce qui décide de ce qui entre dans la file, et laissez le crawler être ce qui le récupère.

La position pratique pour l'année à venir

Il existe un contre-argument, et il vient avec des données. Le 20 octobre, un développeur qui vend des scrapers sur Apify a publié la télémétrie de 169 941 exécutions de ses scrapers et constaté que les appels arrivant via MCP, c'est-à-dire depuis des agents IA, réussissaient dans 86,9 % des cas contre 47,9 % pour les humains dans la console, et que 0,6 % d'entre eux déclenchaient son garde-fou anti-abus. « J'avais l'histoire complètement à l'envers », a-t-il écrit. Les agents qui appellent une API sont les clients les mieux élevés du web, parce que l'API leur dit les règles sous une forme qu'ils savent lire. Le crawler Roblox s'est mal comporté sur des sites qui n'avaient pas une telle interface, seulement un fichier texte qu'il a choisi de ne pas parser.

Tout l'argument tient dans ce contraste. Le web ne se ferme pas aux crawlers. Il remplace une porte par un registre, et un registre récompense exactement une chose : être lisible. Signez vos requêtes si vous le pouvez, lisez les préférences que vous soyez d'accord ou non, laissez un 429 fixer votre débit, envoyez des validateurs, et gardez le log. Faites cela, et la bande de confiance est un actif gratuit qui se capitalise. Sautez cette étape, et chaque crawl que vous lancez est une preuve pour la partie adverse, horodatée par quelqu'un d'autre.

Conclusion

Octobre 2026 est le mois où la conduite des crawlers a acquis un dossier. Cloudflare a commencé à noter les Verified bots sur le respect de robots.txt et des 429 reçus, Google a commencé à signer un agent qui saute robots.txt, et un crawler qui ne faisait ni l'un ni l'autre a fini en première page avec ses logs en pièce jointe. La notation est jeune, le vocabulaire est encore un brouillon, et seul un tiers des plus gros sites a écrit la moindre directive IA. Mais la direction est fixée, et l'ingénierie qu'elle demande est du HTTP vieux de vingt ans fait avec soin : lire les règles d'abord, dépenser sur un budget, obéir au 429, valider avant de récupérer, et tout noter. Si vous exploitez un crawler, faites tourner la boucle ci-dessus via Crawlbase et lisez son log avant que quelqu'un d'autre n'ait à le faire.

Foire aux questions (FAQ)

La bande de confiance s'applique-t-elle à un crawler qui n'est pas un Verified bot ?

Non. La notation s'attache à une identité, donc le trafic non signé et non vérifié n'est pas noté ; il est traité par les règles bot du site comme avant. L'effet pratique est le même : un crawler sans identité n'a pas d'historique à gagner, il ne peut donc pas sortir de la classe refusée par défaut.

Peut-on réessayer un 429 immédiatement sans risque ?

Seulement quand la réponse le dit, et elle ne le dit jamais. Un 429 avec Retry-After vous donne un nombre ; honorez-le. Sans lui, la consigne est de reculer de façon exponentielle et d'abaisser votre débit de croisière. Rejouer la même requête à la même concurrence est exactement ce que le score est conçu pour attraper.

Dois-je obéir aux Content Signals et au vocabulaire aipref ?

Les deux sont des préférences, pas des contrôles d'accès, et aucun des deux n'est encore un standard publié. L'endpoint de crawl de Cloudflare applique déjà le niveau use déclaré, et la bande de confiance lit la cohérence avec les « préférences publiées » d'un site, qui s'étendront pour les inclure. Les lire dès maintenant ne coûte rien et démarre l'historique tôt.

En quoi est-ce différent de ce que Google et Bing ont toujours fait ?

Googlebot lit robots.txt et recule sur les erreurs depuis deux décennies, et cette conduite n'a jamais été mesurée par personne d'autre que Google. Ce qui change, c'est qu'un tiers observe désormais le comportement sur des millions de sites, publie le résultat, et laisse les propriétaires de sites agir dessus dans leurs règles edge.

Que facture Crawlbase quand un site me limite en débit ?

Rien. Une cible qui répond 429 revient en cb_status 706, un 403 en 705, et aucun des deux ne compte comme requête réussie, donc reculer et réessayer plus tard ne coûte que du temps.

VP

Viktor Petrov

Architecte data science · Crawlbase

Architecte data science chez Crawlbase. Travaille sur les modèles qui rendent le crawling à grande échelle fiable face aux défenses anti-bot modernes.