12 juillet 2022

5 choses que vous ne saviez pas sur Google Bot

Googlebot doit explorer votre site Web avant que les utilisateurs ne le voient dans les résultats de recherche. Bien qu'il s'agisse d'une étape essentielle, elle ne reçoit pas la même attention que de nombreux autres sujets. Je pense que c'est en partie parce que Google ne partage pas beaucoup d'informations sur la manière exacte dont Googlebot parcourt le Web.

Bannière GoogleBot

Voyant que beaucoup de nos clients ont du mal à explorer et à indexer correctement leurs sites Web, nous avons parcouru la documentation de Google sur l'exploration, le rendu et l'indexation afin de mieux comprendre l'ensemble du processus.

Certains de nos résultats étaient extrêmement surprenants, tandis que d'autres ont confirmé nos théories précédentes.

Voici 5 choses que j'ai apprises et que vous ignorez peut-être sur le fonctionnement de Googlebot.

1. Googlebot ignore certaines URL

Googlebot ne visite pas toutes les URL qu'il trouve sur le Web. Plus un site Web est important, plus le risque que certaines de ses URL ne soient pas explorées et indexées est élevé.

Pourquoi Googlebot ne se contente-t-il pas de visiter toutes les URL qu'il peut trouver sur le Web ? Il y a deux raisons à cela :

  1. Google a des ressources limitées. Il y a beaucoup de spam sur le Web, Google doit donc développer des mécanismes pour éviter de visiter des pages de mauvaise qualité. Google donne la priorité à l'exploration des pages les plus importantes.
  2. Googlebot est conçu pour être un bon citoyen du Web. Limitez l'analyse pour éviter le plantage du serveur.

Le mécanisme de choix des URL à visiter est décrit dans le brevet de Google intitulé « Méthode et appareil de gestion d'un arriéré d'explorations d'URL en attente » :

« L’analyse d’URL en attente est rejetée de la liste d’attente si sa priorité ne dépasse pas le seuil de priorité . »

« Différents critères sont appliqués aux analyses d'URL demandées, afin que les analyses d'URL les moins importantes soient rapidement rejetées de la structure de données en attente. »

Ces citations suggèrent que Google attribue une priorité d'exploration à chaque URL et peut refuser l'exploration de certaines URL qui ne répondent pas aux critères de priorité.

La priorité attribuée aux URL est déterminée par deux facteurs :

  1. La popularité d'une URL,
  2. Importance d'explorer une URL donnée pour garder l'index Google à jour.

La priorité peut être plus élevée en fonction de la popularité du contenu ou de l'adresse IP/nom de domaine et de l'importance de maintenir la fraîcheur des informations évoluant rapidement, comme les actualités de dernière minute. La capacité d'exploration étant une ressource limitée, elle est gérée avec soin grâce à un système de points de priorité.

Qu'est-ce qui rend une URL populaire ? Le brevet de Google, « Minimiser la visibilité du contenu obsolète dans la recherche Web, notamment en examinant les intervalles d'exploration du Web pour les documents », définit la popularité d'une URL comme une combinaison de deux facteurs : le taux de consultation et le PageRank.

PageRank est également mentionné dans ce contexte dans d'autres brevets, tels que Scheduler pour robot d'exploration de moteur de recherche.

Mais il y a encore une chose que vous devez savoir. Lorsque votre serveur répond lentement, le seuil de priorité que vos URL doivent respecter augmente.

« Le seuil de priorité est ajusté en fonction d'une estimation de probabilité actualisée de la satisfaction des requêtes d'exploration d'URL. Cette estimation de probabilité repose sur la fraction estimée des requêtes d'exploration d'URL qui peuvent être satisfaites. Le numérateur de cette fraction est l'intervalle moyen entre les requêtes, soit la différence de temps d'arrivée entre deux requêtes d'exploration d'URL. »

Pour résumer, Googlebot peut ignorer l'exploration de certaines de vos URL si elles n'atteignent pas un seuil de priorité basé sur le PageRank de l'URL et le nombre de vues qu'elle obtient.

Cela a de fortes implications pour tout grand site Web.

Si une page n'est pas explorée, elle ne sera pas indexée et n'apparaîtra pas dans les résultats de recherche.

À faire:

  1. Assurez-vous que votre serveur et votre site Web sont rapides.
  2. Vérifiez les journaux de votre serveur. Ils vous fournissent des informations précieuses sur les pages de votre site Web qui sont explorées par Google.

 

