Ouvrir la boite noire #1

Ouvrir la boite noire #1

Il y a bientôt deux ans, je rejoignais OnCrawl et la possibilité d’accéder à des millions de données de logs : le sentiment d’entrer chez un mini Google avec un accès à des tas de données de crawl, de logs et de connecteurs tiers.

Dans ce nouvel article, j’aimerai partager mon apprentissage sur les données de logs. On parle désormais beaucoup de science de la donnée, domaine qui s’appuie notamment sur les logs pour leur fiabilité mais ce sujet demeure malgré tout encore dans l’ombre, en dépit de son intérêt déjà démontré.

Fichiers de logs : la grande introduction

Sans entrer dans les menus détails et dans la décomposition d’une ligne de log, on retiendra que c’est une donnée qui ne ment pas : inscrite dans le marbre à chaque passage d’un robot d’exploration et à chacune des visites de vos utilisateurs. La ligne de log relative à une visite organique se montre ainsi plus robuste qu’un tag analytics qui pourrait ne pas se déclencher pour x ou y raison.

Les données de logs ne mentent pas mais elles peuvent être incohérentes si on ne les manie pas correctement. On évoquera plus bas l’indispensable contrôle qualité à fournir au moment de leur récupération.

Bien que les données présentes dans chacune des lignes soient précieuses, elles impliquent moins de flexibilité que d’autres jeux de données en matière de croisement.

Si on devait les catégoriser, on dirait qu’il en existe trois sortes :

  • Les visites de vos utilisateurs.
  • Les traces laissées par les robots d’exploration.
  • Les erreurs relatives à votre infrastructure.

La première est plus fiable que votre déclencheur Analytics, on l’a vu plus haut. La seconde, elle, c’est un peu comme le graal du métier : des traces, éparses et non liées les unes aux autres, qui permettent de mieux comprendre comment Google interprète votre site web. La troisième est, face aux deux premières, moins séduisante, mais elle a parfois le mérite de confirmer certaines hypothèses, on le verra plus loin.

En résumé, toutes ces données sont retranscrites chaque seconde et permettent de recomposer le passé : 

  • la page visitée, 
  • le temps de réponse : bien que généralement aux abonnés absents, les temps de réponse sont importants, vous vous en doutez. Ils permettent d’avoir une mesure du temps écoulé avant que Google puisse accéder à la page : parfois long lorsque c’est le robot qui se charge de déclencher la mise en cache,
  • le code de réponse, 
  • l’origine de la visite, 
  • le nom du robot d’exploration : on peut ainsi décomposer les visites des robots entre desktop et mobile dans un premier temps mais aussi en fonction des verticaux : images, news… 
  • la localisation via l’IP : l’adresse IP permet de vérifier que l’empreinte provienne d’un “vrai” Googlebot (ou robot d’un autre moteur de recherche) : on met parfois au jour des consommations fortes de ressources par des robots qui aimeraient se faire passer pour plus connus qu’ils ne le sont … !
  • la date, l’heure et le fuseau horaire : si on analyse les données sur des périodes larges pour tenter d’en dégager des tendances, l’accès aux données brutes permet de regarder plus finement le nombre de passage d’un robot au cours d’un espace temps réduit (une minute par exemple) et ainsi mesurer la vitesse d’exploration.

Contrôle qualité : un fichier en cache parfois un autre

C’est là toute la complexité des fichiers de logs : il faut identifier leur localisation, vérifier leur cohérence et trouver un moyen de les récupérer et de les traiter jour après jour. Chaque infrastructure de site web est différente, les localisations ne sont donc pas toujours les mêmes. Pire, la composition même d’une ligne de log peut différer en fonction du service que vous utilisez. On pense par exemple à certains cloud qui omettent de récupérer le temps de réponse, d’autres qui remplacent les adresses IP d’origine par les leurs … quand d’autres refusent tout simplement de vous donner accès à vos données de logs. Bref, ce premier travail peut s’avérer une tâche extrêmement complexe entre la récupération des données et leur traitement.
Sur le banc des accusés, on peut facilement nommer le load balancer (répartisseur de charge). Derrière cette appellation anodine, on trouve un algorithme capable de faire appel à un serveur C plutôt qu’à un serveur B afin de garantir un temps de réponse optimal à l’utilisateur, ou robot d’exploration.

Les faits avérés

