Ce que j’avais mal compris à propos de `robots.txt`

• Après avoir tenté de bloquer tous les crawlers d’un site web via la configuration de robots.txt, j’ai constaté des effets secondaires inattendus
• Les aperçus de publication LinkedIn ont disparu, et j’ai aussi observé une baisse de portée des posts
• La cause venait du fait que robots.txt empêchait LinkedInBot d’accéder à la page, ce qui bloquait la collecte des balises méta
• J’ai alors pris conscience du rôle central de l’Open Graph Protocol dans la génération des aperçus sur les réseaux sociaux
• J’ai corrigé le problème en modifiant robots.txt pour une autorisation partielle, et j’ai compris qu’il fallait tester suffisamment avant tout changement de fonctionnalité

---

Introduction : configuration de robots.txt et apparition d’un problème involontaire

• En apprenant récemment à configurer robots.txt sur mon blog, je me suis mis à réfléchir à la question des droits sur les données de mon contenu
• J’ai modifié robots.txt pour bloquer tous les crawlers du site web
• De manière inattendue, cela a entraîné des résultats indésirables sur le site

Problème d’aperçu des posts LinkedIn

• Après avoir modifié robots.txt, lorsque j’ai publié le lien de mon blog sur LinkedIn, l’aperçu (miniature, résumé) n’apparaissait plus
• Jusqu’alors, l’aperçu s’affichait normalement, mais après le changement, la visibilité et l’engagement ont fortement diminué
• Au début, j’ai pensé qu’il s’agissait d’un problème temporaire, mais le phénomène a persisté plus de deux semaines
• L’analyse avec LinkedIn Post Inspector a montré que robots.txt restreignait l’accès de LinkedInBot, rendant impossible la collecte des métadonnées
• Sur les plateformes sociales, la génération d’aperçus de liens nécessite obligatoirement une requête vers la page et la collecte des balises méta

Présentation de l’Open Graph Protocol

• L’Open Graph Protocol (OGP) est un protocole standard créé par Facebook, qui permet de transformer une page web en objet du graphe social
• L’OGP définit un ensemble minimal de balises méta obligatoires
  • og:title : titre de l’article
  • og:type : type d’objet, par exemple video.movie
  • og:image : URL de l’image miniature
  • og:url : URL canonique de l’objet concerné
• Grâce à ce protocole, le contenu peut être résumé efficacement et affiché de manière attrayante sur diverses plateformes sociales

Résolution via une autorisation partielle dans robots.txt

• Pour résoudre le problème, j’ai modifié robots.txt de façon à n’autoriser que LinkedInBot
• Si l’on a également besoin d’aperçus sur d’autres plateformes sociales, il faut autoriser chaque bot séparément
• Exemple de configuration actuellement appliquée :

  User-agent: LinkedInBot
  Allow: /
  
  User-agent: *
  Disallow: /
  

Retour d’expérience et enseignements

• Bloquer tous les crawlers sans distinction peut entraîner des problèmes de visibilité et de présentation du contenu
• J’ai compris que c’était une erreur d’avoir agi sans tests suffisants sur les effets du changement
• Cette expérience m’a permis d’en apprendre davantage sur l’Open Graph Protocol, LinkedIn Post Inspector et d’autres outils utiles ainsi que sur les standards du web
• Lorsqu’on ajoute ou modifie une fonctionnalité, il est nécessaire d’avoir une compréhension globale des zones impactées et une validation suffisante
• Au départ, je n’avais pas fait le lien entre l’OGP et le blocage via robots.txt, mais cette expérience m’en a fait comprendre l’importance

[GN⁺]

Avis Hacker News

