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 que vous ne savez peut-être pas sur le fonctionnement de Googlebot.

1. Googlebot ignore certaines URL

Googlebot ne visitera pas toutes les URL trouvées sur le Web. Plus un site Web est grand, plus il risque que certaines de ses URL ne soient pas explorées et indexées.

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 "Méthode et appareil pour gérer un arriéré d'analyses d'URL en attente"

"L'analyse d'URL en attente est rejetée par le backlog si la priorité de l'analyse d'URL en attente 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 moins importantes soient rejetées à l'avance par la structure de données du backlog.  »

Ces citations suggèrent que Google attribue une priorité de crawl à chaque URL et peut refuser d'explorer 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 adresse IP / nom de domaine e l'importance de conserver la fraîcheur contenu changeant rapidement, comme les dernières nouvelles. Étant donné que la capacité d'analyse est une ressource rare, la capacité d'analyse est préservée avec des scores de priorité" .

Qu'est-ce qui rend une URL populaire ? Le brevet Google" Minimisez la visibilité du contenu obsolète dans la recherche sur le Web, notamment en examinant les intervalles d'analyse des documents Web ”Définit la popularité des URL comme une combinaison de deux facteurs : le taux de vue et le PageRank.

PageRank est également mentionné dans ce contexte dans d'autres brevets, tels que Planificateur pour le robot d'exploration des moteurs 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é, sur la base d'une estimation de probabilité mise à jour de satisfaire les analyses d'URL demandées. Cette estimation de probabilité est basée sur la fraction estimée des analyses d'URL demandées qui peuvent être satisfaites. La fraction d'analyses d'URL demandées qui peuvent être satisfaites a pour numérateur l'intervalle moyen des demandes ou la différence d'heure d'arrivée entre les demandes 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 " Minimiser la visibilité du contenu obsolète dans la recherche Web « J'ai trouvé des informations sur la façon dont ce mécanisme est structuré.

Google est en divisant les pages en niveaux dans en fonction de la fréquence à laquelle l'algorithme décide qu'ils doivent être répétés.

"Dans un mode de réalisation, les documents sont partitionnés à plusieurs niveaux, chaque niveau comprenant une pluralité de documents partageant des plages de balayage 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 numérisation, le moteur de recherche réévalue la plage de numérisation Web d'un document et détermine si le document doit être déplacé du calque actuel vers un autre calque." .

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 Minimisez la visibilité du contenu obsolète dans la recherche sur le Web, notamment en examinant les intervalles d'analyse des documents Web , Google ne réindexe pas une page après chaque crawl.

"Si le document a considérablement changé depuis la dernière analyse, le planificateur envoie un avertissement à un indexeur de contenu (non illustré), qui remplace les entrées d'index pour la version précédente du document avec des entrées d'index pour la version actuelle du document. Ensuite, le planificateur calcule un nouvel intervalle d'analyse 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 le PageRank), le taux de rafraîchissement et/ou le pourcentage de clics. . Si le contenu du document n'a pas changé ou si les modifications apportées au contenu ne sont pas critiques, il n'est pas nécessaire de réindexer le document. "

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é ?

"Ensuite, le planificateur calcule un nouvel intervalle d'analyse 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 le PageRank), le taux de rafraîchissement 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.

Selon le brevet, le PageRank en est également un élément important. C'est une raison de plus pour vous assurer que vous utilisez correctement les liens internes pour connecter 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, comme je Classement des documents en fonction du comportement des utilisateurs et/ou des données de fonctionnalités , qui montrent que Google est bien conscient que certains liens sur une page donnée sont plus importants que d'autres. De plus, Google pourrait 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 construction de modèle peut générer une règle indiquant que des liens avec un texte d'ancrage supérieur à une taille de police donnée sont plus susceptibles d'être sélectionnés que des liens avec un texte d'ancrage inférieur à la taille de police particulière. Aussi, ou alternativement, la génération du modèle d'unité peut générer une règle indiquant que les liens positionnés plus près du haut d'un document sont plus susceptibles d'être sélectionnés que les liens positionnés vers le bas du 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 construction du modèle peut générer une règle indiquant qu'un lien placé sous la rubrique 'More Top Stories' sur le site cnn.com a une forte probabilité d'être sélectionné. De plus, ou en variante, l'unité de construction de modèle peut générer une règle indiquant qu'un lien associé à une URL de destination qui contient le mot « domainpark » a une faible probabilité d'être sélectionné. Aussi, ou alternativement, l'unité de génération de modèle peut générer une règle indiquant qu'un lien associé à un document source contenant une popup a une faible probabilité d'être sélectionné.

En remarque, en conversation avec Barry Schwartz et Danny Sullivan en 2016 , Gary IIIoui a confirmé que Google qualifie les liens de  pied de page ou pingouin.

"Fondamentalement, nous avons des tonnes d'étiquettes de liens ; par exemple, c'est un lien de pied de page, en pratique, qui a une valeur bien inférieure à un lien dans le contenu. Donc, une autre étiquette serait 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 est tout sauf un simple processus consistant à suivre tous les liens que Googlebot peut trouver. C'est vraiment compliqué et a un impact direct sur la visibilité de recherche de n'importe quel site Web. J'espère que cet article vous a aidé à comprendre un peu mieux l'exploration et que vous pourrez utiliser ces connaissances pour améliorer la façon dont Googlebot explore votre site Web et se classe mieux en conséquence et en quoi cela compte au-delà d'avoir un site avec une arborescence correcte et structure et un bon processus de création de liens internes et externes, il est plus que jamais indispensable de disposer d'hébergements et de serveurs rapides et performants afin de gérer au mieux le processus de crawling des Google Bots et donc de maximiser la rentabilité du budget de crawling.

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