Comment analyser les logs serveur d'un WordPress ?

Les rapports d'exploration des outils pour webmasters donnent une vue agrégée et différée de ce que fait le moteur sur un site. Les journaux du serveur, eux, contiennent chaque requête, avec son horodatage, son adresse, son code de réponse et son temps de traitement. C'est la seule source qui dise exactement ce qui s'est passé, sans échantillonnage ni délai. Sur un site WordPress, l'analyse des logs serveur révèle en une heure des choses qu'aucun autre outil ne montre : les sections que le moteur ignore, celles qu'il explore inutilement, les erreurs qu'il rencontre et les pages qu'il ne revoit jamais. Encore faut il savoir où les trouver et quoi en extraire.

Ce que contiennent les journaux

Avant d'analyser quoi que ce soit, il faut savoir quelles données sont disponibles et lesquelles manquent, ce qui dépend entièrement de la configuration du serveur. La démarche générale est présentée dans notre article sur l'analyse de logs en SEO.

Une ligne par requête

Chaque requête reçue par le serveur produit une ligne comportant l'adresse d'origine, la date et l'heure, la méthode, le chemin demandé, le code de réponse, la taille de la réponse, le référent et l'identification du client. Ces champs suffisent à répondre à la quasi totalité des questions que l'on se pose sur l'exploration. Le format exact varie selon le serveur mais l'information est la même, et il vaut mieux vérifier ce format avant d'écrire le moindre traitement. Un format personnalisé, plus riche, se déclare en une ligne et évite de regretter plus tard l'absence d'un champ.

Le temps de traitement

Le temps mis par le serveur à produire chaque réponse n'est pas enregistré par défaut sur la plupart des configurations, et c'est pourtant l'information la plus précieuse. L'ajouter au format d'enregistrement demande une ligne de configuration et un rechargement du service. Une fois disponible, il permet de savoir quelles pages coûtent cher, de croiser cette information avec l'exploration et d'identifier ce qui ralentit le site sous la charge des robots. C'est également la seule mesure qui reflète le coût réel de génération, indépendamment de tout cache placé devant le site.

Ce qui n'y figure pas

Les journaux ne contiennent pas ce qui s'est passé côté navigateur, ni les requêtes servies depuis un cache placé devant le serveur, ni celles interceptées par un réseau de diffusion de contenus. Sur une architecture comportant un service en périphérie, ce sont les journaux de ce service qu'il faut récupérer, faute de quoi l'analyse portera sur une fraction du trafic. Ce point doit être vérifié avant toute conclusion, sous peine de raisonnements entièrement faux. Une requête servie par un cache en périphérie n'atteint jamais le serveur d'origine et reste donc invisible dans ses journaux.

Où les trouver

Sur un serveur dont on dispose, les journaux vivent dans un répertoire système et sont archivés quotidiennement. Sur un hébergement mutualisé, ils sont généralement accessibles depuis l'interface d'administration, parfois avec une conservation limitée à quelques jours seulement. Cette limitation est le premier obstacle rencontré, et elle justifie de récupérer les fichiers régulièrement plutôt que d'aller les chercher le jour où l'on en a besoin. Une récupération automatique quotidienne vers un espace de stockage règle définitivement la question.

La durée de conservation

Une analyse utile suppose au moins un mois de données, idéalement trois. La rotation par défaut conserve souvent quatorze jours, ce qui est court pour observer des cycles d'exploration. Augmenter cette durée demande une modification de la configuration de rotation et un peu d'espace disque, deux choses négligeables au regard de l'information conservée. Ces fichiers se compressent d'ailleurs remarquablement bien. Un mois de journaux d'un site de taille moyenne tient dans quelques dizaines de mégaoctets une fois compressé.

La question des données personnelles

Les adresses réseau enregistrées constituent des données personnelles, ce qui impose une durée de conservation définie et une finalité déclarée. Une conservation de six à douze mois pour un usage de sécurité et d'analyse technique est une pratique courante, à condition d'être documentée. Sur les analyses portant uniquement sur les robots, l'anonymisation partielle des adresses ne gêne en rien et simplifie la question. La vérification d'identité des robots doit toutefois se faire avant l'anonymisation, puisqu'elle en dépend.

Extraire et préparer les données

Le traitement se fait avec des outils en ligne de commande pour le premier tri, puis dans un tableur ou une base pour l'analyse. Aucun outil commercial n'est nécessaire sur un site de taille moyenne, et les solutions dédiées ne se justifient qu'au delà de plusieurs millions de lignes par jour.

Isoler les requêtes de robots

Le champ d'identification du client permet de filtrer les requêtes des principaux moteurs. C'est le premier tri à effectuer, et il réduit généralement le volume de données de façon considérable. Il faut cependant garder à l'esprit que ce champ est déclaratif et peut être falsifié, ce qui rend une vérification nécessaire dès que l'analyse porte sur des décisions importantes. Sur une analyse exploratoire, ce filtre déclaratif suffit largement à dégager les tendances.

