Depuis plusieurs années maintenant, Google semble avoir beaucoup plus de mal à crawler le Web : bugs récurrents, délais d'indexation très longs, difficulté même à explorer certains sites, etc. Comment expliquer ces problèmes à répétition ? Peut-être est-il bon, pour mieux comprendre ce phénomène, de revenir sur l'historique de la création des crawlers web, pour mieux en appréhender l'évolution et comprendre leur avenir.

 

En 1989, Tim Berners-Lee inventait le Web, et c’est à partir de 1993 que sa croissance va devenir folle. Peu de gens le savent, mais c’est le navigateur Mosaic (voir la reférence [1]), développé par Joseph Hardin, Marc Andreessen et Eric Bina, qui va mettre le feu aux poudres du web. À partir de ce moment-là, de nombreux sites web vont apparaître, et l’un des premiers sera www.mit.edu, mis en ligne par Matthew Gray en juin 1993.

Vous n’avez sans doute jamais entendu parler de lui, mais Matthew Gray (voir la référence [2]) est aussi l’un des développeurs de Apache, et maintenant un ingénieur du “noyau” de Google,  aujourd’hui ce sera surtout pour nous le développeur du premier crawler web jamais écrit : le World Wide Web Wanderer (là aussi autour de juin 1993).

L’histoire raconte que Wanderer a créé beaucoup de problèmes à l’époque car il crawlait trop brutalement et provoquait une dégradation substantielle des performances réseaux du Web, et bien entendu des serveurs qui hébergeaient les sites.

A l’époque existait aussi un premier moteur (Archie, par Alan Emtage, voir la référence [3]), mais sans crawler associé.

Depuis, tout à changé, et le crawler est la première brique d’un moteur de recherche.

 

Quelques définitions

Commençons par les définitions les plus simples. Un crawler, ou spider web ou encore robot d’indexation, c’est un programme qui parcourt inlassablement le web pour collecter le contenu des pages des sites web. L’idée de son fonctionnement est très simple : il parcourt l’un après l’autre les liens hypertextes qu’il va trouver lors de son parcours, en partant d’un certain nombre de pages sources.

Dès 1998 (voir les références [4] et [5]), c’est du côté de l’équipe de Hector Garcia-Molina, dont nous avons déjà parlé dans de précédents articles, que la théorie sur le crawling web va être mise au point. Vous remarquerez que Larry Page est auteur de l’un des articles scientifiques en question (le [4]).

En premier va émerger la notion de crawler incrémental. Les premiers crawlers étaient périodiques : ils parcouraient un nombre connu de pages, les mettaient dans un index, puis de temps en temps recommençaient « from scratch » (c’est-à-dire refaisaient un index en repartant totalement de zéro). Inutile de dire qu’à l’échelle du Web et de l’index d’un moteur de recherche, cette approche est totalement illusoire aujourd'hui. L’index d’un moteur de recherche comme Google se mesure en centaines de milliers de milliards de pages web, et même des acteurs comme notre outil Babbar ont des index énormes (quasiment 800 milliards de pages pour nous au moment où nous écrivons ces lignes).

Un crawler incrémental va constituer un index, puis ensuite le mettre à jour en continu : il remet à jour les pages “importantes”, enlève de l’index les pages qui n’ont pas d’intérêt et ajoute celles - nouvelles - qui peuvent en avoir.

L’article [4] de 1998 (par Larry Page, entre autres) est édifiant à plusieurs titres. Pour faire le crawl de manière efficace, une métrique d’importance des pages est utilisée pour ordonner les URL de la plus importante à la moins importante. Le crawler est ensuite biaisé pour favoriser les pages les plus importantes. Jusqu’ici rien d’exceptionnel, mais c’est la définition de la fonction d’importance qui est édifiante. Cette importance prend en compte :

  • Une mesure de pertinence rapide ;
  • Le nombre de backlinks de la page ;
  • Le pagerank de la page ;
  • Le nombre de liens sortants ;
  • La “location”, qui désigne ici une information liée au nom de domaine : son TLD, ou la présence d’une chaîne de caractères spécifique.

