GEO technique : rendre un site récupérable par les IA

Une page peut très bien se positionner en première page de Google et rester parfaitement invisible pour ChatGPT. Ce n’est pas une anomalie : les deux systèmes ne lisent pas ton site de la même façon, ne passent pas par les mêmes robots, et n’ont pas les mêmes capacités techniques.

C’est la partie du GEO dont on parle le moins, parce qu’elle est moins spectaculaire que la rédaction de contenu citable. Elle est pourtant première dans l’ordre : aucun travail éditorial ne rattrape une page qu’un moteur de réponse ne peut pas charger.

Les trois conditions, dans l’ordre

Avant d’ouvrir ton robots.txt, il faut savoir ce qu’on cherche à obtenir. Pour qu’un moteur de réponse te cite, trois conditions doivent être réunies, et elles sont séquentielles :

1. Récupérable. Le robot peut accéder à l’URL et reçoit un vrai contenu.
2. Lisible. Ce contenu est exploitable sans exécuter de code ni deviner la structure.
3. Attribuable. Le moteur sait de qui il parle et peut nommer la source.

L’ordre compte. Une page magnifiquement balisée mais bloquée au niveau du robots.txt vaut zéro. Un contenu parfait rendu uniquement en JavaScript vaut zéro pour la plupart des récupérateurs. C’est pour ça que je commence toujours par là avant de toucher à l’éditorial — la méthode d’ensemble est dans le guide des fondamentaux du GEO.

Les crawlers IA, et le gros malentendu sur GPTBot

C’est l’erreur la plus répandue dans les discussions francophones sur le sujet : on parle des « bots IA » comme d’un bloc. Ils ne font pas le même travail, et les confondre coûte cher dans les deux sens — soit on se coupe de la visibilité en croyant protéger son contenu, soit on laisse tout passer en croyant que c’est le prix de la citation.

Chez OpenAI, trois robots distincts, trois usages :

La conséquence est contre-intuitive : tu peux bloquer GPTBot et rester parfaitement visible dans ChatGPT. Plusieurs éditeurs de presse ont fait exactement ce choix. Et à l’inverse, beaucoup de sites qui ont copié un robots.txt « anti-IA » trouvé sur un forum se sont retirés de la recherche sans l’avoir voulu.

Même piège du côté de Google, avec une nuance encore plus mal comprise :

Bloquer Google-Extended ne te retire pas des AI Overviews. Les Overviews sont construits à partir de l’index de Search : tant que Googlebot passe, tu peux y apparaître. Google le confirme explicitement dans sa documentation — Google-Extended sert à limiter l’entraînement des modèles, pas à contrôler l’apparition dans les fonctionnalités d’IA générative.

En revanche, le bouton « sortir des AI Overviews sans sortir de Google » existe depuis 2026, et il n’est pas dans robots.txt : c’est un réglage de la Search Console, sous Paramètres > IA générative dans la Recherche, disponible sur tous les sites depuis le 31 août 2026. Il couvre les Aperçus IA, le Mode IA et l’IA générative de Discover, s’applique à la propriété entière, et Google indique qu’il n’est pas utilisé comme signal de classement ailleurs dans la Recherche. Le détail est dans Search Console : le rapport IA générative.

Trois leviers distincts, donc, qu’on confond souvent : ce réglage pour l’apparition dans les fonctionnalités IA, Google-Extended pour l’entraînement, noindex pour sortir entièrement de la Recherche.

Les autres robots à connaître : PerplexityBot (index de Perplexity), ClaudeBot (Anthropic), Applebot-Extended (entraînement Apple), CCBot (Common Crawl, qui alimente de nombreux jeux d’entraînement tiers), Bytespider (ByteDance), meta-externalagent (Meta).

Une précision qui a son importance : robots.txt est déclaratif. C’est une convention, pas un verrou. Un robot qui choisit de l’ignorer le peut, et des cas de non-respect ont été rapportés par la presse spécialisée. Si tu veux réellement empêcher l’accès, ça se traite au niveau du serveur ou du pare-feu applicatif, pas dans un fichier texte.

Ton robots.txt, concrètement

Pour un site qui cherche la visibilité — le cas de la grande majorité des lecteurs ici — la configuration est simple : autoriser explicitement les robots de recherche. L’explicite vaut mieux que l’implicite, parce qu’il documente ton intention pour la personne qui reprendra le site après toi.

User-agent: *
Allow: /

# Robots de recherche IA : explicitement bienvenus
User-agent: OAI-SearchBot
Allow: /
User-agent: ChatGPT-User
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: ClaudeBot
Allow: /

Sitemap: https://exemple.fr/sitemap-index.xml

Si ton enjeu est de rester visible sans nourrir l’entraînement, tu ajoutes les blocages ciblés :

User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: Applebot-Extended
Disallow: /
User-agent: CCBot
Disallow: /

Ces deux blocs ne se contredisent pas : le premier ouvre la recherche, le second ferme l’entraînement. C’est une position défendable, et c’est celle que je recommanderais à un éditeur dont le contenu est l’actif principal.

