Retour d’expérience sur l’analyse de logs par Quentin Adt

L’analyse des logs est un sujet que je trouve particulièrement intéressant. C’était quelque chose de très confidentiel il y a quelques années et qui se démocratise de plus en plus grâce notamment à de nouveaux outils. Début novembre j’ai donc eu envie de rédiger un article sur la manière de débuter une analyse de logs.  Suite à cet article je suis entré en contact avec Quentin Adt de la société Kelogs à qui j’ai proposé de répondre à une série de questions pratiques sur l’analyse de logs. Voici ses réponses :

Peux-tu nous expliquer ton parcours et présenter votre solution ?

Je suis consultant SEO depuis 2009, j’ai travaillé chez l’annonceur (Liligo.com), puis en agence (RESONEO) et en freelance.

J’ai mis les mains dans les logs pour des sites à gros volume de pages, à une époque où il n’existait pas encore de solution simple pour faire parler les logs. Il fallait donc systématiquement créer des scripts, ce qui prenait un temps important.

Ensuite sont arrivés quelques solutions open source intéressantes, dont ELK (Elasticsearch, Logstash, Kibana). C’est une solution intéressante, mais qui a ses limites : la configuration est réservée à une certaine élite, et les fonctionnalités sont limitées à celles proposées par Kibana.

Paul et moi avons fait tester ELK et une première version de Kelogs à un panel d’utilisateurs pour comprendre les forces et faiblesses de ces deux produits : il en ressortait qu’ELK restait complexe à administrer, et très gourmand en ressources, aussi bien coté serveur (64 Mo de RAM minimum pour un site d’1 million de page) que coté utilisateur (Kibana a tendance à surcharger le navigateur du client).

Nous avons donc fait le choix de concentrer les développements sur Kelogs, une solution réellement dédiée au SEO, qui est plus rapide et plus simple à utiliser qu’ELK.

A qui conseilles-tu de mener une analyse de log ?

L’analyse de logs dans l’optique de travailler le référencement s’adresse en priorité aux SEO qui travaillent sur des sites ayant un gros volume de pages.

Les boutiques en ligne, les sites de presse et d’annonces (immobilier, automobile, location de biens…) ont généralement un volume de pages important. Certains sites ont la particularité d’avoir un inventaire de produit qui change très souvent, avec d’importantes conséquences sur le crawl de Googlebot.

Nous avons des clients qui ont plusieurs millions de pages à analyser tous les jours. Dans ces conditions, il est très difficile de réaliser un crawl complet du site  rapidement, quelque soit l’outil utilisé, car le serveur d’hébergement atteint vite ses limites.

Admettons un site de 3 millions de page, qui devrait être crawlé en 24h:

• 3 000 000 d’URLs / 24 heures = 125 000 URLs par heures
• 125 000 URLs / 60 minutes = 2 083 URLs à la minutes
• 2 083  / 60 secondes = 35 URLs par secondes.

Vous pouvez demander à votre admin système ce qu’il en pense, je ne suis pas certain qu’il apprécie que vous crawliez son site à cette vitesse…

L’analyse de logs apparait donc comme une évidence pour optimiser le SEO des sites à gros volume de pages.

A quelle fréquence conseilles-tu de réaliser ces analyses ?

Il y a généralement deux étapes :

+ Une phase d’audit, durant laquelle de nombreux points sont examinés. C’est lors de cette étape que l’on identifie par exemple les principales catégories du site qui doivent être optimisées en priorité. C’est aussi à ce moment que l’on prend conscience qu’il y a beaucoup plus d’erreurs que ce que la Search Console de Google (anciennement Google Webmaster Tools) veut bien remonter.

+ Puis une analyse continue : Nous recommandons de mettre en place une analyse journalière. Les logs sont envoyés ou reçus dans la nuit, et nous les traitons tôt dans la matinée. Nos clients ont immédiatement accès aux statistiques de la veille. Cela permet d’identifier très rapidement des erreurs dont les conséquences peuvent être désastreuses si elles ne sont pas corrigées rapidement. Une analyse programmée quotidiennement permet aussi de faire très vite de point sur l’impact d’une mise à jour Google, ou sur la mise en production de modifications sur le site.

Quelle est la première chose que tu regardes après avoir lancé une analyse ?

Je vérifie la fiabilité de la donnée 🙂

Il faut que les chiffres soient cohérents, ou tout au moins que les tendances observées dans Google Analytics correspondent avec ce que disent les logs. Il arrive par exemple qu’un serveur frontal ne soit pas comptabilisé. Il peut aussi arrivé que nous constations une différence de trafic car les pages répondent par un code 200, mais sans afficher de contenu…

Quand tout est ok, je vérifie en priorité le classement des catégories par taux de pages crawlées VS pages active (pages ayant généré au moins une visite). Cela permet de voir rapidement quelles sont les catégories du site qui « travaillent » le plus coté Googlebot, et quelles sont celles qui génèrent le plus de trafic entrant depuis Google. Une catégorie qui génère peu de trafic mais qui est très consommatrice de crawl est ainsi très vite identifiée, et des actions peuvent être mise en place pour par exemple augmenter le trafic ou réorienter le budget de crawl consommé sur des catégories de pages plus stratégiques.

Peux-tu nous raconter un exemple insolite de soucis qui a été détecté par une analyse de logs ?

L’exemple mentionné ci-dessus au sujet de l’absence de code erreur alors que la page répond en 200 est assez inattendu.

C’est un cas très intéressant : Mysql et PHP sont indépendants : l’un ne communiquait pas à l’autre qu’il fallait retourner un code erreur dans le header HTTP. Le message affiché était : « User xxx already has more than ‘max_user_connections’ active connections. », bien que la page répondait avec un code 200…

Que tout le monde se rassure : il est techniquement possible de forcer l’envoi d’un code erreur dans le header HTTP quand Mysql dépasse le nombre de connexion.

Quelles compétences faut-il pour analyser ses logs ? Est-ce à la portée de tous les webmasters ?

Tout dépend du logiciel utilisé…

Utiliser des outils en ligne de commande requière des compétences techniques spécifiques. Il existe bien des tutoriaux pour débuter en analyse de logs avec Grep, Awk, Cut, etc. mais dès que l’on veut travailler sur des sites à gros volume de pages et de façon professionnelle, ces outils atteignent vite leur limite.

L’analyse des logs sur un outil comme Kelogs est à la portée de tous les webmasters, consultants SEO, référenceurs inhouse et même responsable webmarketing. Toute la partie technique est traitée de notre coté, il suffit ensuite de lire les graphiques ou parcourir les logs dans le détail pour faire de l’audit très fin.

Peux-tu nous citer un exemple de site (sans forcément citer le nom du site) qui a fortement progressé en SEO suite aux optimisations menées ?

Un pure player de la presse en ligne, qui avait un « spider trap » qui n’était pas identifié par lors de crawls, mais dans lequel Googlebot s’était empêtré.

50 % de plus de trafic SEO en 3 mois en corrigeant cette faille qui trainait depuis des années, et qui est certainement encore présent dans de nombreuses installations de Drupal…

En 2016 si on n’a jamais fait d’analyse de logs sur son site, est ce qu’on a raté sa vie ? 😉

Si en 2016 on n’a pas encore fait d’analyse de logs, il reste encore un bon moyen de réussir sa vie 🙂

Merci Quentin pour tes réponses, vous savez ce qu’il vous reste à faire pour réussir votre année 2016 😉

Crédits photo : Horia Varlan