Google a publié une série de posts sur son blog pour webmasters au sujet du fichier robots.txt : proposition de standard du protocole auprès de l'IETF, diffusion de ses outils en open source et arrêt de la prise en compte de certaines directives à l'automne prochain...
Le fichier robots.txt, basé sur le Robots Exclusion Protocol (REP), a été conçu par le webmaster Martijn Koster en 1994, aidé par d'autres éditeurs dont les sites avaient été envahis par des robots "aspirateurs" de données. Depuis cette date, il n'avait pas réellement évolué et n'avait surtout jamais fait l'objet d'un standard officiel du Web, ce qui a amené des interprétations diverses de la part d'éditeurs et de moteurs. Certains outils de recherche, et Google le premier, ont également ajouté des fonctionnalités de façon plus ou moins officieuse (comme le Allow: et bien d'autres possibilités).
Google a alors publié hier un billet sur son blog pour webmasters, expliquant qu'avec l'aide du rédacteur initial de ce protocole, des webmasters et d'autres moteurs de recherche, ils avaient documenté la façon dont le REP est utilisé sur le Web et l'avaient soumis à l'IETF (Internet Engineering Task Force).
Parmi les propositions faites à ce niveau, on peut identifier celles-ci :
- Tout protocole de transfert peut utiliser robots.txt. Par exemple, il ne serait plus limité à HTTP(S) et pourrait également être utilisé pour FTP ou CoAP.
- Les développeurs doivent analyser au moins les 500 premiers kilooctets (en fait, kibioctets) d'un fichier robots.txt. La définition d'une taille de fichier maximale garantit que les connexions ne sont pas ouvertes trop longtemps, ce qui réduit la charge inutile sur les serveurs.
- Un nouveau temps maximum de mise en cache de 24 heures ou une valeur de directive de cache si disponible, donne aux propriétaires de sites web la flexibilité de mettre à jour leur fichier robots.txt quand ils le souhaitent, les robots ne surchargeant pas les sites avec les requêtes robots.txt. Par exemple, dans le cas de HTTP, les en-têtes Cache-Control pourraient être utilisés pour déterminer le temps de mise en cache.
- La spécification prévoit maintenant que lorsqu'un fichier robots.txt auparavant accessible devient inaccessible en raison d'une panne de serveur par exemple, les pages interdites au crawl et connues ne sont pas explorées pendant une période de temps "raisonnablement longue".
- Des propositions ont également été faites pour uniformiser la syntaxe des directives proposées dans le fichier, un domaine qui a évolué dans le temps et qui peut donner suite à plusieurs interprétations parfois.
Le document sera maintenant débattu au sein de l'IETF pour suite à donner éventuelle quant à l'évolution du REP. La suite donc au prochain épisode (cela signifie donc que les changements proposés ne sont pas encore effectifs).
Dans ce cadre, Google a également indiqué qu'il proposait dorénavant en open source l'outil qu'il utilise (librairie C++) pour lire et analyser les fichiers robots.txt des sites web, à l'attention des développeurs qui désireraient l'utiliser et/ou le tester.
Toujours dans cette même veine d'annonces autour du fichier robots.txt, Google a annoncé que certaines directives ne seraient plus prises en compte à partir du 1er septembre prochain : Crawl-delay:, Nofollow: (de toutes façons déjà pas prises en compte par le moteur) et Noindex:, une directive qui était prise en compte par Google mais sans garantie de pérennité, et dont l'usage était donc non recommandé, comme nous l'avions déjà indiqué sur Abondance en novembre 2007, en février 2017 et en avril 2019. La pérennité n'était pas garantie, elle cessera donc officiellement pour cette directive le 1er septembre prochain. Pensez donc à modifier vos fichiers robots.txt si vous l'utilisez !
Rappelons également que la directive Crawl-delay:, par exemple, est en revanche prise en considération par le moteur Bing, qui ne s'est pas encore, semble-t-il, exprimé sur la question (ce qui, n'en doutons, pas, ne saurait tarder)…
Articles complémentaires :
Google Search Console dévoile son nouveau rapport robots.txt
Google-Safety : le crawler qui ignore les Robots.txt
Google va explorer des alternatives au fichier robots.txt
Bonjour,
La balise [ meta name= »Robots » content= »noindex » ] ne sera plus prise en compte, il faut donc indiquer les pages à ne pas indexer dans le fichier robots.txt,
D’une manière générale la balise meta robots ne servira donc plus a rien.
C’est bien cela Oliver ?
Non, c’est le contraire 🙂
Oups! Merci Olivier.
Je n’ai donc rien à changer en ce qui me concerne !
Donc toutes les pages d’un site Web seront indexés en follow
Pour résumé.
Il y a d’autres méthodes que le fichier robots.txt pour bloquer l’indexation d’une page, je pense notamment à la balise meta robot dans le code source d’une page ou encore l’entête de réponse du serveur avec la balise X-Robots-Tag.
Sauf si je fais erreur, ce n’est pas la porte ouverte à tout en index / follow, et heureusement 🙂
Hello,
Du coup, dans mon robots.txt (comparatif-vpn.fr/robots.txt)
Tous les noindex deviendront obsolète, c’est bien ça ??
Comment les remplacer ? Enfin, je veux dire, comment faire pour que Google n’indexe pas mes tags ou mes /go/ (liens d’affiliation) ?
Merci d’avance
Florian
Bonjour. c’est bizarre, pourquoi recopiez-vous les DIsallow: en Noindex: ? Quel est l’intérêt ?
Je ne sais pas trop…c’était comme ça quand je l’ai acheté je n’ai jamais modifié…
Dommage pour la directive noindex, c’était bien pratique de bloquer le crawl et de désindexer en même temps, surtout qu’il n’y a pas d’équivalent. Pour désindexer, obligé de laisser le crawl ouvert, d’attendre que ca désindexe puis de bloquer le crawl avec un disallow.