Analyse de logs SEO : lisez les logs serveur et réduisez le gaspillage de crawl

Quiz rapide

Le SEO est-il fait pour vous, et comment commencer ?

Question 1 sur 425%

Les gens cherchent-ils sur Google ce que vous vendez ?

Oui, je penseNon, c'est nouveau ou très spécialiséJe ne sais pas

Ce qu'un log serveur enregistre, et pourquoi il surpasse vos autres données

Chaque fois qu'un élément est demandé à votre serveur, celui-ci écrit une ligne dans son journal d'accès. La plupart des serveurs utilisent un format proche du format Apache « combined ». Une requête de Googlebot ressemble à ceci :

66.249.66.1 - - [13/Nov/2026:08:14:22 +0100] "GET /products/red-running-shoes HTTP/1.1" 200 18342 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Lisez-la de gauche à droite : l'adresse IP, l'horodatage, la méthode HTTP et l'URL, le code de statut (200 ici), le nombre d'octets envoyés, le referrer et l'user agent. Chaque requête y figure, y compris celles qui n'apparaissent jamais comme une page vue dans votre outil d'analyse : images, fichiers CSS, redirections et erreurs 404.

Vos autres sources de données n'en voient chacune qu'une partie. Le rapport Statistiques d'exploration de la Search Console est agrégé et ne couvre que les robots de Google. Les outils d'analyse n'enregistrent que les visiteurs dont le navigateur exécute votre JavaScript. Un crawler de site comme Screaming Frog montre ce qu'il peut atteindre en suivant vos liens, ce qui n'est pas la même chose que ce que Google a choisi de demander. Seul le log serveur enregistre ce qui s'est réellement passé.

Pourquoi l'analyse des logs compte : le budget de crawl en termes simples

Le budget de crawl est l'ensemble des URL que Google peut et veut explorer sur votre site. Google le décrit avec deux facteurs. Le premier est la limite de capacité d'exploration : le nombre de connexions que ses robots peuvent maintenir ouvertes vers votre serveur sans le surcharger. Cette limite monte quand votre site reste en bonne santé et baisse quand les réponses ralentissent ou renvoient des erreurs 5xx ou 429. Le second est la demande d'exploration, qui dépend de la taille de votre site, de la fréquence de changement de son contenu, de sa qualité et de la popularité de ses pages.

Google présente le sujet comme un guide avancé pour les grands sites. Ses seuils indicatifs sont les sites de 1 million de pages uniques ou plus dont le contenu change environ une fois par semaine, et les sites de 10000 pages uniques ou plus dont le contenu change chaque jour. Les sites qui comptent beaucoup d'URL au statut « Détectée, actuellement non indexée » entrent aussi dans ce cadre. Les petits sites peuvent en général s'appuyer sur un sitemap à jour et sur des contrôles réguliers du rapport Indexation des pages. Cela ne rend pas les logs inutiles pour autant. Quand l'exploration pose problème, le log est le moyen le plus rapide de voir exactement où.

Si votre site se situe dans cette fourchette, la question n'est plus de savoir s'il faut lire les logs, mais à quelle fréquence. Un audit ponctuel montre le gaspillage d'aujourd'hui. Un export mensuel montre si vos corrections ont changé ce que Googlebot consacre son temps à explorer. Pour le vocabulaire de base, l'entrée du glossaire sur le budget de crawl couvre les fondamentaux, et le guide sur le statut Détectée, actuellement non indexée explique le statut qui déclenche généralement ce type d'examen.

La méthode, pas à pas

La démarche ci-dessous fonctionne avec n'importe quel serveur et n'importe quel outil. Les sections suivantes expliquent chaque étape en détail et donnent les commandes à lancer sur un fichier de log brut dès aujourd'hui.

Récupérer les logs depuis la bonne couche

Demandez à votre développeur ou à votre hébergeur les logs d'accès bruts du serveur web (Apache, Nginx ou IIS). Vérifiez trois points avant de commencer : le format du log, le fuseau horaire et la durée de conservation. Selon votre configuration, les anciens logs peuvent être supprimés après quelques jours ou quelques semaines, donc demandez l'export maintenant plutôt que plus tard.