Sur ce site, j’ai fait le choix inverse : tout est ouvert, entraînement compris. Mon contenu n’a d’intérêt que s’il circule, et je préfère maximiser les chances d’être repris. C’est un arbitrage assumé, pas une règle générale.

Dernier point, souvent oublié : déclare ton sitemap dans le robots.txt. C’est le chemin le plus court pour qu’un robot découvre l’ensemble de tes URLs sans dépendre de la qualité de ton maillage.

Le piège du JavaScript

C’est le problème technique le plus coûteux, et le plus silencieux.

Googlebot sait exécuter JavaScript. Il rend la page, attend le résultat, puis indexe ce qu’il voit. C’est pour ça qu’un site en rendu client finit par se positionner correctement — avec un délai, mais il y arrive.

La plupart des récupérateurs IA ne font pas ça. Ils récupèrent le HTML renvoyé par ton serveur et le lisent tel quel. Si ton contenu n’existe qu’après l’exécution d’un script, ils reçoivent une coquille vide : une balise div racine, et rien dedans.

Le symptôme est reconnaissable : tes pages se positionnent normalement sur Google, mais aucun moteur de réponse ne te cite, même sur des requêtes où tu devrais être une évidence.

Le test se fait en une commande, sans aucun outil :

curl -s https://ton-site.fr/ta-page/ | grep "une phrase de ton contenu"

Si la phrase ne ressort pas, elle n’existe pas pour ces robots. Les corrections, par ordre de solidité : génération statique, rendu côté serveur, ou à défaut un pré-rendu pour les user-agents concernés. Un site statique ou rendu serveur n’a tout simplement pas ce problème.

llms.txt : mon avis, sans enthousiasme

Le fichier llms.txt est un markdown placé à la racine du domaine, qui liste tes contenus importants avec une courte description — une sorte de sommaire lisible par une machine. La convention a été proposée en 2024 par Jeremy Howard.

Voilà où j’en suis après avoir suivi le sujet de près : aucun éditeur de grand modèle n’a confirmé publiquement lire ce fichier. Ni OpenAI, ni Anthropic, ni Google, ni Perplexity. On trouve pourtant beaucoup d’articles qui le présentent comme un levier GEO majeur ; je n’ai vu passer aucune démonstration d’un effet mesurable.

Mon arbitrage : le fichier prend vingt minutes à produire, ne présente aucun risque, et serait prêt le jour où un éditeur déciderait de l’exploiter. Je l’ai mis en place ici — tu peux aller voir le llms.txt de ce site. Mais je ne le vends pas comme un levier : c’est un pari à faible coût, pas un résultat.

Méfie-toi des contenus qui t’expliquent l’inverse avec assurance. Sur un sujet aussi jeune, la confiance affichée est rarement proportionnelle aux preuves disponibles.

Données structurées : utiles, mais pas pour la raison qu’on croit

Même exercice de lucidité. On lit partout que le balisage schema.org améliore la citation par les IA. Rien ne l’établit directement, et les modèles travaillent sur du texte, pas sur du JSON-LD.

Leur valeur est réelle, mais indirecte, et elle tient en deux points :

• La clarté des entités. Un balisage Organization, Person ou Article correct lève l’ambiguïté sur qui parle, de quoi, et avec quelle autorité. C’est du carburant pour l’attribution — la troisième des trois conditions du début.
• L’éligibilité aux résultats enrichis de Google. Et ceux-là alimentent bien les AI Overviews. Le chemin est détourné, mais il existe.

Donc oui, balise. Organization avec sameAs, Article, FAQPage quand tu as une vraie FAQ, BreadcrumbList. Mais balise parce que c’est propre et que ça sert ton SEO, pas en attendant un bond de citations.

L’ordre dans lequel je traiterais ça

Si tu reprends un site existant, voici la séquence qui donne le plus de résultat pour le moins d’effort :

1. Vérifie que tu n’es pas bloqué par accident. Relis ton robots.txt ligne par ligne. C’est le problème le plus fréquent, et le plus rapide à corriger.
2. Fais le test curl sur trois pages stratégiques. Si le contenu n’est pas dans le HTML source, c’est ta priorité absolue — avant tout le reste.
3. Contrôle l’indexation. Une page absente de l’index de Google ne sera pas reprise par les moteurs qui s’appuient dessus. La Search Console reste l’outil de référence, et le playbook GSC × Claude permet de l’interroger en langage naturel.
4. Balise proprement, sans en attendre de miracle.
5. Ajoute llms.txt, en connaissance de cause.

Le reste — ce qui fait qu’une IA choisit ton passage plutôt qu’un autre, une fois la page accessible — relève de l’éditorial, et c’est un autre chantier. La checklist GEO couvre les deux volets sur une page.

Une fois la technique en place, la question devient : est-ce que ça marche ? C’est l’objet du silo Mesure, parce qu’un chantier technique sans mesure reste une intuition.