• Autrefois, l’objectif principal de robots.txt était d’éviter les pénalités pour contenu dupliqué dans les moteurs de recherche. Quand on exploitait un site dynamique difficile à gérer, la même page pouvait être exposée sous plusieurs URL à cause des paramètres de requête, etc., et les moteurs de recherche pouvaient la pénaliser. robots.txt servait à dire : « voici l’URL canonique, ignorez le reste ». Il aidait aussi les « gentils » crawlers à ne pas se perdre dans des boucles de liens infinies. Bien sûr, les « mauvais » crawlers n’en avaient rien à faire, et on les bloquait avec des mesures comme le blocage d’IP. Le filtrage basé sur le User-Agent n’avait pas vraiment de sens. Croire qu’un bot malveillant va gentiment respecter les règles est naïf. Le header DNT (Do Not Track) relève de la même logique : c’est comme demander à une entreprise dont le métier est de vous pister de « ne pas vous suivre, s’il vous plaît ». C’est un peu comme l’idée du bit malveillant dans la RFC Evil Bit, qui supposerait qu’un paquet malveillant s’identifie lui-même comme tel

  • Il faut se rappeler que la proposition Evil Bit était une RFC du poisson d’avril voir RFC 3514

  • J’en viens presque à penser que robots.txt joue un rôle similaire à celui d’un sitemap, alors qu’en réalité c’est l’inverse exact. robots.txt indique où le crawler ne doit pas aller, le sitemap indique ce qu’on veut voir indexé. Je ne connaissais pas cette finalité initiale liée à la gestion des pénalités pour contenu dupliqué, et ça apporte un nouveau contexte à la question du contrôle SEO

  • Le point essentiel, c’est que si l’on déclare qu’un comportement est « interdit », cela n’a d’effet que sur certaines entités honnêtes, ou sur celles qui n’ont pas bien masqué leur nom d’user agent par erreur. Au-delà de ça, ça fonctionne mal ; au fond, c’est surtout une mesure symbolique

  • Comme pour le header DNT, les tentatives qui paraissent irréalistes à mettre en œuvre sont souvent critiquées, mais l’idée de DNT visait en réalité à s’appliquer avec un dispositif juridique. Même si un blocage purement technique est difficile, il faut garder à l’esprit qu’à grande échelle, des comportements illégaux peuvent finir par être révélés via des lanceurs d’alerte

  • Certaines personnes croient que, dès lors qu’on fixe des règles, tout le monde les respectera ; je me demande parfois si cette croyance vient d’une différence culturelle

• En 2003, j’ai moi-même créé un moteur de recherche qui crawlait le Web. Comme j’avais mis mon adresse e-mail principale dans le user agent, j’ai reçu énormément de messages de protestation. J’avais pourtant conçu le crawler avec sérieux et courtoisie, mais j’ai eu l’impression que les gens n’en voulaient pas s’il ne s’agissait pas de Google. Cette attitude est précisément ce qui empêche l’émergence de concurrents à Google. Le sujet ne se limite pas au problème des aperçus LinkedIn : il faut aussi penser au fait que le Web doit rester ouvert à une diversité de bots et d’usages. Bien sûr, il faut bloquer les crawlers malveillants, mais considérer tous les bots comme malveillants par défaut n’est pas souhaitable

  • L’expérience la plus agaçante que j’ai eue, en tant qu’exploitant d’un bot bienveillant, c’est quand quelqu’un a lancé une attaque avec un bot malveillant en utilisant le user agent de mon bot, puis que les plaintes sont revenues vers moi

  • On peut vouloir protéger son propre bot, mais en pratique le problème ne concerne pas seulement son bot à soi : c’est qu’il y a environ 9 000 bots similaires qui circulent et consomment excessivement les ressources serveur. En plus, ces bots n’apportent pratiquement aucun trafic référent

  • Au début, moi aussi j’avais adopté une approche consistant à tout bloquer, puis j’ai réalisé à quel point le Web est interconnecté et complexe. Je pense qu’il est important de garder la maîtrise de ses propres ressources. En revanche, quand on choisit d’autoriser ou de bloquer un trafic, il faut se demander « pourquoi » et comprendre ce que fait chaque bot. Cela demande du temps et des efforts. J’ai commencé à m’intéresser à robots.txt à cause des pratiques de crawl massif des entreprises d’IA à des fins d’entraînement. Je veux pouvoir décider moi-même de ce que j’autorise ou non. Tous les bots ne respectent pas robots.txt, mais un grand nombre le font. Une façon simple de le tester consiste à demander à un modèle doté de capacités de navigation de scraper un lien précis. Au fond, ce qui importe davantage pour juger si un bot est malveillant, c’est la manière dont l’entreprise utilise les données et le ressenti que cela m’inspire

  • À l’argument « tous les bots ne sont pas malveillants, donc il ne faut pas tout bloquer », je répondrais qu’adopter une stratégie d’ouverture sans base solide de confiance est risqué

  • Il est naturel de se méfier des crawlers inconnus. La majorité des crawlers sont malveillants, et il est impossible de savoir à l’avance lesquels sont bons ou mauvais ; il est donc logique de considérer par défaut les bots inconnus comme potentiellement malveillants