Début 2017, Google se fendait d’un article sur son blog officiel pour les webmasters afin de traduire le concept de budget de crawl. Bien que les données diffèrent en fonction des secteurs d’activité et des typologies de site, il est vrai que l’exploration de Google se fait sans accroc pour les sites peu volumineux. Cela est d’autant plus vrai lorsque les sites sont bâtis sur des CMS connus et largement utilisés puisque les logiques derrière les structures d’URLs sont, le plus souvent, similaires. Google, comme d’autres moteurs de recherche par ailleurs, découvre facilement les URLs et les explore facilement.

A l’inverse, pour les sites web qui contiennent des centaines de milliers ou des millions de pages, l’optimisation du budget de crawl prend tout son sens. Et c’est d’ailleurs avec ces données que l’on s’amuse le plus. On verra dans la seconde partie de l’article comment optimiser (vraiment) les ressources déployées par les moteurs de recherche pour explorer votre site.

Autre fait avéré, les spider trap, ces fameux puits d’exploration infinie, qui sont une réelle plaie. Si le robot d’exploration peut s’arrêter à un moment donné, faute de trouver une once de qualité, il n’en reste pas moins qu’un tel élément détériore la qualité générale de l’exploration et la propension à identifier de nouveaux contenus rapidement.
Enfin, on s’arrêtera sur LE fait qui fera plaisir aux puristes : la planification du crawl en fonction notamment du score d’importance. On retrouve ces écueils dans deux brevets de Google dont le premier porte sur la gestion des URLs.

Brevet de Google, Managing items in crawl schedule

On retrouve ainsi une illustration parfaite de la planification du crawl d’une page, soit sa fréquence de crawl, en fonction de son score d’importance. Cette planification peut-être basée sur le Pagerank comme elle peut aussi utiliser, en fonction de la pertinence, un autre algorithme de positionnement. La figure 3 nous indique le nombre de pages comprises dans l’index en fonction des seuils d’importance tandis que la figure 4 nous indique la limite maximale de pages à entrer dans l’index (ligne pleine) et la limite cible de pages à entrer dans l’index (ligne en pointillé).

Cette analyse est plus généralement effectuée dans une logique de groupe de pages qui rend la lecture plus souple. En fonction des types de site (presse, petites annonces, etc.), on retrouve des planifications de crawl similaires bien que pondérés par les volumes de pages et les signaux positifs et d’incidences.

Les découvertes

On évoquait plus haut la nécessité de contrôler la véracité des données récoltées afin de ne pas biaiser les analyses. De facto, on aurait tendance à vouloir comparer la courbe des pages explorées par Google avec la courbe disponible (malheureusement encore) dans l’ancien rapport de la Search Console : statistiques de l’exploration. Pour les sites dont les leviers d’acquisition sont peu diversifiés, cela fonctionne. Pour les autres, c’est une gageure. En effet, chez OnCrawl, nous avons découvert (merci Nicolas !) que les courbes se ressemblent uniquement lorsque l’on prend en compte l’ensemble des robots d’exploration, que l’on nomme verticaux, et pas uniquement les données relatives au SEO. Ce qui implique que le budget de crawl doit être perçu de manière plus large : comprendre tous les user-agent et pas uniquement ceux auxquels on pense en général. On étudie aujourd’hui une autre hypothèse : la possibilité que cette courbe, côté GSC, soit basée uniquement sur les pages canoniques (ce qui ferait sens compte tenu des dernières mises à jour de l’outil quant à la comptabilisation des clics et des impressions).

Cette découverte rend d’autant plus nécessaire le fait de se reposer sur un analyseur de logs indépendant afin de correctement décomposer le chemin de chacun des robots d’exploration. En effet, on a vite fait de faire dire ce qu’on veut à nos données, plus encore quand on ne sait pas avec certitude ce qu’elles contiennent.

Le reste à découvrir

Sans surprise, on retrouve le Javascript. Google nous donne des indications (notamment lors de l’événement I/O 2018) et nous procure également un schéma largement repris (je contribue donc à la boucle) :

On en sait peu finalement sur cette file d’attente et ce moteur de rendu bien qu’on puisse identifier des schémas de crawl dans lesquels un besoin d’exploration plus grand engloberait le rendering :

