Ce que ChatGPT, Claude et Gemini voient réellement de votre site

Trois familles de robots, trois comportements

Parler des « robots IA » au singulier induit en erreur : ils ne font pas le même travail et ne se bloquent pas de la même façon.

Les crawlers d’entraînement

Ils collectent du contenu pour l’apprentissage des modèles. Les bloquer protège votre contenu mais n’a aucun effet sur votre visibilité dans les réponses générées, puisqu’ils n’y participent pas directement.

Les crawlers de recherche

Ils construisent l’index que l’assistant interroge quand il cherche une information à jour. Les bloquer vous retire des résultats sur lesquels les réponses s’appuient.

Les récupérateurs à la demande

Déclenchés quand un utilisateur pose une question ou fournit une URL : ils vont chercher la page à cet instant. C’est souvent par eux que passe une citation.

Ces trois familles se distinguent par leur user-agent. Un `Disallow: /` global dans robots.txt les bloque toutes indistinctement, ce qui est rarement ce qu’on veut.

Le JavaScript est le premier point de rupture

Googlebot sait rendre une page JavaScript, avec un délai et un budget limités. La plupart des robots d’assistants ne le font pas, ou de façon nettement plus limitée. Ils lisent le HTML servi par le serveur, et rien de plus.

Concrètement, sur une application monopage classique, le HTML initial contient une balise `div` vide et un script. Tout le contenu (titre, offre, prix, FAQ) n’apparaît qu’après exécution. Pour ces robots, la page est vide.

Le correctif n’est pas d’abandonner React : c’est de servir le contenu essentiel dans la première réponse, par rendu serveur ou par génération statique. La partie interactive peut rester côté client.

Comment vérifier en cinq minutes

1. Récupérez la page sans exécuter de JavaScript : dans le navigateur, désactivez-le, ou en ligne de commande utilisez un simple `curl` sur l’URL.
2. Regardez le HTML obtenu : y trouve-t-on le H1, le premier paragraphe, la liste des offres, la FAQ ?
3. Vérifiez les liens : sont-ils des balises `a` avec un attribut `href`, ou des éléments cliquables pilotés par JavaScript ? Seuls les premiers sont suivis.
4. Vérifiez les métadonnées : un `title` unique, une `description` cohérente, une balise canonical absolue.
5. Vérifiez le temps de réponse : un robot qui attend trop longtemps abandonne.

Si ce que vous obtenez à l’étape 2 ne suffirait pas à un lecteur humain pour comprendre ce que vous vendez, aucun moteur de réponse ne le comprendra non plus.

Être lisible ne suffit pas : il faut être extractible

Une fois le texte accessible, la question devient : un moteur peut-il en isoler une affirmation exacte sans l’interpréter ? C’est là que la plupart des sites d’entreprise échouent, non par faute technique mais par style d’écriture.

« Nous accompagnons nos clients avec des solutions sur mesure adaptées à leurs enjeux » ne contient aucune information extractible. « Audit d’architecture de deux à dix jours, livrable : cartographie du système et plan d’action priorisé, à distance ou sur site en Île-de-France » en contient six.

• Répondre à la question dès le premier paragraphe, puis développer. Pas l’inverse.
• Nommer les choses : durées, livrables, périmètres, conditions, ce que vous ne faites pas.
• Écrire des réponses autonomes : compréhensibles sans le paragraphe précédent, car c’est ainsi qu’elles seront lues.
• Une intention par page. Deux pages qui visent la même question se cannibalisent.
• Une hiérarchie de titres correcte : un H1, des H2 qui posent de vraies questions, pas des slogans.

Les données structurées : utiles, pas magiques

Le JSON-LD ne fait pas apparaître votre entreprise dans une réponse. Il lève des ambiguïtés : qui publie, quelle est l’entité derrière l’affirmation, comment les pages se relient entre elles, quelle est la date de publication.

Ce qui compte plus que la quantité de schémas, c’est leur cohérence : des identifiants stables, réutilisés d’une page à l’autre, qui pointent vers la même entité. Dix schémas isolés recopiés page par page valent moins qu’un graphe correctement relié.

Et une règle absolue : le balisage doit décrire ce qui est visible sur la page. Un balisage qui affirme plus que le contenu est au mieux ignoré, au pire pénalisé.

Les erreurs les plus fréquentes

• Contenu essentiel rendu uniquement côté client.
• Navigation en JavaScript sans balises `a href`, qui rend des pages entières inatteignables.
• Un `Disallow: /` hérité d’une préproduction, jamais retiré en production.
• Des balises canonical relatives, ou pointant vers une autre page que la page elle-même.
• Des versions linguistiques sans `hreflang` réciproque, qui se font concurrence au lieu de se compléter.
• Des pages qui répètent toutes la même description générique, donc aucune ne répond à une question précise.

Dans quel ordre traiter

L’ordre compte, parce que chaque étape conditionne la suivante : atteignable, puis lisible sans JavaScript, puis structuré, puis extractible, puis relié à une entité claire. Travailler l’entité avant d’avoir réglé le rendu ne sert à rien : personne ne lira ce que vous affirmez.