• J’essaie d’éviter les réactions trop négatives, mais ce qui me surprend ici, c’est à quel point l’auteur semble découvrir avec gravité les conséquences de ses propres actes. Un récit de développement personnel peut avoir son intérêt, mais ce texte ressemble moins à une intuition qu’à un aveu d’ignorance. J’ai finalement l’impression qu’il a surtout été publié pour attirer l’attention

  • L’auteur n’avait tout simplement pas identifié le fetcher d’aperçu de page comme un crawler, et n’avait pas envisagé de le bloquer via robots.txt. Même si ce n’est pas forcément une évidence pour tout le monde, il y avait au moins quelque chose de nouveau qu’il a appris à titre personnel. Je pense que les billets de blog réellement écrits par des humains peuvent relever la qualité moyenne du Web

  • S’il l’a posté ici (sur Hacker News), c’est parce qu’il n’apparaît pas dans Google

  • Il y avait aussi pour moi un aspect réellement nouveau. Ça m’a donné l’occasion d’en apprendre davantage sur l’Open Graph Protocol et le Robots Exclusion Protocol. J’ai tendance à noter et partager ce que j’apprends ou trouve intéressant. Je l’ai partagé en pensant que cela pourrait aussi intéresser d’autres personnes

  • Je me demande comment ce billet s’est retrouvé en page d’accueil. On dirait une longue reformulation d’une évidence : « si on bloque l’eau, les gentils contournent et les méchants ignorent ». En fin de compte, il est évident que robots.txt n’est qu’un « merci de ne pas faire cela », pas un pare-feu

• Le problème de robots.txt, au fond, c’est qu’il filtre non pas selon l’objectif du crawler, mais selon son « identité ». L’auteur a lui aussi bloqué tous les bots pour empêcher la collecte IA, puis a réautorisé les crawlers d’aperçu OpenGraph (LinkedIn, etc.). Mais que faire si le lien est partagé sur Twitter, Mastodon ou d’autres plateformes ? Il faudrait autoriser un à un les UA de tous les réseaux sociaux, ce qui favorise de fait une petite poignée de grandes plateformes. Ce qu’il faudrait réellement, c’est un moyen de dire : « bloquer l’entraînement IA, mais autoriser l’indexation de recherche, les aperçus, l’archivage, etc. » Pour que cela soit appliqué de manière effective, il faudrait sans doute un cadre juridique, même si ce ne serait pas simple non plus

  • Il y a toujours eu des débats sur l’usage fondamental de robots.txt. À mon sens, à l’origine — et encore aujourd’hui — cela concernait surtout les crawlers au sens strict, ceux qui suivent des liens pour découvrir de nouvelles ressources ; les moteurs de recherche en sont l’exemple typique. Mais lorsqu’un utilisateur demande directement une URL précise (par exemple un navigateur, un abonnement iCal, etc.), il n’y a pas lieu de respecter robots.txt. Il est d’ailleurs déjà arrivé que des abonnements soient bloqués à tort parce que des services comme Google Calendar se heurtaient à un robots.txt, et je considère cela comme un mauvais comportement. Pour les aperçus d’URL, si l’utilisateur ne demande qu’un seul lien, on est plus proche d’une requête ciblée que d’un crawl. En revanche, s’il y a de nombreux liens dans un long message, cela ressemble davantage à une forme de crawl. En somme, je pense qu’il reste une zone grise sur la question de savoir si les aperçus d’URL des réseaux sociaux doivent suivre robots.txt

  • Des jeux de données comme Common Crawl peuvent être réutilisés à la fois pour les moteurs de recherche et pour l’entraînement IA. La distinction par usage n’est pas simple

  • On pourrait résoudre cela en séparant l’échange d’informations non pas in-band mais out-of-band. Si l’on fournissait les métadonnées Open Graph via un chemin ou un header distinct, on pourrait autoriser ce chemin — qui ne contient que des données utilitaires — tout en refusant fermement le contenu principal. Un cadre juridique n’est pas nécessairement indispensable

  • J’aime bien l’idée d’un standard permettant d’autoriser ou de bloquer par fonctionnalité ou par finalité. Mais la difficulté sera de vérifier la fonction réelle et d’empêcher l’usurpation, et au final cela rejoint aussi des questions juridiques. En pratique, il faudra probablement réautoriser différentes plateformes pour les aperçus de réseaux sociaux, et j’apprends beaucoup en essayant de choisir avec soin ce qu’il faut autoriser ou bloquer. Entendre différents points de vue m’aide énormément

