Pourquoi crawler le Web est-il devenu si complexe aujourd’hui ?

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