Screaming Frog Log File AnalyserLire les logs comme Googlebot

Pourquoi analyser vos logs serveur ?

Un crawl avec le SEO Spider simule le comportement d’un robot : il suit vos liens et découvre vos pages comme le ferait Google, en théorie. Mais il reste une simulation. Les logs serveur, eux, enregistrent chaque requête réelle reçue par votre site, y compris celles de Googlebot. C’est la seule source de vérité absolue sur ce que les moteurs font concrètement chez vous.

Prenez une image simple : le crawl, c’est le plan d’un bâtiment ; les logs, ce sont les caméras de surveillance qui montrent par où les visiteurs passent vraiment. Le plan vous dit ce qui est possible ; les caméras vous disent ce qui se passe. Un couloir magnifiquement conçu mais que personne n’emprunte ne sert à rien. En SEO, une page parfaite que Googlebot ne visite jamais est exactement ce couloir désert.

Le Screaming Frog Log File Analyser lit ces fichiers de logs (format Apache, Nginx, IIS) et transforme des millions de lignes illisibles en tableaux exploitables. Vous voyez quelles pages Googlebot visite le plus, lesquelles il n’a jamais explorées, et où il gaspille votre budget de crawl sur des URLs sans valeur.

La différence est fondamentale et souvent mal comprise. Un audit de crawl vous dit : « voici ce que votre site propose à explorer ». L’analyse de logs vous dit : « voici ce que Google a réellement exploré, quand, et combien de fois ». Entre les deux, il y a presque toujours un écart, et c’est précisément dans cet écart que se cachent les problèmes d’indexation les plus coûteux. Une page magnifique que Googlebot ne visite jamais ne rapportera aucun trafic, peu importe sa qualité.

C’est une source de données qu’aucun autre outil ne peut fabriquer, car elle ne relève pas de l’estimation. La Search Console donne des statistiques d’exploration agrégées, utiles mais limitées. Les logs, eux, contiennent le détail brut, ligne par ligne, URL par URL. C’est la matière première la plus fiable qui existe pour comprendre le comportement des moteurs sur votre site.

Concrètement, si Google passe 40 % de son temps sur des pages de filtres e-commerce inutiles, vos pages stratégiques sont explorées moins souvent. L’analyse de logs met ce gaspillage en lumière. C’est un complément naturel de mon guide du crawl avec le SEO Spider.

Log File Analyser ou SEO Spider : deux outils complémentaires

Beaucoup confondent les deux logiciels. Le SEO Spider crawle votre site pour auditer sa structure, ses balises, ses redirections. Le Log File Analyser ne crawle rien : il consomme des fichiers de logs que votre hébergeur produit déjà. Ce sont deux briques distinctes, vendues et installées séparément.

Cette distinction a une conséquence pratique sur votre licence. Posséder le SEO Spider ne vous donne pas accès au Log File Analyser, et inversement. Chacun a son propre tarif (199 £ par an et par utilisateur pour le SEO Spider, soit 279 $ ou environ 245 €) et sa propre version gratuite limitée. Il faut donc évaluer votre besoin réel avant d’investir dans le second outil : sur un petit site, il ne se justifie pas ; sur une grosse volumétrie, il devient vite indispensable.

La vraie puissance vient quand vous croisez les deux. Vous importez votre crawl du SEO Spider dans le Log File Analyser, et vous obtenez une vue unique : pages crawlables non visitées par Google, pages orphelines pourtant visitées, écarts entre votre structure théorique et la réalité d’exploration. Ce croisement est là où l’analyse prend toute sa dimension stratégique.

Ce que vous découvrez dans vos logs

Une fois vos logs importés, l’outil vous donne accès à des indicateurs impossibles à obtenir autrement. La fréquence de crawl par URL vous montre les pages que Google juge importantes. Les codes réponse réels (200, 301, 404, 500) rencontrés par les bots révèlent des erreurs que votre crawl théorique ne verra jamais.