Vérifier l'identité des robots

La vérification consiste à effectuer une résolution inverse de l'adresse d'origine puis une résolution directe du nom obtenu, et à contrôler que l'on retombe sur la même adresse. Les moteurs documentent cette procédure et publient également des listes d'adresses. Sur un site de taille moyenne, une part appréciable des requêtes se déclarant comme un robot connu n'en est pas une, et les compter fausse toutes les statistiques. Le volume de ces fausses déclarations est souvent supérieur à celui du robot légitime, ce qui suffit à inverser certaines conclusions.

Normaliser les adresses

Les chemins demandés doivent être normalisés avant tout regroupement : suppression des paramètres de suivi, harmonisation de la barre oblique finale, décodage des caractères. Sans cette normalisation, une même page apparaît sous cinq formes différentes et les comptages n'ont plus aucun sens. Cette étape prend quelques lignes de traitement et conditionne la fiabilité de tout ce qui suit. Il faut en revanche conserver les paramètres significatifs, ceux qui produisent une page réellement différente.

Classer par section

Rattacher chaque adresse à une section du site, articles, pages, catégories, étiquettes, fichiers, administration, permet de raisonner par famille plutôt que page par page. Ce classement se fait à partir de la structure des adresses et tient en une série de règles simples. C'est lui qui rend l'analyse lisible, un tableau de dix lignes par section étant infiniment plus parlant qu'une liste de dix mille adresses. Les règles de classement doivent être écrites dans un fichier de configuration, afin de rester ajustables sans reprendre le traitement.

Croiser avec la liste des pages réelles

La liste des adresses réellement publiées, obtenue par une exploration du site ou depuis la base, permet de distinguer trois populations : les pages explorées et publiées, les pages publiées et jamais explorées, et les adresses explorées qui n'existent pas. Ces trois ensembles appellent des actions totalement différentes, et leur séparation est le véritable apport de l'analyse. Aucun autre outil ne produit cette distinction, qui suppose de disposer simultanément de l'exploration réelle et de l'inventaire des contenus.

Compter ce qui compte

Quatre indicateurs suffisent : le nombre de requêtes par section, la répartition des codes de réponse, le délai moyen entre deux visites d'une même page, et le temps de traitement moyen par section. Ces quatre chiffres tiennent sur une page et racontent l'essentiel. Y ajouter des dizaines d'autres mesures produit un rapport que personne ne lit, travers classique de ce genre d'exercice. Un rapport d'une page, lu et suivi d'effet, vaut infiniment mieux qu'un tableau de bord complet que personne n'ouvre.

Ce que l'on y lit vraiment

Voici les constats qui reviennent le plus souvent, et ce qu'ils signifient. Aucun ne se lit dans un autre outil avec cette précision ni avec cette fraîcheur.

La répartition du budget d'exploration

Le premier chiffre à regarder est la part des requêtes consacrée à chaque section. Sur un site WordPress mal configuré, les archives d'étiquettes, les pages de date et les résultats de recherche interne consomment souvent la moitié des requêtes, au détriment des articles. Ce constat, immédiat, justifie à lui seul l'exercice, et sa correction produit un effet mesurable sur la vitesse de découverte des contenus nouveaux. Le calcul se fait en une opération de regroupement et donne un résultat que tout le monde comprend immédiatement, y compris hors de l'équipe technique.

Les adresses qui n'existent pas

Un volume important de requêtes aboutissant à une erreur signale des liens internes cassés, des adresses laissées après une refonte ou une exploration de combinaisons générées par une extension. Distinguer ces cas se fait en regardant le référent lorsqu'il est présent. Les erreurs provenant de liens internes sont prioritaires, celles provenant de l'extérieur relèvent de la redirection, et celles générées par des robots malveillants s'ignorent. Un pic soudain d'erreurs sur des chemins improbables signale généralement une exploration automatisée à la recherche de vulnérabilités connues.

Les pages jamais visitées par le moteur

Une page publiée que le robot n'a jamais demandée ne peut pas être indexée. La cause est presque toujours un défaut de maillage : la page n'est liée depuis nulle part, ou seulement depuis une page elle même peu explorée. C'est le constat le plus actionnable de toute l'analyse, puisque sa correction ne demande que d'ajouter quelques liens depuis des pages que le moteur visite régulièrement. Encore faut il disposer de la liste complète des contenus publiés, ce que la base fournit en une requête.

Le rythme de revisite

