Chez Babbar, nous essayons d’explorer le web comme un moteur de recherche. Bien sûr, nous ne disposons pas des mêmes ressources informatiques ni de la même bande passante que Google, Bing ou d’autres grands acteurs du secteur, mais nous avons tout de même de solides performances en matière de couverture et de vitesse d’exploration. Bien que notre principal objectif soit l’optimisation pour les moteurs de recherche (SEO), nous partageons de nombreux objectifs et contraintes avec les moteurs de recherche classiques.
Dans cet article, qui fait suite à notre précédent article sur l’introduction du crawler Babbar, nous allons détailler plus précisément notre politique d’exploration.
Explorer le web, c’est un peu comme être un aventurier perdu dans une jungle infinie d’URLs. Pour progresser efficacement sur Internet, les crawlers ont besoin d’une politique bien pensée qui les guide. Sans cela, ils risquent de se perdre dans une mer de pages de faible qualité, de s’embourber dans des liens morts ou même de disparaître dans un véritable trou noir. Voyons ensemble comment concevoir une politique d’exploration efficace qui équilibre découverte, performance et un soupçon de courtoisie.
Comment fonctionne le crawler
Comprendre le fonctionnement du crawler est essentiel pour élaborer une politique d’exploration solide. Voici une vue d’ensemble représentée par ce schéma :

Barkrowler joue un rôle essentiel, mais ce n’est pas lui qui effectue le travail le plus complexe. Voici un aperçu simplifié des principaux composants :
- Scheduler : C’est le cerveau de l’opération. Il détermine l’ordre et le moment où les URLs doivent être explorées. C’est aussi ici que nous gérons en grande partie les règles de courtoisie envers les sites web.
- Fetcher : (oui, nous avons un fetcher dans notre fetcher) Il est chargé de récupérer le contenu du web, y compris le HTML, les en-têtes et d’autres ressources.
- Parser : Décompose le contenu récupéré en éléments exploitables, tels que les liens, les métadonnées et le texte principal.
Barkrowler gère également les règles définies dans les fichiers robots.txt (autorisation/interdiction d’exploration, délai entre les requêtes), la résolution DNS, les connexions SSL, les subtilités des requêtes HTTP, etc. Ce n’est pas le sujet de cet article, mais si vous souhaitez en savoir plus, nous vous invitons à consulter notre page de conseils sur robots.txt et à attendre un prochain article dédié.
Enfin, nous avons l’élément central : WDL, qui s’occupe de l’index, de la politique d’exploration, du calcul des métriques et bien plus encore. Nous donnerons plus de détails sur son fonctionnement global dans un prochain article, mais pour l’instant, l’essentiel est de comprendre son rôle dans la gestion d’une gigantesque base de données de pages. Voici un schéma très simplifié de WDL :