L’article soulève un problème évident : si une page n’a jamais été visitée, alors on ne peut pas calculer réellement son importance. Il faut alors l’estimer du mieux possible. Dans l’article [4] on trouve la phrase suivante "we may be able to use the text that anchors the URL u as a predictor of the text that P might contain”, Et oui en 1998 Larry Page a déjà l’idée d’utiliser le texte des ancres pour mieux comprendre les contenus !

Dès 1999, les chercheurs commencent à s’intéresser à un sujet bouillant : le fait de visiter une page au bon moment. L’objectif est alors de créer un crawler capable de prédire si une page change souvent ou pas, de savoir si une page a une durée de vie particulière, de voir le rythme de changement du Web. À l’aide d’outils statistiques, un crawl prédictif est démontré possible.

 

Vers des crawlers plus efficaces

Avançons dans le temps (référence [6]) : le web étant de plus en plus grand, les crawlers ont des problèmes de passage à l’échelle. Assez étonnamment, ce sont d’abord les algorithmes plus théoriques qui vont pousser les crawlers à évoluer : le calcul des métriques de type pagerank ne peut plus être fait par tour au delà d’une certaine taille d’index, il faut donc mettre en place des crawlers qui calculent en même temps les métriques, qui vont détecter le spam pendant le crawl, etc. L’objectif est d’avoir un crawler qui va soulager les calculs faits après l’indexation pour éviter des nœuds d’engorgement en pré-calculant le maximum de choses.

Si on réfléchit bien, c’est à partir du moment où les crawlers se sont vu attribuer ces tâches de preprocessing que la problématique de l’indexation apparaît au niveau des moteurs.

L’exemple typique de tâche faite au crawl est l’analyse de duplication. Elle permet d’éviter d’indexer des pages dont le contenu est déjà connu et qui de fait n’apporte pas de nouvelle réponse aux besoins informationnels des utilisateurs du moteur. Le problème de placer l’analyse au moment du crawl parait évident : en cas de souci technique qui ralentit le processus, les pages mettront plus de temps à s’indexer, voire passeront dans une liste de pages à “voir” plus tard pour ne pas arrêter tout le pipeline de traitement (et donc ne seront pas indexées immédiatement).

Autant, si le crawler n’a qu’une tâche à faire, ce phénomène peut être marginal, autant quand il y a des nombreux calculs effectués de manière plus ou moins parallèle, avec des temps de calcul dépendant de la complexité des pages, l’indexation va devenir de plus en plus problématique. C’est une explication possible des soucis d’indexation que Google rencontre en ce moment.

 

Le crawler, du code stratégique, mais aussi du code stratège…

Un crawler web est assez simple sur le papier, mais en pratique beaucoup plus complexe. C’est un sujet sur lequel l’équipe de Babbar a par exemple partagé son expérience (référence [7] pour en savoir plus), et pour lequel il y a un niveau de compréhension stratégique.

En effet, pour réussir à bien crawler et indexer le web, le moteur doit avoir un robot qui va mettre en place :

  • Une stratégie de sélection pour décider quelles sont les pages à explorer parmi les pages découvertes (sachant qu’une page ne sera indexée que si elle est explorée).
  • Une stratégie de rafraîchissement pour décider de quelle page revoir, et quand la revoir.
  • Une politique de politesse qui décide quel serveur, site et page vont être visités à tout moment, pour éviter de saturer les sites ou de faire tomber des serveurs.
  • Une politique de parallélisation pour, comme le nom l’indique, distribuer massivement mais efficacement l’exploration du Web.

D’un point de vue théorique, c’est la stratégie de sélection qui est l’âme du robot. En effet, c’est là qu’on décide si on explore plus de sites mais pas forcément en profondeur, ou bien au contraire moins de sites mais de façon complète ou presque.

Par essence, un moteur a vocation à découvrir le plus possible de sources de contenus, car c’est généralement la diversité qui permet de trouver les réponses de meilleure qualité. Et vis à vis des webmasters, il est bien plus aisé de défendre un moteur qui présente tous les sites - même de façon potentiellement incomplète pour chacun d'eux -, qu’un moteur qui présente toutes les pages de moins de sites.

L’effet de bord de ce dernier point est alors évident : si votre site est mal structuré, par exemple avec des pages très profondes, ou cachées derrière des pages moins attractives (vides, spammy, mal maillées, avec du noindex, etc.), alors vous courrez le risque qu’une partie du site ne soit jamais explorée ni indexée.

