Le budget de crawl expliqué simplement

Le budget de crawl désigne le nombre de pages qu'un moteur explore sur votre site dans un temps donné. Il résulte de deux facteurs : ce que votre serveur supporte sans ralentir, et l'intérêt que le moteur porte à votre site. En dessous de quelques milliers d'adresses, ce n'est pas un sujet : Google explore tout ce qui l'intéresse. Le problème apparaît sur les gros catalogues, les sites à facettes et les sites qui engendrent des adresses sans le savoir.

De quoi il est fait

Deux composantes, que Google documente.

La limite de vitesse d'exploration. Le moteur ne veut pas dégrader votre site. Il augmente sa cadence tant que le serveur répond vite, et la réduit dès que les temps de réponse montent ou que des erreurs apparaissent. Un serveur lent réduit donc mécaniquement l'exploration.

Le besoin d'exploration. Le moteur explore davantage les sites qu'il juge importants et les pages qui changent. Un site sans mise à jour depuis deux ans est exploré au ralenti, quelle que soit la puissance du serveur.

Les deux se multiplient. Un serveur rapide sur un site sans intérêt n'obtient pas plus d'exploration, et un site intéressant sur un serveur lent non plus.

Qui est concerné, réellement

Pas concerné : un site de moins de quelques milliers d'adresses, sans paramètres d'URL, avec un sitemap correct. Google explorera tout ce qu'il veut explorer. Si des pages ne sont pas indexées, la cause est ailleurs : qualité, duplication, ou absence de liens internes.

Concerné : un catalogue de dizaines de milliers de références. Un site à facettes qui engendre des combinaisons de filtres. Un site avec une recherche interne indexable. Un site multilingue avec plusieurs versions par page. Un site qui produit des adresses de session ou de suivi.

Le point commun de ces cas : le nombre d'adresses accessibles dépasse largement le nombre de pages utiles, souvent d'un facteur dix ou cent.

Comment savoir en cinq minutes

Ouvrez les statistiques d'exploration de la Search Console. Elles donnent le nombre de demandes par jour, le temps de réponse moyen, et la répartition par type de fichier et par code de réponse.

Trois lectures.

Comparez le nombre de pages explorées par jour au nombre de pages utiles. Si votre site a 500 pages et que Google en explore 300 par jour, tout va bien. Si votre site a 50 000 pages et que Google en explore 800 par jour, il faut soixante jours pour un tour complet, et les mises à jour mettront des semaines à être vues.

Regardez le temps de réponse moyen. Au-dessus de quelques centaines de millisecondes, il bride l'exploration.

Regardez le rapport d'indexation, motif par motif. « Découverte, actuellement non indexée » sur un grand nombre d'adresses est le symptôme classique : le moteur connaît ces pages et ne juge pas utile d'aller les voir.

Ce qui gaspille l'exploration

Par ordre de fréquence sur les sites que nous auditons.

Les combinaisons de filtres. Trois filtres à cinq valeurs produisent des centaines de combinaisons, dont l'immense majorité n'a aucune valeur. C'est de loin la première cause.

Les paramètres de suivi. Les adresses avec des paramètres de campagne créent autant de variantes de la même page.

La recherche interne indexable. Chaque requête de recherche devient une adresse. Une seule page de recherche liée depuis un site externe suffit à en engendrer des milliers.

Les redirections en chaîne. Chaque saut consomme une demande d'exploration.

Les pages d'archive. Catégories, étiquettes, auteurs, dates, et leur pagination. Sur un WordPress de blog, elles représentent souvent plus d'adresses que les articles eux-mêmes.

Les versions imprimables et les variantes d'affichage.

Comment le récupérer

Par ordre d'efficacité.

Bloquer dans le `robots.txt` ce qui n'a pas à être exploré. Les recherches internes, les paramètres de tri, les combinaisons de filtres au-delà d'un niveau. Attention : bloquer l'exploration n'est pas la même chose qu'empêcher l'indexation. Une page bloquée peut rester indexée si elle reçoit des liens, mais le moteur ne verra jamais son contenu.

