Search Console indique ce que Google veut bien agréger. Les fichiers de logs racontent ce que Googlebot a réellement fait sur votre serveur, hit après hit. Cet écart explique pourquoi deux sites « verts » dans GSC peuvent avoir des destinées SEO opposées. L'analyse de logs n'est pas réservée aux géants du web : dès que vous gérez un catalogue, un site média ou une architecture complexe, elle devient l'un des diagnostics les plus rentables du SEO technique.

Ce que les logs permettent de voir (et GSC non)

Les logs exposent la fréquence de crawl par URL, les codes HTTP réels (y compris les 302 intempestifs, 500 intermittents, soft 404), la répartition jour/nuit, le volume de hits sur des paramètres, et parfois la découverte de zones que vous pensiez bloquées. Search Console, elle, échantillonne, agrège et retarde. Elle reste indispensable — mais pour comprendre pourquoi une catégorie stratégique est sous-explorée alors qu'une facette l'est chaque jour, les logs sont plus honnêtes. C'est la différence entre un reporting de synthèse et une capture terrain.

En pratique, nous croisons toujours logs + crawl Screaming Frog + GSC. Les logs disent « ce qui est crawlé », le crawl dit « ce qui est lié / déclaré », GSC dit « ce qui est indexé / perf ». Les écarts entre les trois orientent le plan d'action.

Prérequis techniques pour une analyse propre

Il vous faut des logs accessibles (Apache, Nginx, CDN, load balancer) sur une période significative — idéalement 2 à 4 semaines, plus sur les sites peu crawlés. Filtrez les user-agents Googlebot (et validez-les, les spoofs existent), normalisez les URLs (casse, slash, paramètres), et excluez les assets si vous voulez concentrer l'analyse sur les documents HTML. Sans cette hygiène, vous tirerez des conclusions sur du bruit : bots fantômes, assets, préprod exposée, healthchecks.

Si vos logs sont chez un hébergeur mutualisé peu flexible, un CDN ou un WAF centralisant les accès peut servir de source. L'important est d'obtenir des lignes timestamp + URL + status + user-agent de façon exploitable, pas forcément un data lake parfait dès le jour 1.

Exemple concret

Site média régional : 41 % du crawl sur des archives mortes

Un site d'actualités économiques (~15 000 URLs) voyait ses nouveaux articles stratégiques mis à jour lentement dans l'index. L'analyse de logs sur 21 jours a montré que 41 % des hits Googlebot HTML portaient sur des archives par date et des tags historiques à très faible trafic, largement liés dans le footer. Nous avons noindexé les archives à faible valeur, réduit les liens footer, renforcé le maillage depuis la home et les rubriques vers les articles frais, et corrigé 3 à 4 % de 301 en chaîne. En six semaines, la part du crawl sur les articles J-7 est passée de 18 % à 33 %, et le trafic organique des contenus récents a augmenté de 22 %.

Les signaux actionnables à extraire

Nous regardons en priorité cinq familles de signaux. Les pages money peu crawlées (opportunité de maillage / sitemap / perf). Les pages inutiles très crawlées (gaspillage à couper). Les codes 4xx/5xx à fort volume (budget brûlé + mauvaise expérience bot). Les oscillations de statut (URL tantôt 200 tantôt 500 : urgence hébergement). Et le délai entre mise à jour de contenu et prochain hit Googlebot sur les pages critiques. Ces signaux nourrissent un backlog technique priorisé par impact, loin des recommandations génériques « améliorez votre crawl budget ».

Sur les sites moyens, reliez ces findings à notre méthode crawl budget sites moyens. Les logs donnent la preuve ; la politique d'indexation donne la correction.

Chiffre clé

Ordres de grandeur observés

Sur les analyses de logs Semsew (sites 500 à 50 000 URLs) :

  • 25 à 60 % du crawl HTML souvent concentré sur des zones à faible valeur quand l'architecture est sale.
  • Top 10 pages money parfois hors du top 100 des URLs les plus crawlées — signal d'alerte fort.
  • 2 à 5 % de hits en erreur 4xx/5xx déjà suffisants pour justifier une action hébergeur / appli.

Fréquence et industrialisation

Une analyse de logs n'a pas vocation à être mensuelle pour tous les sites. Sur une vitrine de 80 pages saine, un audit ponctuel suffit. Sur un e-commerce ou un média, un rythme trimestriel — ou après chaque release majeure — est raisonnable. L'idéal est d'industrialiser quelques dashboards (part de crawl par type de page, erreurs, top URLs) plutôt que de refaire une étude artisanale à chaque fois. L'outil importe moins que la question : « Googlebot passe-t-il son temps là où notre business se joue ? »

Si vous n'avez pas encore de socle technique propre, commencez par un audit technique classique ; les logs viennent en approfondissement quand les enjeux d'exploration le justifient.

Questions fréquentes

À partir de quelle taille de site analyser les logs ?
Dès que vous suspectez un gaspillage de crawl (catalogue, facettes, média, international) ou une indexation lente des pages stratégiques. Même dès 500 à 1 000 URLs, l'analyse peut être très rentable.
Les logs CDN suffisent-ils ?
Oui s'ils capturent les requêtes HTML vers l'origine ou les réponses complètes avec user-agent et status. Vérifiez simplement que vous ne regardez pas uniquement les assets cachés.
Faut-il des compétences data pour démarrer ?
Un minimum oui (agrégations, filtres). Mais des outils SEO de log analysis existent, et un extrait bien préparé sur 2 semaines suffit souvent à décider des premières actions.
Google Search Console remplace-t-elle les logs ?
Non. Elle les complète. GSC reste indispensable pour impressions, clics et indexation ; les logs restent la référence pour le comportement de crawl détaillé.

L'analyse de logs SEO transforme des intuitions floues (« on crawl mal ») en décisions précises : quelles zones couper, quelles pages money pousser, quelles erreurs corriger en premier. Sur les sites où l'exploration est un enjeu, c'est l'un des diagnostics les plus rentables — parce qu'il montre la réalité serveur, pas seulement le résumé Search Console.