La couche compte plus qu'on ne le pense. Si un CDN répond à une requête depuis son cache, votre serveur d'origine ne la voit jamais. Googlebot peut explorer une URL qui n'apparaît jamais dans le log d'origine, si bien qu'un export limité à l'origine sous-estime l'activité sur les contenus mis en cache. Exportez aussi les logs du CDN et comparez les deux sources sur quelques URL avant de faire confiance à l'un ou l'autre total.

Filtrer et compter Googlebot avec quelques commandes

Sur un log au format combined, le code de statut est le 9e champ et le chemin de l'URL le 7e. Ces deux colonnes répondent à la plupart des premières questions. Cette commande compte les requêtes Googlebot par code de statut :

grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Celle-ci liste les 20 chemins les plus demandés par Googlebot, sans la chaîne de requête, pour que les variantes de filtres se regroupent :

grep "Googlebot" access.log | awk '{print $7}' | cut -d '?' -f1 | sort | uniq -c | sort -rn | head -20

La première commande lit le texte du user agent, que n'importe qui peut falsifier. Considérez sa sortie comme une liste de candidats jusqu'à la section suivante. Par ailleurs, si votre log utilise un format personnalisé, les numéros de champs changent : vérifiez une ligne à l'œil avant de faire confiance aux colonnes.

Vérifier Googlebot comme Google le décrit

La méthode officielle de Google pour confirmer qu'un visiteur est Googlebot passe par le DNS. Effectuez une recherche DNS inverse sur l'adresse IP de votre log, vérifiez que le nom d'hôte se termine par googlebot.com, google.com ou googleusercontent.com, puis effectuez une recherche directe sur ce nom d'hôte et vérifiez qu'elle renvoie l'IP d'origine. La documentation de Google utilise cet exemple, où 66.249.66.1 se résout en crawl-66-249-66-1.googlebot.com :

host 66.249.66.1

La vérification directe est la seconde commande, et elle doit renvoyer la même IP :

host crawl-66-249-66-1.googlebot.com

Si vous traitez des millions de lignes, les recherches DNS deviennent lentes. Google publie aussi des fichiers JSON listant les plages d'IP de ses robots, dont common-crawlers.json pour Googlebot. Comparer à ces plages est plus rapide, et le guide officiel de vérification décrit les deux méthodes dans le guide de Google sur la vérification de Googlebot.

Regrouper, mesurer et lire les résultats

Les comptages bruts par URL sont difficiles à exploiter. Regroupez d'abord les URL par gabarit, car une correction s'applique en général à un gabarit et non à une page isolée. Mesurez ensuite quatre choses pour chaque groupe. Le nombre de hits Googlebot reçus par rapport à son importance pour votre activité. La répartition des codes de statut. La rapidité avec laquelle les nouvelles pages reçoivent leur premier hit après publication. Et si les hits se concentrent sur les pages que vous voulez voir bien classées.

Lisez les résultats comme un schéma, et non comme un chiffre isolé. Si la plupart des hits Googlebot tombent sur des URL de filtres et seulement quelques-uns sur les pages produits, le budget de crawl fuit, et le problème vient probablement du maillage interne ou de la gestion des paramètres, pas des pages produits. La section suivante liste les signaux à rechercher.

Les sept signaux cachés dans les logs

Une fois les lignes Googlebot vérifiées et regroupées, sept signaux expliquent la plupart des problèmes d'exploration. Le tableau indique le motif à repérer et la correction habituelle. Chaque correction est une modification du site, à confirmer dans l'export suivant.

Signal	Ce que montrent les logs	Que faire
Gaspillage d'exploration	Des hits Googlebot sur les filtres, les ordres de tri, la recherche interne et les URL de session	Consolider avec des canonical, supprimer les liens internes vers ces URL, et bloquer dans le robots.txt les variantes inutiles qui ne peuvent pas être consolidées
Redirections	Des hits sur des réponses 301 ou 302, et des chaînes de deux redirections ou plus	Pointer directement vers l'URL finale. Le guide 301 ou 302 aide à choisir le bon type de redirection
Erreurs	Des 404 ou 410 répétés, et des pics de réponses 5xx	Restaurer ou rediriger les pages qui comptent encore, et corriger les erreurs serveur, car les réponses 5xx réduisent l'exploration de Google
Explorations manquantes	Des URL importantes sans aucun hit Googlebot pendant la période	Vérifier les liens internes, les entrées du sitemap et les règles du robots.txt qui pourraient tenir les robots à distance
Doublons	Le même contenu atteint sous plusieurs URL, avec des slashs finaux, des majuscules ou des paramètres	Choisir une URL canonique et la lier partout
Délai avant la première exploration	Le temps entre la publication d'une nouvelle page et son premier hit Googlebot	Lier les nouvelles pages depuis des pages déjà explorées souvent, et garder un sitemap propre
Temps de réponse	Des réponses lentes sur les gabarits que Googlebot visite le plus	Accélérer ces gabarits en premier, car Google indique que les réponses lentes le poussent à explorer moins

