Voici comment j’ai compris que l’analyse de logs manuelle avait ses limites : chez un client e-commerce dont le trafic organique venait de chuter de 30% en deux semaines, j’ai dû croiser des millions de lignes de logs serveur pour identifier le comportement exact de Googlebot avant de trouver la cause. Sans un outil centralisé, cette enquête aurait pris des semaines. C’est ce jour-là que j’ai formalisé, pour mes clients à fort volume, un guide d’installation de la stack ELK dédiée à l’analyse SEO des logs.
Qu’est-ce que la stack ELK ?
ELK est l’acronyme d’Elasticsearch, Logstash et Kibana — trois outils open source qui, ensemble, permettent de collecter, indexer et visualiser de très gros volumes de données, notamment des logs serveur. Elasticsearch est le moteur de recherche et d’indexation qui stocke les données. Logstash est le pipeline qui collecte, transforme et achemine les logs vers Elasticsearch. Kibana est l’interface de visualisation qui permet de construire des tableaux de bord à partir des données indexées.
Pour un audit SEO technique, cette stack permet de répondre à des questions que Google Search Console ne couvre pas : quelle proportion du crawl de Googlebot va sur des pages à faible valeur ? Quel est le code de statut HTTP réel renvoyé à chaque visite du bot, indépendamment de ce que rapporte Search Console avec un décalage de plusieurs jours ? Quelles URLs reçoivent le plus de visites de crawl mais génèrent le moins de trafic organique ?
Guide d’installation, étape par étape
Voici la procédure que j’utilise pour une installation simple sur un serveur Linux dédié à l’analyse de logs (à ne jamais installer sur le serveur de production lui-même, pour ne pas consommer ses ressources) :
- Prérequis : un serveur avec au moins 4 Go de RAM (8 Go recommandés pour un volume de logs conséquent), Java (OpenJDK 17 ou supérieur, requis par Elasticsearch)
- Installation d’Elasticsearch : ajout du dépôt officiel Elastic, puis
apt install elasticsearch, configuration du fichierelasticsearch.ymlpour définir le nom du cluster et l’adresse d’écoute réseau - Installation de Logstash : même dépôt,
apt install logstash, puis rédaction d’un fichier de configuration définissant l’entrée (le fichier de logs Nginx ou Apache), le filtre (parsing grok pour extraire IP, date, user-agent, code de statut), et la sortie (vers Elasticsearch) - Installation de Kibana :
apt install kibana, connexion à l’instance Elasticsearch, puis création d’un index pattern correspondant aux données de logs importées - Vérification : lancer les trois services, confirmer que les logs remontent bien dans Kibana via une requête simple sur les dernières 24 heures
Le filtre grok, la partie la plus délicate
La configuration du filtre grok dans Logstash est, en pratique, l’étape où la plupart des installations échouent. Un pattern grok mal écrit ne lèvera pas toujours une erreur visible — il va simplement échouer silencieusement à parser certaines lignes, qui atterriront dans Elasticsearch sous forme de champs bruts inexploitables. J’ai appris à toujours tester mon pattern grok sur un échantillon de 50 lignes avant de lancer l’ingestion complète, en utilisant l’outil de test grok en ligne avant de le déployer.
Identifier Googlebot avec certitude
Une fois les données dans Kibana, l’étape suivante consiste à isoler les visites de Googlebot. Le user-agent seul ne suffit pas — n’importe qui peut usurper « Googlebot » dans son user-agent. La vérification fiable repose sur une résolution DNS inversée de l’adresse IP, suivie d’une résolution DNS directe pour confirmer que l’IP appartient bien à une plage Google (*.googlebot.com ou *.google.com). J’intègre ce filtre directement dans le pipeline Logstash pour ne conserver, dans un index dédié, que le trafic de crawl authentifié.
Ce que ça a révélé chez ce client e-commerce
En croisant les logs Nginx importés dans Kibana avec les catégories du site, j’ai découvert que Googlebot passait plus de 60% de son temps de crawl sur des pages de filtre à facettes générant des milliers de combinaisons d’URL quasiment vides de contenu unique, pendant que les fiches produits stratégiques n’étaient re-crawlées que tous les 12 jours. La chute de trafic organique venait directement de là : les pages produits n’étaient plus fraîchement re-crawlées après une mise à jour de prix et de stock.
Gérer la volumétrie sur la durée
Un piège que j’ai rencontré chez plusieurs clients après quelques mois d’utilisation : Elasticsearch accumule les index quotidiens sans limite si personne ne configure de politique de rétention. J’ai vu une instance saturer son disque après trois mois de logs bruts sur un site à fort trafic. La solution consiste à mettre en place une politique ILM (Index Lifecycle Management) directement dans Elasticsearch, qui archive puis supprime automatiquement les index les plus anciens — je configure généralement une rétention de 90 jours pour les logs bruts, largement suffisante pour repérer des tendances de crawl sur un trimestre, tout en export mensuel des agrégats clés vers un tableau externe pour un historique plus long.
Dans Kibana, je construis systématiquement trois tableaux de bord distincts pour mes audits : un premier centré sur la répartition du crawl par type de page (produit, catégorie, pagination, filtre), un second sur les codes de statut HTTP renvoyés à Googlebot dans le temps, et un troisième croisant les pages crawlées avec les pages recevant réellement du trafic organique — c’est souvent ce dernier tableau qui révèle le plus d’incohérences.
Le mythe qu’il faut nuancer
On répète souvent que « Google Search Console suffit pour analyser le crawl ». En réalité, Search Console échantillonne et agrège les données avec un délai, et ne donne jamais le détail ligne par ligne du comportement réel du bot sur votre infrastructure. Pour un site de plus de quelques milliers de pages, l’analyse de logs brute via une stack comme ELK reste, à ce jour, la seule méthode qui donne une image fidèle et immédiate du crawl réel.
Pour aller plus loin : consultez l’audit des ports ouverts sur le même serveur et ma méthodologie d’audit complète.
Avez-vous déjà comparé ce que Search Console rapporte à ce que vos propres logs serveur enregistrent sur la même période ?