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 la 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ℱ ; Facebook, Inc. dĂ©tient les droits sur FacebookÂź ; 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. Ce site n'est affiliĂ©, sponsorisĂ© ou autrement associĂ© Ă  aucune 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 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