Analyse de logs : RESONEO lève le voile avec 4 études de cas

Par  le 28 février 2017 - 16:53 dans

A quelle fréquence Googlebot vient-il visiter les pages d’un site ? Sur quelles pages revient-il le plus souvent ? Quels codes de statut HTTP lui sont renvoyés ? Quelles sont les pages orphelines ? Quelles sont les pages actives ? Quels sont les bots les plus les plus friands d’un site ? Est-ce que mon budget de crawl est optimisé ? Voici le type de questions auxquelles les logs serveur peuvent répondre. Retour sur quelques exemples de réussites SEO liées à l’analyse de logs.

analyse log

Par définition, un fichier de logs est un journal recensant tous les évènements produits sur un serveur web. Il contient l’ensemble des hits effectués sur un serveur. Selon son paramétrage, il peut contenir : hostname, URL appelée, timestamp, referrer, code reponse, user-agent, etc.

Mais d’où viennent ces pages crawlées ?

Au cours de l’audit d’un de nos clients – un retailer leader dans le secteur du meuble – nous avons identifié un crawl erratique de Google depuis la Search Console. Se posait alors la question de savoir quelle en était l’origine et quelles étaient les URL concernées par ce crawl en dents de scie.

Le rapport d’activité de Googlebot sur les 90 derniers jours est très pratique pour avoir une idée générale du volume journalier de pages explorées par le robot, mais reste trop léger pour avoir plus de détail quant aux pages et types de contenus concernés.

Google Search Console indique une fréquence de crawl par GoogleBot qui est « en dents de scie »

Google Search Console indique une fréquence de crawl par GoogleBot qui est « en dents de scie »

Il a donc été nécessaire de se plonger dans les logs pour mieux comprendre ce qu’il se passait afin d’en tirer des conclusions.

Les premières étapes ont surtout permis d’écarter certaines hypothèses comme le fait que Google soit régulièrement confronté à des redirections internes, ce qui est souvent le cas pour un site marchand.

Le % de pages en 200 étant important, ce n'était pas à ce niveau que se situait le problème

Le % de pages en 200 étant important, ce n’était pas à ce niveau que se situait le problème

C’est le découpage par type de pages qui nous a permis de découvrir que GoogleBot crawlait de façon abusive un type de pages qui était notamment concerné par l’utilisation d’un moteur à facettes. Cela s’apparentait à un spider trap, puisque rien n’avait été mis en place jusqu’ici pour contrôler leur accès à Google. Les robots avaient accès à toutes les combinaisons possibles. Le graphique montrant les pages concernées en bleu est assez révélateur.

La courbe bleu montre la fréquence de hits Googlebot sur un type de page bien précis

La courbe bleue montre la fréquence de hits Googlebot sur un type de page bien précis

Ces pages représentant un pourcentage marginal du trafic SEO, il a donc été décidé de bloquer radicalement le crawl de ces pages, pour que Google puisse se concentrer sur les pages plus stratégiques.

Une fois la consigne Disallow mise en place dans le fichier robots.txt, le crawl de Google est redevenu bien plus stable.

Un retour à la normale constaté 6 mois après

Un retour à la normale constaté 6 mois après

Cela a eu pour conséquence directe une amélioration de la rapidité d’indexation des nouvelles pages mises en ligne ainsi qu’une amélioration des positions et du trafic lié au référencement naturel.

semrush seo

+ 7 615 kw gagnés sur 4 mois et accroissement (+ 3 914 kw) du nombre de requêtes en positions 4 à 10.

A la découverte d’un monde parallèle

Nous avons entrepris une analyse des logs serveur sur un site de biographies composé d’environ 40 000 URL. Nous cherchions à identifier les causes d’une baisse de positions suite au lancement d’une nouvelle version du site.

Une analyse croisée d’un crawl du site avec les logs a permis de valider que Google parcourait le site dans sa quasi intégralité.

Une simulation de crawl VS l'analyse des pages crawlées par Googlebot

Une simulation de crawl VS l’analyse des pages crawlées par Googlebot

