Comment Google interprète la spécification robots.txt

Les robots d'exploration automatiques de Google sont compatibles avec le protocole d'exclusion des robots. Cela signifie qu'avant l'exploration d'un site, les robots d'exploration de Google téléchargent et analysent son fichier robots.txt afin de déterminer les sections qui peuvent être explorées. Ce protocole ne s'applique pas aux robots d'exploration Google contrôlés par les utilisateurs (abonnements à des flux, par exemple) ni aux robots d'exploration conçus pour renforcer la sécurité des internautes (analyse des logiciels malveillants, par exemple).

Cette page décrit l'interprétation du protocole d'exclusion des robots par Google. Pour connaître la version d'origine, consultez la norme RFC 9309.

Qu'est-ce qu'un fichier robots.txt ?

Si vous ne souhaitez pas que les robots d'exploration accèdent à certaines sections de votre site, vous pouvez créer un fichier robots.txt avec des règles spécifiques. Un fichier robots.txt est un fichier texte simple qui contient des règles indiquant quels robots peuvent accéder à quelles sections d'un site. Par exemple, le fichier robots.txt correspondant à example.com peut se présenter comme suit :

# This robots.txt file controls crawling of URLs under https://example.com.
# All crawlers are disallowed to crawl files in the "includes" directory, such
# as .css, .js, but Google needs them for rendering, so Googlebot is allowed
# to crawl them.
User-agent: *
Disallow: /includes/

User-agent: Googlebot
Allow: /includes/

Sitemap: https://example.com/sitemap.xml

Si vous ne connaissez pas les principes de base du fichier robots.txt, commencez par consulter cette présentation. Vous trouverez également des conseils pour créer un fichier robots.txt.

Emplacement du fichier et plage de validité

Vous devez placer le fichier robots.txt dans le répertoire racine d'un site, en utilisant un protocole compatible. Tout comme les autres URL, l'URL du fichier robots.txt est sensible à la casse. Dans le cas de la recherche Google, les protocoles acceptés sont HTTP, HTTPS et FTP. Avec HTTP et HTTPS, les robots d'exploration récupèrent le fichier robots.txt avec une requête GET non conditionnelle HTTP. Avec le protocole FTP, les robots d'exploration utilisent une commande RETR (RETRIEVE) standard avec une connexion anonyme.

Les règles répertoriées dans le fichier robots.txt s'appliquent seulement à l'hôte, au protocole et au numéro de port sur lesquels le fichier robots.txt est hébergé.

Exemples d'URL de fichiers robots.txt valides

Le tableau suivant contient des exemples d'URL de fichiers robots.txt et les chemins d'accès pour lesquels elles sont valides. La première colonne contient l'URL d'un fichier robots.txt et la deuxième colonne contient les domaines auxquels le fichier robots.txt s'appliquerait ou non.

Exemples d'URL de fichiers robots.txt
https://example.com/robots.txt

Il s'agit du cas général. Il n'est pas valide pour les autres sous-domaines, protocoles ou numéros de port. Il est valide pour tous les fichiers des sous-répertoires avec le même hôte, protocole et numéro de port.

Valides :
  • https://example.com/
  • https://example.com/folder/file
Non valides :
  • https://other.example.com/
  • http://example.com/
  • https://example.com:8181/
https://www.example.com/robots.txt

Un fichier robots.txt placé dans un sous-domaine n'est valide que pour ce sous-domaine.

Valides : https://www.example.com/

Non valides :

  • https://example.com/
  • https://shop.www.example.com/
  • https://www.shop.example.com/
https://example.com/folder/robots.txt Ce n'est pas un fichier robots.txt valide. Les robots d'exploration ne vérifient pas la présence de fichiers robots.txt dans les sous-répertoires.
https://www.exämple.com/robots.txt

Les IDN équivalent à leur version Punycode. Voir aussi la RFC 3492.

Valides :
  • https://www.exämple.com/
  • https://xn--exmple-cua.com/

Non valides : https://www.example.com/

ftp://example.com/robots.txt

Valides : ftp://example.com/

Non valides : https://example.com/

https://212.96.82.21/robots.txt

