Bing, noarchive, nocache, et Copilot : quelle différence avec robots.txt ?
L’écosystème Bing est l’un des meilleurs rappels du fait que toutes les décisions de contrôle liées à l’IA ne passent pas par un token de crawler.
Parfois, la bonne couche n’est pas un bloc User-agent supplémentaire dans robots.txt.
Parfois, la bonne couche est une instruction meta à la page.
C’est exactement ce que Microsoft a documenté lorsqu’il a étendu noarchive et nocache à Bing Chat et, plus largement, à la couche de réponse de type Copilot.
La version courte
Voici la distinction la plus simple.
| Contrôle | Rôle principal | Question à laquelle il aide à répondre |
|---|---|---|
robots.txt | Accès au crawl | Bingbot ou un autre crawler peut-il récupérer cette URL ? |
nocache | Usage limité pour les réponses et l’entraînement | Bing peut-il n’utiliser que l’URL, le titre, et l’extrait plutôt que le contenu complet ? |
noarchive | Exclusion plus forte des usages de réponse IA | Ce contenu doit-il rester hors des réponses Bing Chat / Copilot et de l’entraînement, tout en restant présent dans les résultats Search ? |
C’est précisément pour cela que Robots.txt vs meta robots vs x-robots-tag reste un article fondateur.
Ce que Microsoft a documenté
La documentation publique de Microsoft pour Bing Chat a introduit une extension concrète de contrôles meta standard.
Microsoft a expliqué que les éditeurs pouvaient utiliser des contrôles existants pour décider comment le contenu déjà présent dans l’index Bing pouvait être utilisé dans Bing Chat et dans l’entraînement des modèles fondamentaux génératifs de Microsoft.
Les cas clés sont les suivants.
Aucun tag spécial
Si une page n’utilise ni nocache ni noarchive, Microsoft indique que le contenu peut être inclus dans les réponses Bing Chat et peut aussi être utilisé pour l’entraînement des modèles fondamentaux.
nocache
Si une page utilise nocache, Microsoft indique que le contenu peut toujours être inclus dans les réponses Bing Chat, mais que Bing n’affichera alors que l’URL, le titre, et l’extrait dans la réponse.
Microsoft précise aussi que, pour du contenu dans l’index Bing marqué nocache, seuls l’URL, le titre, et l’extrait peuvent être utilisés pour l’entraînement des modèles fondamentaux génératifs de Microsoft.
noarchive
Si une page utilise noarchive, Microsoft indique que le contenu ne sera pas inclus dans les réponses Bing Chat, ne sera pas lié dans ces réponses, et ne sera pas utilisé pour l’entraînement des modèles fondamentaux génératifs.
Les deux ensemble
Microsoft indique que si nocache et noarchive sont tous deux présents, Bing traite la page comme nocache.
C’est un détail opérationnel important, parce que beaucoup d’équipes s’attendent intuitivement à l’inverse.
Pourquoi ce n’est pas la même chose que robots.txt
La vraie question de contrôle, ici, n’est pas seulement :
« Le crawler peut-il récupérer cette URL ? »
C’est aussi :
« Comment le contenu déjà présent dans l’index Bing peut-il être réutilisé dans des contextes de réponse et d’entraînement ? »
C’est un autre problème.
robots.txt reste pertinent quand le vrai sujet est l’accès au crawl pour bingbot ou un autre crawler.
Mais la documentation IA de Bing montre clairement qu’une partie des choix d’usage aval pour les réponses et l’entraînement se gouverne via des directives à la page comme noarchive et nocache.
C’est exactement pour cela qu’une politique sérieuse d’accès machine ne peut pas tout aplatir dans un seul fichier.
Ce que cela implique en pratique
Voici le bon parcours de décision.
Objectif : contrôler l’accès au crawl
Utilisez robots.txt.
C’est toujours la bonne couche quand la question est de savoir si le crawler Bing peut récupérer l’URL.
Objectif : rester dans les résultats Search tout en limitant l’usage dans les réponses IA
Utilisez nocache ou noarchive, selon le niveau de restriction souhaité.
Microsoft indique explicitement que les contenus marqués nocache ou noarchive peuvent toujours apparaitre dans les résultats de recherche Bing.
C’est l’un des détails pratiques les plus importants.
Objectif : rester lié dans les réponses IA tout en limitant la réutilisation du contenu complet
nocache est la voie la plus limitée.
Il autorise Bing à utiliser l’URL, le titre, et l’extrait plutôt que le contenu complet.
Objectif : garder la page hors des réponses de type Copilot
noarchive est la surface d’exclusion la plus forte.
Trois erreurs fréquentes
1. Attendre de robots.txt seul qu’il exprime la politique Bing sur l’usage dans les réponses
C’est trop étroit.
Bing a explicitement documenté noarchive et nocache comme des contrôles significatifs pour Bing Chat et les usages IA associés.
2. Supposer que noarchive retire la page des résultats de recherche Bing
Microsoft indique que non.
Le contenu peut toujours apparaitre dans les résultats Search.
3. Publier nocache et noarchive sans comprendre la priorité
Microsoft indique que lorsque les deux sont présents, Bing traite le contenu comme nocache.
C’est le type de nuance qu’une équipe doit connaitre avant de croire avoir choisi le contrôle le plus strict.
Où Better Robots.txt se place
Better Robots.txt ne transforme pas des contrôles meta Bing à la page en directives robots.txt.
Ce serait la mauvaise couche.
Là où il aide, c’est en rendant la distinction entre les couches explicite :
- l’accès au crawl relève de
robots.txt; - certaines décisions d’usage aval relèvent des meta controls ;
- d’autres questions de gouvernance machine relèvent de signaux d’usage, de
llms.txt, ou de l’infrastructure.
Cette clarté est précieuse en elle-même parce qu’elle évite les erreurs de catégorie.
Le bon modèle mental
Le modèle mental Bing le plus sûr est celui-ci :
robots.txt= accès au crawlnocache= usage limité pour les réponses et l’entraînementnoarchive= exclusion plus forte des usages de réponse de type Copilot et de l’entraînement- la visibilité Search Bing peut rester intacte même quand ces meta controls sont utilisés
Moins on mélange ces couches, moins on risque de publier une politique contradictoire.