Comment calculer son budget d'exploration à partir des journaux serveur ?

Le budget d'exploration est l'une des notions les plus discutées et les moins mesurées du référencement technique. On en parle en général avec des chiffres empruntés à d'autres sites, alors que c'est une grandeur strictement locale : le budget d'exploration d'un site ne se déduit d'aucune moyenne du marché, il se lit dans les journaux du serveur, qui enregistrent chaque passage du robot avec sa date, son adresse, la ressource demandée et le code de réponse. Google lui même rappelle que la plupart des sites n'ont pas à s'en préoccuper (documentation Google Search Central), et c'est exact pour un site de deux cents pages. Au delà de quelques milliers d'adresses, en revanche, la question devient concrète, et la réponse tient dans un fichier que l'hébergeur produit déjà sans qu'on le lui demande.

Ce que le budget d'exploration désigne vraiment

Le terme recouvre en réalité deux mécanismes distincts que Google documente séparément et qu'il est utile de ne pas confondre : la limite que le robot s'impose pour ne pas dégrader le serveur, et l'envie qu'il a de revenir sur un site donné. Le premier dépend de la santé technique de l'hébergement, le second de la valeur perçue des contenus. Les deux se mesurent différemment et se corrigent par des leviers opposés, ce que la lecture des journaux permet précisément de trancher, comme nous l'expliquons plus largement dans nos articles de la rubrique référencement naturel.

La limite liée à la capacité du serveur

Le robot ajuste son rythme au comportement observé du serveur. Des temps de réponse qui s'allongent, des erreurs de type 500 ou des délais d'attente dépassés le font ralentir, parfois pour plusieurs jours, et cette baisse ne se rattrape pas en supprimant simplement la cause : le retour à la normale prend du temps. À l'inverse, un serveur qui répond vite et sans erreur autorise une exploration plus dense, sans que cela soit une garantie. Cette moitié de la question relève entièrement de la performance et de la stabilité, pas du contenu, et se corrige par du travail d'infrastructure.

L'appétit lié à la valeur perçue

L'autre moitié dépend de ce que le robot trouve quand il vient. Un site dont les pages changent, sont consultées depuis les résultats de recherche et reçoivent des liens verra sa fréquence d'exploration monter ; un site dont des milliers de pages n'ont pas bougé depuis quatre ans et n'apportent aucune réponse originale la verra baisser, indépendamment de la qualité du serveur. Les pages de faible valeur, les contenus dupliqués et les adresses générées par des combinaisons de paramètres consomment du volume sans jamais en produire.

Pourquoi la moyenne des autres ne dit rien

Deux sites de dix mille pages hébergés au même endroit peuvent recevoir des volumes d'exploration dans un rapport de un à dix. Comparer son propre chiffre à celui d'un confrère n'apprend donc rien, alors que comparer son chiffre d'aujourd'hui à celui d'il y a trois mois apprend beaucoup. C'est ce qui rend la mesure indispensable : sans historique interne, toute affirmation sur le budget d'exploration d'un site relève de l'intuition, et l'intuition en matière de crawl se trompe très souvent, en particulier sur les sections que l'on croit importantes.

Le seuil à partir duquel la question se pose

Il n'existe pas de seuil officiel, mais un repère pratique se dégage de la pratique : la question devient utile dès que le nombre d'adresses accessibles dépasse largement le nombre de pages que le robot visite en un mois. Un site de trois cents pages entièrement exploré chaque semaine n'a rien à optimiser. Un catalogue de quarante mille références dont le robot ne voit que huit mille adresses par mois a un vrai sujet, et la première chose à faire n'est pas d'augmenter le budget mais de vérifier lesquelles de ces huit mille adresses méritaient d'être vues.

Extraire le volume réel depuis les journaux

Le calcul repose sur une source unique : les journaux d'accès du serveur, qui consignent toutes les requêtes reçues, robots compris. La méthode de lecture et le filtrage des lignes concernées ont été détaillés dans notre article consacré à la manière de lire un fichier de logs Apache pour isoler le crawl de Googlebot, dont ce qui suit constitue la suite directe. Une fois les lignes du robot isolées et vérifiées, le comptage lui même est simple, mais quelques précautions changent complètement le résultat.

Compter des adresses, pas des requêtes

Une page moderne déclenche des dizaines de requêtes, pour ses images, ses feuilles de style et ses scripts. Compter toutes les lignes du journal donne donc un chiffre qui reflète surtout le poids des gabarits. Le volume d'exploration utile se compte en adresses de documents distinctes visitées par jour, donc en filtrant les requêtes de ressources statiques. Il reste pertinent de compter séparément ces ressources, car un site qui consacre les trois quarts de son crawl à des images redimensionnées a un problème identifiable, mais les deux chiffres ne doivent jamais être additionnés.

