Analyse de logs serveur : comment détecter le crawl budget gaspillé et les pages orphelines ?

Search Console montre ce que Google veut bien afficher. Les logs serveur montrent ce que Googlebot a réellement fait, requête par requête. La différence n’est pas cosmétique : elle permet de détecter deux problèmes que les outils habituels ratent, le gaspillage de budget de crawl et les pages orphelines qu’aucun crawl classique ne peut révéler seul.

Ce que les logs montrent que Search Console ne montre pas

Le rapport Stats d’exploration de Search Console agrège des tendances. Les logs serveur, eux, enregistrent chaque requête individuelle de Googlebot : l’URL exacte demandée, le code retour, le temps de réponse, l’horodatage. C’est cette granularité qui permet de voir des comportements invisibles dans un dashboard agrégé, comme un bot qui explore en boucle des pages à faible valeur (des combinaisons de filtres, par exemple) pendant que vos pages stratégiques attendent leur tour, ou qui ralentit nettement son rythme de passage après une série d’erreurs serveur ou un temps de réponse dégradé. Googlebot est rationnel : un serveur qui répond lentement ou en erreur reçoit moins de visites, pas plus, ce qui aggrave mécaniquement le problème plutôt que de le signaler.

Extraire et filtrer les logs : la bonne méthode

Isoler les hits Googlebot, avec la vérification qui manque souvent

La première étape consiste à isoler les lignes correspondant à Googlebot dans le fichier d’accès (grep "Googlebot" /var/log/nginx/access.log ou équivalent Apache). C’est un bon point de départ, insuffisant en soi : filtrer sur le seul user-agent revient à faire confiance à une chaîne de texte que n’importe quel scraper peut usurper. La vérification fiable croise l’adresse IP de la requête avec une résolution DNS inversée suivie d’une confirmation directe, une procédure que Google documente elle-même, qui confirme que l’IP appartient bien à l’infrastructure Google avant de considérer la ligne comme un vrai passage de Googlebot.

Lire les champs utiles

Une fois les lignes isolées, les champs qui comptent sont l’URI complète (avec sa chaîne de paramètres), le code de statut HTTP, le temps de réponse et l’agent utilisateur précis (Googlebot Desktop vs Smartphone). Sur un format nginx standard, awk '{print $7}' access.log | sort | uniq -c donne rapidement les URLs les plus visitées ; la même logique appliquée au code retour (awk '{print $9}') fait apparaître la proportion de 5xx, 4xx et redirections que Googlebot rencontre réellement, plutôt que celle que vous supposez.

Le gaspillage de budget de crawl, tel qu’il apparaît dans les logs

Trois motifs reviennent systématiquement dans les logs d’un site technique mal maîtrisé : les combinaisons de paramètres et de filtres (un cas documenté montre 55 % des requêtes Googlebot absorbées par des variantes de facettes avant correction, ramenées sous 20 % après), les chaînes de redirection que le bot continue de suivre au lieu d’atteindre directement la page finale, et les ressources statiques lourdes qui consomment du temps de crawl sans valeur d’indexation. Notre guide sur l’optimisation du budget de crawl détaille la formule de calcul du taux de gaspillage à partir de ces mêmes données de logs, une fois ces motifs identifiés.

Détecter les vraies pages orphelines : croiser logs et crawl

C’est le point que les guides sur les pages orphelines et les guides d’analyse de logs traitent chacun à moitié. Les premiers admettent que les logs sont « la méthode la plus fiable » pour repérer une page orpheline active, sans jamais détailler comment. Les seconds fournissent les commandes pour filtrer les logs, mais reconnaissent eux-mêmes l’absence de toute validation croisée avec la structure réelle du maillage interne. Aucun des deux ne va au bout de la méthode.

La méthode complète tient en une comparaison d’ensembles, pas en une simple lecture de logs. D’un côté, la liste des URLs que Googlebot a réellement visitées sur la période (extraite des logs, filtrée sur les vrais hits Googlebot, code 200). De l’autre, la liste des URLs qu’un crawl classique découvre en partant de la page d’accueil et en suivant les liens internes (Screaming Frog en mode spider, par exemple). Une URL présente dans la première liste et absente de la seconde est une orpheline confirmée par deux sources indépendantes : Google la connaît et la visite, mais rien sur votre propre site ne mène jusqu’à elle, un backlink externe ancien, une entrée de sitemap XML obsolète ou une mémoire persistante de l’index suffisant à expliquer la visite.

Prioriser les corrections

Toutes les pages orphelines ne méritent pas le même traitement. Une proportion inférieure à 5 % du total des pages actives est généralement considérée comme un niveau sain ; au-delà, l’effet devient mesurable, avec des ordres de grandeur documentés de 35 % de trafic organique perdu et 40 % d’exploration en moins sur les pages stratégiques quand le phénomène s’installe. Un cas de migration mal gérée a montré 9 % de fiches produits orphelines du jour au lendemain, un rappel que le risque grimpe fortement à chaque changement de structure ou de CMS. La correction elle-même suit une hiérarchie simple : ajouter un lien interne réel depuis une page pertinente d’abord (l’action la plus durable), mettre à jour le sitemap ensuite, et ne recourir à une redirection que si la page n’a plus lieu d’exister. Viser une profondeur de clic de trois maximum depuis la page d’accueil pour toute page qui doit rester active limite la récidive.

Ce qu’il faut retenir

Les logs serveur ne remplacent pas un crawl classique, ils le complètent sur exactement ce qu’il ne peut pas voir : ce que Google visite réellement en dehors de votre propre maillage interne. Croiser les deux sources, plutôt que se fier à l’une ou l’autre isolément, est ce qui transforme une intuition sur le gaspillage de crawl en diagnostic vérifiable.