Un fichier robots.txt avec une adresse IP comme nom d'hôte n'est valide que pour l'exploration de cette adresse IP en tant que nom d'hôte. Il n'est pas automatiquement valide pour tous les sites Web hébergés sur cette adresse IP. Il est toutefois possible que le fichier robots.txt soit partagé, auquel cas il est également disponible sous le nom d'hôte partagé.

Valides : https://212.96.82.21/

Non valides : https://example.com/ (même si le fichier est hébergé sur 212.96.82.21)

https://example.com:443/robots.txt

Les numéros de port standards (80 pour le HTTP, 443 pour le HTTPS, 21 pour le FTP) équivalent à leur nom d'hôte par défaut.

Valides :

  • https://example.com:443/
  • https://example.com/

Non valides : https://example.com:444/

https://example.com:8181/robots.txt

Les fichiers robots.txt sur les numéros de port non standards ne sont valides que pour le contenu accessible via ces numéros de port.

Valides : https://example.com:8181/

Non valides : https://example.com/

Gérer les erreurs et les codes d'état HTTP

Lorsque vous demandez un fichier robots.txt, le code d'état HTTP de la réponse du serveur influe sur la façon dont ce fichier robots.txt sera utilisé par les robots d'exploration Google. Le tableau suivant récapitule la façon dont Googlebot traite les fichiers robots.txt pour différents codes d'état HTTP.

Gérer les erreurs et les codes d'état HTTP
2xx (success) Les codes d'état HTTP qui signalent une opération réussie invitent les robots d'exploration Google à traiter le fichier robots.txt fourni par le serveur.
3xx (redirection)

Google suit au moins cinq sauts de redirection tels que définis par la RFC 1945, puis arrête et le traite comme un code d'état 404 pour le fichier robots.txt. Ce comportement s'applique également à toutes les URL non autorisées de la chaîne de redirection, car le robot d'exploration n'a pas pu récupérer les règles en raison des redirections.

Google ne suit pas les redirections logiques dans les fichiers robots.txt (frames, JavaScript ou redirections Meta Refresh).

4xx (client errors)

Les robots d'exploration Google traitent toutes les erreurs 4xx, à l'exception de 429, comme s'il n'existait pas de fichier robots.txt valide. L'exploration a donc lieu sans restriction.

5xx (server errors)

Étant donné que le serveur n'a pas pu donner de réponse précise à la requête robots.txt de Google, les erreurs de serveur 5xx et 429 sont interprétées temporairement comme si le site était entièrement inaccessible. Google essaiera d'explorer le fichier robots.txt jusqu'à ce qu'il obtienne un code d'état HTTP sans erreur de serveur. Une erreur 503 (service unavailable) entraîne de nouvelles tentatives assez fréquentes. Si le fichier robots.txt est inaccessible pendant plus de 30 jours, la dernière copie en cache du fichier robots.txt est utilisée. Si aucune copie en cache n'est disponible, Google considère qu'aucune restriction d'exploration ne s'applique.

Si vous devez suspendre temporairement l'exploration, nous vous recommandons de diffuser un code d'état HTTP 503 pour chaque URL du site.

Si nous parvenons à déterminer qu'un site est configuré à tort pour afficher 5xx au lieu du code d'état 404 pour les pages manquantes, nous traitons l'erreur 5xx de ce site comme une erreur 404. Par exemple, si le message d'erreur sur une page qui renvoie un code d'état 5xx indique "Page introuvable", nous interprétons le code d'état comme 404 (not found).

Autres erreurs Un fichier robots.txt impossible à explorer en raison d'erreurs DNS ou d'erreurs de réseau, telles que des délais d'inactivité, des réponses non valides, des connexions réinitialisées ou suspendues, des erreurs de segmentation HTTP ou autres, est considéré comme une erreur de serveur.

Mise en cache