• À l’OP : 1) vous ne pensiez qu’à LinkedIn, mais en réalité vos liens peuvent aussi être partagés sur Facebook, Bluesky et d’autres réseaux sociaux. J’ai moi-même constaté qu’avec le ai.robots.txt de Facebook, on peut aussi bloquer involontairement les crawlers d’aperçu de FB (exemple de ai.robots.txt).

2. Concernant le classement Google et le blocage via robots.txt, même si d’autres variables entrent en jeu, autoriser le crawl direct est en général bien plus favorable au SEO sur Naver/Google. Si vous bloquez, les vignettes et descriptions n’apparaîtront pas dans les résultats de recherche, ce qui dégrade leur qualité. Si le trafic issu des moteurs de recherche compte pour vous, il faut bien réfléchir avant de bloquer complètement via robots.txt

• Merci pour le retour ! 1) Moi aussi, je n’avais pensé qu’à LinkedIn et HN. Je n’avais pas réalisé que d’autres personnes pouvaient partager les liens de mon blog sur diverses plateformes. Il faudra peut-être que je revoie l’autorisation d’accès pour plusieurs plateformes. 2) Vu l’évolution des moteurs de recherche vers des résumés orientés IA, je pense que le trafic organique vers les sites eux-mêmes va diminuer. Donc la baisse du trafic venant de Google ne me dérange pas tant que ça. Je changerai peut-être d’avis plus tard, mais pour l’instant j’estime que HN et le bouche-à-oreille via les partages sociaux généreront un trafic plus significatif pour mon blog. Je vais continuer à creuser pour vérifier que ma décision ne me desserve pas. Les différents avis m’aident beaucoup dans ma prise de décision

• Une autre conséquence indésirable vient de la confusion entre « crawl » et « indexation » avec robots.txt.
  Pour empêcher totalement l’entrée de nouvelles pages dans l’index Google, bloquer via robots.txt peut être efficace.
  Mais si l’on veut retirer des pages déjà indexées et qu’on se contente de les ajouter dans robots.txt, c’est une erreur. Google ne peut plus les crawler, continue donc à les afficher dans les résultats sans métadonnées, et ne peut pas voir non plus la balise meta noindex, si bien qu’elles peuvent rester longtemps dans les résultats. Google finira par les supprimer complètement, mais le processus peut être extrêmement frustrant

  • Google peut découvrir des URL bloquées par robots.txt via des liens externes, etc., et dans ce cas, même sans pouvoir les crawler, il peut conserver une trace indexée dans les résultats (voir l’avertissement : documentation officielle Google). Pour supprimer complètement une page des résultats de recherche, il faut impérativement placer une balise noindex dans le code ; attention, si robots.txt bloque l’accès, cette balise ne pourra pas être lue

  • Dans mon cas, je ne tiens pas absolument à ce que Google retire ces pages de son index. L’indexation m’importe peu ; ce qui me préoccupe, c’est le crawl et le scraping. Je reconnais avoir parfois employé les termes de manière confuse

• J’ai l’impression que ce texte étire énormément un propos qui aurait pu tenir en une ou deux phrases. Un peu comme quand on rallonge artificiellement une rédaction à l’école

  • Le problème aurait pu être expliqué en un paragraphe. L’objectif de mon texte était de documenter le cheminement allant de mon expérience initiale au problème, puis à mes recherches et à la solution. J’ai volontairement écrit en détail pour que même des non-spécialistes puissent suivre