En s’attardant sur les pages actives – c’est à dire les pages ayant obtenu au moins une visite depuis les résultats organiques – nous avons constaté que 64 % des pages de niveau 2 n’étaient pas actives.

logs pages actives

L’analyse des pages actives pour détecter les pages avec peu de valeur SEO

Dans le cas présent, ces URL inactives correspondaient à une mauvaise gestion de leur fonctionnement. Certaines pages dupliquées jusqu’à 8 fois étaient la cause de la perte de position du site dans les résultats naturels.

Les pages concernées par de la duplication de contenu étaient principalement :

  • Anciennes URL, liées à l’ancienne version du site, qui répondaient toujours en 200
  • Mauvaise gestion de la réécriture d’URL
  • Dossier /en/ avec contenu en français
  • Biographies en doublons (inversion nom prénom)

L’étude des logs a donc permis de lever le voile sur l’ensemble des sources de duplication de page et ainsi endiguer rapidement le problème.

Quand Googlebot s’acharne sur une seule page

Sur un site d’événement caritatif, nous avons constaté que le nombre de pages explorées chaque jour était extrêmement élevé, comparativement au volume de page total indexées (environ 4 690 résultats). Nous avons analysé le détail des URL crawlées afin de détecter une éventuelle fuite de crawl (exemple : spider-trap, chaine de paramètres, etc).

Un nombre astronomique de pages vues par Google quotidiennement !

Un nombre astronomique de pages vues par Google quotidiennement !

En isolant les URL les plus visitées par Google, nous avons eu la surprise de découvrir qu’une seule page captait plus de 92% du crawl de Googlebot ! Ce comportement posait plusieurs problématiques :

  • Des nouveaux contenus indexés plus lentement
  • Des pages pertinentes moins fraîches dans l’index
  • Une prise en compte plus lente du maillage interne
  • Une limite des performances serveur : plus de 1.200.000 requêtes en provenance de Googlebot sur une même journée !
Le temps consacré à cette URL empêche les autres URL d’être crawlées régulièrement, ce qui peut nuire à un positionnement optimal

Le temps consacré à cette URL empêche les autres URL d’être crawlées régulièrement, ce qui peut nuire à un positionnement optimal

Dans la réalité, cette URL était crawlée avec une chaine de paramètres prenant cette forme :

  • /services-masque?filter_%5B176%5D=176&filter_%5B113%5D=113&form_id=specifics_map_form
  • /services-masque?filter_%5B176%5D=176&filter_%5B113%5D=113&form_build_id=form-WpxZ9kZ1We7mn3jL9UojSbcOsYCh2CFEfWVqutYH4Ho&form_id=specifics_map_form

Ce qui correspondait aux valeurs d’un formulaire envoyé en GET accessible à Googlebot :

Googlebot visite ces URL via le système de filtre de la page

Googlebot visite ces URL via le système de filtre de la page

Nous avons donc recommandé de bloquer l’accès à Googlebot aux paramètres via la consigne suivante dans le fichier robots.txt :

Disallow: /services-masque
Allow: /services-masque$

Quelques mois plus tard, suite à la mise en place de cette recommandations, nous avons constaté un retour à la normale du crawl de Google, une nette amélioration des performances en termes de temps de chargement et une hausse globale des performances SEO.

Un retour à la normale constaté rapidement

Un retour à la normale constaté rapidement

 

Les bots, des consommateurs de ressources serveur

Si tous les documents utiles doivent être parcourus pour pouvoir être présentés aux internautes, attention à la gourmandise parfois excessive de certains crawlers.

bot crawler

Il existe des centaines de bots, certains peuvent être très gourmands en ressources

Leur consommation de votre site peut directement impacter les performances techniques de celui-ci puisqu’ils sollicitent vos serveurs (de plus en plus) à la manière des internautes. Il n’est pas rare de constater que la majorité du trafic d’un site est en réalité composée de robots dont l’action n’est aucunement positive ! Une étude menée par Imperva Incapsula en 2015 indiquait que les « mauvais bots » représentaient cette année là 29% du trafic des sites, contre 19,5% pour les « bons bots ».