Le délai entre deux visites d'une même page indique la priorité que le moteur lui accorde. Un article revisité chaque jour est considéré comme important, un article revu tous les trois mois ne l'est pas. Comparer ce délai entre sections révèle immédiatement quelles parties du site le moteur juge dignes d'intérêt, information qu'aucun autre outil ne fournit et qui oriente utilement les décisions éditoriales. Un contenu important dont le rythme de revisite s'allonge mérite une mise à jour et un renforcement de son maillage.

Les combinaisons de paramètres

Les adresses comportant des paramètres de tri ou de filtrage apparaissent en volume dans les journaux, alors qu'elles sont invisibles ailleurs. Leur part dans le total permet de décider s'il faut intervenir, et de mesurer l'effet de l'intervention ensuite. Les journaux sont d'ailleurs le seul endroit où l'on voit ces adresses, aucun rapport ni aucune interface d'administration ne les listant. Ce point est développé dans notre article sur les combinaisons de facettes à laisser explorer.

La charge produite par l'exploration

Le croisement du nombre de requêtes et du temps de traitement donne la charge réelle imposée par les robots. Sur certains sites, elle dépasse celle des visiteurs humains, ce qui explique des ralentissements inexpliqués à certaines heures. Ce constat oriente vers deux réponses complémentaires : réduire le nombre d'adresses inutiles à explorer, et diminuer le coût de génération des gabarits les plus sollicités. La limitation du rythme d'exploration proposée par certains outils est une solution de dernier recours, qui traite le symptôme sans corriger la cause.

Agir et suivre

Une analyse qui ne débouche sur aucune décision est un exercice stérile. Voici les actions qui découlent directement des constats les plus fréquents, classées par rapport entre effort et résultat.

Réduire l'exploration inutile

Le blocage des sections sans valeur, la suppression des liens vers celles ci et le nettoyage des archives inutilisées réduisent immédiatement le volume de requêtes parasites. L'effet se mesure dans les journaux des jours suivants, ce qui permet de valider l'intervention plutôt que de l'espérer. C'est l'un des rares chantiers de référencement technique dont le résultat se constate en moins d'une semaine. Cette rapidité de retour en fait un excellent point de départ pour engager une démarche plus large.

Renforcer le maillage vers les oubliées

Les pages jamais explorées doivent recevoir des liens depuis des pages que le moteur visite souvent, généralement l'accueil, les catégories principales ou les articles récents. Un bloc de contenus liés, correctement alimenté, règle une bonne partie du problème. Il faut ensuite vérifier dans les journaux, quelques semaines plus tard, que ces pages sont effectivement visitées, seul contrôle qui vaille. Un délai de trois à six semaines est normal avant de constater le changement, selon le rythme d'exploration général du site.

Corriger les erreurs internes

Les liens internes menant à une erreur se corrigent à la source, dans le contenu ou dans le gabarit, plutôt que par une redirection. La redirection est la bonne réponse pour les liens externes que l'on ne maîtrise pas, elle est un pansement pour les liens internes que l'on pourrait simplement corriger. Cette distinction évite d'accumuler des règles de redirection dont plus personne ne connaîtra l'origine. Un lien interne cassé signale par ailleurs souvent un problème plus large, comme une génération d'adresse défectueuse dans un gabarit.

Alléger les gabarits coûteux

Les sections dont le temps de traitement est élevé méritent une optimisation, d'autant plus qu'elles sont explorées en volume. Le gain profite à la fois aux robots et aux visiteurs. Il faut cependant vérifier que la lenteur constatée vient bien du gabarit et non d'un appel externe déclenché par une extension. Cette démarche rejoint la supervision courante d'un site, décrite dans notre article sur la manière de surveiller un WordPress en production.

Automatiser l'extraction

Un script hebdomadaire produisant les quatre indicateurs et les écrivant dans un fichier historique transforme un exercice ponctuel en suivi. La valeur apparaît au bout de quelques mois, quand la comparaison dans le temps devient possible et qu'une dérive se repère avant d'avoir des conséquences. Ce script tient en quelques dizaines de lignes et ne demande aucun outil particulier. Il doit écrire ses résultats dans un format simple, une ligne par semaine et par indicateur, directement exploitable dans un tableur.

Refaire l'analyse après chaque changement

Une refonte, une migration, un changement de structure d'adresses ou l'ajout d'une extension modifient l'exploration, parfois radicalement. Relire les journaux dans les semaines qui suivent permet de détecter immédiatement une régression, là où les rapports agrégés mettront plusieurs semaines à la révéler. C'est particulièrement vrai après une migration, moment où les journaux constituent le meilleur outil de contrôle disponible. Ils permettent notamment de vérifier que les anciennes adresses répondent bien en redirection et que les nouvelles sont effectivement explorées, deux points qu'aucun autre outil ne montre aussi tôt. Ils permettent enfin de dater précisément le moment où un problème est apparu, information que les rapports agrégés lissent systématiquement et sans laquelle le rapprochement avec une mise en production reste impossible.