Ce que les agents IA reçoivent vraiment : rendu et JavaScript

Vous voyez une page complète. L’agent, lui, reçoit un fichier HTML brut. Si votre contenu est assemblé dans le navigateur par JavaScript, il y a un risque réel que ce qui est arrivé de l’autre côté ne soit qu’une coquille vide. La seule mesure publique que j’aie trouvée sur le sujet — réalisée par Vercel et MERJ en décembre 2024 — conclut qu’aucun des grands robots d’IA n’exécute JavaScript : ils téléchargent bien les fichiers JS (11,50 % des requêtes de ChatGPT, 23,84 % de celles de Claude) mais ne les exécutent jamais. Google fait exception : il effectue le rendu avec une version evergreen de Chromium, tout en s’arrêtant lui aussi à 2 Mo. Le test lui-même prend deux minutes et une ligne de curl.

La seule question qui compte : qu’y a-t-il dans le HTML initial ?

Il y a une différence entre ce que votre site affiche et ce que votre site envoie. Le navigateur reçoit un document HTML, télécharge les fichiers JavaScript, les exécute, effectue d’autres appels d’API et assemble à partir de tout cela la page que vous voyez. Toute la chaîne se déroule sur la machine de l’utilisateur, pas sur votre serveur. Un agent qui demande l’URL et s’arrête là ne reçoit que la première étape.

Sur la plupart des systèmes de gestion de contenu classiques, cela ne pose aucun problème, car le HTML arrive du serveur entièrement constitué. La difficulté commence quand le site est construit comme une application côté client : React, Vue ou Angular générant le contenu après le chargement. Dans ce cas, le document qui quitte votre serveur peut se résumer à trois kilo-octets de balises vides avec un <div id=”root”></div> au milieu, tout le reste étant construit uniquement dans le navigateur.

Un point mérite d’être souligné : ce n’est pas une question d’autorisations. Vous pouvez donner à tous les bots un accès total, renvoyer 200 à chaque requête, et n’apparaître malgré tout dans aucune réponse — simplement parce qu’il n’y avait aucun contenu à lire. J’ai décortiqué la couche des autorisations séparément dans la carte des bots 2026 ; voici la couche qui vient juste après.

Ce qui a réellement été mesuré — et ce qui ne l’a pas été

Le sujet demande de la prudence, car il regorge de chiffres qui circulent sans source. Ce qui existe : une étude conjointe de Vercel et MERJ publiée le 17 décembre 2024, analysant les logs réels de grands sites. Sa conclusion centrale est qu’aucun des grands robots d’IA — GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot et les autres — n’exécute JavaScript. Ils téléchargent les fichiers JS mais ne les exécutent pas. L’exception de leur liste est AppleBot, qui effectue le rendu via un navigateur.

La même étude donne aussi un ordre de grandeur du volume : environ 569 millions de requêtes mensuelles pour GPTBot et près de 370 millions pour Claude, soit ensemble à peu près un cinquième du volume de requêtes de Googlebot sur cette période.

Google est l’exception, pas la règle

Google Search Central indique explicitement, sur une page mise à jour le 4 mars 2026, que Google Search exécute JavaScript avec une version evergreen de Chromium et que Googlebot met en file d’attente pour le rendu toutes les pages renvoyant un code de statut 200. Dans le même document, Google ajoute la réserve la plus pertinente ici : tous les bots ne savent pas exécuter JavaScript.

Deux limites pratiques de Google méritent d’être connues. D’abord, selon la documentation de Googlebot, le robot récupère les 2 premiers mégaoctets d’un type de fichier pris en charge et s’arrête là. Si votre HTML est plus lourd, tout ce qui dépasse n’est tout simplement pas lu. Ensuite, sur les fonctionnalités fondées sur l’IA, Google précise qu’il n’existe aucune exigence technique supplémentaire au-delà du fait que la page soit indexée et éligible à un affichage avec extrait. Aucun fichier spécial, aucun balisage dédié : ce qui se lit bien dans Search se lit bien là aussi.

