Caractéristiques du fichier robots.txt

Extrait

Ce document décrit la façon dont Google gère le fichier robots.txt qui vous permet de contrôler l'exploration et l'indexation des sites Web accessibles au public par nos robots d'exploration.

Vocabulaire de l'obligation

Les mots clés "DOIT", "NE DOIT PAS", "REQUIS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT" et "FACULTATIF" employés aux présentes doivent être interprétés conformément au sens qui leur est conféré dans la RFC 2119.

Définitions de base

Définitions
Robot d'exploration Un robot d'exploration est un service ou un agent qui explore des sites Web. De manière générale, un robot d'exploration accède de manière récursive et automatique aux URL connues d'un hôte qui présente un contenu consultable via les navigateurs Web standards. Au fur et à mesure de la découverte de nouvelles URL (par divers moyens, notamment à partir de liens sur des pages existantes et explorées ou à partir de fichiers sitemap), ces dernières sont explorées de la même façon.
User-agent Un moyen d'identifier un robot d'exploration ou un ensemble de robots d'exploration précis.
Instructions Liste des consignes applicables à un robot d'exploration ou à un groupe de robots d'exploration énoncées dans le fichier robots.txt.
URL Uniform Resource Locators tels que définis dans la RFC1738.
Propre à Google Ces éléments sont propres à notre mise en œuvre des fichiers robots.txt, et ne sont pas nécessairement pertinents pour des tierces parties.

Applicabilité

Tous les robots d'exploration automatiques de Google suivent les consignes énoncées dans le présent document. Lorsqu'un agent accède à des URL au nom d'un internaute (par exemple, pour des projets de traduction, pour s'abonner manuellement à des flux ou pour analyser des logiciels malveillants, etc.), ces consignes ne s'appliquent pas.

Emplacement du fichier et plage de validité

Vous devez placer le fichier robots.txt dans le répertoire racine de l'hôte, et veiller à ce qu'il soit accessible via le protocole et le numéro de port appropriés. Les protocoles généralement acceptés pour les fichiers robots.txt (et l'exploration de sites Web) sont les protocoles "HTTP" et "HTTPS". Avec ces protocoles, le fichier robots.txt est exploré à l'aide d'une requête HTTP GET non conditionnelle.

Propre à Google : nous acceptons et nous suivons également les instructions des fichiers robots.txt pour les sites FTP. Nous accédons aux fichiers robots.txt basés sur un FTP via le protocole FTP, à l'aide d'une connexion anonyme.

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

Exemples d'URL de fichiers robots.txt valides

Exemples d'URL de fichiers robots.txt
http://example.com/robots.txt Valide pour :
  • http://example.com/
  • http://example.com/folder/file
Non valide pour :
  • http://other.example.com/
  • https://example.com/
  • http://example.com:8181/
http://www.example.com/robots.txt

Valide pour : http://www.example.com/

Non valide pour :

  • http://example.com/
  • http://shop.www.example.com/
  • http://www.shop.example.com/
http://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.
http://www.müller.eu/robots.txt Valide pour :
  • http://www.müller.eu/
  • http://www.xn--mller-kva.eu/

Non valide pour : http://www.muller.eu/

ftp://example.com/robots.txt

Valide pour : ftp://example.com/

Non valide pour : http://example.com/

Propre à Google : nous utilisons les fichiers robots.txt pour les ressources FTP.

http://212.96.82.21/robots.txt

Valide pour : http://212.96.82.21/

Non valide pour : http://example.com/ (même s'il est hébergé sur 212.96.82.21)

http://example.com:80/robots.txt

Valide pour :

  • http://example.com:80/
  • http://example.com/

Non valide pour : http://example.com:81/

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

Valide pour : http://example.com:8181/

Non valide pour : http://example.com/

Gestion des codes de résultat HTTP

L'exploration de fichiers robots.txt peut généralement aboutir à trois résultats différents :

  • autorisation totale : tout le contenu peut être exploré ;
  • interdiction totale : aucun contenu ne peut être exploré ;
  • autorisation conditionnelle : les instructions du fichier robots.txt déterminent la possibilité d'explorer certains contenus.
Gestion des codes de résultat HTTP
2xx (réussite) Codes de résultat HTTP qui signalent qu'une demande d'exploration avec "autorisation conditionnelle" a été traitée correctement.
3xx (redirection) Nous suivons généralement les redirections jusqu'à ce que nous trouvions un résultat valide ou que nous reconnaissions une boucle. Nous suivons un nombre limité de sauts de redirection (la RFC 1945 sur le HTTP/1.0 autorise jusqu'à 5 sauts) avant d'arrêter et d'afficher le code d'état 404. La gestion de redirections entre des fichiers robots.txt et des URL bloquées n'est ni définie ni conseillée. La gestion des redirections logiques du fichier robots.txt suivant le contenu HTML qui affiche un code 2xx (redirections JavaScript, cadres ou méthode Meta Refresh) n'est ni définie ni conseillée.
4xx (erreurs de client) Nous traitons toutes les erreurs 4xx de la même manière et supposons qu'il n'existe aucun fichier robots.txt valide. Nous estimons donc qu'il n'y a pas de restrictions. Il s'agit d'une "autorisation totale" de l'exploration.
5xx (erreur de serveur)