2. Google divise les pages en niveaux pour les réexplorer

Google veut que les résultats de recherche soient aussi frais et à jour que possible. Cela n'est possible que lorsqu'un mécanisme est en place pour réanalyser le contenu déjà indexé.

Dans le brevet intitulé « Minimiser la visibilité des contenus obsolètes dans la recherche Web », j'ai trouvé des informations sur la structure de ce mécanisme.

Google classe les pages en différents niveaux en fonction de la fréquence à laquelle son algorithme décide de les reclasser.

« Dans un mode de réalisation, les documents sont divisés en plusieurs niveaux, chaque niveau comprenant une pluralité de documents qui partagent des plages d'exploration Web similaires. »

Par conséquent, si vos pages ne sont pas numérisées aussi souvent que vous le souhaitez, elles se trouvent probablement dans une couche de document avec un intervalle de numérisation plus long.

Cependant, ne désespérez pas ! Vos pages n'ont pas besoin de rester indéfiniment dans ce calque - elles peuvent être déplacées.

Chaque fois qu'une page est explorée, c'est l'occasion pour vous de prouver qu'elle vaut la peine d'être explorée à nouveau plus fréquemment à l'avenir.

« Après chaque analyse, le moteur de recherche réévalue la zone d'exploration du Web d'un document et détermine si celui-ci doit être déplacé du niveau actuel vers un autre niveau . »

Il est clair que si Google constate qu'une page change fréquemment, elle peut être déplacée vers un autre niveau. Mais il ne suffit pas de changer quelques éléments esthétiques mineurs : Google analyse à la fois la qualité et la quantité des modifications apportées à vos pages.

À faire:

  1. Utilisez les journaux de votre serveur et Google Search Console pour savoir si vos pages sont explorées assez souvent.
  2. Si vous souhaitez réduire l'intervalle de crawl de vos pages, améliorez régulièrement la qualité de votre contenu.

 

3. Google ne réindexe pas une page à chaque crawl

Selon le brevet intitulé « Minimiser la visibilité du contenu obsolète dans la recherche Web, notamment en examinant les intervalles d'exploration des documents Web » , Google ne réindexe pas une page après chaque exploration.

Si le document a subi des modifications importantes depuis la dernière exploration, le planificateur envoie une alerte à un indexeur de contenu (non représenté), qui remplace les entrées d'index de l'ancienne version par celles de la version actuelle. Le planificateur calcule ensuite un nouvel intervalle d'exploration pour le document en fonction de l'ancien intervalle et d'informations supplémentaires, telles que son importance (mesurée par un score, comme le PageRank), sa fréquence de mise à jour et/ou son taux de clics. Si le contenu du document est resté inchangé ou si les modifications sont mineures, il n'est pas nécessaire de le réindexer.

Je l'ai vu plusieurs fois dans la nature.

De plus, j'ai fait quelques expériences sur des pages existantes sur Onely.com. J'ai remarqué que si je ne modifiais qu'une partie intelligente du contenu, Google ne le réindexait pas.

 

À faire:

Si vous avez un site Web d'actualités et que vous mettez fréquemment à jour vos publications, vérifiez si Google le réindexe assez rapidement. Si ce n'est pas le cas, vous pouvez être assuré que Google Actualités recèle un potentiel inexploité pour vous.

 

4. Taux de clics et lien interne

Dans la citation précédente, avez-vous remarqué comment le taux de clics était mentionné ?

« Le planificateur calcule ensuite un nouvel intervalle d'exploration Web pour le document en fonction de son ancien intervalle et d'informations supplémentaires, telles que l'importance du document (mesurée par un score, tel que PageRank), la fréquence de mise à jour et/ou le taux de clics . »

Cette citation suggère que le taux de clics affecte le taux d'exploration d'une URL.

Imaginons que nous ayons deux URL. L'un est visité par les utilisateurs de Google 100 fois par mois, un autre est visité 10000 10000 fois par mois. Toutes choses étant égales par ailleurs, Google devrait revoir plus fréquemment celle qui compte XNUMX XNUMX visites par mois.

D'après le brevet, le PageRank joue également un rôle important. C'est une raison supplémentaire de veiller à utiliser correctement les liens internes pour relier les différentes parties de votre domaine.

 