Trois schémas qui vident la page

Le rendu côté client. Le cas classique. Le document venant du serveur ne contient qu’une coquille, et le contenu se charge ensuite. Facile à repérer : le code source de la page est bien plus court que ce que l’œil voit.

Le contenu qui ne s’ouvre qu’à l’interaction. Accordéons, onglets, « charger plus », défilement infini. Si le contenu n’est injecté dans le DOM qu’après un clic, il n’existe pas dans le document. S’il est présent dans le HTML et simplement masqué en CSS, il est bien là, et c’est parfaitement acceptable.

Les couches bloquantes devant le contenu. Une bannière de cookies qui exige un consentement avant le chargement du contenu, un paywall, une fenêtre de connexion, ou une couche de gestion des bots qui renvoie un challenge. Dans ces cas-là, le bot reçoit bien une page — mais pas la vôtre.

Comment le vérifier en deux minutes

Aucun outil externe n’est nécessaire. Trois lignes suffisent pour savoir exactement ce qui quitte votre serveur :

L’interprétation est simple. Si la ligne 2 renvoie un nombre proche du nombre de mots que vous voyez sur la page, tout va bien. Si elle renvoie 40 mots pour une page de 1 200 mots, le contenu est construit dans le navigateur. Si la ligne 3 renvoie 0, votre phrase centrale n’existe dans aucune réponse qui sera jamais générée à partir de cette page. Il vaut aussi la peine de refaire le même test avec un user-agent de navigateur ordinaire et de comparer : un écart important entre les deux indique un serveur qui sert un contenu différent aux bots.

Comment confirmer que le bot est authentique

Avant de tirer des conclusions de votre log, assurez-vous que celui qui se présentait comme GPTBot est bien GPTBot. Tous les grands acteurs publient des listes officielles d’adresses IP, et Google publie en plus une méthode de vérification par DNS inversé :

Google est le seul des quatre à proposer une vérification par DNS inversé. Chez les autres, comparer l’IP à la liste officielle est la seule vérification disponible. Mieux vaut récupérer ces fichiers automatiquement plutôt que de recopier les plages à la main — elles changent.

Que faire quand la réponse est « la page est vide »

Le correctif dépend de l’architecture, mais la direction est la même dans tous les cas : déplacer l’assemblage du contenu du navigateur vers le serveur.

1. Rendu côté serveur ou génération statique. Dans les frameworks modernes, c’est un réglage page par page, pas une réécriture. Le résultat est un HTML complet dès la toute première réponse, ce qui améliore aussi le temps de chargement pour les utilisateurs humains.
2. Vérifiez que le contenu principal ne dépend pas d’une interaction. Un accordéon dont le contenu se trouve dans le HTML et est masqué en CSS est une solution parfaitement valable. Un accordéon qui va chercher son contenu au clic ne l’est pas.
3. Regardez ce qui se passe avant le consentement. Si la bannière de cookies bloque le contenu jusqu’au clic, le bot ne voit rien. Le contenu doit être présent dans le document même quand rien n’a été cliqué.
4. Mesurez à nouveau ; ne supposez pas. Après chaque changement, la même ligne de curl. La vérification prend quelques secondes, et supposer que ça a marché est exactement ce qui a créé le problème au départ.

Et si la question plus large vous intéresse — ce qu’un agent d’IA lit réellement sur votre site avant même que la question du rendu ne se pose — j’en ai parlé dans la couche de découverte.

Un ordre de priorités concret

Si vous avez une heure, voici l’ordre que je recommande. D’abord, lancez le test curl sur les trois pages les plus importantes du site — la page d’accueil, la page de service principale et l’article qui reçoit le plus de trafic. Ensuite, comparez le nombre de mots à ce qui est réellement visible. Ce n’est qu’en cas d’écart qu’il faut ouvrir la question de l’architecture. Sur la plupart des sites WordPress et des sites vitrines, la réponse sera que tout va bien, et c’est un très bon résultat — mieux vaut savoir que passer un mois à résoudre un problème que l’on n’a pas.

Questions fréquentes