Un exemple parlant : une page peut renvoyer un beau code 200 quand vous la visitez dans votre navigateur, mais servir un 500 intermittent quand Googlebot la sollicite en masse aux heures de forte charge. Votre crawl ponctuel ne le verra pas ; les logs, qui enregistrent chaque requête sur la durée, captureront ces erreurs sporadiques. Ce sont précisément ces problèmes intermittents, invisibles autrement, qui pénalisent l’indexation sans qu’on comprenne pourquoi.

Vous observez aussi la répartition du crawl par type de bot. Googlebot desktop, Googlebot mobile, Bingbot et les autres n’explorent pas forcément de la même façon. Depuis le passage à l’index mobile-first, vérifier que Googlebot mobile explore bien vos pages importantes est devenu un contrôle essentiel, que seule l’analyse de logs permet de faire précisément.

Vous identifiez aussi les faux Googlebot : des robots qui se font passer pour Google mais viennent d’adresses IP suspectes. L’outil vérifie l’authenticité des user-agents, ce qui aide à détecter le scraping et les tentatives d’exploration malveillantes.

Ces indicateurs viennent de vos propres logs : ce sont des faits mesurés, pas des estimations.

Comment récupérer et importer vos logs ?

Première étape : obtenir les fichiers de logs. Ils sont produits automatiquement par votre serveur web. Sur un hébergement mutualisé, vous les téléchargez généralement depuis le panneau cPanel, section « Logs bruts ». Sur un serveur dédié ou un VPS, ils se trouvent dans les répertoires classiques d’Apache ou de Nginx.

Selon la configuration, ces fichiers portent des noms comme access.log ou access_log, parfois datés et compressés au format gzip. Chaque ligne suit un format standard qui comprend l’adresse IP du visiteur, la date et l’heure, la méthode et l’URL demandées, le code de réponse et le user-agent. C’est ce dernier champ qui permet d’identifier Googlebot et de le distinguer du trafic humain ou des autres robots.

Un conseil pratique sur la période : visez au minimum sept jours de logs, idéalement trente. Sur une seule journée, les chiffres de fréquence sont trop bruités pour être exploitables ; Googlebot peut avoir un comportement atypique un jour donné. Sur un mois complet, les tendances se lissent et vous voyez vraiment quelles sections il privilégie et lesquelles il délaisse. Pensez donc à archiver régulièrement vos logs si votre hébergeur les efface vite.

Ensuite, vous glissez simplement les fichiers dans le Log File Analyser. L’outil accepte les formats compressés et fusionne plusieurs jours de logs. Un projet se crée, les données s’indexent, et vous commencez à explorer. Plus vous importez de jours, plus l’analyse de fréquence est fiable.

Voici un extrait simplifié d’un fichier de log serveur, avec trois visites de Googlebot.

# une ligne de log = une requête reçue par le serveur
66.249.66.1 [15/Jul/2026:08:14:22] "GET /blog/audit-seo/ HTTP/1.1" 200
66.249.66.1 [15/Jul/2026:08:14:25] "GET /produit/filtre?couleur=x HTTP/1.1" 200
66.249.66.1 [15/Jul/2026:08:14:31] "GET /page-supprimee/ HTTP/1.1" 404
# le Log File Analyser agrège ces lignes par URL et par bot

Optimiser votre budget de crawl grâce aux logs

Le budget de crawl est le nombre de pages que Google accepte d’explorer sur votre site dans un temps donné. Sur les gros sites, il est limité : chaque URL inutile explorée est une URL stratégique de moins visitée. L’analyse de logs est le seul moyen de mesurer ce budget avec précision.

Google détermine ce budget en fonction de deux facteurs : la capacité de votre serveur à répondre vite sans saturer, et l’intérêt qu’il porte à votre site. Un site rapide et souvent mis à jour sera crawlé plus généreusement qu’un site lent et statique. Améliorer votre temps de réponse serveur peut donc, indirectement, augmenter la fréquence d’exploration, ce que vous constaterez justement dans vos logs au fil des semaines.

