Ce qu’il faut retenir : Claude et Perplexity ne rendent pas le JavaScript côté client. Si votre site repose sur React, Vue ou Next.js mal configuré, vous êtes invisible pour 2 LLM majeurs sur 4 en 2026.
Pourquoi 2 LLM majeurs sur 4 ne rendent pas votre JavaScript en 2026
La documentation officielle Anthropic publiée en mai 2026 est sans ambiguïté :
« The web fetch tool currently does not support websites dynamically rendered via JavaScript ».
Claude récupère uniquement le HTML initial servi par le serveur. Tout contenu chargé après par JavaScript reste invisible. Perplexity fonctionne sur la même mécanique selon les tests Vercel publiés en décembre 2024 et confirmés par Glenn Gabe (GSQi) en août 2025.
La cause est technique. Les LLM ne sont pas Google. Google maintient une infrastructure de rendu JavaScript depuis plus de 10 ans, avec des coûts d’infrastructure en milliards de dollars. Les LLM sont arrivés trop vite pour répliquer cette infrastructure. Ils utilisent des appels HTTP simples qui récupèrent le HTML brut, parsent le contenu textuel, et passent à la suite. Aucun moteur JavaScript en aval.
L’étude Salt Agency publiée en septembre 2025 sur 2 138 sites confirme cette mécanique à grande échelle. Sur l’échantillon analysé, les sites en rendu purement client (Single Page Application sans SSR) obtiennent des taux d’inclusion dans les réponses IA significativement plus faibles que les sites en rendu serveur, indépendamment de la qualité éditoriale du contenu.
Le constat opérationnel pour 2026 : un site bien rédigé, bien chunké, avec une bonne autorité SEO, peut rester totalement invisible pour Claude et Perplexity si son architecture technique repose sur du JavaScript client. Les efforts éditoriaux GEO sont alors annulés par un blocage technique en amont.
La matrice de visibilité par LLM en mai 2026
Les 4 grands LLM ont des comportements distincts face au JavaScript. Cette matrice synthétise l’état de l’art en mai 2026, basé sur les sources officielles (documentation Anthropic, communications OpenAI) et les tests indépendants Vercel et Salt Agency.
| LLM | Rendu JavaScript | Conséquence pour votre site | Source |
|---|---|---|---|
| Claude (Anthropic) | Non | Site invisible si rendu client uniquement | Doc officielle Anthropic, mai 2026 |
| Perplexity | Non | Site invisible si rendu client uniquement | Tests Vercel 2024, GSQi 2025 |
| ChatGPT (OpenAI) | Incertain selon versions | Visibilité aléatoire, dépend du mode (SearchGPT ou conversationnel) | Tests Salt Agency 2025 |
| Gemini (Google) | Oui | Site visible, profite de l’infrastructure Google | Doc Google + tests Salt Agency |
Le résultat est asymétrique : seul Gemini lit votre JavaScript de manière fiable. Les 3 autres LLM, qui représentent collectivement la majorité du trafic IA en mai 2026 (ChatGPT en volume, Claude en knowledge work, Perplexity en B2B), ont un comportement défavorable au rendu client.
Cette asymétrie a une conséquence stratégique forte : si votre cible utilise majoritairement ChatGPT, Claude ou Perplexity, l’investissement technique pour basculer vers du rendu serveur est rentable rapidement. Si votre cible est Google-centrée et utilise Gemini, l’urgence est moins forte mais reste pertinente à moyen terme.
Comment tester votre site en 5 minutes
Vous pouvez vérifier dès maintenant si votre site est lu correctement par les LLM sans web fetch JavaScript. La méthode prend 5 minutes et ne nécessite aucun outil payant. Trois tests complémentaires se renforcent mutuellement.
Test 1 : Désactiver le JavaScript dans votre navigateur
Sur Chrome, ouvrez les DevTools (F12), allez dans Settings (icône engrenage en haut à droite des DevTools), puis « Debugger » et cochez « Disable JavaScript ». Rechargez votre page. Si le contenu textuel principal apparaît correctement, votre site passe le test. Si la page est blanche, vide ou affiche uniquement un loader, votre contenu est invisible aux LLM qui ne rendent pas le JavaScript.
Cette méthode reproduit exactement ce que voient Claude et Perplexity quand ils récupèrent votre URL. C’est le test le plus proche de la réalité d’extraction des LLM.
Test 2 : Utiliser curl en ligne de commande
Dans un terminal, exécutez la commande curl -L https://votre-site.com/votre-page. La commande retourne le HTML brut servi par votre serveur, sans aucune exécution JavaScript. Recherchez le contenu textuel principal de votre page dans la sortie. S’il y est, vous êtes en SSR (Server-Side Rendering) ou en pré-rendu statique. S’il n’y est pas, votre contenu est généré côté client et reste invisible aux LLM concernés.
Cette commande reproduit littéralement le mécanisme de fetch des LLM. Si vous voyez du HTML quasi vide avec uniquement des balises script et un div id= »root » ou « app » sans contenu, vous êtes en rendu client pur.
Test 3 : Demander directement à Claude et Perplexity
Le test ultime : ouvrez Claude et Perplexity, copiez l’URL d’une page importante de votre site, et demandez « Peux-tu lire le contenu de cette page et me résumer le premier paragraphe ? ». Si l’IA répond avec un résumé pertinent, votre contenu est accessible. Si elle répond qu’elle ne peut pas accéder au contenu ou produit un résumé générique, votre page est invisible.
Glenn Gabe (GSQi) a documenté cette méthodologie en 2025. Elle reste la plus fiable pour valider en conditions réelles.
Les 3 catégories de sites les plus invisibles aux LLM
Trois catégories concentrent l’essentiel des sites en situation problématique en mai 2026. Si votre site appartient à l’une d’elles, le test des 5 minutes est prioritaire.
Les SaaS B2B en React ou Next.js mal configurés
La majorité des SaaS B2B français lancés depuis 2022 utilisent React, Next.js ou Vue. Le problème ne vient pas du framework lui-même. Next.js bien configuré (App Router avec Server Components, ou Pages Router avec getServerSideProps / getStaticProps) rend correctement côté serveur. Le problème vient des configurations par défaut ou des migrations partielles où le contenu critique reste rendu côté client.
Les pages les plus exposées : pages de pricing avec prix calculés dynamiquement, pages de fonctionnalités avec contenu chargé via API client, pages blog avec composants React qui chargent les articles après le mount. Sur ces pages, le HTML servi est souvent vide. C’est la situation la plus fréquente que je rencontre en audit.
Les e-commerce headless
L’architecture headless commerce (front en Next.js, Nuxt ou Gatsby qui consomme une API Shopify, Commercetools, Magento) est devenue standard pour les e-commerce mid-market. Le risque GEO est massif si la configuration n’inclut pas de rendu serveur ou de génération statique au moment du build.
Les pages produit en headless mal configuré servent souvent un HTML vide aux LLM. Les fiches produit, les comparatifs, les guides d’achat deviennent invisibles. L’enjeu commercial est élevé car ces pages sont précisément celles qui pourraient capter du trafic IA dans les requêtes de recommandation produit.
Les sites Webflow ou Framer mal configurés
Webflow et Framer sont devenus populaires pour les sites marketing en 2024-2025. Ces plateformes peuvent générer du HTML rendu correctement, mais certaines configurations (fortes interactions, animations complexes, contenus chargés via CMS dynamique) basculent en rendu client. Les sites concernés perdent en visibilité IA sans que les équipes marketing en aient conscience.
Le test simple : les pages avec beaucoup d’animations Lottie, de scroll triggers, ou de contenu CMS chargé via API sont les plus à risque. Une page d’accueil simple Webflow rend correctement, une page avec composants dynamiques peut ne pas rendre.
Les solutions par ordre de complexité et de coût
Plusieurs corrections sont possibles selon votre stack et votre budget. Je classe par ordre croissant de complexité et de coût.
- Activer le SSR ou la génération statique sur les pages critiques (gratuit à 5 jours dev) : pour Next.js, basculer vers App Router avec Server Components ou utiliser getServerSideProps / getStaticProps. Pour Nuxt, activer le mode universal. C’est la solution la plus propre et la plus pérenne.
- Utiliser un service de prerender (50-200 €/mois) : Prerender.io ou Rendertron interceptent les requêtes des bots et leur servent une version pré-rendue. Solution rapide à déployer, mais ajoute une dépendance externe et un coût récurrent.
- Migrer vers une architecture hybride (10 à 30 jours dev) : conserver le React/Vue côté front pour l’interactivité, mais ajouter une couche SSR pour le contenu critique. Solution la plus flexible mais demande une refonte technique partielle.
- Servir une version texte alternative pour les bots (1-2 jours dev) : détecter les User-Agents des LLM (GPTBot, ClaudeBot, PerplexityBot) et leur servir une version statique du contenu. Solution rapide mais fragile sur la durée et potentiellement perçue comme du cloaking si mal exécutée.
Le choix dépend de votre stack actuel, de vos ressources dev disponibles et de l’urgence stratégique. Pour un SaaS B2B mature en Next.js, la migration vers App Router avec Server Components est la voie la plus propre. Pour un e-commerce headless, le pré-rendu via Prerender.io reste l’option la plus rapide pour démarrer.
Comment mesurer l’impact réel d’un correctif via Cockpyt AI
Sans mesure, vous ne pouvez pas justifier l’investissement technique de la correction. La méthode baseline / post-correction sur un panel de prompts stratégiques produit des données chiffrées exploitables en interne.
La méthode que j’applique chez Cockpyt AI :
- Baseline avant correction : relevé du Share of Voice IA sur 30 à 100 prompts stratégiques liés à votre marque, en isolant les citations Claude et Perplexity (les 2 LLM les plus impactés)
- Mise en place du correctif technique : SSR, prerender ou hybride selon votre choix
- Mesure à 30 et 60 jours : nouvelle exécution du panel pour identifier les nouvelles citations, particulièrement sur Claude et Perplexity
- Coverage Breadth delta : mesure de la progression de votre couverture cross-platform. Une correction réussie fait passer votre présence de 1-2 LLM (Gemini + ChatGPT partiel) à 3-4 LLM
Les premiers effets apparaissent à 30 jours pour Perplexity (recherche web active) et entre 30 et 60 jours pour Claude selon la captation par les retrievers connectés au web.
FAQ sur le rendu JavaScript et les LLM en 2026
Pourquoi Google rend le JavaScript et pas Claude ou Perplexity ?
Google maintient une infrastructure de rendu JavaScript depuis plus de 10 ans, avec des milliards de dollars d’investissement. Les LLM sont arrivés trop vite pour répliquer cette infrastructure. Ils utilisent des appels HTTP simples qui récupèrent le HTML brut sans exécuter le JavaScript. C’est un choix d’architecture technique et de coûts, pas une volonté de discriminer les sites modernes.
Mon site est en Next.js, suis-je forcément concerné ?
Non, pas forcément. Next.js bien configuré (App Router avec Server Components ou Pages Router avec getServerSideProps / getStaticProps) rend correctement côté serveur. Le problème survient avec les configurations par défaut en rendu client uniquement, ou avec des composants critiques qui chargent leur contenu via fetch côté client après le mount. Le test des 5 minutes vous donne la réponse précise.
SearchGPT contourne-t-il le problème de JavaScript pour ChatGPT ?
Partiellement. SearchGPT utilise une recherche web active qui peut ramener davantage de contenu, y compris depuis des pages indexées par Google qui sont déjà rendues. Mais le mode conversationnel classique de ChatGPT garde le comportement incertain documenté par Salt Agency. La meilleure pratique reste de servir un HTML rendu côté serveur pour garantir la lecture par toutes les versions de ChatGPT.
Combien coûte le passage de CSR à SSR sur un site existant ?
Cela varie selon la complexité du site. Pour un site Next.js avec migration vers App Router : 5 à 15 jours dev pour un site moyen. Pour un e-commerce headless avec architecture custom : 20 à 40 jours dev. Pour une solution de prerender comme Prerender.io : 1 à 2 jours dev plus 50 à 200 euros de coût mensuel. La rentabilité se mesure sur le delta de Share of Voice IA gagné, mesurable à 60 jours.
La situation va-t-elle évoluer en 2026-2027 avec les nouvelles versions de Claude et Perplexity ?
Possiblement. Anthropic et Perplexity peuvent investir dans le rendu JavaScript dans les prochains mois ou années. La documentation officielle Anthropic en mai 2026 confirme l’absence de support actuel, sans annonce de roadmap. Plutôt que d’attendre, la stratégie la plus sûre consiste à servir du HTML rendu serveur, qui sera toujours lisible par toutes les versions futures des LLM.
Cloudflare ou un CDN suffisent-ils à résoudre le problème ?
Non, pas en eux-mêmes. Cloudflare et les CDN servent le contenu plus vite, mais ne transforment pas du JavaScript client en HTML rendu. Cloudflare propose toutefois des features de prerender (HTML Cache + Workers) qui peuvent simuler un SSR, mais demandent une configuration spécifique. Pour une solution propre, le SSR natif de votre framework reste préférable.
Comment savoir si le problème vient du JavaScript ou d’une autre cause ?
Le test curl est diagnostiquant. Si curl -L sur votre URL retourne du HTML avec votre contenu textuel principal, le problème ne vient pas du JavaScript. Il peut venir d’un manque d’autorité de domaine, d’un mauvais chunking, d’une absence de signaux d’entité brand, ou simplement d’une faible présence sur les sources tierces que les LLM privilégient. Un audit Cockpyt AI avec analyse cross-LLM identifie la cause précise.
Sources
- Anthropic, Web fetch tool documentation, mise à jour mai 2026, https://platform.claude.com/docs/en/agents-and-tools/tool-use/web-fetch-tool
- Salt Agency, Technical SEO for AI Search, septembre 2025, https://salt.agency/blog/technical-seo-for-ai-search/
- Glenn Gabe (GSQi), AI Search and JavaScript Rendering Case Study, août 2025, https://www.gsqi.com/marketing-blog/ai-search-javascript-rendering/
- Vercel, AI Bots and JavaScript Rendering Tests, décembre 2024.
- Stacker + Scrunch, Coverage Breadth Study: The Latest GEO Research, mars 2026, https://stacker.com/blog/latest-research-on-expanding-brand-visibility-across-llms
