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.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'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 The FreeBSD Foundation ; 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® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; 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. 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®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. 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. Hetzner Online GmbH détient les droits sur Hetzner® ; OVHcloud est une marque déposée d'OVH Groupe SAS ; cPanel®, LLC détient les droits sur cPanel® ; Plesk® est une marque déposée de Plesk International GmbH ; Facebook, Inc. détient les droits sur Facebook®. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente en aucune manière aucune de ces entités. 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 appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italie.

JUSTE UN MOMENT !

Souhaitez-vous voir comment votre WooCommerce fonctionne sur nos systèmes sans avoir à migrer quoi que ce soit ? 

Entrez l'adresse de votre site WooCommerce et vous obtiendrez une démonstration navigable, sans avoir à faire absolument quoi que ce soit et entièrement gratuite.

Non merci, mes clients préfèrent le site lent.
Retour en haut de page