Il existe une catégorie de sites parfaitement sains du point de vue du référencement classique, bien positionnés, correctement indexés, sans erreur dans la Search Console, et pourtant strictement absents des réponses de ChatGPT, de Claude et de Perplexity. Le contenu est bon. L'autorité est là. Le robots.txt est ouvert. Et il ne se passe rien.
Réponse courte : Googlebot exécute votre JavaScript, les crawlers des moteurs génératifs ne l'exécutent pas. Ils téléchargent le HTML initial, le lisent tel quel, et repartent. Si votre contenu est injecté par le navigateur après le chargement, ils voient une coquille vide. Vos classements Google, eux, restent excellents, ce qui vous prive du seul signal qui aurait pu vous alerter.
C'est la panne la plus silencieuse du Generative Engine Optimization, et l'une des rares dont la correction est purement technique.
Ce que voit réellement un crawler IA
L'étude de référence reste celle menée par Vercel et Merj, publiée en décembre 2024 sur un mois de trafic réel. Elle a mesuré, requête par requête, le comportement des principaux robots.
Les volumes d'abord, pour situer l'enjeu : 569 millions de récupérations pour GPTBot, 370 millions pour le robot d'Anthropic, 314 millions pour AppleBot, 24,4 millions pour PerplexityBot. Soit environ 1,3 milliard au total, l'équivalent de 28 % du volume de Googlebot sur la même période. Ce n'est plus un trafic marginal.
Le résultat central est net : aucun des grands crawlers IA n'exécute JavaScript. Plus troublant, ils téléchargent bel et bien les fichiers .js. GPTBot en récupère dans 11,50 % de ses requêtes, le robot d'Anthropic dans 23,84 %. Ils consomment votre bande passante pour des fichiers qu'ils n'exécuteront jamais. La présence de ces requêtes dans vos logs peut donc donner l'illusion rassurante d'un crawl complet.
Deux exceptions méritent d'être connues, car elles expliquent une bonne part de la confusion ambiante. Gemini s'appuie sur l'infrastructure de Googlebot et bénéficie donc du même moteur de rendu. AppleBot dispose lui aussi d'un crawler capable de rendu, hérité de la recherche Apple. Tous les autres, GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, Meta-ExternalAgent, lisent la source et rien d'autre.
Et surtout, il n'y a pas de rattrapage. Google dispose d'une file de rendu qui revient exécuter le JavaScript de la page plus tard. Les moteurs génératifs n'ont pas cette seconde vague : sur une récupération donnée, ce qui est absent du HTML initial ne leur parviendra jamais. Ils repasseront sur l'URL lors d'un prochain crawl, mais pour y lire exactement la même source.
Le piège : vos classements Google vous rassurent à tort
C'est ce qui rend le problème si difficile à détecter en interne.
Googlebot fonctionne en deux temps. Première vague, il récupère le HTML et indexe le contenu statique immédiatement. Seconde vague, la page rejoint une file d'attente où le Web Rendering Service exécute le JavaScript et évalue le DOM complet. Le délai entre les deux est variable, de quelques secondes à plusieurs jours, voire plusieurs semaines quand la file est chargée, mais le rattrapage finit par avoir lieu. Un site entièrement rendu côté client peut donc se positionner tout à fait normalement sur Google.
D'où la situation absurde que nous rencontrons régulièrement en audit GEO : la Search Console affiche des impressions en hausse, les positions sont bonnes, l'inspection d'URL renvoie un rendu impeccable, et le même site est invisible dans tous les moteurs génératifs.
L'outil de diagnostic participe même à l'aveuglement. L'inspection d'URL de la Search Console vous montre le DOM après exécution du JavaScript. Le panneau Éléments des outils de développement de votre navigateur aussi. Les deux affichent un contenu que les crawlers IA ne verront jamais. Vous inspectez une réalité qui n'est pas la leur.
Une analyse de cas publiée en 2025 sur un site intégralement rendu côté client donne une idée du symptôme vu de l'autre côté. Interrogé sur une de ses pages, ChatGPT indiquait ne pas pouvoir en lire le contenu, celui-ci dépendant d'un rendu JavaScript. Perplexity signalait un échec de récupération. Claude renvoyait l'URL sans contenu visible. Les pages n'apparaissaient pas dans les citations mais dans les sections secondaires, sans extrait, avec un favicon générique. Le site n'était souvent pas même retenu comme source officielle sur des questions portant sur ses propres contenus.
Notons au passage une conséquence probable sur Google lui-même. Les AI Overviews s'appuyant sur l'index de recherche, il est raisonnable de penser qu'un site rendu côté client y entre avec le décalage de la file de rendu. Google ne le documente pas explicitement, et nous le donnons comme une déduction, pas comme un fait établi. Si elle se vérifie, vous n'êtes pas absent mais systématiquement en retard, ce qui pèse surtout sur les sujets d'actualité, comme nous l'évoquions dans notre article sur les AI Overviews.
Le cas le plus fréquent n'est pas celui que vous croyez
La single page application entièrement vide sans JavaScript est le cas d'école. Elle est spectaculaire, et relativement rare chez les entreprises établies.
Le cas réellement répandu est plus vicieux : un site majoritairement rendu côté serveur, dont quelques blocs seulement sont injectés par le navigateur. Et la liste de ces blocs a de quoi inquiéter :
- les prix et les grilles tarifaires, souvent chargés depuis une API pour rester à jour ;
- les FAQ en accordéon, dont les réponses sont fréquemment récupérées à l'ouverture ;
- les contenus en onglets, où seul le premier onglet existe dans la source ;
- les avis clients, presque toujours servis par un widget tiers ;
- les tableaux comparatifs générés à partir d'un jeu de données ;
- les contenus derrière un « voir plus » ou une pagination infinie.
Regardez cette liste une seconde fois. Ce sont exactement les formats qu'un moteur génératif cite le plus volontiers, parce que ce sont des passages courts, factuels, autonomes, directement réutilisables dans une réponse. Autrement dit, la partie de votre page la plus citable est très souvent la seule que le crawler ne voit pas.
Le paradoxe est complet sur un point précis. Un éditeur investit dans un balisage FAQ impeccable, obtient ses résultats enrichis sur Google, et reste absent des réponses génératives sur ces mêmes questions. La raison est banale : Google exécute le script de l'accordéon, pas OAI-SearchBot. C'est une des vérifications que nous menons en priorité sur les prestations de référencement ChatGPT.
Le rendu conditionne aussi la découverte de vos pages
Un second effet, moins évident, se joue sur les liens.
L'étude Vercel a mesuré une navigation nettement moins efficace du côté des crawlers IA : 34,82 % des récupérations de ChatGPT et 34,16 % de celles d'Anthropic aboutissent sur des pages 404, contre 8,22 % pour Googlebot. ChatGPT passe en plus 14,36 % de ses requêtes à suivre des redirections, contre 1,49 % pour Googlebot. Ces robots naviguent beaucoup à partir d'URL mémorisées ou reconstituées, et se trompent une fois sur trois.
Ils dépendent donc davantage que Googlebot des liens présents dans le HTML pour se repérer. Or si votre navigation est produite par un routeur côté client, si vos liens sont des <div> porteurs d'un gestionnaire de clic plutôt que des balises <a href>, ou si vos liens internes n'apparaissent qu'après hydratation, ces robots n'ont littéralement aucun chemin vers vos pages profondes.
Le problème se cumule proprement : un contenu invisible dans des pages elles-mêmes indécouvrables. C'est aussi pourquoi un sitemap.xml propre compte plus dans un contexte génératif que dans un contexte purement Google.
La nuance qui évite une refonte inutile
Un point est régulièrement mal compris, et il peut vous épargner beaucoup de travail.
Ce qui compte n'est pas que votre contenu soit du HTML sémantique parfaitement balisé dans la réponse initiale. Ce qui compte est qu'il soit présent en texte dans la réponse initiale, sous une forme ou une autre. Les modèles de langage lisent du texte, pas un arbre DOM. Vercel le note explicitement : un contenu livré dans la réponse HTML initiale reste exploitable, y compris sous forme de données JSON, ou via des React Server Components envoyés en différé dans le même flux.
Concrètement, une application Next.js dont le contenu se trouve dans la charge utile __NEXT_DATA__ ou dans le flux RSC est dans une bien meilleure position qu'une application React classique qui va chercher ses données en fetch après le montage des composants. Ce n'est pas idéal, le HTML sémantique reste préférable pour la structure et la sélection des passages, mais ce n'est pas la panne totale.
La règle de tri est simple : la question n'est pas « mon site utilise-t-il du JavaScript », mais « mon contenu est-il dans la réponse du serveur, ou faut-il un navigateur pour le faire apparaître ». L'hydratation n'est pas le problème. Le rendu initial l'est.
Le test qui prend trois minutes
Oubliez les outils qui affichent un DOM. La seule vérification honnête consiste à demander la page comme le ferait un crawler, et à regarder ce qui revient.
# 1. Le contenu est-il dans la réponse du serveur ?
curl -sL -A "OAI-SearchBot" https://votresite.com/page/ \
| grep -c "une phrase entière de votre contenu principal"
# 2. Quelle quantité de texte revient réellement ?
curl -sL -A "OAI-SearchBot" https://votresite.com/page/ | wc -c
# 3. Vos liens internes existent-ils en HTML ?
curl -sL -A "OAI-SearchBot" https://votresite.com/ \
| grep -o 'href="/[^"]*"' | sort -u | head -40
La lecture est immédiate. Un 0 à la première commande signifie que la phrase n'existe pas dans la source : ce contenu n'atteindra jamais ChatGPT. Une réponse de quelques kilo-octets sur une page longue trahit une coquille vide. Une troisième commande qui ne renvoie presque rien vous dit que vos pages sont indécouvrables.
Répétez l'opération sur vos trois ou quatre pages stratégiques, et surtout sur les blocs à risque de la liste précédente, pas seulement sur la page d'accueil. Il est courant qu'un site passe le test sur son accueil, rendu statiquement, et le rate sur ses pages produit.
Un deuxième contrôle, plus grossier mais parlant, consiste à désactiver JavaScript dans votre navigateur et à parcourir le site. Ce qui reste à l'écran est une bonne approximation de ce que reçoit un moteur génératif.
Que faire, sans refondre le site
Les corrections vont de la demi-journée au chantier, et il est rarement nécessaire d'aller jusqu'au chantier.
Le pré-rendu. Une étape de build génère un fichier HTML complet par URL, servi tel quel. C'est la solution la plus simple pour un site dont les pages changent peu, typiquement un site vitrine, un blog, des pages de service. Aucun serveur applicatif à maintenir. C'est exactement ce que nous appliquons sur ce site, en React : le HTML des articles est produit au build et déployé statiquement.
La génération statique. Même principe, industrialisé par le framework, avec régénération à la demande quand les données évoluent. C'est le bon choix par défaut pour la majorité des sites de contenu et des catalogues.
Le rendu serveur. Le serveur produit le HTML à chaque requête. Nécessaire dès que le contenu est personnalisé ou change en continu. Plus coûteux à exploiter, à réserver aux pages qui l'exigent réellement.
La correction chirurgicale. Souvent la meilleure première action. Vous ne touchez pas à l'architecture, vous faites simplement remonter dans le HTML initial les quelques blocs qui comptent : les prix, les réponses des FAQ, le contenu de tous les onglets, les liens de navigation en vraies balises <a href>. Le comportement interactif reste identique pour l'utilisateur, seule la source change. Sur beaucoup de sites, c'est une journée de développement pour l'essentiel du gain.
Ce que nous déconseillons, c'est le dynamic rendering, qui consiste à servir une version pré-rendue aux robots et l'application normale aux humains. Google l'a lui-même rétrogradé au rang de contournement temporaire, l'entretien est pénible, et la liste des user-agents à traiter change tous les trimestres. Vous ajoutez de la dette pour un problème qui a des solutions propres.
Un ordre de priorité raisonnable : corriger les blocs critiques d'abord, mesurer dans les logs si les crawlers reviennent et ce qu'ils obtiennent, et n'engager une bascule d'architecture que si le diagnostic la justifie encore.
Questions fréquentes
Un site React ou Vue peut-il être visible dans ChatGPT ? Oui, sans difficulté. Le framework n'est pas en cause, c'est la stratégie de rendu qui l'est. Une application React pré-rendue ou rendue côté serveur est parfaitement lisible par tous les crawlers IA. Ce site en est un exemple.
Mon site est bien classé sur Google, suis-je tranquille ? Non, et c'est précisément le piège. Googlebot exécute le JavaScript dans une seconde vague de rendu, les crawlers génératifs n'ont pas de seconde vague. De bons classements Google ne disent rien de votre lisibilité par ChatGPT, Claude ou Perplexity.
L'inspection d'URL de la Search Console suffit-elle à vérifier ? Non. Elle affiche le DOM après exécution du JavaScript, donc une version du contenu que les crawlers IA ne verront jamais. Utilisez curl ou l'affichage de la source, jamais le panneau Éléments.
Combien de temps avant de revenir dans les réponses après correction ? Cela dépend du passage des robots de recherche, qui repassent régulièrement. Comptez quelques semaines pour une réindexation visible, à condition que rien ne les bloque en amont. Vérifiez d'abord vos autorisations, détaillées dans notre guide des user-agents IA.
Faut-il un llms.txt pour compenser un site rendu côté client ? Non, et l'idée revient souvent. Un fichier qui décrit vos pages ne rend pas ces pages lisibles, et les données montrent qu'il n'est de toute façon quasiment jamais consulté, comme nous l'avons documenté dans notre analyse de llms.txt.
Le rendu est le premier étage de la visibilité générative, avant le contenu, avant la structure, avant l'autorité. Un moteur ne peut pas citer ce qu'il n'a jamais reçu. Et contrairement à la plupart des chantiers GEO, dont les effets se jugent sur des mois, celui-ci se vérifie en une commande et se corrige souvent en quelques jours.
Si vous voulez savoir ce que reçoivent réellement les crawlers de ChatGPT, Claude et Perplexity sur vos pages stratégiques, c'est le deuxième point que nous contrôlons dans un diagnostic de visibilité IA, juste après les autorisations.