Les fichiers de log sont une mine d’informations pour vous aider à améliorer votre stratégie SEO. Mais pour que leur contenu soit explicite, il est important que les données qu’ils contiennent soient correctes et complètes. Et ce n’est pas toujours aussi évident que nous pouvons le penser !

Dans cet article, je vais détailler quelques erreurs typiques dues à une configuration souvent standard et incomplète de l’écriture des logs.

HTTP vs. HTTPS

Depuis que Google a enchaîné les annonces relatives au HTTPS courant 2018, la migration du protocole HTTP vers le HTTPS est devenue un chantier prioritaire pour un grand nombre d’experts SEO. Pour ce type d’opération, les fichiers de logs sont un outil à privilégier pour s’assurer que la migration se déroule sans encombre.

Tout d’abord, je vous conseille de mettre en place une implémentation de vos logs solide, couplée à une segmentation adaptée dans un crawler SEO comme OnCrawl. Cela vous permettra de suivre l’évolution de la prise en compte de vos redirections et du transfert progressif du crawl budget d’un protocole à l’autre.

Mais dans la plupart des cas, le format d’origine des logs ne permet pas de faire la distinction entre le protocole HTTP et le HTTPS. Pourquoi ? À cause de l’absence d’un élément permettant d’identifier explicitement le protocole ciblé.
Concrètement, cet élément peut être le port (80 pour le HTTP, 443 pour le HTTPS), le scheme (HTTP ou HTTPS) ou même le protocole SSL/TLS (ex. TLSv1.2).

L’un des impacts notables serait de voir deux status codes différents pour une même URL. Lors d’une visite SEO (ou d’un passage de bot) sur une page en HTTP (http://www.site.com/a.html) proprement redirigée en 301 vers son équivalent HTTPS (ici https://www.site.com/a.html), vous retrouveriez deux entrées pour /a.html : la première en 301 et la seconde avec le status code final.

En amont d’un chantier comme une migration HTTPS, pensez donc à vous assurer que vos fichiers de log contiennent bien toutes les informations requises pour assurer le monitoring nécessaire.

Le port

Dans certains cas, le port est bien présent dans les logs que vous consultez. Toutefois, il n’est pas certain qu’il s’agisse du bon port.

Par exemple, dans les options de formats de logs pour les serveurs Apache, le port peut être décliné de 3 manières – Canonical, Local ou Remote – pouvant parfois amener des résultats différents.

Dans d’autres cas, il n’est pas impossible que les seuls logs disponibles soient ceux d’une couche interne de votre infrastructure qui ne fait que des échanges non-sécurisés avec les autres couches. Il sera donc préférable de veiller à ce que le port renvoyé corresponde bien à celui utilisé par les visiteurs.

L’adresse IP

Dans la même logique que le port, l’adresse IP écrite dans vos logs peut-être fausse. Où du moins différente de celle attendue.
Selon le principe d’infrastructure en strates comme vue précédemment, l’adresse IP remontée dans vos logs pourrait être, par exemple, celle du serveur de cache qui appelle la page/ressource ciblée au lieu de celle de l’utilisateur qui est à l’origine de cette requête.

Or, l’adresse IP peut être leur seul élément permettant de dissocier le crawl des “vrais” Googlebots de celui de vos concurrents ou autres outils qui parcourent votre site en falsifiant leur User-Agent. Il semble donc pertinent pour votre stratégie SEO de vous assurer que vous travaillez avec la bonne information.

Le host (ou vhost)

Certains serveurs hébergent plusieurs sites en même temps. Dans beaucoup de configurations, chaque site/host/vhost dispose de ses propres fichiers de logs.
Ces fichiers sont généralement identifiables via leur nom (contenant le vhost) ou le nom du répertoire dans lequel ils sont stockés.

Toutefois, il arrive que la configuration du serveur amène l’écriture des logs de différents sites dans un fichier commun.
Dans ce cas, il est important, voire impératif, qu’un champ permettant d’identifier le site concerné soit présent sur chaque ligne de log. Sans cela, impossible d’attribuer l’activité remontée dans les logs à un site précis. L’alternative serait, par exemple, de renseigner l’URL absolue en guise de Path (champ indiquant l’URL appelée) par opposition à l’URL relative qui est généralement retrouvée.
Cela offrirait également une bonne alternative à la présence du port ou de tout autre champ permettant l’identification du protocole.

L’heure du serveur

Assurez-vous que l’heure de votre serveur est correcte et respecte bien le fuseau horaire local.
En général, chaque ligne de logs contient la date et l’heure, facilitant très logiquement la localisation dans le temps d’un événement donné.

Mais il arrive que l’heure inscrite dans les logs soit en décalage (plus ou moins léger) avec celle à laquelle l’événement a eu lieu.

Cela peut sembler anecdotique, mais lorsque vous tenter d’identifier le moment et la cause d’un pic d’erreurs par exemple, il est préférable de pouvoir s’arrêter rapidement et facilement sur les lignes pertinentes.

N’oubliez donc pas de vérifier ce point de configuration avec votre hébergeur.

Conclusion

Gardez en tête qu’il est rare que les fichiers de logs soient parfaitement paramétrés sans votre intervention.
Toute modification des règles d’écriture de vos logs ne sera pas rétroactive. Par conséquent, plus tôt vous optimisez leur format, plus tôt vos analyses de logs seront efficaces et utiles pour piloter votre stratégie SEO.