par Un audit SEO technique, c’est le moment où on arrête de croire les tableaux de bord et où on regarde ce qui se passe vraiment sur le serveur. La plupart des audits démarrent par Search Console, un crawler, quelques captures d’écran. Le problème, c’est que ces outils vous montrent une version reconstituée du crawl, pas le crawl lui-même. Les fichiers journaux, eux, enregistrent chaque passage de robot, requête par requête, sans rien filtrer. Commencer par là change l’ordre des priorités.
Ce que les logs serveur racontent et que les outils taisent
Un fichier access.log, sur Apache comme sur Nginx, garde la trace brute de toutes les requêtes reçues par le serveur, robots compris. Pas d’échantillon, pas de projection, pas de moyenne calculée sur un sous-ensemble. Chaque ligne correspond à un appel réel, avec l’adresse IP, la date, l’URL demandée et le code de statut renvoyé.
Pour qui veut comprendre le SEO technique dans le détail, c’est la matière première. Et jbetco.fr en fait un point de départ logique pour tout audit sérieux, notamment quand on veut confronter ce que le serveur enregistre à ce que les outils déclarent.
Search Console agrège et projette. Elle vous donne une tendance du crawl, pas la liste exhaustive des requêtes. Un logiciel de crawl, lui, simule le comportement d’un robot depuis l’extérieur : il ne voit que ce qu’on lui demande de voir, avec les limites qu’on lui a fixées.
Quant à Analytics, il ne connaît des robots que ce que le JavaScript veut bien exécuter, autant dire rien. Trois sources, aucune complète, et c’est précisément ce manque qui rend indispensable l’observation directe du serveur.
Lire un access.log sans se noyer
La première fois qu’on ouvre un access.log, on tombe sur des milliers de lignes qui défilent et on referme le fichier. C’est normal. Ce n’est pas un signe d’incompétence : le fichier brut n’est pas fait pour être lu à l’œil nu.
La méthode consiste à filtrer par user-agent d’abord, puis à vérifier l’identité réelle du robot par ses plages d’IP. Un User-Agent déclaré ne prouve rien, n’importe qui peut l’écrire dans une requête. On croise donc avec les plages officielles publiées par Google avant de compter quoi que ce soit.
Les questions à se poser avant d’ouvrir le fichier
Une analyse fiable demande de la patience : deux à quatre semaines de logs sont un minimum pour distinguer un comportement régulier d’un incident ponctuel. En dessous, vous risquez de prendre une migration ratée pour la norme, et de tirer des conclusions sur un fichier trop court. Voilà ce qu’il faut clarifier avant de parcourir les lignes.
- Quel est le volume quotidien de requêtes servies aux robots, et varie-t-il fortement d’un jour à l’autre ?
- Avez-vous vérifié les plages d’IP, pas seulement le User-Agent déclaré ?
- Est-ce que Googlebot revient sur des pages qui n’ont aucune raison d’être crawlées, comme les paramètres de tri ou les pages de recherche interne ?
- Quels codes de statut reviennent le plus souvent sur les URL demandées par les robots ?
- La période choisie couvre-t-elle au moins un cycle complet de publication ?
Ces réponses tiennent en quelques heures de tri une fois le bon filtre posé. Le reste de l’audit s’appuie dessus, et c’est là que l’ordre des étapes compte. Un crawl lancé avant l’analyse des logs risque de chercher au mauvais endroit pendant des heures, alors qu’un fichier bien filtré oriente immédiatement vers les zones à problème.
Trois constats que seuls les logs permettent de poser
Le premier constat concerne les pages réellement explorées. Un plan de site peut lister des milliers d’URL, ça ne dit rien de celles que le robot visite. Les fichiers journaux, en revanche, le disent. On découvre parfois que des pages stratégiques ne sont jamais demandées, tandis que des archives sans intérêt sont crawlées chaque semaine, ce qui inverse complètement les priorités d’un audit. Sur ce point, voir aussi notre article sur resultats concrets des outils ia.
Le deuxième constat porte sur le budget de crawl gaspillé : combien de requêtes partent vers des redirections en chaîne, des pages en erreur ou des URL à paramètres inutiles. Chaque passage gaspillé ne l’est pas ailleurs.
Le troisième constat concerne les erreurs servies aux robots. Des pages introuvables s’accumulent, des indisponibilités temporaires tombent pile au moment du crawl, des erreurs serveur intermittentes échappent à tout monitoring parce qu’elles ne touchent que certaines requêtes. Search Console finit par en signaler une partie, avec du retard et sans le détail des URL concernées. Le log, lui, donne la ligne exacte, l’horodatage et l’adresse IP à l’origine de la requête.
Replacer les fondations du SEO dans le bon ordre
On résume souvent le référencement naturel en quatre familles : la technique, le contenu, la popularité et l’expérience utilisateur. L’analyse de logs appartient clairement à la première, et c’est aussi celle qui conditionne les trois autres. Un contenu excellent sur une page jamais crawlée ne sert à rien, une bonne popularité qui pointe vers des redirections en chaîne non plus. La technique est le sol qui porte le reste, pas un préalable parmi d’autres.
Dans cette logique, l’audit commence par les logs parce qu’ils disent ce que le serveur a réellement servi aux robots, avant toute interprétation. Les outils viennent ensuite, pour confirmer, croiser, mesurer l’évolution. Franchement, l’ordre inverse donne l’illusion du travail bien fait : on produit un rapport propre, on coche des cases, et on passe à côté du vrai problème, celui qui se trouve dans un fichier texte que personne n’a ouvert.
Il y a une nuance à assumer, cela dit. Lire des logs demande un accès serveur, un peu de ligne de commande et de la patience pour trier des fichiers parfois volumineux. Tout le monde n’a pas ça sous la main, et un audit qui démarre par Search Console reste mieux que pas d’audit du tout. Simplement, il ne répondra qu’à moitié à la question de départ : ce que les robots voient vraiment.
Reste un point que beaucoup découvrent en cours de route : les logs ne mentent pas, mais ils ne racontent pas non plus toute l’histoire. Ils montrent ce qui a été demandé et ce qui a été renvoyé, pas ce que le robot a compris de la page. Un contenu rendu en JavaScript peut très bien apparaître dans le log comme exploré, sans que son texte soit jamais indexé. Le croisement avec les autres sources reprend son sens.
Un point de départ, pas une fin en soi
Commencer par les logs, c’est accepter de regarder les données brutes avant les synthèses. On y gagne une vision exacte du crawl, des erreurs réellement servies et du budget gaspillé, sans les arrondis d’un outil qui résume. Le reste de l’audit devient plus court, parce qu’on sait déjà où chercher. La question qui reste ouverte est simple : votre prochain audit, vous le commencez par le fichier ou par le tableau de bord ?
