Screaming Frog Log File Analyser
lire les logs comme Googlebot

Le Screaming Frog Log File Analyser est un logiciel distinct du SEO Spider. Il ne crawle pas ton site : il lit tes fichiers de logs serveur pour te montrer exactement quelles URLs Googlebot visite, à quelle fréquence, et quels codes réponse il rencontre.

C’est l’outil qui révèle ton budget de crawl réel. Tu passes des suppositions aux faits : tu vois enfin ce que les moteurs explorent vraiment, et surtout ce qu’ils ignorent.

Pourquoi analyser tes logs serveur

Un crawl avec le SEO Spider simule le comportement d’un robot : il suit tes liens et découvre tes 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 ton site, y compris celles de Googlebot. C’est la seule source de vérité absolue sur ce que les moteurs font concrètement chez toi.

Prends 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 te dit ce qui est possible ; les caméras te 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. Tu vois quelles pages Googlebot visite le plus, lesquelles il n’a jamais explorées, et où il gaspille ton budget de crawl sur des URLs sans valeur.

La différence est fondamentale et souvent mal comprise. Un audit de crawl te dit : « voici ce que ton site propose à explorer ». L’analyse de logs te 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 ton site.

Concrètement, si Google passe 40 % de son temps sur des pages de filtres e-commerce inutiles, tes 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 ton site pour auditer sa structure, ses balises, ses redirections. Le Log File Analyser ne crawle rien : il consomme des fichiers de logs que ton 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 ta licence. Posséder le SEO Spider ne te donne pas accès au Log File Analyser, et inversement. Chacun a son propre tarif et sa propre version gratuite limitée. Il faut donc évaluer ton 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 tu croises les deux. Tu importes ton crawl du SEO Spider dans le Log File Analyser, et tu obtiens une vue unique : pages crawlables non visitées par Google, pages orphelines pourtant visitées, écarts entre ta structure théorique et la réalité d’exploration. Ce croisement est là où l’analyse prend toute sa dimension stratégique.

Ce que tu découvres dans tes logs

Une fois tes logs importés, l’outil te donne accès à des indicateurs impossibles à obtenir autrement. La fréquence de crawl par URL te 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 ton crawl théorique ne verra jamais.

Un exemple parlant : une page peut renvoyer un beau code 200 quand tu la visites dans ton navigateur, mais servir un 500 intermittent quand Googlebot la sollicite en masse aux heures de forte charge. Ton 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.

Tu observes 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 tes pages importantes est devenu un contrôle essentiel, que seule l’analyse de logs permet de faire précisément.

Tu identifies 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.

Comment récupérer et importer tes logs

Première étape : obtenir les fichiers de logs. Ils sont produits automatiquement par ton serveur web. Sur un hébergement mutualisé, tu les télécharges 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 : vise 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 tu vois vraiment quelles sections il privilégie et lesquelles il délaisse. Pense donc à archiver régulièrement tes logs si ton hébergeur les efface vite.

Ensuite, tu glisses 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 tu commences à explorer. Plus tu importes de jours, plus l’analyse de fréquence est fiable.

Optimiser ton budget de crawl grâce aux logs

Le budget de crawl est le nombre de pages que Google accepte d’explorer sur ton 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 ton serveur à répondre vite sans saturer, et l’intérêt qu’il porte à ton site. Un site rapide et souvent mis à jour sera crawlé plus généreusement qu’un site lent et statique. Améliorer ton temps de réponse serveur peut donc, indirectement, augmenter la fréquence d’exploration, ce que tu constateras justement dans tes logs au fil des semaines.

Le schéma typique que je rencontre en mission : 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 te donne un argument concret pour décider quoi bloquer et quoi laisser explorer.

Une fois les gaspillages identifiés, tu agis : 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. Tu rediriges 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.

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, tu veux vérifier que Googlebot découvre bien les nouvelles URLs et abandonne les anciennes. Les logs te 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 ton 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 tu gères un site à forte volumétrie, coupler le SEO Spider et le Log File Analyser te donne une longueur d’avance. Tu ne devines plus le comportement de Google : tu le lis. Pour aller plus loin sur la méthode globale, ma 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 en mission. 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 trustait 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’oeil 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 le client 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 ton serveur. Si un service comme un CDN intercepte une partie des requêtes, tes logs d’origine peuvent être incomplets : certaines visites de Googlebot sont servies par le cache et n’atteignent jamais ton 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 ta 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.

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 : commence par un simple export de logs sur sept jours, importe-les et regarde d’abord les pages les plus crawlées. Tu seras souvent surpris de voir Google passer du temps sur des URLs que tu croyais sans importance.