Google met généralement en cache le contenu du fichier robots.txt pendant 24 heures, mais peut rallonger cette durée si l'actualisation de la version mise en cache n'est pas possible (en raison d'un délai d'inactivité ou de l'erreur 5xx, par exemple). La réponse mise en cache peut être partagée par différents robots d'exploration. Nous pouvons augmenter ou diminuer la durée de vie du cache avec des en-têtes HTTP max-age Cache-Control.

Format de fichier

Le fichier robots.txt doit être un fichier de texte brut encodé en UTF-8. Ses lignes doivent être séparées par CR, CR/LF ou LF.

Google ignore les lignes non valides des fichiers robots.txt, y compris l'indicateur d'ordre des octets (BOM) Unicode au début du fichier, et n'utilise que les lignes valides. Par exemple, si le contenu téléchargé est au format HTML au lieu de règles de fichier robots.txt, Google essaie d'analyser le contenu et d'extraire les règles, puis ignore tout le reste.

De même, si l'encodage des caractères du fichier robots.txt n'est pas UTF-8, Google peut ignorer les caractères qui ne font pas partie de la plage de caractères UTF-8, ce qui pourrait invalider les règles du fichier robots.txt.

Google applique actuellement une limite de taille de fichier robots.txt de 500 kibioctets (Kio). Tout contenu qui dépasse cette taille est ignoré. Pour réduire la taille du fichier robots.txt, consolidez les règles susceptibles d'entraîner la création d'un fichier robots.txt surdimensionné. Par exemple, placez le contenu exclu dans un répertoire distinct.

Syntaxe

Les lignes robots.txt valides se composent d'un champ, du deux-points et d'une valeur. Les espaces sont facultatifs, mais recommandés pour améliorer la lisibilité. Les espaces au début et à la fin de la ligne sont ignorés. Pour inclure un commentaire, ajoutez le caractère # au début de la ligne. Gardez à l'esprit que tout ce qui suit le caractère # sera ignoré. Le format général est <field>:<value><#optional-comment>.

Google accepte les champs suivants :

  • user-agent : identifie le robot d'exploration auquel les règles s'appliquent.
  • allow : chemin d'URL à explorer.
  • disallow : chemin d'URL à ne pas explorer.
  • sitemap : URL complète d'un sitemap.

Les champs allow et disallow sont également appelés règles (ou directives). Ces règles sont toujours spécifiées sous la forme rule: [path][path] est facultatif. Par défaut, il n'existe pas de restrictions d'exploration pour les robots d'exploration désignés. Les robots d'exploration ignorent les règles sans [path].

Si elle est spécifiée, la valeur [path] est relative à la racine du site Web à partir duquel le fichier robots.txt a été exploré (en utilisant les mêmes protocole, numéro de port, hôte et noms de domaine). La valeur du chemin doit commencer par / pour désigner la racine. Elle est sensible à la casse. En savoir plus sur la correspondance des URL en fonction des valeurs des chemins

user-agent

La ligne user-agent identifie les robots d'exploration auxquelles les règles s'appliquent. Pour obtenir la liste complète des chaînes de user-agent que vous pouvez utiliser dans votre fichier robots.txt, consultez la page consacrée à nos robots d'exploration et à nos chaînes de user-agent.

La valeur de la ligne user-agent n'est pas sensible à la casse.

disallow

La règle disallow spécifie les chemins auxquels les robots d'exploration identifiés par la ligne user-agent avec laquelle la règle disallow est regroupée ne doivent pas avoir accès. Si aucun chemin n'est spécifié, les robots d'exploration ignorent la règle.

Google ne peut pas indexer le contenu des pages dont l'exploration n'est pas autorisée, mais peut tout de même indexer l'URL et l'afficher dans les résultats de recherche sans extrait. Découvrez comment bloquer l'indexation.

La valeur de la règle disallow est sensible à la casse.

Utilisation :

disallow: [path]

allow

La règle allow spécifie les chemins auxquels les robots d'exploration désignés peuvent accéder. Si aucun chemin n'est spécifié, les robots d'exploration ignorent la règle.

La valeur de la règle allow est sensible à la casse.

Utilisation :

allow: [path]

sitemap

Google, Bing et d'autres moteurs de recherche connus acceptent le champ sitemap dans le fichier robots.txt, tel que défini par sitemaps.org.

La valeur du champ sitemap est sensible à la casse.

Utilisation :

sitemap: [absoluteURL]

La ligne [absoluteURL] pointe vers l'emplacement d'un sitemap ou d'un fichier d'index de sitemaps. Il doit s'agir d'une URL complète, comprenant le protocole et l'hôte. Elle ne doit pas nécessairement être encodée au format URL. L'URL n'a pas besoin non plus d'être hébergée au même endroit que le fichier robots.txt. Vous pouvez spécifier plusieurs champs sitemap. Le champ "sitemap" n'est associé à aucun user-agent spécifique et peut être suivi par tous les robots d'exploration, à condition que l'exploration soit autorisée.

Exemple :

user-agent: otherbot
disallow: /kale

sitemap: https://example.com/sitemap.xml
sitemap: https://cdn.example.org/other-sitemap.xml
sitemap: https://ja.example.org/テスト-サイトマップ.xml

Regroupement de lignes et de règles

Vous pouvez regrouper les règles qui s'appliquent à plusieurs user-agents en répétant les lignes user-agent pour chaque robot.

Exemple :

user-agent: a
disallow: /c

user-agent: b
disallow: /d

user-agent: e
user-agent: f
disallow: /g

user-agent: h

Cet exemple comprend quatre groupes de règles distincts :

  • Un groupe pour le user-agent "a"
  • Un groupe pour le user-agent "b"
  • Un groupe pour les user-agents "e" et "f"
  • Un groupe pour le user-agent "h"

Pour obtenir la description technique d'un groupe, consultez le paragraphe 2.1 du protocole d'exclusion des robots.

Ordre de priorité des user-agents

Un seul groupe est valide pour un robot d'exploration particulier. Pour déterminer le groupe de règles approprié, les robots d'exploration Google recherchent dans le fichier robots.txt celui dont le user-agent correspond le plus spécifiquement possible au user-agent du robot d'exploration. Les autres groupes sont ignorés. Tout texte qui ne correspond pas est ignoré (par exemple, googlebot/1.2 et googlebot* sont équivalents à googlebot). L'ordre des groupes dans le fichier robots.txt n'est pas pris en compte.

S'il existe plusieurs groupes pour un user-agent, toutes les règles des groupes qui lui sont applicables sont combinées dans un seul et même groupe. Les groupes spécifiques à un user-agent et les groupes généraux (*) ne sont pas combinés.

Exemples

Correspondance des champs user-agent

user-agent: googlebot-news
(group 1)

user-agent: *
(group 2)

user-agent: googlebot
(group 3)

Voici la façon dont les robots d'exploration sélectionneraient le groupe approprié :

Groupe suivi par robot d'exploration
Googlebot-News googlebot-news suit le groupe 1, car le groupe 1 est le groupe le plus spécifique.
Googlebot (Web) googlebot suit le groupe 3.
Google StoreBot Storebot-Google suit le groupe 2, car il n'existe aucun groupe Storebot-Google spécifique.
Googlebot-News (lors de l'exploration d'images) Lors de l'exploration des images, googlebot-news suit le groupe 1. googlebot-news n'explore pas les images pour Google Images. Il suit donc uniquement le groupe 1.
Autre robot (Web) Les autres robots d'exploration Google suivent le groupe 2.
Autre robot (Actualités) Les autres robots Google qui explorent le contenu d'actualités, mais qui ne s'identifient pas comme googlebot-news, suivent le groupe 2. Même s'il existe une entrée pour un robot d'exploration lié, elle n'est valide qu'en cas de correspondance exacte.

Regroupement de règles

Si un fichier robots.txt contient plusieurs groupes pertinents pour un user-agent spécifique, les robots d'exploration Google fusionnent ces groupes en interne. Exemple :

user-agent: googlebot-news
disallow: /fish

user-agent: *
disallow: /carrots

user-agent: googlebot-news
disallow: /shrimp

Les robots d'exploration regroupent les règles en fonction du user-agent. Exemple :

user-agent: googlebot-news
disallow: /fish
disallow: /shrimp

user-agent: *
disallow: /carrots

Les règles autres que allow, disallow et user-agent sont ignorées par l'analyseur robots.txt. En d'autres termes, l'extrait robots.txt suivant est traité comme un groupe. Dès lors, les attributs user-agent a et b sont tous les deux concernés par la règle disallow: / :

user-agent: a
sitemap: https://example.com/sitemap.xml

user-agent: b
disallow: /

Lorsque les robots d'exploration traitent les règles du fichier robots.txt, ils ignorent la ligne sitemap. Voici un exemple de la façon dont les robots d'exploration peuvent interpréter l'extrait robots.txt précédent :

user-agent: a
user-agent: b
disallow: /

Correspondance d'URL en fonction des valeurs des chemins

Google utilise la valeur du chemin d'accès dans les règles allow et disallow pour déterminer si une règle s'applique à une URL spécifique d'un site. Pour ce faire, la règle est comparée au composant du chemin d'URL que le robot d'exploration tente de suivre. Les caractères ASCII non encodés en 7 bits dans un chemin d'accès peuvent être inclus sous forme de caractères UTF-8 ou de caractères d'échappement encodés en UTF-8 sous forme de pourcentage conformément à la RFC 3986.

Seuls certains caractères génériques pour les valeurs de chemin sont compatibles avec Google, Bing et les autres moteurs de recherche connus. Ces caractères génériques sont les suivants :

  • * désigne 0 ou plusieurs instances d'un caractère valide.
  • $ désigne la fin de l'URL.

Le tableau suivant montre comment les différents caractères génériques affectent l'analyse :

Exemples de correspondances de chemins
/ Correspond à l'URL racine et à toute URL de niveau inférieur.
/* Équivaut à /. Le caractère générique de fin est ignoré.
/$ Ne correspond qu'à la racine. Toute URL de niveau inférieur peut être explorée.
/fish

Correspond à tout chemin commençant par /fish. Notez que la correspondance est sensible à la casse.

Correspondances :

  • /fish
  • /fish.html
  • /fish/salmon.html
  • /fishheads
  • /fishheads/yummy.html
  • /fish.php?id=anything

Pas de correspondance :

  • /Fish.asp
  • /catfish
  • /?id=fish
  • /desert/fish
/fish*

Équivaut à /fish. Le caractère générique de fin est ignoré.

Correspondances :

  • /fish
  • /fish.html
  • /fish/salmon.html
  • /fishheads
  • /fishheads/yummy.html
  • /fish.php?id=anything

Pas de correspondance :

  • /Fish.asp
  • /catfish
  • /?id=fish
  • /desert/fish
/fish/

Correspond à tous les éléments du dossier /fish/.

Correspondances :

  • /fish/
  • /fish/?id=anything
  • /fish/salmon.htm

Pas de correspondance :

  • /fish
  • /fish.html
  • /animals/fish/
  • /Fish/Salmon.asp
/*.php

Correspond à tout chemin contenant .php.

Correspondances :

  • /index.php
  • /filename.php
  • /folder/filename.php
  • /folder/filename.php?parameters
  • /folder/any.php.file.html
  • /filename.php/

Pas de correspondance :

  • / (même si cela correspond à /index.php)
  • /windows.PHP
/*.php$

Correspond à tout chemin se terminant par .php.

Correspondances :

  • /filename.php
  • /folder/filename.php

Pas de correspondance :

  • /filename.php?parameters
  • /filename.php/
  • /filename.php5
  • /windows.PHP
/fish*.php

Correspond à tout chemin contenant /fish et .php, dans cet ordre.

Correspondances :

  • /fish.php
  • /fishheads/catfish.php?parameters

Pas de correspondance : /Fish.PHP

Ordre de priorité des règles

Lors de la mise en correspondance des règles robots.txt avec les URL, les robots d'exploration utilisent la règle la plus spécifique en fonction de la longueur de son chemin. Dans le cas de règles contradictoires, y compris celles comportant des caractères génériques, Google utilise la règle la moins restrictive.

Les exemples suivants illustrent la règle appliquée par les robots d'exploration Google pour une URL donnée.

Exemples de situations
https://example.com/page
allow: /p
disallow: /

Règle applicable : allow: /p, car elle est plus spécifique.

https://example.com/folder/page
allow: /folder
disallow: /folder

Règle applicable : allow: /folder, car dans le cas des règles contradictoires, Google utilise la règle la moins restrictive.

https://example.com/page.htm
allow: /page
disallow: /*.htm

Règle applicable : disallow: /*.htm, car le chemin d'accès à la règle est plus long et correspond à davantage de caractères dans l'URL. Il est donc plus spécifique.

https://example.com/page.php5
allow: /page
disallow: /*.ph

Règle applicable : allow: /page, car dans le cas des règles contradictoires, Google utilise la règle la moins restrictive.

https://example.com/
allow: /$
disallow: /

Règle applicable : allow: /$, car elle est plus spécifique.

https://example.com/page.htm
allow: /$
disallow: /

Règle applicable : disallow: /, car la règle allow ne s'applique qu'à l'URL racine.