Utiliser `noindex` pour ce qui doit être vu mais pas indexé. Le moteur doit pouvoir explorer la page pour lire la balise, ce qui consomme du budget. C'est le bon choix quand la page a des liens internes utiles.

Réparer les redirections en chaîne. Écrire directement vers la destination finale.

Servir un sitemap juste. Uniquement les adresses canoniques, en 200, indexables. Un sitemap qui contient des redirections et des 404 fait perdre du temps au moteur et de la confiance à votre déclaration.

Améliorer le temps de réponse du serveur. Cela augmente directement la cadence d'exploration.

Supprimer réellement ce qui ne sert plus. Un catalogue de vingt mille produits dont douze mille n'ont jamais été vendus et ne reçoivent aucune visite n'a pas besoin d'exister en ligne. La suppression est plus efficace que toute optimisation.

Ce qui ne marche pas

Demander une exploration plus rapide. L'outil d'inspection d'URL permet de demander l'indexation d'une page à la fois. Ce n'est pas un levier à l'échelle d'un site.

Multiplier les sitemaps. Découper un sitemap en dix fichiers ne change pas la cadence. Le découpage sert au diagnostic, en permettant de suivre l'indexation par section.

Ajouter des liens internes partout. Un maillage cohérent aide à faire découvrir les pages importantes, un maillage qui lie tout à tout ne hiérarchise plus rien. Le sujet est traité dans notre article sur le maillage interne.

Le cas des sites de contenu

Sur un site éditorial de quelques centaines de pages, la question du budget de crawl est presque toujours un faux problème. Si vos articles ne sont pas indexés, ce n'est pas parce que Google manque de temps, c'est parce qu'il n'a pas jugé utile de les indexer.

Le diagnostic est différent, et le remède aussi : moins de pages, mieux écrites, avec un maillage qui désigne les plus importantes. C'est moins satisfaisant qu'un réglage technique, et c'est le vrai sujet.

Questions fréquentes

À partir de combien de pages faut-il s'en préoccuper ?

En pratique, à partir de plusieurs milliers d'adresses accessibles, ou dès qu'il existe un mécanisme qui engendre des combinaisons (filtres, recherche, paramètres). Le nombre de pages utiles compte moins que le nombre d'adresses atteignables, qui peut être cent fois supérieur sans que personne s'en rende compte.

Bloquer une page dans le robots.txt la retire-t-elle de l'index ?

Non, et c'est un piège fréquent. Une page bloquée à l'exploration peut rester indexée si d'autres sites la lient, avec un affichage dégradé faute de contenu lisible. Pour retirer une page de l'index, il faut un noindex accessible, donc une page explorable. Bloquer et vouloir désindexer sont contradictoires.

Un site rapide est-il mieux exploré ?

Oui, directement : la limite de vitesse d'exploration s'ajuste sur les temps de réponse du serveur. C'est un des rares cas où l'amélioration de la performance technique a un effet mécanique et immédiat sur le référencement, indépendamment du contenu.

Les crawlers d'IA consomment-ils mon budget de crawl ?

Ils consomment des ressources serveur, ce qui peut indirectement affecter les temps de réponse et donc l'exploration par Google. Sur un site à gros catalogue, la charge est parfois significative et mérite d'être mesurée dans les journaux. La décision de les autoriser ou non est traitée dans notre article sur les crawlers d'IA.

En résumé

Vérifiez vos statistiques d'exploration avant de traiter un problème que vous n'avez peut-être pas. Si le rapport entre adresses atteignables et pages utiles dépasse largement un pour un, vous avez un vrai sujet, et il commence par un inventaire de ce qui engendre des adresses. Nous traitons ce point dans le cadre de notre page audit SEO technique.