SEO & visibilité IA
Faut-il bloquer les robots IA ? Protéger son contenu sans disparaître
Robots IA · SEO · droits
Bloquer les robots IA n’est pas une décision binaire. Il faut séparer visibilité, entraînement, recherche, action utilisateur et protection réelle.
- Autoriser Les crawlers utiles à la découverte, aux citations et aux parcours utilisateurs.
- Réserver Les contenus que l’on refuse de laisser utiliser pour l’entraînement ou certains usages IA.
- Limiter Les robots trop fréquents, opaques ou sans bénéfice visible pour le site.
- Protéger Les zones sensibles avec de vrais contrôles, pas seulement avec robots.txt.
Repères vérifiés le 21 juin 2026. Cet article ne remplace pas un avis juridique : il aide à cadrer une décision SEO, GEO, technique et éditoriale avant de modifier un fichier robots.txt.
Réponse courte
Il ne faut pas bloquer “les IA”. Il faut choisir quels usages du site on autorise.
La mauvaise décision consiste à écrire quelques lignes dans robots.txt pour “bloquer ChatGPT”, “bloquer Gemini” ou “bloquer tous les robots IA” sans distinguer les usages. Un même éditeur peut utiliser plusieurs robots : un robot pour l’entraînement, un autre pour la recherche, un autre pour une action déclenchée par un utilisateur, parfois un token de contrôle qui ne crawl pas lui-même.
La bonne décision consiste à répondre à une question plus fine : voulez-vous rester visible dans les moteurs, les réponses IA et les parcours assistés, tout en refusant certains usages d’entraînement ou d’exploitation de vos contenus ? Dans la plupart des cas, la réponse n’est donc ni “tout ouvrir”, ni “tout fermer”.
Autoriser la visibilité, réserver les droits sur les contenus sensibles, et protéger techniquement ce qui ne doit jamais être accessible.
La vraie grille de décision
Quatre usages se cachent derrière l’expression “robot IA”.
Avant de toucher au fichier robots.txt, il faut classer chaque robot selon son rôle. Un robot d’entraînement n’a pas le même impact qu’un robot de recherche. Un agent déclenché par un utilisateur n’a pas le même statut qu’un crawler automatique. Un robot classique de moteur de recherche reste parfois le passage obligé pour les fonctionnalités IA intégrées au moteur.
Indexation classique
Googlebot, Bingbot ou Applebot servent d’abord à découvrir, indexer et classer des pages. Les bloquer revient souvent à réduire la visibilité search.
Recherche IA
Certains robots alimentent les réponses générées, les citations ou la recherche conversationnelle. Les bloquer peut réduire la présence dans ces réponses.
Entraînement
D’autres robots ou tokens servent à contrôler l’usage des contenus pour améliorer des modèles. C’est souvent le périmètre le plus légitime à réserver.
Action utilisateur
Des agents peuvent visiter une page parce qu’un utilisateur leur demande une recherche, une comparaison ou une action. Le blocage peut casser un usage volontaire.
Tableau de référence
Les principaux robots et tokens IA à connaître avant de bloquer.
Ce tableau synthétise les comportements documentés ou déclarés au 21 juin 2026. Il doit être relu régulièrement : les noms de robots, les rôles et les politiques d’accès évoluent vite.
| Robot ou token | Rôle principal | Effet du blocage | Décision recommandée |
|---|---|---|---|
| Googlebot | Indexation Google Search et fonctionnalités IA intégrées à Search. | Réduit ou coupe l’accès de Google à vos pages pour Search, AI Overviews et AI Mode. | À ne pas bloquer si la visibilité Google compte. |
| Bingbot | Indexation Bing Search et expériences IA Microsoft qui s’appuient sur les résultats Bing. | Réduit ou coupe l’accès de Bing à vos pages pour Search et les réponses Copilot ancrées dans Bing. | À ne pas bloquer si la visibilité Bing, Edge ou Copilot compte. |
| Google-Extended | Token robots.txt pour contrôler certains usages Gemini, Vertex AI et grounding hors Search. | N’affecte pas l’inclusion ni le ranking Google Search, mais peut limiter certains usages IA Google hors Search. | À bloquer si vous voulez réserver l’usage IA sans sortir de Google Search. |
| GPTBot | Crawl pouvant servir à l’entraînement des modèles OpenAI. | Signale que le contenu ne doit pas être utilisé pour l’entraînement des modèles génératifs OpenAI. | Souvent le premier blocage sélectif à envisager, en gardant OAI-SearchBot si la citation ChatGPT compte. |
| OAI-SearchBot | Crawl automatique lié à la recherche et aux citations dans ChatGPT. | Peut réduire la découverte, la citation et la présence dans ChatGPT Search. | À conserver si vous cherchez une visibilité GEO dans ChatGPT. |
| ChatGPT-User | Visites déclenchées par des actions ou demandes utilisateur dans ChatGPT et certains GPTs. | Peut empêcher l’utilisateur assisté par ChatGPT d’accéder au contenu ou à une action. | À bloquer seulement si l’usage agentique du site est indésirable. |
| ClaudeBot | Collecte pouvant contribuer à l’entraînement des modèles Anthropic. | Signale l’exclusion des futurs contenus des jeux d’entraînement Anthropic. | À bloquer si vous réservez les usages d’entraînement. |
| Claude-SearchBot | Robot de recherche pour améliorer les résultats et réponses de Claude. | Peut réduire la visibilité et la précision de vos contenus dans les réponses de recherche Claude. | À arbitrer selon votre stratégie de visibilité IA. |
| Claude-User | Accès au web à la demande d’un utilisateur Claude. | Peut empêcher Claude de récupérer votre contenu pour répondre à une demande utilisateur. | À conserver pour les contenus publics utiles ; à limiter pour les zones sensibles. |
| Applebot | Découverte pour les expériences Apple comme Safari, Spotlight, Siri et Search. | Peut réduire la découvrabilité dans l’écosystème Apple. | À conserver pour les pages publiques stratégiques. |
| Applebot-Extended | Contrôle d’usage pour l’entraînement des modèles de fondation Apple. | N’empêche pas Applebot de crawler ; sert à refuser certains usages d’entraînement. | À bloquer si vous réservez les usages d’entraînement Apple. |
| PerplexityBot / Perplexity-User | Robots déclarés de Perplexity pour crawling et accès utilisateur. | Peut réduire la présence dans Perplexity, mais robots.txt ne suffit pas toujours à contrôler le trafic observé. | À piloter avec robots.txt, logs et règles réseau si le sujet est sensible. |
| CCBot, Bytespider, meta-externalagent, Amazonbot | Robots de collecte, d’indexation ou d’usage IA selon les opérateurs et les périodes. | Bénéfice direct souvent moins clair pour un site business ; impact à vérifier dans les logs. | À surveiller, documenter et bloquer seulement si le rapport risque/bénéfice est défavorable. |
Le piège Google
Bloquer Google-Extended ne vous sort pas des AI Overviews.
C’est le point le plus contre-intuitif. Google-Extended sert à contrôler certains usages liés à Gemini, Vertex AI et au grounding dans des systèmes Google autres que Search. Google indique explicitement que ce token n’affecte ni l’inclusion dans Google Search ni le ranking.
Les fonctionnalités IA intégrées à Search, comme AI Overviews ou AI Mode, reposent sur les contrôles habituels de Search. Si vous voulez limiter les informations affichées par Google dans ces expériences, Google renvoie vers nosnippet, data-nosnippet, max-snippet ou noindex. Ces contrôles peuvent aussi réduire l’extrait classique ou la visibilité search.
On ne peut pas sortir proprement des AI Overviews sans toucher à la manière dont Google peut afficher le contenu dans Search.
Europe
Bloquer peut aussi servir à exprimer une réserve de droits.
En Europe, le sujet n’est pas seulement technique. L’article 4 de la directive 2019/790 sur le droit d’auteur dans le marché unique numérique prévoit une exception pour le text and data mining, mais cette exception ne s’applique que si l’usage n’a pas été expressément réservé par les titulaires de droits, notamment par des moyens lisibles par machine pour les contenus publiés en ligne.
L’AI Act ajoute des obligations pour les fournisseurs de modèles d’IA à usage général, notamment une politique de conformité au droit d’auteur de l’Union. Le Code de bonnes pratiques GPAI précise aussi un chapitre Copyright destiné à aider les fournisseurs à démontrer cette conformité. En pratique, robots.txt peut donc devenir un support de gouvernance éditoriale et juridique, pas seulement un outil SEO.
La prudence reste indispensable : Edikka ne remplace pas un avocat. Mais un site européen qui publie des contenus propriétaires, des études, des bases documentaires ou des corpus éditoriaux a intérêt à documenter explicitement ce qu’il autorise et ce qu’il réserve.
Cadre à documenter
La décision robots.txt doit être reliée à une politique de contenu.
- Directive DSM
Réserve possible des droits contre certains usages de text and data mining, y compris par moyens lisibles par machine.
- AI Act
Obligations des fournisseurs de modèles GPAI, dont politique de respect du droit d’auteur de l’Union.
- GPAI Code
Chapitre Copyright proposant des solutions pratiques de conformité pour les fournisseurs de modèles.
- Site web
robots.txt, conditions d’utilisation, logs, CDN et gouvernance éditoriale doivent raconter la même chose.
Cette lecture doit être validée selon votre activité, vos droits et vos juridictions cibles.
Limite technique
robots.txt est une préférence déclarée, pas un mur de sécurité.
Un robot respectueux lit robots.txt et applique les consignes. Un scraper opportuniste peut l’ignorer, changer d’IP, changer de user-agent ou passer par des fournisseurs tiers. Cloudflare a documenté des comportements de crawling furtif attribués à Perplexity malgré des directives de blocage et des règles WAF.
La conclusion n’est pas qu’il faut abandonner robots.txt. La conclusion est qu’il faut lui donner le bon rôle. Il exprime une préférence, une politique d’accès et parfois une réserve de droits. Il ne protège pas un fichier confidentiel, un PDF privé, un endpoint interne, une préproduction ou un back-office.
Donner une consigne aux robots déclarés, documenter une préférence, réduire certains crawls respectueux, exprimer une réserve machine-readable.
Empêcher un accès HTTP, authentifier un agent, protéger une donnée sensible, bloquer un scraper hostile ou masquer une URL déjà connue.
Authentification, noindex, X-Robots-Tag, WAF, rate limiting, vérification IP, logs, alertes et séparation stricte des zones publiques et privées.
Matrice Edikka
La bonne politique dépend du modèle économique du site.
Une agence, un média, un e-commerce et un SaaS n’ont pas le même intérêt à ouvrir ou fermer leurs contenus. La politique de crawl doit partir de la valeur du contenu, du besoin de visibilité, du risque de copie et de la capacité technique à contrôler réellement les accès.
| Type de site | Objectif principal | Politique recommandée | Erreur à éviter |
|---|---|---|---|
| Site vitrine B2B | Être trouvé, compris, recommandé et contacté. | Conserver les crawlers de recherche IA, réserver éventuellement l’entraînement, protéger formulaires et endpoints. | Bloquer tous les robots IA et perdre les citations utiles. |
| Média ou éditeur | Préserver la valeur éditoriale et négocier l’usage des contenus. | Réserve de droits claire, blocage d’entraînement, politique premium, suivi des logs et décisions par rubrique. | Laisser l’ensemble du corpus ouvert par inertie. |
| E-commerce | Rester visible dans les comparaisons, prix, produits et assistants d’achat. | Ouvrir les pages produit publiques, contrôler les stocks/prix dynamiques, protéger comptes, panier et checkout. | Bloquer les agents utiles ou exposer des actions sensibles sans garde-fou. |
| SaaS | Faire comprendre l’offre, la documentation et les cas d’usage. | Ouvrir marketing et docs publiques, réserver contenus propriétaires, authentifier l’application et les API. | Confondre documentation publique et données client. |
| Formation ou contenu premium | Vendre l’accès à un savoir structuré. | Ouvrir extraits, pages de preuve et sommaires ; réserver les modules complets et ressources payantes. | Mettre les contenus payants simplement derrière une URL non liée. |
| Intranet, préprod, back-office | Empêcher l’accès non autorisé. | Authentification, IP allowlist, noindex, blocage réseau, pas seulement robots.txt. | Croire qu’un Disallow: / protège une zone privée. |
Exemples robots.txt
Trois configurations types, à adapter avant publication.
Ces exemples sont des points de départ. Ils doivent être testés, documentés et adaptés à vos objectifs. Les user-agents évoluent : vérifiez toujours les noms dans les documents officiels avant mise en ligne.
Pour un site qui cherche d’abord la visibilité et accepte temporairement les usages IA, tout en surveillant les logs.
User-agent: *
Allow: /
Sitemap: https://www.exemple.fr/sitemap.xmlPour rester visible dans la recherche et les réponses utiles, tout en réservant les usages d’entraînement les plus évidents.
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: Applebot-Extended
Disallow: /
User-agent: *
Disallow: /admin/
Disallow: /client/
Disallow: /private/
Sitemap: https://www.exemple.fr/sitemap.xmlPour un média, un corpus premium ou un site qui veut limiter fortement l’usage IA public. À compléter par CDN, WAF et règles contractuelles.
# Conserve Googlebot et Bingbot pour Search, bloque les principaux robots IA déclarés.
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Disallow: /
User-agent: ChatGPT-User
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Claude-SearchBot
Disallow: /
User-agent: Claude-User
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: Applebot-Extended
Disallow: /
User-agent: PerplexityBot
Disallow: /
User-agent: Perplexity-User
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Bytespider
Disallow: /
User-agent: meta-externalagent
Disallow: /
User-agent: Amazonbot
Disallow: /
User-agent: *
Disallow: /premium/
Disallow: /ressources-privees/
Sitemap: https://www.exemple.fr/sitemap.xmlMéthode
Avant de bloquer, auditez ce que les robots IA voient déjà.
Classez les contenus par valeur et par risque.
Séparez pages publiques, pages de conversion, études, images, PDF, documentation, ressources payantes, préproduction, back-office et API. Une politique unique pour tout le domaine est rarement optimale.
Lisez les logs avant de décider.
Identifiez les user-agents, la fréquence, les pages touchées, les statuts HTTP, les IP, les pays et les pics de charge. Un robot invisible dans les logs ne mérite pas toujours une décision prioritaire.
Décidez par usage, pas par peur.
Gardez les robots qui soutiennent la découverte et la citation utile. Réservez l’entraînement si le contenu est stratégique. Fermez les zones qui n’ont aucune raison d’être lues par un robot public.
Testez l’effet réel après publication.
Contrôlez que le fichier est accessible, que les règles sont syntaxiquement valides, que les crawlers concernés les lisent, et que la visibilité Google, ChatGPT, Claude, Perplexity ou Apple évolue comme attendu.
Maillage
La gouvernance des robots IA complète le SEO, le GEO et l’agent-ready.
Bloquer ou autoriser les robots n’a de sens que dans une stratégie plus large : être trouvé, être cité, être compris par les agents, et mesurer ce qui se passe réellement. Cette page doit donc se lire avec les autres ressources du cluster SEO et visibilité IA.
Conclusion
La meilleure politique robots IA est sélective, datée et vérifiée.
Un site qui bloque tout se protège parfois, mais il se rend aussi moins visible dans des environnements où les utilisateurs demandent déjà aux IA de chercher, comparer et recommander. Un site qui ouvre tout gagne peut-être en exposition, mais il laisse partir ses contenus sans stratégie.
Le bon niveau se trouve entre les deux : ouvrir les pages publiques qui doivent être citées, réserver l’entraînement quand le contenu le justifie, fermer les zones sensibles avec de vrais contrôles, puis mesurer l’effet dans les logs et dans les réponses IA.
Ne bloquez pas les IA par réflexe. Gouvernez chaque usage comme une décision de visibilité, de droit et de sécurité.
La gouvernance des robots IA devient une couche normale de la stratégie SEO.
Le sujet n’est plus seulement “peut-on être crawlé ?”. Le sujet est : quel contenu doit être visible, quel contenu doit être réservé, et quel contenu doit être protégé autrement que par une déclaration.
Chez Edikka, une politique robots IA n’est pas un réflexe défensif. C’est un arbitrage entre acquisition, droit, confiance et sécurité : on garde ouvert ce qui doit nourrir la découverte, on réserve ce qui constitue un actif éditorial, et on protège techniquement ce qui ne devrait jamais dépendre d’un simple robots.txt.
Rester citable
Les pages publiques qui portent l’offre, les preuves et les réponses utiles doivent rester accessibles aux bons moteurs.
Réserver les usages sensibles
Les contenus propriétaires peuvent justifier une réserve explicite contre certains usages d’entraînement.
Vérifier les accès réels
Les logs, le CDN et les règles réseau disent souvent plus que le fichier robots.txt seul.
Pour aller plus loin sur ce sujet
Des réponses complémentaires pour clarifier les points essentiels abordés dans cet article.
