L’expression circule beaucoup, et elle inquiète surtout des gens qui n’ont aucune raison de s’en préoccuper. On lit qu’il faut « optimiser son budget de crawl » comme s’il s’agissait d’un réglage universel, au même titre que la vitesse de chargement ou les balises de titre. C’est faux : pour l’immense majorité des sites, le sujet est parfaitement théorique. Pour une minorité, en revanche, il explique des problèmes d’indexation que rien d’autre n’expliquerait. Encore faut-il savoir de quel côté on se trouve.
Ce qu’est le budget de crawl
Un moteur de recherche ne dispose pas de ressources infinies. Explorer une page coûte de la bande passante, du temps machine et de la sollicitation serveur. Multiplié par les milliards d’adresses existantes, cela impose un arbitrage permanent : combien de pages explorer sur chaque site, et à quelle fréquence.
Ce que l’on appelle budget de crawl résulte en réalité de deux mécanismes distincts, souvent confondus.
Le premier est une limite de capacité. Le moteur observe comment votre serveur réagit : s’il répond vite et sans erreur, l’exploration s’intensifie ; s’il ralentit ou renvoie des erreurs, le robot lève le pied pour ne pas dégrader votre site. C’est un mécanisme de politesse technique, et il est directement lié à la santé de votre hébergement.
Le second est un niveau d’intérêt. Le moteur explore d’autant plus volontiers qu’il juge le contenu utile et susceptible d’avoir changé. Un site d’actualité mis à jour plusieurs fois par jour sera visité constamment ; un site vitrine figé depuis trois ans le sera très épisodiquement. Cette dimension dépend de la popularité du site, de la fraîcheur perçue de ses contenus, et de la qualité générale de ce qui a déjà été exploré.
Le budget effectif est le produit de ces deux facteurs. Un serveur rapide mais un site sans intérêt sera peu exploré ; un site très demandé mais lent le sera moins qu’il ne le mériterait. C’est le premier point que clarifie Julien Jimenez quand on l’interroge sur le sujet : le budget de crawl ne s’achète pas et ne se force pas, il se mérite techniquement et éditorialement.
Qui est réellement concerné
C’est la question à trancher avant toute autre, et elle épargne beaucoup de travail inutile.
Un site de trente, cent ou même mille pages n’a strictement aucun problème de budget de crawl. Les moteurs exploreront l’intégralité de ses adresses sans difficulté, et si certaines pages ne sont pas indexées, la cause est ailleurs qualité du contenu, duplication, absence de liens internes, directive de blocage. Chercher à optimiser l’exploration dans ce cas revient à traiter un symptôme qui n’existe pas.
Trois profils sont réellement concernés. Les sites volumineux, à partir de plusieurs dizaines de milliers d’URL : grands catalogues, places de marché, sites d’annonces, médias avec vingt ans d’archives. Les sites générant des adresses automatiquement, quel que soit leur nombre de pages réelles : un catalogue de deux cents produits combiné à cinq filtres croisés produit des dizaines de milliers d’URL. Et les sites lents ou instables, dont le serveur bride mécaniquement l’exploration quelle que soit leur taille.
Ce tri préalable entre sites concernés et non concernés évite bien des chantiers inutiles. Si vous ne relevez d’aucun des trois profils, arrêtez ici : votre temps sera bien mieux investi dans le contenu ou le maillage interne.
Les gouffres classiques
Chez les sites concernés, l’exploration se perd presque toujours aux mêmes endroits.
Les facettes et les paramètres. C’est de très loin le premier poste. Un listing filtrable par couleur, taille, prix, marque et disponibilité, avec en plus trois ordres de tri, génère un nombre d’adresses qui croît de façon combinatoire. Le robot explore consciencieusement des variantes qui affichent toutes le même contenu réorganisé.
Les calendriers. Un module d’agenda avec navigation par mois peut produire une chaîne infinie de pages vides, chacune liant vers la suivante. Les robots suivent, indéfiniment.
Les résultats de recherche interne. Chaque requête tapée par un visiteur, si elle produit une URL indexable et qu’un lien pointe vers elle, devient une page à explorer. Ces pages n’ont aucune valeur pour un moteur.
La pagination sans fin. Des listings paginés sur quatre cents niveaux, dont personne ne consulte jamais la page 87.
Les redirections en chaîne. Chaque saut consomme une requête. Un site ayant vécu trois refontes accumule des chaînes de quatre ou cinq redirections sur des milliers d’adresses.
Les erreurs en masse. Des dizaines de milliers de pages renvoyant une erreur serveur ou introuvable consomment du budget sans rien produire.
Les leviers d’optimisation
Quatre actions produisent l’essentiel de l’effet, dans cet ordre de rentabilité.
Empêcher l’exploration de ce qui n’a pas à l’être. Le fichier robots.txt est l’outil principal : bloquez les chemins de recherche interne, les combinaisons de filtres sans valeur, les calendriers, les paramètres de tri. Attention à la nuance essentielle : bloquer l’exploration ne désindexe pas. Si des pages sont déjà indexées et doivent disparaître, laissez-les explorables avec une directive noindex le temps qu’elles sortent, puis bloquez.
Réduire les chaînes de redirection. Faites pointer chaque redirection directement vers sa destination finale. Sur un gros site, ce seul chantier libère souvent une part significative du budget.
Accélérer le serveur. Puisque la capacité d’exploration dépend du temps de réponse, tout gain sur ce terrain se traduit mécaniquement par un nombre de pages explorées supérieur. C’est le levier le plus indirect et l’un des plus efficaces.
Tenir des sitemaps propres. Ils ne doivent contenir que des URL en code 200, indexables, canoniques et à jour. Un sitemap rempli d’adresses redirigées ou mortes perd sa crédibilité et cesse d’orienter utilement l’exploration. Découpez-les par section pour identifier plus finement d’où viennent les problèmes.
Ajoutez-y un cinquième levier, souvent oublié : le maillage interne. Les pages profondément enfouies, accessibles en six clics, sont explorées rarement. Remonter les pages stratégiques dans l’architecture agit directement sur la fréquence de visite.
Ce qui n’est pas un levier
Trois croyances persistent et font perdre du temps.
Publier artificiellement plus souvent. Ajouter des contenus faibles pour « stimuler » l’exploration produit l’effet inverse : le moteur, constatant que ce qu’il explore n’a pas de valeur, réduit son intérêt pour l’ensemble du site.
Forcer l’indexation manuellement. La demande d’indexation dans les outils pour webmasters sert à traiter quelques URL ponctuelles, pas à compenser un problème structurel. Soumettre mille adresses à la main ne change rien au fond.
Les indications de priorité dans le sitemap. La balise priority est ignorée depuis des années. La date de dernière modification, en revanche, est prise en compte à condition d’être exacte, ce qui exclut de la mettre à jour automatiquement sur toutes les pages chaque nuit.
Mesurer avant et après
Sans mesure initiale, vous ne saurez pas si votre travail a servi.
Le rapport de statistiques d’exploration des outils pour webmasters constitue le point de départ : nombre de requêtes par jour, temps de réponse moyen, répartition par type de fichier et par code de réponse. Relevez ces chiffres avant d’intervenir.
Les journaux du serveur donnent la vision réelle et complète : quelles URL exactes ont été demandées, par quel robot, avec quel code de retour. C’est la seule source qui montre le budget effectivement dépensé, et sur quoi.
Suivez enfin deux indicateurs dans la durée : le nombre de pages explorées par jour, et surtout le ratio entre pages utiles et pages parasites dans ce total. C’est ce ratio qui doit progresser, pas le volume brut.
Comptez quatre à huit semaines avant d’observer un effet net. L’exploration s’ajuste progressivement.
La liste de vérification
Sept points à passer en revue, dans l’ordre.
Le site dépasse-t-il quelques dizaines de milliers d’URL, ou en génère-t-il automatiquement ? Sinon, refermez ce dossier. Le temps de réponse moyen du serveur est-il inférieur à 500 ms ? Les paramètres de filtre et de tri sont-ils neutralisés ? La recherche interne est-elle bloquée à l’exploration ? Les chaînes de redirection ont-elles été aplaties ? Les sitemaps ne contiennent-ils que des URL valides et canoniques ? Les pages stratégiques sont-elles atteignables en trois clics maximum depuis l’accueil ?
Sept réponses affirmatives, et le sujet est traité. C’est un chantier d’entretien, pas une optimisation permanente.