Le schéma typique que l’on rencontre souvent : un site e-commerce dont 60 % du budget de crawl part sur des URLs à paramètres, des combinaisons de filtres, des variantes de tri, des pages de pagination profonde. Pendant ce temps, les fiches produits récemment mises à jour ne sont revisitées qu’une fois par mois. Résultat : les nouveautés mettent des semaines à remonter dans les résultats. Sans logs, ce problème reste totalement invisible et on l’attribue à tort au contenu ou aux backlinks.

La navigation à facettes est le coupable numéro un sur les gros catalogues. Chaque combinaison de filtres, taille, couleur, marque, prix, génère une URL unique que Googlebot peut explorer. Sur un catalogue conséquent, cela produit des dizaines de milliers d’URLs de faible valeur qui n’existent que pour l’utilisateur, pas pour l’index. Les logs chiffrent précisément le temps que Google y consacre, ce qui vous donne un argument concret pour décider quoi bloquer et quoi laisser explorer.

Une fois les gaspillages identifiés, vous agissez : blocage des paramètres d’URL inutiles dans le robots.txt, mise en noindex des pages à faible valeur, renforcement du maillage vers les pages prioritaires. Vous redirigez ainsi l’attention de Google là où elle compte vraiment. Je détaille la partie blocage sur mon guide du robots.txt avec Screaming Frog.

Pour quels sites l’analyse de logs est-elle indispensable ?

Sur un petit site de quelques dizaines de pages, l’analyse de logs apporte peu : Google explore tout facilement. L’outil devient vraiment stratégique à partir de plusieurs milliers d’URLs, et incontournable sur les gros e-commerce ou les sites d’actualité où le budget de crawl est un enjeu quotidien. Sur un petit site, ce que les logs disent de vos vrais visiteurs et des robots des IA compte souvent plus. C’est ce que suit mon analyseur de logs. Pour un premier coup d’œil à un fichier, sans rien installer, il y a aussi l’analyseur de logs gratuit.

Les sites d’actualité et les médias sont un cas particulier : leur contenu doit être indexable en quelques minutes pour capter le trafic à chaud. L’analyse de logs leur permet de vérifier que Googlebot revient assez souvent sur les rubriques chaudes, et de détecter tout ralentissement d’exploration qui ferait rater une actualité. Pour eux, quelques minutes de délai d’indexation peuvent représenter une perte de trafic considérable.

Les sites en pleine migration ou refonte tirent aussi un grand bénéfice des logs. Après un changement de structure, vous voulez vérifier que Googlebot découvre bien les nouvelles URLs et abandonne les anciennes. Les logs vous montrent en temps réel si la migration est correctement perçue par les moteurs, là où la Search Console met parfois plusieurs jours à refléter la réalité.

Attention toutefois à ne pas surdimensionner : si votre site tient sur quelques centaines de pages bien maillées, investir du temps et de l’argent dans l’analyse de logs serait déplacé. Le bon réflexe est de commencer par un crawl propre et un maillage solide ; l’analyse de logs vient ensuite, quand la volumétrie et les enjeux le justifient vraiment. C’est un outil de maturité SEO, pas un point de départ.

Si vous gérez un site à forte volumétrie, coupler le SEO Spider et le Log File Analyser vous donne une longueur d’avance. Vous ne devinez plus le comportement de Google : vous le lisez. Sur la méthode globale, mon guide de formation Screaming Frog couvre le croisement crawl et logs.

Mon workflow d’analyse de logs, étape par étape

Voici concrètement comment je procède sur un site à analyser. Je commence par récupérer trente jours de logs, que j’importe dans le Log File Analyser. Première lecture : je regarde le volume total de requêtes Googlebot et sa répartition dans le temps, pour vérifier qu’il n’y a pas de chute brutale d’exploration, signe possible d’un problème serveur ou d’un blocage accidentel.

Ensuite, je trie les URLs par fréquence de crawl décroissante. Les pages en haut de liste sont celles que Google juge importantes : je vérifie qu’elles correspondent bien à mes pages stratégiques. Quand une page de faible valeur truste le haut du classement, c’est un signal d’alerte immédiat sur un gaspillage de budget.