Distinguer le robot annoncé du robot réel

Une part non négligeable des lignes qui se présentent sous le nom de Googlebot n'en sont pas. N'importe quel programme peut annoncer l'identité qu'il veut dans son en tête, et les aspirateurs de contenu s'en servent abondamment pour passer les protections les plus simples. Un budget calculé sans ce filtrage est surestimé, parfois du double, et conduit à conclure qu'un site est bien exploré alors qu'il ne l'est pas. La vérification officielle passe par une résolution inverse de l'adresse, qui doit renvoyer un nom appartenant aux domaines de Google, suivie d'une résolution directe de ce nom qui doit redonner l'adresse de départ (documentation Google Search Central). Cette double vérification se scripte une fois et se met en cache, le nombre d'adresses distinctes concernées étant faible.

Choisir une fenêtre assez longue

Le crawl est irrégulier par nature : une journée creuse ne signifie rien, une pointe non plus. Une fenêtre de trente jours glissants lisse ces variations et permet de comparer des mois entre eux. Sur cette fenêtre, trois chiffres suffisent pour commencer : le nombre total d'adresses distinctes visitées, le nombre de visites par jour en moyenne et le nombre d'adresses du site jamais visitées sur la période. Ce troisième chiffre est de loin le plus instructif, et c'est celui qu'aucun outil ne donne sans croiser les journaux avec la liste réelle des pages.

Rapporter le volume à la taille du site

Le nombre brut de visites quotidiennes ne se compare à rien. Le rapporter au nombre de pages publiées donne un taux de couverture mensuel, exprimable en pourcentage, qui répond à une question utile : en combien de temps le robot voit il l'intégralité du site ? Un taux de couverture de 300 % par mois signifie que chaque page est vue trois fois en moyenne, ce qui est confortable. Un taux de 20 % signifie qu'une page attend cinq mois entre deux passages, et qu'une modification de contenu mettra ce délai à être prise en compte.

Vérifier que les journaux sont complets

Une erreur de mesure fréquente vient du dispositif lui même. Un site derrière un service de mise en cache en amont voit une partie du trafic servie sans jamais atteindre le serveur d'origine, dont les journaux sont alors incomplets. De même, un journal tourné toutes les vingt quatre heures et conservé sept jours interdit toute fenêtre de trente jours. Avant de tirer une conclusion, il faut donc vérifier la période réellement couverte par les fichiers disponibles et l'existence éventuelle d'une couche intermédiaire, faute de quoi on mesure la configuration de l'hébergement plutôt que le comportement du robot.

Trouver où part le budget

La mesure du volume ne sert qu'à préparer la vraie question, celle de sa répartition. Un budget d'exploration confortable mal réparti vaut moins qu'un budget modeste bien orienté, et c'est là que se situe presque toujours la marge de manœuvre. Le principe est celui que nous avons appliqué à la navigation dans notre retour d'expérience sur la pagination d'un blog : identifier les familles d'adresses qui consomment sans rien rapporter, puis décider pour chacune.

Regrouper les adresses par famille

Analyser dix mille adresses une par une n'a aucun sens. Il faut les regrouper selon leur forme, par segment de chemin ou par présence de paramètres, pour faire apparaître des familles : les articles, les pages de rubrique, les pages de liste numérotées, les résultats de recherche interne, les archives par date, les adresses avec paramètres de tri ou de filtre. Le tableau qui en résulte tient sur une page et se lit en quelques secondes, alors que le fichier brut est illisible. Dans la plupart des cas, deux ou trois familles concentrent la moitié du volume, et la surprise porte rarement sur les articles.

Les réponses qui ne produisent rien

Toute requête qui reçoit un code 404, 410 ou une redirection consomme du budget pour un résultat nul ou différé. Une redirection en chaîne consomme autant de requêtes qu'elle comporte d'étapes. Le comptage des codes de réponse dans les journaux du robot met immédiatement ce gaspillage en évidence, et l'origine des adresses concernées se retrouve en général vite : anciennes adresses laissées dans un plan de site obsolète, liens internes vers des contenus supprimés, adresses issues d'un ancien système que plus personne ne référence mais que le robot continue de tester des années durant.

Les adresses générées par la navigation