La progression entre 2012 et 2015 des types de visiteurs (humains ou robots)

La progression entre 2012 et 2015 des types de visiteurs (humains ou robots)

Plutôt que de gaspiller des ressources serveur, coûteuses, des techniques peuvent être mises en place pour endiguer cette perte.

Au-delà du coût important que peut engendrer une sur-sollicitation de vos serveurs par des robots mal orientés, n’oublions pas que l’utilisateur final doit avoir accès à vos pages le plus rapidement possible. La bande passante de votre site doit être préservée pour un public qui vous est utile : internautes et robots bienveillants parcourant des pages à potentiel.

Lors de l’analyse des logs du site geneanet.org nous avons pu mettre en exergue que l’utilisation de techniques load balancing générait une dilution majeure du crawl de Google. Bien que les sous-domaine utilisés étaient redirigés en 301, Google les crawlait de façon assez agressive.

 la série de sous-domaines gw0, gw1, etc… utilisée pour faire du Load Balancing entrainait de la duplication de contenu

La série de sous-domaines gw0, gw1, etc… utilisée pour faire du Load Balancing entrainait une dilution du budget de crawl à la défaveur du www

Les logs peuvent en dire long sur la façon dont les moteurs et les internautes perçoivent votre site. L’analyse de logs constitue un complément essentiel aux études de structure et d’analyse d’audience. Sans les logs impossible par exemple de connaitre le nombre de hits sur les fichiers media (images, PDF, JS, CSS…) ou sur certaines pages d’erreur serveur généralement non trackées par les outils de mesure d’audience…

Si vous avez un projet d’analyse de logs, ou constatez des anomalies dans les rapports de crawl de la Search Console n’hésitez pas à nous solliciter !

Et vous, avez-vous déjà observé des choses insolites en décortiquant les hits de Googlebot ?

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someone
Partagez cet article!
Ajouter le votre
14 commentaires
François-Olivier 01 mars 2017 - 9:57 - Répondre

Bonjour,

« Une analyse croisée d’un crawl du site avec les logs a permis de valider que Google parcourait le site dans sa quasi intégralité. »
Sur une période de combien de temps et choisie selon quelle méthode ?

Merci

Sébastien Bulté 01 mars 2017 - 10:27 - Répondre

Salut François-Olivier,

nous avons utilisé un extrait des logs sur 1 mois (33 jours exactement) pour avoir suffisamment de data à analyser. Je pense que l’on peut considérer qu’une page non crawlée par Googlebot sur 1 mois aura peu de chance de l’être sur une plus longue période et aura de tout façon du mal à se positionner.

Ensuite on a fait un recoupement avec les données d’un crawl réalisé via notre crawler maison pour regarder quelle était la proportion de pages dans la structure qui étaient visitées au moins un fois par Googlebot. Dans le cas présent, presque toutes les pages trouvées par notre crawler avaient été parcourues au moins une fois par Googlebot.

Bonne journée !

Esteves Serge 01 mars 2017 - 17:17 - Répondre

Salut Sébastien,

Intéressant même si on a l’impression que vous découvrez l’analyse de logs depuis peu ;)

Pour la période de logs, mois aussi j’ai été étonné de voir que le taux de crawl était plutôt bon ce qui est très rarement le cas surtout au vu des problèmes du site.

La période de logs à adopter est en fonction de la fenêtre de crawl c’est à dire la période nécessaire entre 2 passages de googlebot pour que 90% des pages soient actives. 30 jours ça suppose une typologie de trafic très longue traine déja, on peut même dans certains cas pousser jusqu’à 3 mois pour des gros forums ultra longue traine. Mais ca reste des cas assez particuliers, en général la plupart des sites on une fenêtre de crawl de 15 jours – 3 semaines. Ce qui explique ton taux de crawl « faussement » très bon, c’est que la période d’analyse croisée est trop longue.

J’ai remarqué aussi que la catégorisation manque de précisions, puisque les pages « filter » ont été vus à posteriori et manuellement par exemple.

Ca a tout de même le mérite de vulgariser l’analyse de logs, donc c’est cool pour ceux qui connaissent pas.

