Exploiter les logs serveur pour le SEO : le guide qui change tout

Un client m'appelle un mardi matin, paniqué. Search Console lui annonce une chute de 40 % de ses impressions depuis trois semaines. Je demande son trafic analytics : stable. Ses ventes ? Stables aussi. Alors quoi ? J'ai ouvert ses logs serveur, et là, en dix minutes, tout était clair : Googlebot passait l'essentiel de son temps à crawler des URL de filtres à facettes qu'aucun humain ne visitait, pendant que ses pages catégories — celles qui rapportent — attendaient leur tour. Le problème n'était pas dans Search Console. Il était dans les logs.

Voilà pourquoi j'ai fini par considérer les logs serveur comme le seul outil SEO qui ne ment pas. Pas d'échantillonnage, pas de délai de latence, pas de « données indisponibles ». Juste la vérité brute de ce qui a frappé votre serveur, seconde par seconde.

Pourquoi exploiter les logs serveur change votre vision du SEO

Search Console vous dit ce que Google veut bien montrer. Les logs vous disent ce qu'il a réellement fait. Entre les deux, il y a un gouffre, et c'est dans ce gouffre que se cachent la plupart des problèmes techniques qu'on met des mois à identifier autrement.

Ce que les logs contiennent vraiment

Une ligne de log Apache ou Nginx, c'est une requête complète : adresse IP, date, méthode HTTP, URL demandée, code de statut, taille de réponse, user-agent et référent. Sur un site de taille moyenne, cela représente facilement plusieurs millions de lignes par mois. Brut, illisible à l'œil nu. Et pourtant, tout est là.

Ce qui m'a le plus surpris la première fois que j'ai vraiment creusé : la proportion de requêtes qui viennent de robots. Sur un site e-commerce que je suivais, plus de 60 % du trafic log était non humain. Bingbot, Googlebot, mais aussi des scrapers, des outils de monitoring, des aspirateurs de contenu. Tous ces gens consomment de la bande passante et faussent votre perception si vous ne les filtrez pas.

Logs et Search Console : complémentaires, pas concurrents

Un raccourci que je vois souvent : « Search Console suffit ». Non. Search Console échantillonne, agrège, et retarde. Les logs ne font rien de tout ça. Voici la différence en pratique :

Critère	Logs serveur	Search Console
Couverture	100 % des requêtes reçues	Échantillon, pas de garantie d'exhaustivité
Tous les bots	Oui, y compris Bingbot, scrapers	Google uniquement
Délai	Immédiat	24 h à plusieurs jours
Statuts HTTP détaillés	Tous, ligne par ligne	Partiel, agrégé
Historique conservé	Limité par votre hébergeur	16 mois

Ma conviction : les logs sont le seul moyen de vérifier ce que Googlebot fait vraiment. Le reste, c'est de la déclaration.

Filtrer Googlebot sans se tromper : la méthode qui marche

Première erreur que j'ai commise. J'ai filtré mes logs sur le user-agent « Googlebot », tout content d'avoir mes données en cinq minutes. Résultat : j'ai compté des dizaines de faux Googlebot, des scrapers qui se faisaient passer pour le crawler. Le user-agent se falsifie en une ligne de code.

IP ou reverse DNS, la seule vérité

Deux approches fiables. La première : faire un reverse DNS sur l'IP source et vérifier qu'elle se termine par googlebot.com ou google.com. La seconde : utiliser la plage d'IP officielle publiée par Google (fichier googlebot.json), et croiser. Avec grep ou une regex propre dans votre outil d'analyse, c'est trivial.

Concrètement, sur un fichier de 2 Go, un filtre approximatif vous donne des faux positifs à hauteur de 15 à 30 % selon l'exposition du site. Sur mon projet, c'était 22 %. Inutile de dire que toutes mes conclusions initiales étaient fausses.

Les commandes de base que tout le monde devrait connaître