Bots hits sur les pages (en rouge) et le JS (en jaune) et nombre de visites SEO. Données issues de plusieurs sites (secteurs d’activité variés) entre le 12/02/2020 et le 12/04/2020.

On distingue facilement les patterns dans lesquels Google effectue un rendering plus important, tous les 15 jours environ (pour le site analysé, bien entendu). On ne note toutefois pas de corrélation directe avec une éventuelle baisse de visites SEO : ce qui aurait pu démontrer une consommation plus importante de ressources un jour donné.

Plus intéressant encore, si on se focalise sur une URL en particulier, on note que les différents bots (seo et verticaux) effectuent un pré-rendu. Il n’y a pas de vase communiquant entre eux : l’exploration est donc silotée. Bien que cela fasse sens car chaque robot évalue la qualité d’une page par rapport à certains critères, cela peut toutefois nous surprendre car nous pourrions imaginer que ce fameux vase communiquant permettrait de réduire les coûts d’exploration et donc, in fine, les coûts générés par l’exploitation des data center. Cependant, le premier bot permet de réactiver le cache et réduit ainsi les temps de réponse pour les bots suivants (qui interviennent tous dans une amplitude de 5h, pour les données analysées).

Nous venons d’évoquer plus haut le besoin d’exploration, que Google explique en ces termes : 

Même si la vitesse d’exploration n’atteint pas sa limite, en l’absence de besoin d’indexation, l’activité de Googlebot sera faible. Les deux facteurs qui jouent un rôle important dans la détermination du besoin d’exploration sont les suivants :

La popularité : les URL les plus populaires sur Internet ont tendance à être explorées plus souvent pour être le plus à jour possible dans notre index.
L’obsolescence : nos systèmes s’efforcent d’empêcher que les URL ne soient pas actualisées dans l’index.

En outre, les événements sur l’ensemble du site comme les déplacements de site peuvent déclencher une augmentation du besoin d’exploration afin de réindexer le contenu sur les nouvelles URL. En associant la vitesse d’exploration et le besoin d’exploration, nous définissons le budget d’exploration comme le nombre d’URL que Googlebot peut et veut explorer

Gary Illyes, équipes Crawl et Indexation (Google)

On remarque que ce besoin est intimement lié à la fréquence de visites sur le site, toutefois avec un décalage de +24/48h :

Données issues de plusieurs sites (secteurs d’activité variés) entre le 12/02/2020 et le 12/04/2020.

C’est certainement le premier critère qui permet de pondérer l’exploration de Google : ce dernier se définissant comme un bon citoyen du web (ne mettant ainsi pas en péril les performances du site lors de fortes affluences). On pourrait imaginer que ce décalage s’explique par le délai de mise à jour des données de clics sur Google Search Console : données de situation réelles sur lesquelles Google pourrait ainsi se baser afin d’adapter l’allocation de ses ressources.

L’analyse de logs, la vraie

Comprendre les données

Les deux graphiques que l’on vient de voir illustrent parfaitement le propos : il s’agit de comprendre l’origine des informations et les causalités qu’elles peuvent avoir entre elles (et avec des éléments externes) pour comprendre leur signification.

On évoque souvent les termes suivants :

  • Pages crawled : une page explorée par un robot d’exploration. Les valeurs sont souvent agrégées sur une période (90 jours permettant de se faire une idée sur une tendance éventuelle).
  • Bot hit : une page explorée par un robot d’exploration à un moment T, qui peut avoir lieu plusieurs fois par jour par exemple.

On retrouve la même logique pour les ressources et, pour les deux, menu détails quant aux métriques telles que le temps de chargement, le code de réponse, etc. (ce que l’on a vu en introduction au final).

Puis, souvent délaissée au profit des outils d’audience, on retrouve la SEO visit qui renseigne sur le nombre total de visites organiques.

Comment interpréter ces courbes dont les variations sont quotidiennes ?

On peut expliquer une partie avec les différentes allocations de ressources comme on l’a vu précédemment mais, parfois, cela ne suffit pas à tout expliquer. On sait en effet que le traitement des pages est inégal, qu’il diffère selon leur score d’importance et est donc soumis à une planification de crawl.

La difficulté la plus souvent rencontrée revient à créer une vue permettant de distinguer les URLs qui ont une valeur ajoutée et celles qui n’en n’ont pas, qui font partie des URLs que vous ne voulez pas voir crawlées. 