Les filtres, tris et pagination créent des combinaisons d'adresses dont le nombre croît très vite, souvent bien au delà du nombre de contenus réels. Sur une boutique, trois filtres combinables produisent des milliers d'adresses pour quelques centaines de produits, et le robot les explore parce qu'il les trouve dans les liens. Ces familles se repèrent dans le journal à leur volume disproportionné rapporté au nombre de pages utiles qu'elles servent. Les traiter passe par la structure des liens et les balises canoniques bien plus que par le fichier robots.txt, dont le blocage empêche l'exploration sans empêcher l'indexation d'une adresse liée ailleurs.

Le contenu jamais vu

Le symétrique du gaspillage est l'oubli. Croiser la liste des adresses réellement présentes dans le plan de site avec la liste des adresses visitées sur trente jours produit la liste des pages que le robot n'a pas vues. Sur un site en bonne santé, cette liste est courte et ne contient que des contenus anciens et peu liés. Quand elle contient des publications récentes, le problème n'est pas le budget mais le maillage : une page qu'aucun lien interne ne pointe ne se découvre que par le plan de site, ce qui est la manière la plus lente d'exister. Le croisement mérite d'être refait après chaque publication importante, car il répond en une minute à la question de savoir si un nouveau contenu a été découvert, question pour laquelle on attend sinon plusieurs jours l'affichage d'un outil tiers.

Décider quoi faire du résultat

Une mesure qui ne débouche sur aucune décision est un exercice. Les journaux donnent trois leviers, dont deux seulement sont réellement actionnables à court terme, et il faut résister à la tentation d'agir sur les trois en même temps, sous peine de ne pas savoir ce qui a produit l'effet observé le mois suivant.

Réduire le gaspillage avant de chercher à augmenter

Supprimer les adresses mortes du plan de site, corriger les liens internes vers des contenus disparus, raccourcir les chaînes de redirection et consolider les familles d'adresses en double libère du volume immédiatement, sans dépendre de la bonne volonté du robot. C'est le seul levier qui produit un effet mesurable en quelques semaines, et il est presque toujours suffisant. Chercher à augmenter le budget avant d'avoir nettoyé revient à agrandir un entrepôt encombré.

Améliorer les temps de réponse servis au robot

Le temps de réponse moyen mesuré sur les lignes du robot est un chiffre différent de celui des outils de mesure de performance, car il porte sur le document HTML seul et sur des pages souvent non mises en cache. Le faire baisser durablement autorise mécaniquement une exploration plus dense. Les gains les plus nets viennent en général de la mise en cache des pages de liste, des requêtes de base de données non indexées et du nombre d'appels externes effectués pendant la génération de la page, jamais de micro optimisations du code applicatif.

Rendre l'important plus accessible

La profondeur de clic reste un signal fort : une page atteignable en deux clics depuis l'accueil est explorée bien plus souvent qu'une page atteignable en six. Réduire la profondeur des contenus qui comptent, par des liens contextuels, des pages de regroupement thématique et un plan de site structurel, redirige le budget vers eux sans rien retirer au reste. C'est un travail éditorial autant que technique, et il produit ses effets sur plusieurs mois plutôt que sur plusieurs semaines.

Refaire la mesure et la conserver

La valeur de tout ce travail vient de sa répétition. Un relevé mensuel des cinq indicateurs du tableau, conservé dans un simple tableur, transforme des impressions en série chronologique et permet d'attribuer une variation à une cause. C'est aussi ce qui permet de détecter les incidents silencieux : une chute de trente pour cent du volume d'exploration précède souvent de plusieurs semaines une baisse de visibilité, et c'est l'un des rares indicateurs disponibles avant que le trafic ne bouge. Le relevé gagne enfin à être conservé au delà de la mission en cours : les journaux, eux, sont effacés au bout de quelques semaines par la rotation de l'hébergeur, et une série d'indicateurs mensuels tenue depuis deux ans est une information qu'aucun outil ne pourra reconstituer après coup.

Se méfier des conclusions tirées d'un seul mois

Le volume d'exploration varie pour des raisons qui n'ont rien à voir avec le site : une mise à jour d'algorithme, une réorganisation interne des priorités du moteur, une période de forte activité ailleurs. Une variation de vingt pour cent d'un mois sur l'autre entre donc dans le bruit normal et ne justifie aucune action. Ce qui mérite attention, ce sont les tendances tenues sur trois relevés consécutifs, et les ruptures nettes qui coïncident avec une intervention connue sur le site. Noter dans le même tableur les dates des mises en ligne importantes, des changements d'hébergement et des refontes permet de relire l'historique bien plus tard sans avoir à reconstituer de mémoire ce qui s'est passé.