En revanche, d'un point de vue pratique, c’est la politique de politesse et parallélisation qui est très complexe à mettre en œuvre. Et sa complexité croît avec le nombre de robots et de pages qui sont en jeu. Quand on crawle le Web, il existe des tas de pièges : trous noirs (réseaux de sites interconnectés générant des milliards de liens et des pages automatiquement), redirections JS ou avec cookies, soft 404 pour n'en citer que quelques-uns. Pour bien crawler, il faut donc crawler très intelligemment, sinon les robots passeraient tout leur temps dans les trous noirs, ou rateraient des pages utiles.

D’un point de vue conceptuel, il est assez difficile de couvrir tous les cas (par exemple pour ne pas faire tomber des serveurs qui sont assez singulièrement configurés, avec des milliers de sites sur un seul petit serveur parfois) et aussi parce que la “stack” technologique à mettre en place est complexe (base de données, système de messages, le crawler lui même qui doit être massivement multi-thread, etc.).

Des tâches de plus en plus complexes lors du crawl

Tous les problèmes ci-dessus sont depuis assez longtemps résolus par un opérateur du niveau de Google. Mais de nouveaux challenges sont désormais présents, et font que le moment du crawl pose à nouveau beaucoup de problèmes.

Parmi ces challenges, on trouve notamment :

  • La création d’un vecteur sémantique pour le contenu de la page. Ce challenge n’est pas nouveau, loin de là, mais ce sont les algorithmes utilisés pour le résoudre qui sont nouveaux. Depuis quelques années, il n'a échappé à personne que des méthodes innovantes, à base de réseaux de neurones, permettent de mieux comprendre les pages. Nous parlons ici bien entendu de BERT, Smith, MUM, etc.
    Les temps de calcul induits par ces nouveaux algorithmes ne sont pas anodins, d’autant qu’ils dépendent terriblement de la taille du contenu extrait. Par ailleurs, ils viennent au dessus de l’analyse de la duplication, de la mesure de la qualité des contenus, etc.
    Au total, la chaîne de traitement sémantique est lourde, et la moindre latence peut expliquer des retards d’indexation conséquents.
  • La compréhension du robots.txt et autres directives plus ou moins explicites. Beaucoup de sites se protègent des robots : captcha, mesures anti-DDOS, anti-scraping, etc. Google est largement épargné par ces mesures, car la plupart des sites souhaitent être indexés. Cependant de nombreux sites veulent contrôler la manière dont les bots perçoivent leurs pages (Google comme les autres), via le robots.txt ou autrement. Notre expérience du crawl à grande échelle est qu’il y a beaucoup d'erreurs dans la mise en place des robots.txt, car c'est une méthode non normalisée. Si vous rencontrez des problèmes de crawl et/ou d’indexation, c’est le premier point à vérifier.
  • La détection des contenus inutiles. C’est un vieux challenge qui reprend du poil de la bête : on est encore au moment du crawl sur une détection très syntaxique, mais sur le moyen voire long terme, le plus important est de ne pas garder plusieurs pages qui n’apportent pas de nouvelle information, au sein d’un site ou plus généralement. Les contenus inutiles peuvent être les contenus dupliqués, ou les contenus qui apportent peu d’information (la soupe, la bouillie), plus facile à détecter maintenant avec des embeddings vectoriels comme ceux de BERT ou ses équivalents.
  • L’interprétation des pages web. ll existe de nombreux sites qui exposent un contenu légitime, mais qui est difficile à comprendre par un moteur de recherche : cela peut-être parce qu'une technologie exotique est utilisée et qu’il faut passer par un rendering coûteux, ou encore cela peut être parce qu’il y a une structure mal codée. Dans ces deux cas, il y a fort à parier que l’indexation tardera, ou qu’elle ne sera jamais faite (car pour le moteur la page n’a pas de réel contenu).