Aurélien 01 mars 2017 - 19:14 - Répondre

Hello Sébastien

Merci beaucoup pour cet excellent article. Je l’écris en toute sincérité même si le reste de mon commentaire sera moins cool.

Il est vraiment concret ce qui permet aux personnes effrayées rien qu’en lisant les mots « analyse de logs » de mieux comprendre.

Sans volonté aucune de troller ou remettre en cause cet article, je me permets juste quelques remarques visant à minorer l’importance de l’analyse de logs.

J’espère que tu ne prendras pas mal ce commentaire, tu sais tout le bien que je pense des personnes qui prennent le temps de partager leur savoir et plus globalement du savoir faire indubitable de la team Resoneo :)

Pour moi, ce sujet est un peu sur-évolué par les SEO notamment car :

- Des vendeurs d’outils doivent bien vendre leur outil
- Sujet plus neuf que les autres en conf
- Besoin des consultants dont je fais parti de donner l’impression au client de faire et savoir des trucs de dingue
- Permet de se différencier des SEO old school qui en sont restés à la balise TITLE.

Pour les plus vieux d’entre nous, on se rappellera qu’avant google analytics/xiti on faisait tous de l’analyse de log via awstats/urchin (base de GA) et qu’il existait déjà en 2005 un super outil SPYWORDS qui trackait les robots. Il en existant d’autres dont le fameux crawltrack

On faisait de l’analyse de logs à cette époque mais on ne le « marketait » pas vraiment.

Et… ce qui n’est pas marketé n’a pas vraiment de valeur :)

Je me rappelle que j’avais ainsi découvert via l’analyse de logs à l’époque qu’un robot comme MSN ignorait quasiment toutes les URL avec plus de 3 tirets entre les mots clés (oui oui…) il fallait utiliser un autre séparateur comme des « , ».

Voici pourquoi je minore cette approche

- « redirections internes » => on les voit via un crawler

- « moteur à facettes/spidertrap » => on le voit via un crawler ou juste avec de l’EXP à l’oeil nu (c’est beau comme expression :-)

- « Google parcourait le site dans sa quasi intégralité » => check de l’indexation/taux indexation le confirme aussi mais cela peut être rassurant de constater qu’il passe partout. Les outils d’analytics peuvent aussi permettre de voir les pages qui génèrent du trafic moteur. SI trafic en provenance des moteurs alors page forcément active.

- « pages dupliquées » => J’espère que l’audit seo sans analyse de log aboutie au même résultat

- « problème du formulaire en get et URL services-masque?filter_%5″ => on le voit via un crawler

- load balancing : Bravo c’est un bel argument.

Loin de moi l’envie de pourrir ton billet mais il fallait que cela sorte :) A la base je voulais en faire un article depuis quelques temps, finalement je poste mon avis ici :)

Sébastien Bulté 01 mars 2017 - 19:43 - Répondre

Salut Aurélien,

on est d’accord, l’analyse de logs ne fait pas tout et beaucoup de choses peuvent déjà être analysées et entreprises sans y avoir accès. Pour aller dans ton sens, je rajouterais même que ce n’est pas adapté à tous les sites. Les sites avec peu de pages ou sur des CMS dont on connait déjà les failles SEO n’ont pas spécialement besoin de passer par cette étape.

Mais sur les très gros sites, pour lesquels un crawl va prendre beaucoup de temps, l’analyse des logs me semble être un passage obligé. C’est encore plus vrai pour les sites qui ont subit de nombreuses refontes et qui peuvent trainer beaucoup de ressources qui vont consommer inutilement du budget de crawl.

Au plaisir d’en discuter de vive voix ;)

Serge Esteves 01 mars 2017 - 20:28 - Répondre

Salut Aurélien,

Je me permet de répondre car je trouve que c’est dommage qu’un ancien du SEO n’attache plus d’importance (ou très peu) à l’analyse de logs. Certes, ça fait pas tout pour réaliser un audit SEO avancé mais c’est utile à partir de sites avec quelques milliers de pages et indispensable au delà.