Nous allons principalement nous concentrer sur la grande flèche verte, qui représente le processus d’itération. Ce processus scanne en continu la base de données et effectue de nombreuses tâches, y compris l’envoi de requêtes de crawl. C’est à ce niveau que la politique de crawl est appliquée pour décider si une page web découverte doit être explorée.
L’architecture est conçue pour être évolutive et efficace, s’appuyant sur des technologies comme Pulsar pour la messagerie et les threads virtuels pour le traitement parallèle. Ces fonctionnalités garantissent que le crawler peut gérer l’exploration du web à grande échelle sans planter ni surcharger les serveurs.
Pourquoi une politique de crawl est-elle importante ?
Avant d’entrer dans les détails techniques, répondons à la grande question : pourquoi avez-vous besoin d’une politique de crawl ? Pensez-y comme au règlement de votre crawler. Elle détermine :
- Quoi crawler : faut-il privilégier un nouveau site ou revisiter des pages déjà explorées ? Le web est complexe et en perpétuelle évolution, mais certains sites restent inchangés pendant des années. Nous avons également des contraintes de stockage : nous ne voulons pas gaspiller d’espace sur nos serveurs, nous devons donc nous concentrer sur les pages les plus intéressantes. Comme un moteur de recherche, découvrir un nouveau site peut être un tournant.
- À quelle vitesse crawler : personne n’aime un crawler impoli qui surcharge les serveurs. Nous explorons environ 3,5 milliards de pages par jour, donc même si nous essayons d’être respectueux, nous recevons parfois des plaintes concernant notre vitesse de crawl, notamment lorsque plusieurs sites sont hébergés sur un même serveur.
- Où donner la priorité : devons-nous investir nos ressources dans des domaines de haute qualité ou explorer les parties inexplorées du web ? Comme nous voulons imiter le comportement des moteurs de recherche, nous devons nous concentrer sur les pages les plus intéressantes. Mais qu’est-ce que cela signifie ?
Une bonne politique de crawl ne se limite pas à l’efficacité, elle garantit que les efforts du crawler fournissent des informations précieuses sans causer trop d’inconvénients. Comme un moteur de recherche, notre objectif est d’établir un ensemble de règles nous permettant d’explorer efficacement les parties les plus pertinentes du web.
Les bases d’une bonne politique de crawl
Objectifs
- Envoyer les requêtes de crawl à un rythme contrôlé.
- Différencier le traitement des nouvelles URLs et du re-crawl (exploration répétée de la même URL).
Qualité
- Ne pas gaspiller trop de temps sur des sites de faible qualité et maximiser l’exploration (et la mise à jour) des sites de valeur.
- Prioriser les URLs ayant un fort intérêt (généralement celles avec des métriques élevées).
Découverte
- Lorsqu’un nouveau site est découvert, effectuer un crawl initial pour évaluer sa valeur.
Fraîcheur
- Le re-crawl permet de détecter de nouvelles pages, de nouveaux liens et d’identifier les pages supprimées.
Contraintes
- La politique de crawl fonctionne dans le cadre de l’itérateur global.
- La partition est effectuée par domaine.
- L’information est agrégée par domaine, hôte et vue.
- L’ordre des hôtes et URLs suit une structure lexicographique (bien que non stricte).
- La plus petite unité de l’itérateur est un bloc de 4096 vues, contenant :
- Un nombre variable de backlinks.
- Une fetch qui peut inclure des liens sortants.
Les requêtes de crawl sont envoyées à Barkrowler, qui gère les files d’attente pour appliquer des limites de vitesse et assurer le respect des serveurs externes. Envoyer trop de requêtes en même temps à un hôte ou un domaine est contre-productif.
L’espace de stockage est limité. Comme le web évolue constamment, il est nécessaire de supprimer périodiquement les anciennes données pour libérer de l’espace pour de nouveaux crawls.
1. Limitation du taux d’envoi des requêtes
Nous devons prendre en compte plusieurs facteurs, dont l’un est très basique : la bande passante internet. Nos serveurs de crawl sont connectés via des cartes réseau et des routeurs qui ont une capacité maximale. Nous ne pouvons pas crawler plus vite que nous ne pouvons télécharger, donc notre première contrainte est de limiter la fréquence d’envoi des requêtes de crawl.
L’une des premières versions de notre politique de crawl sélectionnait aléatoirement des URLs avec un taux d’échantillonnage ajusté pour atteindre un volume donné de requêtes.
Désormais, nous avons un mécanisme complexe de limitation de taux avec une boucle de rétroaction qui ajuste dynamiquement un seuil cible pour sélectionner les URLs en fonction d’une méthode de pondération.
2. Cibler le Crawl et le Re-Crawl
Explorer le web, c’est comme chasser un trésor : certaines pages sont précieuses, d’autres sans intérêt.
Notre politique doit décider :
- Quand crawler de nouvelles pages : prioriser la découverte pour évaluer la valeur des domaines inexplorés.
- Quand revisiter d’anciennes pages : assurer leur fraîcheur, suivre les modifications, identifier les nouveaux liens ou suppressions de contenu.
Astuce : attribuer un poids plus élevé aux URLs ayant une valeur sémantique élevée ou une importance dans les classements de recherche.
3. Répartition des requêtes entre les hôtes et domaines
Nous ne voulons pas concentrer tout notre crawl sur un seul site tout en en ignorant d’autres. Une bonne politique définit des limites de requêtes par hôte ou domaine pour assurer une distribution équilibrée.
Par exemple :
- Allouer des quotas en fonction de la taille et de la qualité du domaine.
- Utiliser un mélange de répartition proportionnelle et équitable.
Sélection des pages comme un moteur de recherche
Les règles qui déterminent sur quoi nos crawlers vont se concentrer sont un mélange de plusieurs règles de pondération.
Principes de pondération du crawl et du re-crawl
Nous utilisons deux principales métriques comme base :
- BAS (Babbar Authority Score)
- Valeur sémantique, qui mesure la pertinence entre le contenu des pages et les pages vers lesquelles elles pointent.
Nous appliquons ensuite des boosts en fonction de la qualité :
- Langues détectées sur la page.
- Nombre de sites sur un domaine.
- Plateforme d’hébergement utilisée.
Nous appliquons aussi un boost pour les domaines non encore explorés, car certaines informations comme le niveau business ou la plateforme d’hébergement nécessitent un premier crawl pour être connues.
Gestion des défis
Problème de la collecte des déchets
Le web évolue constamment : les pages naissent, évoluent et finissent par disparaître. Notre politique de crawl doit inclure un mécanisme de collecte des déchets pour :
- Supprimer les pages mortes en utilisant un système de durée de vie (TTL).
- Remplacer les contenus obsolètes par des données plus récentes et pertinentes.
Ces règles de collecte interagissent avec le reste de la politique de crawl pour maintenir une vision actualisée du web, ce qui permet de calculer des métriques basées sur les liens et le contenu, à l’image d’un moteur de recherche. Les données évoluent en permanence, tandis que nos ressources restent constantes. Supprimer des données permet d’ajouter de nouvelles pages, de nouveaux sites et de nouveaux domaines.
Conclusion sur la politique de crawl
Concevoir une politique de crawl est à la fois un art et une science. Il s’agit de trouver le bon équilibre entre exploration et efficacité, tout en restant un invité respectueux sur le web. Avec une stratégie solide, nous sommes convaincus que notre crawler nous permet d’avoir une vision juste, précise, fraîche et représentative du web, similaire (bien que plus modeste) à celle des grands moteurs de recherche comme Google. Nos crawlers ne font pas de recherche, mais ils collectent des données avec le même objectif.
Nous comprenons que votre priorité soit de permettre principalement aux moteurs de recherche comme Google d’explorer votre site. Cependant, cette approche favorise le maintien de monopoles. Les crawlers comme le nôtre (et d’autres hors du domaine du SEO) ne sont généralement pas là pour voler votre contenu, vous attaquer par DDoS ou vendre vos données. Notre objectif est simplement de comprendre le web et son contenu afin d’apporter des informations précieuses à nos clients et d’améliorer la qualité du contenu qu’ils produisent.
Chaque règle de votre fichier robots.txt doit être soigneusement réfléchie et testée. Vous pouvez utiliser notre outil babbar.tech pour obtenir la liste des URLs connues de votre site, afin de vous assurer qu’aucune règle ne bloque ou n’autorise involontairement un URL non souhaité.
Exemples de règles de fichiers robots.txt :
Un fichier robots.txt avec un crawl-delay de 15 secondes
Un fichier robots.txt limitant les URLs accessibles au crawler
Il existe de nombreux validateurs de fichiers robots.txt en ligne, il est donc essentiel d’y consacrer du temps pour s’assurer que vos règles sont correctement configurées.