La ligne « explorations manquantes » est celle que l'on oublie, et elle coûte souvent le plus cher. Une page absente du log peut ne rien rapporter en classement, même si son contenu est excellent. Si une URL figure dans votre sitemap sans jamais apparaître dans les logs, la page n'est probablement accessible que par un chemin que les robots ne suivent pas. Le guide sur le statut Explorée, actuellement non indexée couvre l'autre situation, celle où Googlebot passe bien mais n'indexe toujours pas.

Trois façons de mener l'analyse, comparées

Vous pouvez analyser les logs avec des scripts, avec une application de bureau ou avec une plateforme. Chaque option convient à un volume et à une équipe différents. Le bon choix dépend moins de la taille du site que de la fréquence à laquelle vous avez besoin de la réponse et de la personne qui la lira.

Ligne de commande : grep, awk et Python

Principe : vous analysez les fichiers bruts avec des scripts et écrivez les résultats dans un fichier ou un tableur. Quand l'utiliser : contrôles ponctuels, petits sites, ou développeur qui veut un contrôle total. Avantages : c'est gratuit, vous voyez chaque ligne, et vous pouvez l'automatiser avec une tâche planifiée. Limites : il faut du temps pour l'écrire et le maintenir, la vitesse dépend de votre machine, il n'y a pas de graphiques, et vous devez vérifier les robots vous-même.

Exemple : les commandes de la section méthode, lancées une fois par mois sur le même export, donnent la répartition des codes de statut et les chemins les plus demandés par Googlebot. Un petit script Python peut faire la même chose et ajouter la vérification DNS, plus lente mais plus exacte.

Outil de bureau : Screaming Frog Log File Analyser

Principe : vous importez les logs bruts dans un projet de bureau, l'outil regroupe les robots, contrôle leur identité et trace les graphiques. Quand l'utiliser : un consultant ou un analyste interne qui travaille sur un site de plusieurs dizaines de milliers d'URL. Avantages : il lit les logs Apache, IIS et Nginx au format W3C Extended, il vérifie les robots des moteurs de recherche, et il signale les pages volumineuses ou lentes. Limites : la version gratuite est plafonnée, et le volume de données chargeable dépend de votre disque dur.

Lisez la page de présentation de Log File Analyser de Screaming Frog avant d'acheter. Pour un tutoriel complet du crawler qui s'associe à cet outil, consultez notre guide Screaming Frog SEO Spider. L'analyseur de logs fait une chose que le crawler ne peut pas faire : il montre ce que les robots ont réellement demandé, et non ce que suggèrent vos liens.

Plateforme : surveillance continue des logs

Principe : la plateforme reçoit vos logs selon un calendrier, souvent depuis le CDN ou le serveur, et les croise avec un crawl de votre site et avec les données d'indexation. Quand l'utiliser : les grands sites e-commerce ou les équipes d'entreprise qui suivent l'exploration chaque semaine sur plusieurs marchés. Avantages : elle passe à l'échelle des très gros logs, conserve l'historique, et permet à plusieurs équipes de partager des tableaux de bord. Limites : elle coûte plus cher, prend du temps à déployer, et l'enfermement chez le fournisseur est réel : vérifiez comment exporter vos données avant de vous engager. Parmi les éditeurs de cette catégorie figurent Oncrawl et Botify, et il vaut la peine de demander à chacun comment il vérifie les robots.