Tes arguments comme quoi on peut se servir uniquement d’un simple crawl, d’analytics et de l’exp ne tiennent pas pour plusieurs raisons:

- Sur Un simple crawl par exemple tu ne vois pas toutes les pages connues de Google. Comme le dit Sébastien, un site peut traîner plusieurs refontes derrière lui, plus accessibles dans la structure du site mais encore connues de Google. Tu me diras, avec analytics et des outils de backlinks on peut en retrouver quelques unes mais ce sera pas précis, ni exhaustif et plus compliqué en plus car nécéssitant de croiser plusieurs sources. Il peut aussi crawler spontanément des pages que tu ne pourras pas découvrir lors d’un simple crawl, d’autant plus lorsqu’il s’agit de javascript.

- Sans analyse de logs, tu n’as aucune notion de volume de crawl, Tu ne sais pas quel temps passe Google sur tel ou tel catégorie de pages, c’est quand même determinant.

- Et tu ne peut pas faire des tas d’analyses super utiles pour apporter des recommandations fines et personnalisées pour ton site client.

De plus, j’ai pas l’impression que Sébastien essaye de vendre un outil ou autres, surtout que les outils ne sont rien sans expertise et qu’ils ne font pas tout non plus, il faut souvent croiser d’autres données et faire ses propres analyses pour aller plus loin que les données de l’outil.

D’ailleurs, un client m’a contacté récemment pour une prestation, très pointu techniquement, qui connait Botify et oncrawl, qui l’a testé mais n’a pas renouvelé avec l’outil car incapable d’en sortir des conclusions concrètes pour son site.

D’ailleurs ces outils sont surtout utiles pour les consultants eux-mêmes, et pour du monitoring éventuellement (encore que, quid de l’intérêt de monitorer un site en temps réel qui évolue assez peu, des petites analyses ponctuelles suffisent en général)

Après, je suis assez d’accord sur le fait que certains consultants abusent un peu en parlant d’analyse de logs, parce que c’est à la mode et juste pour faire les mecs super calés techniquement alors qu’en réalité ils y connaissent pas grand chose.

Mouad 02 mars 2017 - 11:13 - Répondre

Hello , c’est vrai que c’est très surprenant ce taux de crawl très élevé .. mais l’essentiel est là ! Les logs en SEO et plus particulièrement en informatique sont indispensables: ils sont l’outil de diagnostique par excellence pour un site, un serveur mail, ou même comprendre le crash de son imprimante.

Bonne journée

PS: bonjour à Serge au passage ;)

Thomas 02 mars 2017 - 11:56 - Répondre

Bonjour,

J’ai souvent constaté que GoogleBot s’acharnait pas mal sur les fichiers CSS, c’est sûrement facile à charger pour lui car c’est que du texte.
Mais en même temps, quel est l’intérêt de le laisser crawlé le CSS ? En quoi est-ce utile pour le référencement ?

Bref, je me posais la question de bloquer éventuellement l’accès aux CSS.
Qu’en penses-tu ?

Sébastien Bulté 02 mars 2017 - 12:13 - Répondre

Bonjour Thomas,

Ça fait longtemps que Google nous demande de lui laisser explorer les CSS, déjà en 2012 Matt Cutts en parlait. Ils ont rajouté une couche en 2014 avec la mise à jour de leurs consignes : « Le blocage de l’exploration des fichiers JavaScript ou CSS dans le fichier robots.txt de votre site nuit directement à la qualité de l’affichage et de l’indexation de votre contenu par nos algorithmes. Cela peut avoir un impact négatif sur le classement de votre site.« . Et comme si ça suffisait pas, ils envoient également des messages via la Search Console si les CSS/JS sont en disallow.

Dans la réalité, Google émule le rendu graphique des pages pour déterminer s’il y a ou non des points de blocage pour les internautes. Sur mobile par exemple, il nous informe si la taille des contenus est suffisamment lisible, si les éléments ne sont pas trop proches, etc.

