Commençons par l’essentiel : à l’heure actuelle, presque aucun robot d’exploration IA grand public n’exécute JavaScript. Si le contenu de votre page n’apparaît qu’après l’exécution de JS dans le navigateur, GPTBot, ClaudeBot et PerplexityBot voient une page vide. Il ne s’agit pas d’un simple enjeu de classement, mais d’une condition préalable : être visible ou ne pas exister.
L’erreur vient souvent du fait que l’on transpose aux robots IA ce que l’on sait de Googlebot. Au fil des années, Googlebot s’est doté de capacités de rendu JavaScript assez avancées. Même avec un rendu entièrement côté client, il parviendra probablement à récupérer le contenu, au prix d’un traitement plus lent et plus gourmand en ressources. Les robots IA ne fonctionnent pas ainsi. La plupart se contentent de récupérer le HTML brut renvoyé par le serveur, de le lire, puis de repartir : ils n’ouvrent pas de navigateur, n’attendent pas l’exécution de JS et ne lancent pas une seconde phase de rendu.
Les robots IA et Googlebot ne fonctionnent pas de la même manière
Googlebot explore les pages en deux vagues. Lors de la première, il lit le HTML brut et récupère immédiatement tout ce qui est déjà disponible. Lors de la seconde, la page rejoint une file d’attente de rendu : un navigateur sans interface graphique, comparable à Chrome, exécute JavaScript et ajoute le contenu généré dynamiquement. Ce mécanisme mobilise d’importantes ressources de calcul, un investissement que Google peut consentir puisque la recherche constitue son cœur de métier.
Les robots des entreprises d’IA ne disposent pas de cette seconde vague. À l’heure actuelle, GPTBot d’OpenAI, ClaudeBot d’Anthropic, le robot de Perplexity et OAI-SearchBot, chargé de la recherche en temps réel de ChatGPT, s’arrêtent tous au HTML. La raison est très concrète : exécuter un navigateur sans interface graphique à l’échelle du Web leur coûterait démesurément cher. Leur objectif est d’obtenir du texte directement exploitable par le modèle, pas de reproduire l’affichage de votre site. Tout le JavaScript consacré aux interactions, aux animations ou au chargement différé ne représente pour eux que du bruit — voire du vide. Google AI Overviews fait figure d’exception, car il s’appuie sur l’index existant de Google et bénéficie donc des capacités de rendu de Googlebot. Mais si vous ciblez également ChatGPT, Perplexity et Claude, vous ne pouvez pas partir du principe que JavaScript sera exécuté.
SSG, SSR ou CSR : quelles différences de lisibilité pour l’IA ?
Selon la stratégie de rendu employée, un même contenu se présente de façon radicalement différente au robot IA. Tout tient à une question : le contenu est-il déjà intégré au HTML côté serveur, ou n’apparaît-il qu’une fois JavaScript exécuté dans le navigateur ?
- SSG (génération statique) : le HTML complet de chaque page est généré lors de la compilation, puis enregistré sous forme de fichier statique. Le serveur renvoie directement la page finalisée ; le robot IA peut donc en récupérer l’intégralité du texte. C’est l’option la plus lisible et la plus rapide à charger.
- SSR (rendu côté serveur) : à chaque requête, le serveur assemble le HTML complet en temps réel avant de le renvoyer. Les robots IA accèdent eux aussi à l’intégralité du texte, mais le serveur doit refaire le calcul à chaque visite. En cas de trafic important, surveillez la charge.
- CSR (rendu entièrement côté client) : le serveur ne renvoie qu’une structure HTML presque vide. Le contenu réel n’est injecté qu’après le téléchargement et l’exécution de JS par le navigateur. Si le robot IA n’exécute pas JavaScript, il ne voit qu’une coquille vide, presque dépourvue de texte susceptible d’être cité.
Pour un robot IA, SSG et SSR ne présentent aucune différence fondamentale : dans les deux cas, le contenu est intégré au HTML côté serveur. Seul le moment du calcul change. Le SSG le réalise en amont ; le SSR, à la demande. La véritable ligne de partage se situe donc entre ces approches et le CSR. Sans rendu côté serveur, le HTML initial d’une application monopage (SPA) se limite souvent à un conteneur racine `div` vide suivi d’une série de balises `script`. C’est tout ce que lit le robot IA : aucun texte.
Un test à réaliser vous-même en 30 secondes
Vous pouvez déterminer si votre site est correctement accessible sans outil particulier ni intervention de l’équipe technique. Ouvrez une page stratégique dans votre navigateur, faites un clic droit, puis sélectionnez « Afficher le code source de la page ». Attention : n’utilisez pas le panneau Éléments des outils de développement. Celui-ci présente le résultat obtenu après l’exécution de JavaScript et peut donc vous induire en erreur. L’affichage du code source révèle le HTML brut initialement renvoyé par le serveur — celui que lit réellement le robot IA.
Comment corriger un site en CSR ?
Découvrir que votre site repose sur le CSR ne signifie pas qu’il faut reconstruire tout le front-end. Trois options s’offrent généralement à vous, classées ici de la moins coûteuse à la plus exigeante.
- Prérendu : lorsqu’un robot visite la page, le serveur lui renvoie un instantané HTML statique généré en amont. Cette solution permet de corriger rapidement une SPA existante avec un minimum de modifications. En contrepartie, il faut maintenir un mécanisme supplémentaire pour actualiser les instantanés.
- Adopter un framework compatible avec le SSR et le SSG : Next.js, Nuxt ou SvelteKit permettent de rendre côté serveur le contenu visible au-dessus de la ligne de flottaison, tout en conservant les interactions côté client. Pour la plupart de nos clients B2B, c’est la recommandation par défaut et l’option la plus fiable.
- Passer en priorité les pages stratégiques au SSR : si vos ressources sont limitées, inutile de transformer tout le site d’un seul coup. Commencez par les pages que l’IA doit pouvoir utiliser comme sources : pages produits, offres, tarifs et articles de fond. Le back-office et les outils interactifs peuvent parfaitement rester en CSR.
Toutes les pages n’ont pas besoin du SSR
Une stratégie de rendu relève de l’arbitrage, pas du dogme. Les tableaux de bord, les outils internes et les pages de configuration très interactives accessibles après connexion n’ont pas vocation à servir de sources aux IA. Les conserver en CSR est parfaitement logique ; imposer le SSR ne ferait qu’alourdir la charge du serveur. Concentrez-vous sur les pages que vous souhaitez voir utilisées comme sources dans les réponses des IA : celles qui expliquent le problème que vous résolvez, pourquoi votre solution est pertinente et ce qui la distingue. La règle est simple : si vous voulez que le contenu d’une page apparaisse dans les réponses de ChatGPT ou de Perplexity, il doit être intégralement présent dans le HTML côté serveur.
Googlebot attendra que votre JavaScript s’exécute ; les robots IA, non. Dans un monde où l’IA décide quelles sources citer, être invisible revient à ne pas exister.— Tenten GEO
Pour de nombreux sites B2B taïwanais, le problème d’explorabilité ne tient pas à la qualité éditoriale du contenu, mais au fait que celui-ci n’est jamais transmis à l’IA. La cause se cache souvent dans le choix du framework ou dans les paramètres de rendu. À l’écran, tout semble fonctionner normalement ; le problème n’apparaît qu’en consultant le code source. Si vous ignorez si vos pages stratégiques sont lisibles par les IA, notre diagnostic GEO de 30 minutes analyse directement votre URL pour vérifier si le HTML initial contient bien le contenu visible au-dessus de la ligne de flottaison et déterminer quelles pages doivent passer en priorité au rendu côté serveur.