À faire:

  • Google et les utilisateurs peuvent-ils accéder facilement aux sections les plus importantes de votre site ?
  • Est-il possible d'atteindre toutes les URL importantes ? Avoir toutes vos URL disponibles dans le sitemap peut ne pas suffire.

 

5. Tous les liens ne sont pas créés égaux

Nous venons d'expliquer comment, selon les brevets de Google, le PageRank affecte fortement le crawl.

La première implémentation de l'algorithme PageRank n'était pas sophistiquée, du moins à en juger par les normes actuelles. C'était relativement simple : si vous receviez un lien d'une page * importante *, vous seriez mieux classé que les autres pages.

Cependant, la première implémentation de PageRank a été publiée il y a plus de 20 ans. Google a beaucoup changé depuis.

J'ai trouvé des brevets intéressants, notamment les articles sur le classement basé sur le comportement des utilisateurs et/ou les données de fonctionnalités , qui démontrent que Google est parfaitement conscient que certains liens d'une page sont plus importants que d'autres. De plus, Google peut traiter ces liens différemment.

« Ce modèle de navigation raisonnable reflète le fait que tous les liens associés à un document n'ont pas la même probabilité d'être suivis. Des exemples de liens improbables peuvent inclure des liens vers les "Conditions d'utilisation", des bannières publicitaires et des liens sans rapport avec le document. "

Google analyse donc les liens en fonction de leurs différentes caractéristiques. Par exemple, ils peuvent examiner la taille de la police et la position du lien.

« Par exemple, l'unité de génération de modèles peut générer une règle indiquant que les liens dont le texte d'ancrage est plus grand qu'une certaine taille de police sont plus susceptibles d'être cliqués que les liens dont le texte d'ancrage est plus petit que cette taille de police. De plus, ou alternativement, l'unité de génération de modèles peut générer une règle indiquant que les liens situés plus haut dans un document sont plus susceptibles d'être cliqués que les liens situés plus bas dans le document. »

Il semble même que Google puisse créer des règles pour évaluer les liens au niveau du site Web. Par exemple, Google peut voir que les liens dans "More Top News" sont cliqués plus fréquemment afin de leur donner plus de poids.

« (…) l’unité de modélisation peut générer une règle indiquant qu’un lien placé sous la rubrique « Plus d’articles importants » sur le site web cnn.com a une forte probabilité d’être cliqué. De plus, ou alternativement, l’unité de modélisation peut générer une règle indiquant qu’un lien associé à une URL de destination contenant le mot « domainpark » a une faible probabilité d’être cliqué. De plus, ou alternativement, l’unité de modélisation peut générer une règle indiquant qu’un lien associé à un document source contenant une fenêtre contextuelle a une faible probabilité d’être cliqué. »

À noter également que, lors d'une conversation avec Barry Schwartz et Danny Sullivan en 2016 , Gary IIIyes a confirmé que Google étiquette les liens, tels que « pied de page » ou « pingouin ».

« En gros, nous avons une multitude d'étiquettes de liens ; par exemple, un lien en bas de page a beaucoup moins de valeur qu'un lien intégré au contenu. Une autre étiquette possible serait donc une étiquette Penguin en temps réel . »

Résumant les points clés :

  • Google donne la priorité à chaque page explorée
  • Plus le site Web est rapide, plus Google explore rapidement.
  • Google n'explorera pas et n'indexera pas toutes les URL. Seules les URL dont la priorité est supérieure au seuil seront explorées.
  • Les liens sont traités différemment selon leurs caractéristiques et leur positionnement
  • Google ne réindexe pas une page après chaque exploration. Cela dépend de la gravité des modifications apportées.

En conclusion

Comme vous pouvez le constater, l'exploration du Web est loin d'être un simple processus consistant à suivre tous les liens que Googlebot peut trouver. C'est un processus complexe qui a un impact direct sur la visibilité de chaque site Web dans les résultats de recherche. J'espère que cet article vous a permis de mieux comprendre l'exploration du Web et que vous pourrez utiliser ces connaissances pour améliorer la façon dont Googlebot explore votre site et, par conséquent, son classement. Il montre également l'importance, outre un site Web bien structuré et une stratégie de liens internes et externes efficace, de disposer d'un hébergement et de serveurs rapides et performants pour optimiser le processus d'exploration de Googlebot et ainsi maximiser la rentabilité de votre budget d'exploration.

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