Les erreurs de serveur sont considérées comme des erreurs temporaires qui se traduisent par une "interdiction totale" de l'exploration. La demande est renouvelée jusqu'à l'obtention d'un code de résultat HTTP qui n'indique plus une erreur de serveur. Une erreur 503 (Service non disponible) entraîne de nouvelles tentatives assez fréquentes. Pour suspendre temporairement l'exploration, il est recommandé d'afficher un code de résultat HTTP 503. La gestion des erreurs de serveur permanentes n'est pas définie.

Propre à Google : si nous parvenons à déterminer qu'un site renvoie de manière incorrecte une erreur 5xx au lieu d'une erreur 404 en cas de pages manquantes, nous traitons les erreurs 5xx de ce site comme des erreurs 404.

Demandes infructueuses ou données incomplètes La gestion d'un fichier robots.txt impossible à explorer en raison d'erreurs DNS ou de réseau, telles que des délais avant expiration, des réponses non valides, des connexions réinitialisées ou suspendues, des erreurs de segmentation HTTP, etc., n'est pas définie.
Mise en cache La mise en cache d'une demande de fichier robots.txt dure généralement un jour, mais peut être plus longue lorsqu'il est impossible d'actualiser la version en cache, par exemple en raison de délais avant expiration ou d'erreurs 5xx. 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 Cache-Control max-age.

Format de fichier

Le format de fichier attendu est du texte brut encodé en UTF-8. Le fichier se compose d'enregistrements (lignes) séparés par CR, CR/LF ou LF.

Nous prenons uniquement en compte les enregistrements valides. Nous ignorons tout autre contenu. Par exemple, si le document obtenu est une page HTML, nous traitons uniquement les lignes de texte valides. Nous ignorons le reste, sans afficher de message d'erreur ou d'avertissement.

Si vous utilisez un codage des caractères qui n'est pas un sous-ensemble de la norme UTF-8, cela risque de poser des problèmes lors de l'analyse du contenu du fichier.