Critère	Ligne de commande	Outil de bureau	Plateforme
Coût	Gratuit	Gratuit jusqu'à 1000 événements de log, 99 £ par an pour la licence complète	Abonnement, prix selon le volume
Mise en place	Vous écrivez et maintenez les scripts	Installer, importer, lancer	Connecteurs et onboarding
Volume	Limité par votre machine	Limité par votre disque dur et votre licence	Conçu pour de très gros logs
Vérification des robots	Manuelle, avec contrôle DNS ou plages d'IP	Intégrée	À demander au fournisseur
Idéal pour	Contrôles ponctuels et petits sites	Consultants et sites de taille moyenne	Équipes d'entreprise et e-commerce avec suivi hebdomadaire

Le rapport Statistiques d'exploration de Google : utile, mais insuffisant

Avant d'exporter le moindre log, ouvrez le rapport Statistiques d'exploration de la Search Console. Il affiche le total des requêtes d'exploration, le volume total téléchargé, le temps de réponse moyen, les réponses regroupées par type, les types de fichiers, l'objectif de l'exploration et le type de Googlebot à l'origine de chaque requête. Pour une vérification de tendance, c'est la vue la plus rapide dont vous disposez, et le tutoriel Google Search Console explique où la trouver.

Ses limites expliquent pourquoi les logs restent indispensables. Le rapport n'est disponible que pour les propriétés de domaine et les propriétés de préfixe d'URL au niveau racine. Il ne couvre que les robots de Google, si bien que GPTBot, ClaudeBot et les autres sont absents. Il regroupe les données au lieu de lister chaque URL : il peut vous dire que les requêtes d'exploration ont baissé, mais pas quels gabarits en ont perdu. Servez-vous-en pour repérer qu'un changement a eu lieu, puis utilisez les logs pour trouver lequel.

L'aide de Google sur le rapport Statistiques d'exploration décrit chaque regroupement. Quand le graphique et votre export de logs ne concordent pas, ne faites confiance à aucun des deux avant d'avoir vérifié la fenêtre temporelle et l'étape de vérification des robots. La plupart de ces écarts viennent d'une fenêtre différente, d'un CDN qui répond depuis son cache, ou d'un décompte de robots qui inclut des requêtes non vérifiées.

Corriger le gaspillage d'exploration une fois repéré

Les corrections découlent des signaux. La plupart se résument à trois gestes : cesser d'envoyer les robots vers les pages qui comptent peu, les diriger directement vers l'URL finale quand une page a changé d'adresse, et rendre plus rapides les pages qui comptent.

Navigation à facettes. Les filtres et les ordres de tri créent de nombreuses URL au contenu presque identique. Consolidez-les avec des canonical lorsque c'est possible, et supprimez les liens internes vers les variantes sans valeur de recherche. Quand une variante ne peut pas être consolidée et doit rester hors de l'exploration, bloquez-la dans le robots.txt. Les recommandations de Google sont précises sur ce point : n'utilisez pas noindex pour cela, car Google doit tout de même demander la page avant de pouvoir lire la balise. Voici le type de règle à tester :