Mais c’est vrai que parfois, Googlebot est assez brutal avec les documents CSS ou JS. Dans ce cas, voici quelques pistes d’optimisation : regrouper les consignes CSS dans un minimum de fichiers, optimiser la mise en cache coté client pour utiliser une période longue, si le fichier CSS contient peu de déclarations il faut envisager de les intégrer directement dans le HTML, etc. Cela dit, nous recommandons de ne pas bloquer l’accès aux CSS, on a plus à y perdre en cachant des choses à Googlebot qu’en essayant d’optimiser le crawl sur ces fichiers.

Bonne journée.

Serge Esteves 02 mars 2017 - 12:11 - Répondre

Salut Thomas,

Mauvaise idée, Google en a besoin pour interpréter les sites mobiles et pour ses critères mobile-friendly. Comme tu dis les CSS sont rapides à charger et gaspillent au final peu de temps de crawl. Ce que tu peux faire c’est essayer d’optimiser (fusion, minification,..) tes fichiers css

A+

serge esteves 02 mars 2017 - 12:16 - Répondre

Ah oui, et les mettre dans un sous domaine aussi pourquoi pas

Seg 02 mars 2017 - 13:08 - Répondre

Salut à tous,
Je suis ravi de voir que ce post suscite de nombreux commentaires et un débat intéressant !

Je pense au fond que chacun a raison :))

En effet, Aurélien ne dit pas que l’analyse de logs est inutile, mais que le packaging de cette « discipline » est parfois survendu. Et c’est vrai qu’auparavant on avait awstats, urchin et autres spywords :) on n’en faisait pas tout un flan :)

Aujourd’hui avec la simplicité des outils de mesure d’audience modernes on a gagné une certaine facilité d’analyse mais par exemple je ne vois que très rarement les pages d’erreur serveur Apache (ou autre) sur lesquelles le marketing à demandé aux dev d’installer un tag GA, et encore moins un tag chargé sans Javascript ^^

Et je ne parle pas des hits sur les images et autres fichiers media pour lesquels sans les logs on est aveugles…

Donc oui l’analyse de logs reste importante, ce n’est peut être pas la botte secrète des SEO, mais au moins une corde de plus à notre arc ;)

Quentin 02 mars 2017 - 14:02 - Répondre

@aurelien
(disclamer: j’édite une solution d’analyse de logs ;) )

« Je me rappelle que j’avais ainsi découvert via l’analyse de logs à l’époque qu’un robot comme MSN ignorait quasiment toutes les URL avec plus de 3 tirets entre les mots clés (oui oui…) il fallait utiliser un autre séparateur comme des « , ».

Voici pourquoi je minore cette approche »

N’était-ce pas déjà à l’époque une preuve suffisante de l’importance de l’analyse de logs versus analyse d’un crawl perso ?

« - « moteur à facettes/spidertrap » => on le voit via un crawler ou juste avec de l’EXP à l’oeil nu (c’est beau comme expression :-) »

Tu peux très bien utiliser un tournevis pour faire office de marteau, et trouver des avantages à cela ;) (troll n°1 ;) )

Une page orpheline en noindex qui te génère un spidertrap, sur un gros site, ça commence à se corser si tu veux la trouver avec ton crawleur ;) Même en branchant ton outil de trafic au crawleur. L’impact de la correction c’était +50% de trafic en un rien de temps. C’est du vécu, et c’est entre autre pour ça que je me suis lancé dans l’édition d’une solution d’analyse de logs dédiée au SEO.

Désolé, mais faire du SEO à l’oeil nu sur un gros site, c’est de la radiesthésie. (troll n°2 ;)).

A mes yeux, l’analyse de logs s’inscrit dans une logique d’excellence qui ne se limite pas nécessairement au SEO, et son intérêt est croissant, quand les variables suivantes sont également croissantes (liste non exhaustive):
- capacité d’interprétation des résultats
- volume de pages
- pression concurrentielle
- sollicitation/saturation des autres leviers d’optimisation SEO (contenus, netlinking, …)
- age du site

Aurélien 03 mars 2017 - 0:21 - Répondre

Hello Quentin et Serge Esteves,

Merci pour vos commentaires.
Vous m’avez mal compris ou alors je me suis mal exprimé.

Oui cela peut être utile
sinon je n’en ferai jamais :)