IABIGEN · English

Guides par plateforme · Mis à jour le 2026-10-25 · Version Markdown

Robots d'IA sur IIS - robots.txt, URL Rewrite, Request Filtering et restrictions IP

Sur IIS, publier robots.txt, refuser les robots d'entraînement avec une règle URL Rewrite dans web.config et voir les limites des filtres et restrictions IP.

Sur un serveur Windows avec IIS, les robots d'IA se gèrent avec des outils qui n'ont pas été conçus pour eux : un fichier robots.txt statique, le module URL Rewrite, le filtrage des requêtes (Request Filtering) et les restrictions par adresse IP. Chacun a ses forces et ses angles morts, et le choix du mauvais outil peut bloquer robots.txt lui-même ou ralentir tout le site. Ce guide propose une configuration qui refuse l'entraînement tout en laissant passer les robots de recherche de ChatGPT, Claude et Perplexity, explique ce que chaque module sait faire d'après la documentation de Microsoft, et dit clairement ce qu'IIS ne sait pas faire seul. Nous n'avons pas pu exécuter ces configurations sur un serveur IIS : elles suivent la documentation officielle et le fichier web.config a été contrôlé comme XML valide, mais testez-les d'abord sur un site de préproduction.

Publier robots.txt

Déposez robots.txt dans le dossier physique du site (souvent sous C:\inetpub\wwwroot pour le site par défaut). IIS le sert comme n'importe quel fichier statique. Vérifiez qu'il répond en 200, en texte brut, et qu'aucune règle ne le bloque : un robot qui ne peut pas lire le fichier ne peut pas y découvrir votre refus, et la RFC 9309 assimile une erreur 5xx sur ce fichier à une interdiction totale.

C'est robots.txt qui porte votre politique auprès des robots qui la respectent, ce que déclarent OpenAI, Anthropic et Perplexity pour leurs robots d'exploration. C'est aussi le seul moyen de refuser l'entraînement à Google (Google-Extended) et à Apple (Applebot-Extended), jetons qui ne correspondent à aucun robot distinct. Les règles serveur qui suivent ne servent qu'en complément, contre les robots qui ignorent le fichier.

Refuser par User-Agent avec URL Rewrite

Le module URL Rewrite ne fait pas partie de l'installation par défaut d'IIS : il s'installe séparément depuis le site iis.net. Ses règles « distribuées » se placent dans web.config, sous system.webServer/rewrite/rules, et sont évaluées dans l'ordre. Une condition peut lire n'importe quel en-tête de la requête sous la forme {HTTP_NOM_DE_L_EN_TETE}, donc {HTTP_USER_AGENT} pour le User-Agent.

<?xml version="1.0" encoding="UTF-8"?>
<!-- web.config à la racine du site - nécessite le module URL Rewrite -->
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <!-- Refus des robots d'entraînement (liste à adapter) -->
        <rule name="Refus robots entrainement IA" stopProcessing="true">
          <!-- Toutes les URL sauf robots.txt.
               Au niveau du site, le motif reçoit le chemin sans la barre initiale. -->
          <match url="^robots\.txt$" negate="true" />
          <conditions logicalGrouping="MatchAll">
            <add input="{HTTP_USER_AGENT}"
                 pattern="GPTBot|ClaudeBot|CCBot|Bytespider|meta-externalagent"
                 ignoreCase="true" />
          </conditions>
          <!-- Réponse 403 ; AbortRequest couperait la connexion sans réponse -->
          <action type="CustomResponse" statusCode="403"
                  statusReason="Forbidden"
                  statusDescription="Access denied to AI training crawlers." />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Plusieurs points de la documentation de Microsoft éclairent cette règle. Le motif de <match> est comparé au chemin relatif à l'emplacement du web.config, sans la chaîne de requête : à la racine du site, /robots.txt arrive sous la forme robots.txt, d'où l'absence de barre dans le motif. L'action CustomResponse répond avec le code choisi et arrête l'évaluation des règles suivantes. Si votre web.config contient déjà un bloc <rewrite>, n'en ajoutez pas un second : insérez la règle en tête de la liste existante.