• grep -i "googlebot" access.log | wc -l — comptage brut (à affiner avec l'IP)
• awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -50 — top 50 des URL les plus demandées
• awk '{print $9}' access.log | sort | uniq -c — répartition des codes de statut
• grep " 404 " access.log | awk '{print $7}' | sort | uniq -c | sort -rn — les 404 les plus fréquentes

Une fois, j'ai trouvé en trois commandes qu'une page produit générait 4 000 requêtes 404 par jour parce qu'un lien interne pointait vers une URL avec un slash en trop. Personne ne l'avait vu. Search Console affichait bien les 404, mais noyées dans le bruit.

Budget de crawl : comment arrêter de le gaspiller

Le budget de crawl n'est pas une invention de blogueur SEO. C'est une réalité mesurable dans les logs : sur une période donnée, Googlebot consacre un nombre fini de requêtes à votre site. La question n'est pas « combien » mais « où ».

Identifier les pages qui aspirent le bot

Croisez le top des URL crawlées avec votre sitemap. Tout ce qui apparaît dans les logs mais pas dans le sitemap et qui n'a aucune valeur SEO est un candidat à la désindexation ou au noindex. Paramètres de tri, filtres à facettes, pages de recherche internes, pagination infinie : la liste est longue.

Sur le site du client dont je parlais en ouverture, 68 % des hits Googlebot portaient sur des paramètres de tri. Après avoir ajouté des rel="nofollow" ciblés et bloqué certains paramètres dans le robots.txt, la part est tombée sous les 20 % en six semaines. Les pages catégories ont vu leur fréquence de crawl augmenter dans la foulée.

Vérifier ce que Googlebot ne crawle pas

Le problème inverse est tout aussi fréquent. Une page stratégique qui n'apparaît jamais dans les logs, c'est une page que Google ignore. J'ai vu un cas où une nouvelle section de blog n'avait reçu aucune visite du bot pendant deux mois. Cause : elle n'était liée depuis aucune page crawlée. Un lien interne ajouté, trois jours plus tard, le bot passait.

Le croisement est simple : liste des URL à crawler (sitemap) moins liste des URL crawlées (logs filtrés) = liste des pages orphelines SEO. À traiter en priorité.

Les outils que j'utilise vraiment (et ceux que j'ai abandonnés)

J'ai testé beaucoup de choses. Voici mon verdict honnête.

Screaming Frog Log File Analyser : le couteau suisse

Payant, mais robuste. Il gère des fichiers de plusieurs Go, filtre proprement Googlebot par vérification DNS, et sort des rapports lisibles. Pour un consultant qui gère plusieurs sites, c'est mon outil principal. Le seul défaut : il ne fait pas de corrélation avec les données de position, il faut bricoler.

GoAccess : rapide, gratuit, en ligne de commande

Pour un premier diagnostic en SSH, c'est imbattable. Une commande, un dashboard HTML. Je l'utilise pour les audits express avant de sortir la grosse artillerie.

grep, awk et un peu de regex

Franchement, pour 80 % des questions que je me pose, trois lignes de shell suffisent. Et j'apprends plus en écrivant mes filtres qu'en cliquant dans une interface. Avouons-le : c'est aussi plus satisfaisant.

Et les solutions « cloud » (Logstash, BigQuery) ?

Utiles au-delà de 10 Go de logs par mois, ou pour un suivi permanent automatisé. En dessous, le coût d'installation dépasse le bénéfice. J'ai fait l'erreur une fois de monter une stack Elasticsearch pour un site à 50 000 visites par mois. Trois jours de setup, pour un résultat identique à un script awk de 15 lignes.

De la donnée brute à la décision chiffrée

C'est l'étape où la plupart des articles s'arrêtent. Les logs ne servent à rien si vous ne traduisez pas une ligne en action priorisée.

Ma règle : chaque anomalie identifiée doit être quantifiée en deux métriques. Le volume de requêtes concernées (en % du crawl total) et l'impact estimé sur les pages qui génèrent du revenu. Une page catégorie crawlée 200 fois par mois qui convertit à 3 % vaut infiniment plus que 5 000 hits sur un filtre paramétré qui convertit à zéro.

1. Extraire le top 100 des URL crawlées sur 30 jours.
2. Classer chaque URL en : stratégique, neutre, ou inutile.
3. Calculer le ratio requêtes « inutiles » / total.
4. Si supérieur à 30 %, agir : robots.txt, noindex, ou suppression du maillage.
5. Re-mesurer 4 semaines plus tard. Si le ratio baisse, la stratégie fonctionne.

Sur les six derniers sites que j'ai audités, cinq avaient un ratio supérieur à 25 %. Le pire atteignait 71 %. À chaque fois, le client n'en avait aucune idée.

Ce que les logs ne vous diront jamais

Une mise en garde qui m'a coûté une présentation entière devant un client. Les logs disent ce qui est demandé, pas ce qui est indexé, ni ce qui positionne. Un URL peut être crawlée 500 fois et ne jamais apparaître dans les résultats. Inversement, une page peut ranker sans avoir été crawlée récemment. Les logs sont un indicateur technique, pas un juge de performance.

Traitez-les comme un thermomètre. Utile, précis, mais il ne remplace pas le diagnostic du médecin.

Et la vraie question n'est pas « faut-il exploiter ses logs ? » — la réponse est oui, sans hésitation. La vraie question, c'est : êtes-vous prêt à regarder ce qu'ils vont vous montrer ? Parce que dans 8 cas sur 10, ça ne fait pas plaisir. Le bot gaspille. Les redirections fuient. Les 404 s'accumulent depuis des mois. Personne ne les a vues parce que personne n'avait ouvert le fichier. La bonne nouvelle ? Une fois qu'on les voit, on peut agir. Et là, en général, ça bouge vite.