User-agent: Googlebot
Disallow: /*?sort=
Disallow: /*?color=

Gardez la modification du robots.txt à sa juste mesure. Google indique que bloquer des URL ne libère pas de budget d'exploration pour vos autres pages, sauf si le site atteint déjà sa limite de capacité. Le blocage sert aux URL sans valeur, et non à déplacer le budget vers vos meilleures pages. Notre entrée du glossaire sur robots.txt explique comment le fichier est lu.

Chaînes de redirections. Quand une page a été déplacée deux fois, le robot traverse les deux redirections à chaque passage. Mettez à jour les liens internes pour qu'ils pointent vers l'URL finale, puis conservez les anciennes redirections pour les liens externes. Le choix entre redirection permanente et temporaire compte pour la même raison, et le guide 301 ou 302 le détaille.

Pages supprimées. Renvoyez une 404 ou une 410 pour les pages retirées définitivement. Google indique que les soft 404 continuent d'être explorées et gaspillent le budget d'exploration : une page « introuvable » servie avec un statut 200 est donc pire qu'une vraie 404.

Temps de réponse et cache. Google indique que les réponses lentes ou en erreur le conduisent à explorer moins. Prenez en charge les réponses 304 (Not Modified), pour que les pages inchangées puissent être servies depuis le cache. Regardez ensuite les gabarits qui reçoivent le plus de hits Googlebot, et accélérez-les en premier.

Les erreurs qui coûtent le plus cher, et comment les éviter

La plupart des analyses de logs qui échouent commettent l'une d'une petite série d'erreurs. Chacune décrite ci-dessous a un symptôme repérable dans les données et une correction applicable la même semaine.

Faire confiance à la chaîne du user agent

Ce que c'est : compter comme exploration de Google chaque requête qui se dit « Googlebot ». Comment la repérer : des hits Googlebot venant d'adresses IP qui ne se résolvent pas vers les noms d'hôte de Google, ou un bond soudain depuis une seule adresse. Comment la corriger : lancez la vérification de la section méthode avant de compter quoi que ce soit, et gardez les hits non vérifiés dans un groupe à part, pour voir tout de même l'activité des scrapers.

Ne lire que les réponses 200

Ce que c'est : se concentrer sur les pages qui renvoient 200 et ignorer le reste. Comment la repérer : votre rapport n'a aucune section 3xx, 4xx ou 5xx, ou la répartition des codes de statut n'est jamais discutée. Comment la corriger : commencez toujours par la répartition des codes de statut. Une hausse des hits 404 peut révéler un lien interne cassé, et une hausse des hits 5xx peut révéler un problème serveur qui ralentit toute l'exploration.

Bloquer une page que vous voulez désindexer

Ce que c'est : ajouter une règle robots.txt à une page qui porte aussi une balise noindex. Comment la repérer : la page reste dans l'index, et le log ne montre aucun hit Googlebot, car le robot est empêché de la demander. Comment la corriger : retirez le blocage pour que Google puisse lire la balise noindex, attendez que la page sorte de l'index, puis rétablissez le blocage si vous en avez encore besoin. Le guide sur les pages bloquées par robots.txt explique le statut de la Search Console qui apparaît dans ce cas.

Comparer des fenêtres de durées différentes

Ce que c'est : comparer un export de 3 jours avant une correction avec un export de 30 jours après. Comment la repérer : les totaux varient beaucoup, mais la part par gabarit ne bouge pas. Comment la corriger : comparez le même nombre de jours, à la même période de l'année si possible, et comparez des parts plutôt que des totaux bruts quand le volume change.

Mesurer les hits au lieu de la valeur

Ce que c'est : se réjouir d'une hausse des hits Googlebot sans vérifier si ces hits atteignent des pages indexées. Comment la repérer : les hits se concentrent sur des URL non indexées ou qui ne génèrent jamais de trafic. Comment la corriger : croisez vos groupes de logs avec le statut d'indexation de l'outil d'inspection d'URL de la Search Console, et ne considérez une correction comme gagnante que lorsque l'exploration se dirige vers les pages qui comptent.

Où se situent les robots IA dans les mêmes logs

Les mêmes logs montrent ce que font les robots d'IA sur votre site, et la méthode est identique : regroupez-les, vérifiez-les quand le fournisseur propose un moyen de le faire, et lisez les codes de statut. Notre guide des logs de robots IA détaille les robots à rechercher et leurs différences avec Googlebot. Cet article couvre en profondeur la méthode Googlebot, et la section IA ci-dessous montre comment réunir les deux dans un seul rapport.

Type de robot	Exemples	Ce qu'il faut vérifier dans les logs	Pour aller plus loin
Robot de recherche	Googlebot	Hits par gabarit, répartition des codes de statut, délai avant la première exploration des nouvelles pages	Les sections ci-dessus de cet article
Robot d'entraînement	GPTBot, ClaudeBot, CCBot	Savoir s'ils demandent votre contenu et s'ils respectent votre robots.txt	Robots.txt pour les robots IA
Robot de récupération	ChatGPT-User, PerplexityBot	De courtes rafales de visites liées aux questions des utilisateurs, et les pages qu'elles atteignent	Logs des robots IA

La distinction entre entraînement et récupération vient de la manière dont les robots d'IA sont documentés. Les robots d'entraînement collectent du contenu pour les modèles, et les robots de récupération vont chercher des pages quand un utilisateur pose une question. Votre rapport doit garder les deux séparés, car une décision de politique pour l'un ne s'applique pas automatiquement à l'autre.

Si vous voulez voir côte à côte le trafic Google et le trafic IA pendant que vous déployez ces corrections, le tableau de bord GEO / SEO de Sorank les affiche dans une même vue. Servez-vous-en pour vérifier si les changements issus des logs font bouger le trafic, et pas seulement les comptages d'exploration.