Un autre cas, mais qui à coup sûr ne concerne pas nos lecteurs ;), est celui des contenus cachés (le cloaking). Détecter le vrai contenu visible est parfois indispensable (dans ce cas on ne veut pas indexer ce qui est dissimulé), mais qui dit détection automatisée, dit risque de faux positif. Une page légitime qui utiliserait une technique un peu borderline (par exemple pour un consentement ou des rajouts d’informations de manière dynamique) pourrait être mal perçue par un moteur de recherche.

On le voit, il y a encore de nombreux challenges dans le crawl, même pour Google. Mais le plus important est vraiment celui du maintien de la capacité d’être full scale, c’est-à-dire être capable d’avoir une chaîne de traitement rapide et fluide même lors du déploiement d’algorithmes très coûteux. Or, on voit qu’à chaque update fondamental du noyau de Google (interprétation du JS, incorporation de nouveaux modèles de la langue type BERT, MUM, etc.) apparaissent des problèmes techniques qui sont sans doute résolus par des modifications d’infrastructure côté moteur.

Dans le cadre des évolutions liées à la sémantique, la meilleure compréhension du moteur lui permet aussi d’être plus sélectif et de moins indexer tout en répondant aussi bien aux besoins informationnels des utilisateurs. Une partie des stratégies SEO de netlinking devra ainsi être revue sur le moyen terme pour pallier la pauvreté des textes utilisés pour porter les liens, tout en ne cannibalisant pas les pages cibles de la stratégie.

 

Est-ce que Google donne officiellement des conseils ?

Comme toujours, la communication de Google est, au mieux, cryptique. Dans l’article [8] du blog des développeurs Google, on trouve quelques informations, avec notamment les facteurs qui peuvent être officiellement problématiques pour le crawl et l’indexation. Plutôt que de vous faire une longue explication, nous vous laissons découvrir sur la figure 1 ce qui est dit :

Les facteurs affectant le crawl et l’indexation selon Google

 

On retrouve toujours les mêmes éléments : des problèmes techniques, des contenus dupliqués, et des contenus inutiles car de mauvaise qualité.

Dans l’article [9], on découvre que John Mueller lui-même annonce qu’il est tout à fait normal que 20% d’un site ne soit pas indexé par le moteur. L’information plus intéressante est surtout le fait qu’il dise qu’il existe une forme de qualification globale des sites (et non des pages) pour décider si tout un site mérite d’être exploré et indexé (ou pas...).

 

Conclusion

Il n’y a pas réellement de conclusion à apporter à cet article. Aujourd’hui les crawlers modernes font déjà un bon travail, mais se heurtent à des nouveaux problèmes, principalement issus des nouvelles méthodes d’analyse sémantique, mais aussi aux choix des développeurs des sites web. C’est aux SEO encore une fois d’être vigilants et de s'adapter à ce nouveau contexte, en augmentant le niveau de qualité globale de leurs actions. C’est donc toujours la même histoire qui se répète !

 

Références

[1] https://fr.wikipedia.org/wiki/NCSA_Mosaic

[2] https://www.linkedin.com/in/mkgray/

[3] https://fr.wikipedia.org/wiki/Archie_(moteur_de_recherche)

[4] Cho, Junghoo, Hector Garcia-Molina, and Lawrence Page. "Efficient crawling through URL ordering." Computer networks and ISDN systems 30.1-7 (1998): 161-172.

http://ilpubs.stanford.edu:8090/347/1/1998-51.pdf

[5] Cho, Junghoo, and Hector Garcia-Molina. The evolution of the web and implications for an incremental crawler. Stanford, 1999.
http://ilpubs.stanford.edu:8090/376/1/1999-22.pdf

[6] Cambazoglu, Berkant Barla, and Ricardo Baeza-Yates. "Scalability challenges in web search engines." Advanced topics in information retrieval. Springer, Berlin, Heidelberg, 2011. 27-50.

[7] https://blog.babbar.tech/babbar-crawle-des-dizaines-de-milliards-de-pages-mais-comment-1-2/
https://blog.babbar.tech/babbar-crawle-des-dizaines-de-milliards-de-pages-mais-comment-2-2/

[8] https://developers.google.com/search/blog/2017/01/what-crawl-budget-means-for-googlebot

[9] https://www.searchenginejournal.com/google-not-indexing-site/416717/#close

Sylvain Peyronnet, concepteur de l'outil d'analyse de backlinks Babbar.