Analyseur de logs SEO
Ce que vos serveurs savent, et que Search Console ne dira pas
Search Console vous montre un échantillon, en différé. Les journaux de vos serveurs, eux, gardent la trace de chaque requête réellement reçue. Nous les lisons, nous séparons les robots des visiteurs, et nous croisons le résultat avec le reste de l’audit, sans conserver une seule adresse IP.
Les accès s’ouvrent par vagues, nous prévenons par e-mail.
Nos chiffres, avec leur provenance
-
52 000lignes de logs par seconde mesuré
Les moteurs passent, mais où ?
Un crawl part de ce qui est lié, et Search Console rapporte ce qu’elle veut bien rapporter. Entre les deux, il reste une catégorie entière de constats que seule la trace des requêtes réelles produit.
-
01
Vos pages importantes ne sont pas explorées
Le budget d’exploration part dans des paramètres d’URL, des filtres à facettes et des redirections, pendant que vos pages de vente attendent leur tour, parfois pendant des semaines.
-
02
Des pages existent sans que personne ne les demande
Ni lien entrant, ni requête de moteur, ni visite. Elles n’apparaissent dans aucun crawl, précisément parce qu’un crawl suit les liens : il ne peut pas trouver ce qui n’en a pas.
-
03
Le service qui détient les journaux n’est pas celui qui en a besoin
La demande passe par l’infrastructure, revient sous forme d’archive de plusieurs gigaoctets, et le fichier reste fermé. La question SEO se pose ailleurs que là où vit la donnée.
Ce que l’analyse de vos logs vous apprend
Six questions qu’un SEO se pose chaque fois qu’un fichier de logs s’ouvre enfin. Chaque réponse vient des requêtes que votre serveur a réellement reçues, recoupées avec le reste de l’audit.
-
Quels robots passent vraiment, et sont-ils ceux qu’ils prétendent être ?
Chaque requête de robot est confrontée aux plages d’adresses IP que publie son opérateur (Google, Bing, Apple, OpenAI, Anthropic, Perplexity et d’autres) et en sort vérifiée, usurpée ou invérifiable. Le trafic usurpé est retiré de tous les comptes au lieu de gonfler vos statistiques d’exploration.
-
Qu’ont reçu les robots ?
La part de réponses réussies, de redirections, d’erreurs client et d’erreurs serveur servies aux robots, et la liste des URL qui ont répondu par une erreur, par robot et par code de statut.
-
À quelle fréquence les moteurs reviennent-ils ?
Une courbe quotidienne qui sépare moteurs de recherche, robots d’IA, autres robots et humains, la moyenne quotidienne de chaque robot, et la dernière date à laquelle chaque URL a été demandée.
-
Quelles pages Googlebot demande-t-il encore alors que votre site ne les lie plus ?
Les URL servies avec succès à un Googlebot vérifié que votre dernier crawl n’a pas atteintes : anciennes rubriques, pages d’atterrissage oubliées, paramètres encore en circulation. Chacune est une page à relier, rediriger ou retirer.
-
Le budget de crawl va-t-il aux pages qui rapportent ?
Search Console connectée, chaque page se place sur le parcours connue, explorée, indexable, performante. Les pages qui reçoivent des clics pendant que Googlebot les délaisse, et celles très explorées sans une seule impression, sortent en deux listes distinctes.
-
Les robots d’IA lisent-ils votre contenu ?
Robots d’entraînement et robots des moteurs de réponse sont comptés à part, puis confrontés à ce que votre robots.txt autorise et aux réponses qu’ils ont reçues. Un robot d’IA qui ne vient jamais n’est déclaré absent qu’après une semaine complète de logs.
Ce que nous mesurons
Ce que le parseur extrait
Un parseur écrit pour ce seul usage, qui lit le fichier en flux et n’en conserve que ce qui sert à une décision. Tout le reste est jeté à la lecture, y compris ce qui identifierait quelqu’un.
- Le trafic des moteurs, robot par robot (chaque requête est attribuée à l’agent qui l’a émise, et le trafic automatisé est séparé du trafic humain. Deux grandeurs distinctes, jamais additionnées en un total qui ne voudrait rien dire.)
- Les pages ignorées et les pages fantômes (ce que les moteurs demandent souvent, ce qu’ils ne demandent jamais, et ce qui répond alors que rien ne le lie. Un crawl seul ne peut produire aucun de ces trois constats.)
- Le croisement avec le reste de l’audit (journaux, Search Console, positions et structure du site se rejoignent sur la même URL normalisée. Une source manquante laisse la case vide et le dit : jamais un zéro, qui serait une mesure.)
- Un débit mesuré au banc (le parseur a un débit connu, publié avec sa preuve dans notre registre de chiffres. Une archive volumineuse s’analyse sans y passer la nuit, et sans charger le fichier en mémoire.)
Comment analyser vos fichiers de logs serveur pour le SEO
Quatre étapes, de l’archive que vous envoie votre hébergeur à une liste de décisions. La première est la seule qui vous demande un peu de temps.
-
01
Exportez vos journaux d’accès
Demandez au moins une semaine de journaux d’accès, un mois si possible : une fenêtre plus courte décrit une coïncidence. Les formats courants sont lus tels que livrés, archives compressées comprises : combined (nginx, Apache), IIS W3C, JSON Cloudflare et Caddy, CloudFront, journaux de répartiteur de charge et de stockage objet, Traefik, ou une chaîne de format personnalisée.
Guides d’export, format par format
-
02
Importez-les dans votre projet
Un import guidé envoie le fichier par morceaux et reprend là où il s’est arrêté si la connexion tombe. Le même fichier envoyé deux fois est reconnu et refusé : une période n’est jamais comptée deux fois.
-
03
Laissez le parseur trier et vérifier
Chaque ligne est attribuée à un robot ou à un visiteur, chaque robot est confronté aux plages d’adresses publiées par son opérateur, et l’adresse est abandonnée dès ce contrôle fait. Le fichier brut est supprimé une fois traité.
-
04
Croisez le résultat avec l’audit
Les logs rejoignent le crawl, Search Console et le suivi de positions sur la même URL normalisée. Vous repartez avec des URL en erreur à corriger, des pages orphelines à relier ou retirer, et un export Excel de chaque tableau.
Pour aller plus loin
Analyse de logs serveur : ce que vos serveurs savent et que Search Console ignore
Le tutoriel : récupérer vos journaux et les lire, format par format.
Lire ComparatifNessFlow vs Botify & Oncrawl
Ce qu’une plateforme d’entreprise apporte sur les journaux, et ce qu’elle demande en retour.
Lire GlossaireGlossaire
Budget d’exploration, page fantôme, page orpheline : les définitions.
LireLes autres modules
Questions fréquentes
Quels formats de journaux acceptez-vous ?
Les formats courants des serveurs web, y compris compressés. Le parseur lit le fichier en flux plutôt que de le charger en mémoire : une archive de plusieurs gigaoctets passe sans que la machine s’en aperçoive. Son débit est publié avec la mesure de banc qui l’établit, vous pouvez donc estimer la durée avant d’envoyer quoi que ce soit.
Que faites-vous des adresses IP ?
Elles servent au tri pendant la lecture, puis elles disparaissent : aucune n’est écrite en base, aucune ne part vers un modèle. Ce n’est pas un réglage désactivable, c’est la façon dont le parseur est construit, et c’est la seule raison pour laquelle une équipe peut nous confier ses journaux sans ouvrir un dossier de conformité de trois mois.
Pourquoi croiser les journaux et Search Console ?
Parce qu’ils ne disent pas la même chose. Search Console rapporte ce que Google veut bien rapporter, en différé et par échantillon ; le journal rapporte ce que votre serveur a effectivement reçu. Une page très demandée par les robots et absente des impressions (ou l’inverse) est un constat qu’aucune des deux sources ne produit seule.
Combien de temps conservez-vous les journaux ?
Le fichier importé est traité puis n’est pas conservé. Ce qui reste, ce sont les agrégats par URL et par agent, soumis à une rétention documentée. Notre page confidentialité publie les durées telles qu’elles sont écrites dans les commandes de purge, pas telles qu’on aimerait les annoncer.
Qu’est-ce que l’analyse de logs SEO ?
La lecture des journaux d’accès de votre serveur web pour savoir ce que les robots des moteurs de recherche et de l’IA ont réellement demandé, quand, et ce que votre serveur leur a répondu. Un crawl montre ce qui peut être trouvé et Search Console ce que Google choisit de rapporter ; le journal est la seule trace de chaque requête reçue, ce qui en fait la référence pour le budget de crawl, les erreurs d’exploration et la vérification des robots.
Savez-vous distinguer un vrai Googlebot d’un faux ?
Oui. Chaque requête qui se réclame d’un robot connu est confrontée aux plages d’adresses IP que publie son opérateur, et reçoit l’un de trois verdicts : vérifiée, usurpée ou invérifiable. Les requêtes usurpées restent hors de tous les chiffres. Quand la liste publiée d’un opérateur a plus d’une semaine, ses robots sont déclarés invérifiables plutôt que devinés. Le contrôle repose sur les seules plages publiées, sans résolution DNS inverse.
Ce que deviennent vos journaux
Un journal serveur est une donnée personnelle avant d’être une donnée SEO. Le traitement a été écrit dans ce sens dès l’origine : ce n’est pas une option de configuration que quelqu’un pourrait désactiver.
Ce que nous couvrons
- Les formats de journaux courants des serveurs web, lus en flux
- La séparation robots/humains et l’attribution requête par requête
- Le croisement avec le crawl, Search Console et le suivi de positions
Limites assumées
- Aucune adresse IP conservée ni envoyée à un modèle : elle sert au tri, puis elle disparaît
- Aucun temps réel : un journal décrit ce qui a eu lieu, pas ce qui se passe
- Aucune explication : un journal dit qu’une page n’est pas demandée, la cause reste à chercher
- Aucune résolution inverse des adresses, donc aucune vérification d’identité de robot par DNS
Vos journaux, sans dossier de conformité
Aucune adresse IP conservée, aucune donnée envoyée à un modèle : c’est ce qui rend un premier import possible cette semaine plutôt qu’au prochain trimestre.
Les accès s’ouvrent par vagues, nous prévenons par e-mail.