Présentation des crawlers et fetchers de Google (agents utilisateurs)

Google utilise des crawlers et des fetchers pour effectuer des actions pour ses produits, soit automatiquement, soit déclenchées par une demande de l’utilisateur. Crawler (parfois aussi appelé “robot” ou “araignée”) est un terme générique pour tout programme utilisé pour
découvrir et scanner automatiquement des sites Web. Les fetchers agissent comme un programme tel que
wget qui effectuent généralement une seule requête au nom d’un utilisateur. Les clients de Google se répartissent en trois catégories :

Propriétés techniques des crawlers et fetchers de Google

Les crawlers et fetchers de Google sont conçus pour être exécutés simultanément par des milliers de machines afin d’améliorer les performances et de s’adapter à la croissance du Web. Pour optimiser l’utilisation de la bande passante, ces clients sont répartis dans de nombreux centres de données à travers le monde afin qu’ils soient situés à proximité des sites auxquels ils pourraient accéder. Par conséquent, vos journaux peuvent montrer des visites provenant de plusieurs adresses IP. Google émet principalement à partir d’adresses IP situées aux États-Unis. Si Google détecte qu’un site bloque les requêtes provenant des États-Unis, il peut tenter de crawler à partir d’adresses IP situées dans d’autres pays.

Protocoles de transfert pris en charge

Les crawlers et fetchers de Google prennent en charge HTTP/1.1 et
HTTP/2. Les crawlers utiliseront la version du protocole qui offre les meilleures performances de crawl et peuvent changer de protocole entre les sessions de crawl en fonction des statistiques de crawl précédentes. La version de protocole par défaut utilisée par les crawlers de Google est HTTP/1.1 ; le crawl via HTTP/2 peut économiser des ressources informatiques (par exemple, CPU, RAM) pour votre site et Googlebot, mais sinon, il n’y a aucun avantage spécifique au produit Google pour le site (par exemple, aucune augmentation du classement dans la recherche Google). Pour désactiver le crawl via HTTP/2, demandez au serveur qui héberge votre site de répondre avec un 421 code d’état HTTP
lorsque Google tente d’accéder à votre site via HTTP/2. Si cela n’est pas réalisable, vous pouvez
envoyer un message à l’équipe de crawling

(cependant, cette solution est temporaire).
L’infrastructure de crawling de Google prend également en charge le crawling via FTP (tel que défini dans RFC959
et ses mises à jour) et FTPS (tel que défini dans RFC4217

et ses mises à jour), cependant, le crawling via ces protocoles est rare.

Encodages de contenu pris en charge
Les crawlers et fetchers de Google prennent en charge les encodages de contenu (compressions) suivants :,
gzipdeflate
, etBrotli (br)
. Les encodages de contenu pris en charge par chaque agent utilisateur Google sont annoncés dans l'en-tête Accept-Encoding
de chaque requête qu'ils effectuent. Par exemple,.

Accept-Encoding: gzip, deflate, br

Limites de taille de fichier
Par défaut, les crawlers et fetchers de Google ne crawlent que les 15 premiers Mo d’un fichier, et tout contenu au-delà de cette limite est ignoré. Cependant, des projets individuels peuvent définir des limites différentes pour leurs crawlers et fetchers, ainsi que pour différents types de fichiers. Par exemple, un crawler Google comme Googlebot

peut avoir une limite de taille plus petite (par exemple, 2 Mo), ou spécifier une limite de taille de fichier plus grande pour un PDF que pour un HTML.

Taux de crawl et charge de l’hôte
Notre objectif est de crawler autant de pages de votre site que possible à chaque visite sans surcharger votre serveur. Si votre site a du mal à suivre les requêtes de crawl de Google, vous pouvezréduire le taux de crawl
. Notez que l’envoi du
code de réponse HTTP

inapproprié aux crawlers de Google peut affecter la façon dont votre site apparaît dans les produits Google.

Mise en cache HTTP
L’infrastructure de crawling de Google prend en charge la mise en cache HTTP heuristique telle que définie dans lanorme de mise en cache HTTP , spécifiquement via l'en-tête de réponse ETag et de requête If-None-Match , et l'en-tête de réponse Last-Modified et de requête If-Modified-Since

indépendamment de la préférence des crawlers de Google. Ces en-têtes sont également utilisés par d’autres applications telles que les CMS. Si les deux champs d'en-tête de réponse ETag et Last-Modified sont présents dans la réponse HTTP, les crawlers de Google utilisent l'ETag valeur comme
exigée par la norme HTTP. Pour les crawlers de Google spécifiquement, nous recommandons d’utiliser
ETag
au lieu de l’en-tête Last-Modified pour indiquer la préférence de mise en cache, car
ETag ne présente pas de problèmes de formatage de date.

Les autres directives de mise en cache HTTP ne sont pas prises en charge.

Les crawlers et fetchers individuels de Google peuvent ou non utiliser la mise en cache, en fonction des besoins du produit auquel ils sont associés. Par exemple, Googlebot prend en charge la mise en cache lors du re-crawling des URL pour la recherche Google, et Storebot-Google ne prend en charge la mise en cache que dans certaines conditions.

Pour implémenter la mise en cache HTTP pour votre site, contactez votre fournisseur d’hébergement ou de système de gestion de contenu.

ETag et If-None-Match

L’infrastructure de crawling de Google prend en charge ETag et If-None-Match tels que définis par la norme
HTTP Caching standard. En savoir plus sur l’en-tête de réponse
ETag
et son homologue d’en-tête de requête,
If-None-Match.

Last-Modified et If-Modified-Since

L’infrastructure de crawling de Google prend en charge Last-Modified et
If-Modified-Since tels que définis par la norme
HTTP Caching standard
avec les mises en garde suivantes :

• La date dans l’en-tête Last-Modified doit être formatée conformément à la norme
  HTTP standard. Pour éviter les problèmes d’analyse, nous recommandons d’utiliser le format de date suivant : “Jour de la semaine, DD Mon YYYY HH:MM:SSFuseau horaire”. Par exemple,“.
• ”
  Fri, 4 Sep 1998 19:15:56 GMT Bien que non obligatoire, envisagez également de définir le champ max-age de l’en-tête de réponse
  Cache-Control
  pour aider les crawlers à déterminer quand re-crawler l'URL spécifique. Définissez la valeur du champ max-age sur le nombre de secondes attendu pendant lequel le contenu restera inchangé. Par exemple,.

Cache-Control: max-age=94043
En savoir plus sur l'en-tête de réponse
Last-Modified et son homologue d'en-tête de requête,.

If-Modified-Since

Vérifiez les crawlers et fetchers de Google

1. Les crawlers de Google s’identifient de trois manières : L'en-tête de requête HTTP user-agent
2. .
3. L’adresse IP source de la requête.

Le nom d’hôte DNS inverse de l’IP source. Apprenez à utiliser ces détails pour vérifier les crawlers et fetchers de Google. Aperçu des crawlers et fetchers de Google (agents utilisateurs) | Alien Road. Comprenez les propriétés techniques des crawlers et fetchers de Google, y compris les protocoles de transfert pris en charge, la mise en cache et les limites de taille de fichier.
ru.