• La limite fondamentale de robots.txt, c’est qu’au final le vrai problème ne vient pas des bots qui le respectent, mais de ceux qui ne le respectent pas. robots.txt ne contrôle pas la majorité des bots qui posent aujourd’hui des problèmes de trafic. Les bots les plus agressifs, ceux qui abîment les serveurs, ne s’en soucient absolument pas

  • Pour attraper ce type de bots, un « honeypot » peut être utile. Il suffit d’indiquer explicitement dans robots.txt qu’il faut éviter le chemin /honeypot, puis d’ajouter dans index.html un lien masqué avec display:none, comme <a href="/honeypot">ban me</a>. Toute IP qui visite ce chemin peut alors être bloquée immédiatement

  • Je ne comprends pas pourquoi ce commentaire a été downvoté. Rien ne permet de faire confiance au niveau réel de respect de robots.txt chez des entreprises majeures comme OpenAI ou Anthropic. Elles rendent en outre la détection plus difficile en faisant transiter leur trafic via des IP d’ISP résidentiels et diluent leur responsabilité en évitant le pistage direct par le biais de « publicités tierces »

• Ce qui me choque le plus, c’est qu’il existe si peu de bibliothèques de parsing correctement conçues pour interpréter à la fois robots.txt et les balises meta robots, et pour définir clairement la priorité en cas de conflit entre autorisation et interdiction. Le parseur de référence officiel de Google est basé sur C++11, ce qui reste un cas particulier, et pour les bibliothèques Python ou JS réellement utilisées, les développeurs doivent souvent implémenter eux-mêmes une partie du comportement. Dans le cas des meta robots, l’information n’est même pas dans le fichier robots.txt, mais cachée dans index.html. Le problème, c’est que même les auteurs de bots qui veulent bien faire sur le plan éthique peuvent se heurter à une vraie difficulté d’implémentation

  • La bibliothèque standard Python contient urllib.robotparser (documentation officielle). Par ailleurs, rel=nofollow n’a rien à voir avec robots.txt. Cet attribut signifie qu’un moteur de recherche ne doit pas « accorder sa confiance » à ce lien (ne pas lui transmettre de valeur), pas « ne suis pas ce lien » (explication détaillée). L’intention d’origine était d’empêcher le spam consistant à poster massivement des liens vers son propre site dans des communautés en ligne

  • Les développeurs de bots « bienveillants » qui ont peu de moyens ne bombardent pas les serveurs au hasard ; en pratique, le manque de bibliothèques n’est donc pas un problème si gênant pour eux

  • Si l’on veut vraiment créer un bot correct et de bonne foi, il est tout à fait possible d’open-sourcer soi-même une bibliothèque de parsing dans un autre langage. Ce n’est pas particulièrement difficile

• Fait intéressant, Apple aborde le problème autrement. Lorsqu’un lien est partagé dans iMessage, c’est le client de l’expéditeur qui récupère directement les données pour construire l’aperçu. Des services comme LinkedIn font cela côté serveur pour diverses raisons — lutte contre le spam, le phishing, etc. — mais c’est assurément une approche différente

  • Moi aussi, je trouvais logique que ce soit le client qui génère l’aperçu après réception d’un lien dans un message, et je m’attendais d’ailleurs à ce que quelqu’un le fasse remarquer. Cela dit, je comprends aussi les différentes raisons pour lesquelles le serveur scrape lui-même. 1) Se préparer à un futur où toutes les pages pourraient être récupérées et exploitées ; 2) pouvoir continuer à fournir les informations d’aperçu déjà extraites même si la page change, renvoie une 404 ou si la base de données côté client est perdue ; 3) éviter d’avoir à générer l’aperçu côté client et permettre d’afficher rapidement une prévisualisation avec le message. En fin de compte, si comme dans iMessage c’est « l’expéditeur » qui crée l’aperçu, il ne reste que le point 1) et une partie du point 2), et le fait que le serveur puisse réessayer de son côté peut être un meilleur choix en termes de fiabilité