Je regarde aussi la répartition des codes de réponse côté bots. Un taux anormal de 404 signifie que Google perd du temps sur des liens morts qu’il faudrait corriger ou rediriger. Une proportion notable de 301 indique des chaînes de redirection à nettoyer, car chaque saut consomme une part du budget. Ces détails, invisibles à l’œil nu, ressortent immédiatement dans un bon tableau de logs et orientent les premières corrections.

Troisième temps : j’importe mon crawl du SEO Spider pour croiser les deux jeux de données. J’isole alors deux listes critiques. D’un côté, les pages crawlables et stratégiques que Googlebot n’a jamais visitées en trente jours : elles ont un problème de maillage ou de profondeur. De l’autre, les URLs visitées par Google mais absentes de ma structure : des pages orphelines ou des restes d’anciennes versions.

Ce croisement révèle presque toujours des surprises. Des pages que l’on croyait supprimées depuis longtemps et que Google continue de visiter. Des sections entières du site jamais explorées car enfouies trop profond dans l’arborescence. Des versions paramétrées d’URLs qui démultiplient artificiellement le nombre de pages vues par les bots. Chaque anomalie devient une action concrète d’optimisation, chiffrée et priorisable.

Je répète ensuite l’opération à intervalle régulier, un mois ou un trimestre plus tard, pour mesurer l’effet des corrections. C’est l’intérêt majeur de cette méthode : elle n’est pas qu’un diagnostic ponctuel, mais un vrai suivi. Voir la fréquence de crawl des pages stratégiques augmenter après un renforcement du maillage est la preuve tangible que le travail a porté, là où la plupart des optimisations SEO restent difficiles à attribuer.

Enfin, je hiérarchise les actions. Corriger d’abord les erreurs réelles rencontrées par les bots, puis récupérer le budget gaspillé sur les URLs inutiles, puis renforcer le maillage vers les pages sous-explorées. Ce trio d’actions, mené dans cet ordre, donne généralement des résultats visibles sur l’indexation en quelques semaines. Sur le volet maillage, mon guide du maillage interne complète cette approche.

Les limites à connaître

L’analyse de logs demande un minimum de rigueur technique. Il faut savoir récupérer les fichiers, comprendre leur format, et disposer d’un historique suffisant. Certains hébergeurs conservent les logs peu de temps ou les rendent difficiles à exporter, ce qui complique l’analyse sur la durée.

Un autre piège fréquent : la présence d’un cache ou d’un CDN devant votre serveur. Si un service comme un CDN intercepte une partie des requêtes, vos logs d’origine peuvent être incomplets : certaines visites de Googlebot sont servies par le cache et n’atteignent jamais votre serveur. Dans ce cas, il faut récupérer les logs au bon niveau, souvent ceux du CDN lui-même, sous peine d’analyser une image partielle et trompeuse de l’exploration.

Il faut enfin composer avec le volume. Sur un site à fort trafic, un mois de logs peut représenter des centaines de millions de lignes et plusieurs gigaoctets de données. Le Log File Analyser gère bien ces volumes, mais l’import et l’indexation prennent du temps et sollicitent votre machine. Sur les cas vraiment massifs, c’est d’ailleurs là que les solutions cloud d’analyse de logs reprennent l’avantage, en traitant les données sur leurs propres serveurs.

Autre point : les logs bruts ne contiennent pas les données JavaScript ni les interactions front. Ils enregistrent les requêtes serveur, pas le rendu final. C’est pourquoi ils se combinent avec un crawl, jamais seuls. Ensemble, les deux donnent une image complète ; séparément, chacun a ses angles morts.

Mon verdict sur le Log File Analyser

Le Screaming Frog Log File Analyser n’est pas un gadget : c’est l’outil qui transforme le SEO technique en science exacte. Là où le crawl suppose, les logs prouvent. Pour tout site dépassant quelques milliers de pages, c’est l’investissement qui révèle les gaspillages invisibles et redirige le budget de crawl vers ce qui compte.

Mon conseil pour démarrer : commencez par un simple export de logs sur sept jours, importez-les et regardez d’abord les pages les plus crawlées. Vous serez souvent surpris de voir Google passer du temps sur des URLs que vous croyiez sans importance.