Budget de crawl

Les deux moitiés : capacité et demande

La capacité est un plafond que Google s'impose. Il observe la vitesse de réponse de votre serveur et sa fréquence d'erreurs, puis lève le pied dès que le site ralentit ; l'objectif est de vous explorer sans vous faire tomber. La demande est l'autre moitié : à quel point Google veut vos URL, selon leur popularité et l'ancienneté de sa copie. Un serveur rapide sans rien qui mérite d'être récupéré à nouveau reste peu exploré, parce que la capacité n'a jamais été la contrainte.

• Augmente la capacité — une réponse rapide et sans erreur, de façon constante. Le rythme d'exploration suit la santé du serveur : le travail sur les Core Web Vitals et un pré-rendu peu coûteux se paient deux fois.
• Réduit la capacité — délais dépassés, erreurs 5xx et réponses lentes sous charge. Un crawler qui rencontre des erreurs ralentit et reste prudent un moment.
• Augmente la demande — des pages qui gagnent du trafic et des liens, et du contenu qui change vraiment. Les sitemaps et les liens internes aident Google à trouver des URL, mais être trouvé n'est pas être désiré.
• Gaspille les deux — les espaces d'URL infinis comme les filtres à facettes, les identifiants de session et les calendriers sans fin, plus les soft 404, les chaînes de redirections et les quasi-doublons qui auraient dû porter une balise canonique.

Quand c'est un vrai problème, et quand c'est une distraction

La documentation de Google est inhabituellement franche sur les personnes concernées. Son guide du budget de crawl pour les grands sites nomme trois publics : les sites de plus d'un million d'URL uniques dont le contenu change environ chaque semaine, les sites de plus de dix mille URL uniques dont le contenu change quotidiennement, et les sites où la Search Console classe une part importante des URL en *Détectée, actuellement non indexée*. Si vous n'entrez dans aucun de ces cas, Google dit qu'il suffit de tenir le sitemap à jour et de surveiller le rapport d'indexation des pages.

Le troisième public est le plus utile, parce qu'il décrit un symptôme et non une taille. Il faut aussi séparer exploration et indexation : Google est explicite, toute page explorée ne sera pas indexée. Une URL bloquée en *Explorée, actuellement non indexée* n'a pas manqué de budget de crawl — elle a été récupérée, évaluée puis écartée, ce qui relève du contenu ou du doublon, pas de la bande passante. Cette confusion est le mauvais usage le plus courant du terme, et elle pousse à trafiquer le robots.txt quand il faudrait fusionner des pages trop minces.

À quoi ressemble vraiment le trafic d'exploration sur un site de longue traîne

Nous pouvons chiffrer cela à partir de nos propres journaux, et le résultat nous a surpris. Notre site marketing pré-rend environ trois mille pages en huit langues, exactement la zone où l'on commence à s'inquiéter. Sur un échantillon de trois heures de requêtes vers l'origine, nous avons compté 1 438 récupérations réparties sur 558 URL distinctes : environ 2,6 par URL, et pour la plupart c'était la seule visite de la journée.

Le second constat a pesé davantage. Environ trois quarts de ce trafic n'était pas un moteur de recherche, mais des scrapers de datacenter aux user agents falsifiés ou vides. Les crawlers d'IA identifiés, nous les laissons passer volontairement, car être lu est tout l'objet de l'optimisation pour moteurs génératifs. Deux conséquences pratiques : ce qui ressemble à une pression d'exploration n'est presque jamais le crawler que vous visez, et une durée de cache CDN courte apporte très peu à un corpus de longue traîne, chaque URL étant demandée trop rarement pour rester chaude au passage suivant. Pour surveiller la moitié « moteur de recherche » sur votre propre site, un moniteur auto-hébergé comme CrawlSEO la lit directement dans la Search Console.