Rendu côté serveur et robots IA : le piège du JavaScript

Une page qui brille sur Google peut être invisible pour ChatGPT

Un site en React, Vue ou Angular affiche son contenu après coup, une fois que le navigateur a téléchargé et exécuté le JavaScript. Googlebot sait faire ce travail depuis plusieurs années : il ouvre la page dans un navigateur headless, attend que le script s’exécute, puis indexe le résultat. GPTBot, ClaudeBot et PerplexityBot ne font rien de tout ça. Ils récupèrent le HTML brut renvoyé par le serveur, l’analysent tel quel, et passent à la page suivante. Si ce HTML brut ne contient qu’une balise <div id="root"></div> vide en attendant que React prenne le relais, ces robots ne voient rien du tout.

Ce décalage passe inaperçu pendant des mois parce que les deux symptômes ne se manifestent jamais au même endroit. Le classement dans Google Search Console reste stable, parfois même bon, puisque Googlebot rend correctement la page. C’est en interrogeant directement ChatGPT ou Perplexity sur son propre secteur qu’une PME découvre l’écart, généralement trop tard, après avoir investi dans un contenu que personne, côté IA, n’a jamais lu.

Le problème n’est pas nouveau, mais il change de nature. Entre 2015 et 2022, la bascule vers des frameworks JavaScript comme React ou Vue concernait surtout des applications web complexes, tableaux de bord, outils métier, où le SEO importait peu. Le même choix technique s’est ensuite généralisé aux sites vitrines et aux blogs d’entreprise, par habitude d’équipe plutôt que par nécessité, à une époque où seul Google savait gérer le rendu différé. L’arrivée des robots de réponse IA change le calcul : un choix d’architecture qui coûtait, au pire, un peu de délai d’indexation sur Google coûte aujourd’hui une absence pure et simple dans les réponses ChatGPT, Claude ou Perplexity.

Quels robots lisent le HTML brut, lesquels attendent le rendu

La liste des robots qui n’exécutent pas de JavaScript est plus longue qu’on ne l’imagine, et elle dépasse largement OpenAI.

Une analyse portant sur 569 millions de requêtes GPTBot sur un grand réseau d’hébergement en 2026 n’a trouvé aucune exécution de JavaScript, ni côté GPTBot, ni côté OAI-SearchBot, ChatGPT-User, ClaudeBot ou PerplexityBot. Une étude distincte publiée par Onely en février 2026 a chiffré à 42% la part du contenu rendu en JavaScript qui n’est jamais indexée par les systèmes d’IA, tous sites confondus. Ce n’est pas un bug ponctuel : c’est une limite structurelle, documentée dans les pages techniques de chaque opérateur, et qui n’a pas bougé depuis l’arrivée de ces robots.

Le test en cinq minutes : voir ce que voit réellement GPTBot

Pas besoin d’outil payant pour savoir où on en est. Cinq étapes suffisent, à répéter une fois sur chaque type de page importante du site : page d’accueil, fiche produit, article de blog.

1. Ouvrir la page dans le navigateur et désactiver le JavaScript (dans les outils de développement, onglet Rendering). Si le contenu principal disparaît, un robot IA voit exactement la même chose.
2. Faire un clic droit puis « Afficher le code source de la page » (pas l’inspecteur, qui montre le DOM déjà rendu). Chercher le texte du titre et du premier paragraphe : s’il n’apparaît pas dans ce code source brut, aucun robot IA ne le lira jamais.
3. Lancer curl -A "GPTBot" https://votresite.ch/page-cible depuis un terminal, et vérifier si le contenu attendu figure dans la réponse.
4. Comparer avec curl https://votresite.ch/page-cible sans user-agent particulier : si les deux réponses sont identiques et contiennent le texte, la page est déjà servie en HTML complet.
5. Vérifier les journaux du serveur sur les dernières semaines pour confirmer que GPTBot, ClaudeBot ou PerplexityBot visitent effectivement le site. Une page techniquement visible ne sert à rien si aucun robot ne passe jamais.

Un passage autonome pour résumer ce test : une page est visible pour les robots IA si son texte principal figure dans le HTML brut renvoyé par le serveur, avant toute exécution de script, et invisible dans le cas contraire, quelle que soit la qualité du rendu final dans un navigateur.

Trois façons de corriger le problème, du plus léger au plus lourd

Toutes les solutions ramènent à la même idée : renvoyer du HTML complet dès la première réponse du serveur, sans attendre qu’un script s’exécute côté client.

Le rendu côté serveur (SSR)