Nous ignorons tout BOM (indicateur d'ordre des octets) Unicode facultatif placé au début du fichier robots.txt.

Chaque enregistrement se compose d'un champ, de deux-points et d'une valeur. Les espaces sont facultatives (mais recommandées pour améliorer la lisibilité). Il est possible d'inclure des commentaires n'importe où dans le fichier en utilisant le caractère "#". Nous estimons que tout le contenu situé entre le début d'un commentaire et la fin de l'enregistrement forme un commentaire, et nous l'ignorons. Le format général est <field>:<value><#optional-comment>. Nous ignorons les espaces au début et à la fin de l'enregistrement.

L'élément <field> n'est pas sensible à la casse. L'élément <value> peut être sensible à la casse, en fonction de l'élément <field>.

La gestion des éléments <field> avec des fautes de frappe/erreurs simples, par exemple "useragent" au lieu de "user-agent", n'est pas définie. Certains user-agents peuvent les interpréter comme des instructions correctes.

Chaque robot d'exploration peut avoir une taille maximale de fichier. Tout contenu qui dépasse cette taille est donc susceptible d'être ignoré. La taille limite que nous imposons actuellement est de 500 Ko.

Syntaxe formelle/définition

Cette description, qui utilise les conventions de la RFC 822, est semblable à la forme de Backus-Naur (BNF), à l'exception près qu'on utilise "|" pour désigner les alternatives. Les littéraux sont indiqués entre guillemets "", les parenthèses "(" et ")" servent à regrouper les éléments, les éléments facultatifs sont entourés de crochets [], et il est possible de faire précéder certains éléments de <n>* pour désigner n répétitions ou plus de l'élément suivant. Par défaut, n vaut 0.

robotstxt = *entries
entries = *( ( <1>*startgroupline
  *(groupmemberline | nongroupline | comment)
  | nongroupline
  | comment) )
startgroupline = [LWS] "user-agent" [LWS] ":" [LWS] agentvalue [comment] EOL
groupmemberline = [LWS] (
  pathmemberfield [LWS] ":" [LWS] pathvalue
  | othermemberfield [LWS] ":" [LWS] textvalue) [comment] EOL
nongroupline = [LWS] (
  urlnongroupfield [LWS] ":" [LWS] urlvalue
  | othernongroupfield [LWS] ":" [LWS] textvalue) [comment] EOL
comment = [LWS] "#" *anychar
agentvalue = textvalue

pathmemberfield = "disallow" | "allow"
othermemberfield = ()
urlnongroupfield = "sitemap"
othernongroupfield = ()

pathvalue = "/" path
urlvalue = absoluteURI
textvalue = *(valuechar | SP)
valuechar = <any UTF-8 character except ("#" CTL)>
anychar = <any UTF-8 character except CTL>
EOL = CR | LF | (CR LF)

La syntaxe des éléments "absoluteURI", "CTL", "CR", "LF" et "LWS" est définie dans la RFC 1945. La syntaxe du "chemin d'accès" est définie dans la RFC 1808.

Regroupement d'enregistrements

Les enregistrements sont classés en différentes catégories en fonction du type d'élément <field> :

  • début-de-groupe
  • membre-du-groupe
  • non-groupe

Tous les enregistrements de type membre-du-groupe compris entre un enregistrement de type début-de-groupe et le prochain enregistrement de ce genre sont considérés comme un groupe d'enregistrements. Le seul élément de champ de type début-de-groupe est user-agent. Plusieurs lignes de type début-de-groupe placées directement les unes à la suite des autres suivent les enregistrements de type membre-du-groupe après la dernière ligne de type début-de-groupe. Nous ignorons tous les enregistrements de type membre-du-groupe qui ne sont pas précédés par un enregistrement de type début-de-groupe. Les enregistrements de type non-groupe sont tous valides, indépendamment de tous les groupes.

Les éléments <field> valides, que nous détaillerons plus loin dans ce document, sont les suivants :

  • user-agent (début de groupe) ;
  • disallow (uniquement valide comme enregistrement de type membre-du-groupe) ;
  • allow (uniquement valide comme enregistrement de type membre-du-groupe) ;
  • sitemap (enregistrement de type non-groupe).

Tous les autres éléments <field> peuvent être ignorés.

L'élément de type début-de-groupe user-agent sert à indiquer pour quel robot d'exploration le groupe est valide. Un seul groupe d'enregistrements est valide par robot d'exploration. Nous expliquerons l'ordre de priorité plus loin dans ce document.

Exemples de groupes :

user-agent: a
disallow: /c

user-agent: b
disallow: /d

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

Il existe trois groupes distincts, un pour "a", un autre pour "b", et un seul et même groupe pour "e" et "f". Chaque groupe possède son propre enregistrement de type membre-du-groupe. Remarquez l'utilisation facultative d'un espace blanc (une ligne vide) pour améliorer la lisibilité.

Ordre de priorité des user-agents

Un seul groupe d'enregistrements de type membre-du-groupe est valide par robot d'exploration. Le robot d'exploration doit déterminer le bon groupe d'enregistrements en trouvant le groupe avec le user-agent le plus spécifique, mais où il y a toujours une correspondance. Le robot d'exploration ignore tous les autres groupes d'enregistrements. Le user-agent n'est pas sensible à la casse. Le texte sans correspondance est ignoré. Par exemple googlebot/1.2 et googlebot* équivalent à googlebot. L'ordre des groupes dans le fichier robots.txt n'est pas significatif.

Exemple

En supposant que le fichier robots.txt soit le suivant :

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 d'enregistrements suivi par robot d'exploration
Googlebot Google Actualités Le groupe d'enregistrements suivi est le groupe 1. Le robot d'exploration suit seulement le groupe le plus spécifique. Il ignore tous les autres.
Googlebot (Web) Le groupe d'enregistrements suivi est le groupe 3.
Googlebot Google Images Le groupe d'enregistrements suivi est le groupe 3. Il n'existe aucun groupe googlebot-images spécifique, c'est pourquoi le robot d'exploration suit le groupe plus générique.
Googlebot Google Actualités (lors de l'exploration d'images) > Le groupe d'enregistrements suivi est le groupe 1. Ces images sont explorées pour et par Googlebot Google Actualités, c'est pourquoi le robot d'exploration suit seulement le groupe Googlebot Google Actualités.
Autre robot (Web) Le groupe d'enregistrements suivi est le groupe 2.
Autre robot (Actualités) Le groupe d'enregistrements suivi est 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.

Vous pouvez également consulter la page consacrée à nos robots d'exploration et à nos chaînes de user-agents.

Enregistrements de type membre-du-groupe

Cette rubrique traite seulement des enregistrements de type membre-du-groupe propres à Google et en général. Pour ces types d'enregistrements, on parle également d'"instructions" destinées aux robots d'exploration. Ces instructions sont de type directive: [path][path] est facultatif. Par défaut, il n'existe pas de restrictions d'exploration pour les robots d'exploration désignés. Nous ignorons les instructions sans chemin d'accès [path].

Si elle est spécifiée, la valeur [path] doit être définie à partir de la racine du site Web dont 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 d'accès doit commencer par "/" pour désigner la racine. Le chemin d'accès est sensible à la casse. Pour en savoir plus, consultez la rubrique "Correspondance d’URL en fonction des valeurs des chemins d'accès" ci-dessous.

disallow

L'instruction disallow indique les chemins d'accès non accessibles par les robots d'exploration désignés. Si aucun chemin d'accès n'est spécifié, les robots d'exploration ignorent l'instruction.

Utilisation :

disallow: [path]

allow

L'instruction allow indique les chemins d'accès accessibles par les robots d'exploration désignés. Si aucun chemin d'accès n'est spécifié, les robots d'exploration ignorent l'instruction.

Utilisation :

allow: [path]

Correspondance d’URL en fonction des valeurs des chemins d'accès

La valeur du chemin d'accès permet de déterminer si oui ou non une règle s'applique à une URL spécifique d'un site. À l'exception des caractères génériques, le chemin d'accès sert à correspondre au début d'une URL et de toutes les URL valides qui commencent par le même chemin d'accès. 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" de valeurs de chemin d'accès sont compatibles avec Google, Bing, Yahoo et Ask, à savoir :

  • * désigne 0 ou plusieurs instances d'un caractère valide.
  • $ désigne la fin de l'URL.
Exemples de correspondances de chemins d'accès
/ Correspond à l'URL racine et à toute URL de niveau inférieur.
/* Équivaut à /. Le caractère générique de fin est ignoré.
/fish

Correspond à :

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

Ne correspond pas à :

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

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

Correspond à :

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

Ne correspond pas à :

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

La barre oblique finale signifie qu'il y a une correspondance avec tout élément de ce dossier.

Correspond à :

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

Ne correspond pas à :

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

Correspond à :

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

Ne correspond pas à :

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

Correspond à :

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

Ne correspond pas à :

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

Correspond à :

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

Ne correspond pas à : /Fish.PHP

Enregistrements de type non-membre-du-groupe que nous acceptons

sitemap

Compatible avec Google, Ask, Bing, Yahoo ; défini sur sitemaps.org.

Utilisation :

sitemap: [absoluteURL]

[absoluteURL] redirige vers un sitemap, un fichier d'index de sitemaps ou une URL équivalente. L'URL n'a pas besoin d'être hébergée au même endroit que le fichier robots.txt. Plusieurs entrées sitemap peuvent exister. En tant qu'enregistrements de type non-membre-du-groupe, ils ne sont pas liés à des user-agents précis, et tous les robots d'exploration peuvent les suivre, tant qu'ils n'ont pas été bloqués.

Ordre de priorité des enregistrements de type membre-du-groupe

Au niveau des enregistrements de type membre-du-groupe, en particulier pour les instructions allow et disallow, la règle la plus spécifique basée sur la longueur de l'entrée [path] l'emporte sur la règle la moins spécifique (la plus courte). L'ordre de priorité des règles avec des caractères génériques n'est pas défini.

Exemples de situations
http://example.com/page

Allow: /p

Disallow: /

Verdict: allow

http://example.com/folder/page

Allow: /folder

Disallow: /folder

Verdict: allow

http://example.com/page.htm

Allow: /page

Disallow: /*.htm

Verdict: undefined

http://example.com/

Allow: /$

Disallow: /

Verdict: allow

http://example.com/page.htm

Allow: /$

Disallow: /

Verdict: disallow

Envoyer des commentaires concernant…