On comprend ici que les besoins d’exploration plus importants se concentrent sur des pages utiles (à noter que cela reste rare. Bien souvent, c’est l’inverse qui prévaut avec plus de pages inutiles crawlées que de pages utiles). Il reste maintenant à comprendre pourquoi ces allocations plus importantes de ressources ont lieu à ces périodes précises. J’évoquais plus haut les facteurs externes : il faut en effet lire la donnée par rapport aux dates de mise en production, optimisation importante et événement plus extérieur encore : le déploiement de mises à jour algorithmiques qui peut entraîner un besoin d’exploration plus important mais temporaire. On l’a parfaitement vu avec le passage à l’Index Mobile First pour les sites concernés.

Interpréter les tendances

Évoquons une actualité qui parle à tout le monde : le Covid-19. Avec le confinement, on s’est demandé si le réseau internet n’allait pas être saturé. Aussi, il a été logique de penser que Google, comme les autres moteurs de recherche, pourrait réduire sa voilure afin de ne pas consommer trop de cette précieuse bande passante.

On observe en effet que, sur la période relative au confinement dans le monde (les données étant des médianes tirées par industrie similaire dans plusieurs pays), le nombre de pages crawlées a réduit à l’exception de la presse : sans surprise.

Si on observe de manière plus granulaire deux industrie antinomiques face à l’actualité, on comprend rapidement les tendances observées entre 2019 et 2020 à période équivalente :

In fine, hors actualité aussi marquante, les tendances doivent être analysées par rapport aux cycles de vos mises en production (techniques ou lots d’optimisations organiques), qui sont souvent révélatrices. C’est ce travail qui permet de mieux comprendre pourquoi tel robot se comporte de telle et telle façon sur votre site.

Tester les hypothèses

À l’instar d’un Google Analytics qui donne des faits, l’analyse de logs est toujours soumise à de nombreuses hypothèses malgré la qualité et la richesse de l’information. L’analyse de logs permet une analyse plus granulaire certes mais il n’en demeure pas moins que le SEO reste une science inexacte.

L’analyse croisée prend tout son sens dans ce chapitre car les facteurs qui détériorent vos performances organiques peuvent être facilement prioriser grâce à aux logs :

  • Un nombre important de vos pages est dupliqué,
  • Mais vous avez aussi de nombreuses pages orphelines,
  • Avec un plan de redirections qui ne s’est pas passé comme prévu et vous avez la majorité de vos redirections coincées dans des chaînes de redirection,
  • Et vos canonical tags ont décidé de vous donner le tournis : ils ne répondent plus à votre logique,
  • Et on pourrait continuer longtemps ainsi.

Ces faits que vous démontrent le crawl peuvent être rapidement mis au jour avec l’analyse de logs afin de déterminer quel(s) élément(s) impacte(nt) le plus l’exploration de Google, Bing et consors.

Conclusion : test & learn

On note une chose : les fichiers de logs regorgent d’informations toutes plus importantes les unes que les autres : libre à nous de les analyser dans les moindres détails pour confirmer certaines hypothèses, en réfuter d’autres et se poser de nouvelles questions.

À l’heure où le SEO est privilégié par certaines marques du fait de l’impact économique récent et à venir mais aussi par le mariage possible avec les équipes data, il est aussi temps de se plonger dans les données de logs : à la fois précises mais aussi opaques et impartiales. Nous avons accès à des données factuelles et tangibles mais encore partielles pour obtenir toutes les pièces du puzzle : il est par exemple difficile de reproduire un schéma de crawl car on ne sait pas encore définir le temps T0 ni relier les points entre les lignes de logs : elles sont parfois le fait de but d’analyses différentes en fonction du robot, etc.

On terminera sur cette récente réponse apportée par John Mueller : “il n’y a pas de chiffres”. Pas de chiffres précis ni de moyenne générale. Chaque analyse est différente, c’est ce qui fait tout l’attrait de l’analyse de logs. C’est aussi ce qui rend naïfs certains graphiques présentés plus haut : il n’y a pas de vérité établie mais il y a toujours de bonnes hypothèses.

Cet article est le premier d’une longue série (je l’espère) car il est difficile voire impossible de résumer en un article ce que l’on peut découvrir au travers des données de logs.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

data science
Up Next:

Quand utiliser la data science en SEO ?

Quand utiliser la data science en SEO ?