Le serveur exécute le rendu à chaque requête et renvoie une page HTML déjà complète. Next.js, Nuxt ou Angular Universal savent le faire nativement. C’est la solution la plus robuste pour un contenu qui change souvent, un fil d’actualité, un catalogue produit avec stock en temps réel, au prix d’une charge serveur supplémentaire à chaque visite.

La génération statique (SSG)

Les pages sont générées une fois, au moment du build, puis servies telles quelles. C’est le choix le plus simple pour un contenu éditorial qui ne change pas à chaque seconde, un blog ou un site vitrine. Un site 100% statique, comme celui que vous lisez en ce moment, sert par construction du HTML complet à chaque robot, sans étape de rendu intermédiaire.

Le rendu hybride ou le prerendering

Pour une application existante en rendu client qu’on ne veut pas réécrire entièrement, un service de prerendering (Prerender.io et équivalents) génère un instantané HTML des pages et le sert aux robots identifiés, tout en gardant la version JavaScript pour les visiteurs humains. C’est une solution de transition utile, pas une architecture définitive : elle ajoute une dépendance externe et un point de défaillance de plus.

Comment choisir entre les trois

Le critère décisif est rarement technique en premier lieu : c’est la taille de l’équipe qui maintiendra la solution dans la durée. Une PME sans développeur interne a intérêt à repartir sur une génération statique dès la prochaine refonte, plus simple à héberger et à faire auditer par un prestataire externe. Une entreprise avec un contenu qui change en continu, un catalogue produit ou un espace membre public, gagne davantage avec du SSR natif. Le prerendering reste réservé aux cas où aucune des deux autres options n’est réalisable avant plusieurs mois, le temps de sécuriser un budget de refonte plus large.

Quand ce n’est pas la peine de migrer tout le site

Un formulaire de connexion, un espace client authentifié, un configurateur interactif réservé à des utilisateurs déjà engagés : aucun de ces éléments n’a besoin d’être lu par un robot IA, et migrer ces sections vers du SSR consomme du budget sans aucun bénéfice de visibilité. La règle pratique est simple : seules les pages destinées à être trouvées, lues et citées par un robot, page d’accueil, pages de service, articles de blog, fiches produit publiques, justifient l’effort. Une PME avec un budget limité gagne davantage à migrer ses dix pages les plus stratégiques qu’à réécrire l’intégralité d’une application interne pour un bénéfice nul.

Il existe aussi un cas où le diagnostic ne change rien à la décision : un site déjà construit en rendu côté serveur ou en génération statique, comme WordPress avec un thème classique ou un générateur de site statique, n’a tout simplement pas ce problème. Le test des cinq minutes reste la bonne première étape avant d’investir dans un audit ou une migration : sur une bonne partie des sites d’entreprise romands, le contenu principal est déjà lisible sans JavaScript, et le vrai chantier se trouve ailleurs, dans la structure des données ou le maillage interne.

Un cas intermédiaire mérite d’être nommé directement : un site qui mélange les deux logiques, une coquille statique pour les pages marketing autour d’un espace produit en JavaScript, capte déjà l’essentiel du bénéfice sans réécriture complète. Auditer page par page, plutôt que de traiter le domaine comme une décision unique, réduit généralement le périmètre réel de la migration de plus de moitié.

Ce que ça change pour une PME romande

Une fiduciaire, un cabinet d’architectes ou une clinique privée qui a fait développer un site vitrine « moderne » ces dernières années a de bonnes chances d’avoir hérité d’une architecture en rendu client, souvent sans que personne n’ait posé la question à l’agence au moment du choix technique. Le symptôme typique : le site remonte correctement sur Google pour le nom de l’entreprise, mais n’apparaît jamais quand un prospect demande à ChatGPT ou Perplexity une recommandation dans son secteur et sa région. Le test décrit plus haut permet de vérifier le diagnostic en moins d’une heure, avant d’engager un budget de développement.

Ce chantier technique reste un prérequis, pas une stratégie complète : un site parfaitement rendu mais sans données structurées ni contenu réellement citable ne gagnera pas davantage de visibilité pour autant. C’est ce que couvre notre panorama des six leviers de la visibilité dans les moteurs de réponse IA, dont le rendu côté serveur n’est qu’un des six. Une fois le rendu corrigé, encore faut-il vérifier que les robots ne sont pas bloqués par ailleurs, un arbitrage détaillé dans notre méthode pour décider quels robots IA laisser passer, puis suivre l’effet dans le temps avec une méthode de mesure de la visibilité IA. Pour une PME qui veut savoir où elle en est avant d’investir, le Sprint GEO part justement de ce diagnostic technique. L’ensemble des articles du studio sur le sujet reste consultable sur le blog.