AVIS DE NON-RESPONSABILITÉ, Mentions légales et droits d'auteur. Red Hat, Inc. détient les droits sur Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale de la AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de la Fondation FreeBSD ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt ; Oracle Corporation détient les droits sur Oracle®, MySQL®, MyRocks®, VirtualBox® et ZFS® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; PostgreSQL® est une marque déposée de PostgreSQL Global Development Group ; SQLite® est une marque déposée de Hipp, Wyrick & Company, Inc. ; KeyDB® est une marque déposée d'EQ Alpha Technology Ltd. ; Typesense® est une marque déposée de Typesense Inc. ; REDIS® est une marque déposée de Redis Labs Ltd ; F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB ; HAProxy® est une marque déposée de HAProxy Technologies LLC ; Traefik® est une marque déposée de Traefik Labs ; Envoy® est une marque déposée de CNCF ; Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited ; Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal® ; Shopify® est une marque déposée de Shopify Inc. ; BigCommerce® est une marque déposée de BigCommerce Pty. Ltd.; TYPO3® est une marque déposée de la TYPO3 Association; Ghost® est une marque déposée de la Ghost Foundation; Amazon Web Services, Inc. détient les droits sur AWS® et Amazon SES® ; Google LLC détient les droits sur Google Cloud™, Chrome™ et Google Kubernetes Engine™ ; Alibaba Cloud® est une marque déposée d'Alibaba Group Holding Limited ; DigitalOcean® est une marque déposée de DigitalOcean, LLC ; Linode® est une marque déposée de Linode, LLC ; Vultr® est une marque déposée de The Constant Company, LLC ; Akamai® est une marque déposée d'Akamai Technologies, Inc. ; Fastly® est une marque déposée de Fastly, Inc. ; Let's Encrypt® est une marque déposée d'Internet Security Research Group ; Microsoft Corporation détient les droits sur Microsoft®, Azure®, Windows®, Office® et Internet Explorer® ; Mozilla Foundation détient les droits sur Firefox® ; Apache® est une marque déposée de The Apache Software Foundation ; Apache Tomcat® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée de PHP Group ; Docker® est une marque déposée de Docker, Inc. Kubernetes® est une marque déposée de The Linux Foundation ; OpenShift® est une marque déposée de Red Hat, Inc. ; Podman® est une marque déposée de Red Hat, Inc. ; Proxmox® est une marque déposée de Proxmox Server Solutions GmbH ; VMware® est une marque déposée de Broadcom Inc. ; CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV ; Grafana® est une marque déposée de Grafana Labs ; Prometheus® est une marque déposée de The Linux Foundation ; Zabbix® est une marque déposée de Zabbix LLC ; Datadog® est une marque déposée de Datadog, Inc. ; Ceph® est une marque déposée de Red Hat, Inc. ; MinIO® est une marque déposée de MinIO, Inc. ; Mailgun® est une marque déposée de Mailgun Technologies, Inc. ; SendGrid® est une marque déposée de Twilio Inc. Postmark® est une marque déposée d'ActiveCampaign, LLC ; cPanel®, LLC détient les droits sur cPanel® ; Plesk® est une marque déposée de Plesk International GmbH ; Hetzner® est une marque déposée de Hetzner Online GmbH ; OVHcloud® est une marque déposée d'OVH Groupe SAS ; Terraform® est une marque déposée de HashiCorp, Inc. ; Ansible® est une marque déposée de Red Hat, Inc. ; cURL® est une marque déposée de Daniel Stenberg ; Facebook®, Inc. détient les droits sur Facebook®, Messenger® et Instagram®. Ce site n'est pas affilié, sponsorisé ou autrement associé à l'une des entités mentionnées ci-dessus et ne représente aucune de ces entités de quelque manière que ce soit. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées sont la propriété de leurs titulaires respectifs. MANAGED SERVER® est une marque déposée européenne de MANAGED SERVER SRL, dont le siège social est situé Via Flavio Gioia, 6, 62012 Civitanova Marche (MC), Italie et le siège opérationnel Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italie.

JUSTE UN MOMENT !

Vous êtes-vous déjà demandé si votre hébergement était nul ?

Découvrez dès maintenant si votre hébergeur vous pénalise avec un site web lent digne des années 1990 ! Résultats immédiats.

Fermer le CTA
Retour en haut de page