Un effet de bord mérite d'être connu avant la mise en production : selon la documentation, une règle qui utilise une variable serveur absente d'une liste précise (HTTP_USER_AGENT n'y figure pas) rend l'ensemble des règles « non sûr » pour le cache de sortie. Le module désactive alors le cache en mode noyau pour toutes les requêtes, réécrites ou non. Sur un site très fréquenté qui s'appuie sur ce cache, mesurez l'impact.

Request Filtering : possible, mais moins adapté

Le filtrage des requêtes, installé par défaut, sait aussi inspecter un en-tête grâce aux règles de filtrage (filteringRules, disponibles depuis IIS 7.5) :

<!-- Dans <system.webServer><security> du web.config -->
<requestFiltering>
  <filteringRules>
    <filteringRule name="Refus robots entrainement IA"
                   scanUrl="false" scanQueryString="false" scanAllRaw="false">
      <scanHeaders>
        <add requestHeader="User-Agent" />
      </scanHeaders>
      <!-- appliesTo vide : la règle vaut pour toutes les requêtes -->
      <denyStrings>
        <add string="GPTBot" />
        <add string="ClaudeBot" />
        <add string="CCBot" />
      </denyStrings>
    </filteringRule>
  </filteringRules>
</requestFiltering>

Deux limites nous font préférer URL Rewrite. Une requête bloquée reçoit une erreur 404, inscrite dans le journal avec le sous-code 404.19 (« Denied by filtering rule ») : le robot ne comprend pas qu'il est refusé. Surtout, une règle ne peut être restreinte que par extension de fichier (appliesTo), pas par chemin : sans précaution, elle bloque aussi robots.txt. La documentation ne précise pas non plus si la comparaison des chaînes tient compte de la casse ; vérifiez-le sur votre serveur avant de compter dessus.

Restrictions par adresse IP

Le module IP and Domain Restrictions n'est pas installé par défaut : il s'ajoute comme service de rôle (Web Server > Security > IP and Domain Restrictions). Il refuse ou autorise des adresses ou des plages, exprimées avec un masque de sous-réseau et non en notation CIDR. La documentation de l'élément <ipSecurity> ne mentionne que l'IPv4. Microsoft configure ce module dans applicationHost.config : avec AppCmd, il faut ajouter /commit:apphost, ou passer par IP Address and Domain Restrictions dans le Gestionnaire IIS.

:: Refuser une plage abusive (exemple : 203.0.113.0/24 = masque 255.255.255.0)
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site" -section:system.webServer/security/ipSecurity /+"[ipAddress='203.0.113.0',subnetMask='255.255.255.0',allowed='False']" /commit:apphost

Ce module ne sait pas combiner adresse et User-Agent. IIS ne permet donc pas, avec ses seuls modules, de reproduire la vérification décrite dans nos guides nginx et Apache, qui n'accepte un robot de recherche que s'il vient des plages publiées par son éditeur : URL Rewrite compare des expressions régulières, pas des plages CIDR. Si cette vérification vous importe, placez-la en amont, sur un CDN, un pare-feu applicatif ou un proxy inverse.

Pour limiter le débit, le même module propose depuis IIS 8.0 des restrictions dynamiques (dynamicIpSecurity) : refus d'une adresse au-delà d'un nombre de requêtes simultanées ou d'un nombre de requêtes sur une période. Elles s'appliquent à tous les visiteurs, robots ou non. Activez d'abord enableLoggingOnlyMode, qui journalise les refus sans les appliquer.

X-Robots-Tag

<!-- Dans web.config : en-tête sur tout le dossier /documents -->
<location path="documents">
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="X-Robots-Tag" value="noindex" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</location>

Google documente cet en-tête ; les pages d'OpenAI, d'Anthropic et de Perplexity consultées pour ce guide ne le mentionnent pas. Pour ces robots, robots.txt reste la seule consigne documentée.

Tester

Sous Windows PowerShell 5.1, curl est un alias d'Invoke-WebRequest : appelez explicitement curl.exe, fourni avec les versions récentes de Windows.

:: Robot d'entraînement : 403 attendu
curl.exe -s -o NUL -w "%{http_code}\n" -A "compatible; GPTBot/1.4" https://www.example.com/
:: Le même robot sur robots.txt : 200 attendu
curl.exe -s -o NUL -w "%{http_code}\n" -A "compatible; GPTBot/1.4" https://www.example.com/robots.txt
:: Robot de recherche : 200 attendu
curl.exe -s -o NUL -w "%{http_code}\n" -A "compatible; OAI-SearchBot/1.4" https://www.example.com/

Ces tests sont indicatifs : curl reproduit le User-Agent, pas l'adresse du robot. Les journaux W3C se trouvent par défaut sous %SystemDrive%\inetpub\logs\LogFiles, dans un sous-dossier par site, et le User-Agent fait partie des champs enregistrés par défaut ; dans ces fichiers, les espaces du User-Agent apparaissent remplacés par des +. Pour repérer les refus :

Select-String -Path "$env:SystemDrive\inetpub\logs\LogFiles\W3SVC1\*.log" -Pattern "GPTBot|ClaudeBot|CCBot" |
  Select-String -Pattern " 403 | 404 19 "

Pour écrire un robots.txt sans faute de jeton, vous pouvez partir du générateur de robots.txt pour les IA.

Pièges à éviter

  • Le User-Agent seul ne prouve rien. Une règle par nom n'arrête que les robots honnêtes, que robots.txt arrêtait déjà ; un collecteur qui se présente comme un navigateur passe.
  • Un motif trop large. bot refuserait Googlebot et Bingbot, et vous retirerait des moteurs de recherche.
  • Bloquer robots.txt sans le vouloir, en particulier avec Request Filtering.
  • Bloquer les plages d'un éditeur pour refuser l'entraînement. Anthropic indique que cette méthode n'est pas fiable, car elle empêche aussi la lecture de robots.txt.
  • Oublier le proxy. Derrière un répartiteur de charge, IIS voit l'adresse de l'intermédiaire ; le module de restrictions IP propose un mode proxy (enableProxyMode) qui lit l'en-tête x-forwarded-for.

Revenir en arrière

Supprimez la règle dans le web.config (ou dans URL Rewrite du Gestionnaire IIS), retirez la règle de l'onglet Rules de Request Filtering, et supprimez les entrées ajoutées dans IP Address and Domain Restrictions. Gardez une copie du fichier avant chaque changement : c'est le retour arrière le plus rapide.

Sources officielles

Outils gratuits

Scanner de visibilité IA gratuit

Analysez gratuitement si ChatGPT, Claude, Perplexity et Gemini peuvent lire et citer votre site - robots.txt, llms.txt, JavaScript, texte caché.

Générateur de robots.txt pour les robots d'IA (GPTBot, ClaudeBot, PerplexityBot…)

Créez en un clic un robots.txt qui bloque l'entraînement des IA tout en restant visible dans ChatGPT Search, Claude et Perplexity. Gratuit.

Testeur de robots.txt pour les robots d'IA

Collez votre robots.txt et voyez instantanément, robot par robot, si GPTBot, ClaudeBot, PerplexityBot ou Google-Extended peuvent lire une page.

À lire aussi