Votre site JavaScript est invisible pour les IA

Le robot qui visite votre site ne voit pas la même page que vous

Quand un crawler d’IA visite votre site, il ne voit peut-être qu’une page blanche. Vous voyez un site complet, avec ses titres, ses paragraphes, ses arguments. Le robot, lui, reçoit souvent un document quasi vide : un conteneur, un script, et rien à lire. La différence tient à un détail d’architecture que personne ne mentionne en réunion marketing, et qui décide pourtant si ChatGPT pourra un jour citer votre contenu.

Ce détail, c’est le rendu JavaScript. Une partie considérable du web B2B tourne aujourd’hui sur des frameworks comme React, Vue ou Angular qui construisent la page dans le navigateur, après le chargement. Cette technique fonctionne bien pour un utilisateur humain. Elle est silencieusement catastrophique pour la visibilité dans les moteurs de réponse, parce que les crawlers IA n’exécutent pas ce JavaScript.

Le problème est facile à diagnostiquer et souvent coûteux à ignorer. Voici comment savoir, en cinq minutes, de quel côté de la ligne se trouve votre site, et quoi faire si la réponse ne vous plaît pas.

Pourquoi les crawlers IA ne voient pas votre JavaScript

Un navigateur fait deux choses en chargeant une page : il télécharge le HTML, puis il exécute le JavaScript qui peut modifier, compléter ou construire entièrement le contenu affiché. Sur un site en rendu côté client (client-side rendering, ou CSR), la deuxième étape fait tout le travail. Le HTML initial ne contient presque rien, typiquement une balise <div id="root"></div> vide et un appel vers un bundle JavaScript. C’est ce bundle qui, une fois exécuté, va chercher les données et peindre la page.

Les crawlers d’IA, eux, s’arrêtent à la première étape. Ils récupèrent le HTML brut et ne lancent pas le moteur JavaScript. L’analyse publiée par Vercel fin 2024 sur le comportement réel de GPTBot, de ClaudeBot et des autres robots IA est sans ambiguïté sur ce point : ces agents ne rendent pas le JavaScript. La documentation de référence des éditeurs (OpenAI pour GPTBot, Anthropic pour ClaudeBot) décrit des robots qui récupèrent des pages, pas qui les rendent. Pour un site CSR, cela signifie que le robot lit le conteneur vide et repart sans avoir vu une seule phrase de votre contenu.

La comparaison avec Googlebot est instructive, parce qu’elle est trompeuse. Googlebot rend bien le JavaScript : il dispose d’un Chrome headless et procède en deux vagues, d’abord le HTML, puis le rendu différé. Beaucoup d’équipes en déduisent que leur SPA passe partout. C’est faux pour deux raisons. D’abord, même chez Google, ce rendu est différé et imparfait. Ensuite et surtout, les crawlers IA n’ont pas cette infrastructure : la construire et la faire tourner à l’échelle de milliards de pages coûte cher, et rien n’indique qu’ils prévoient de le faire. Parier sur leur évolution future, c’est parier votre visibilité présente.

Le test en cinq minutes

Inutile de croire sur parole qui que ce soit, y compris cet article. Le test est reproductible et prend quelques minutes. Trois méthodes, de la plus rigoureuse à la plus accessible.

1. Le curl avec user-agent de crawler. Ouvrez un terminal et lancez curl -A "GPTBot" https://votresite.fr/une-page-importante. La commande affiche exactement le HTML que le robot reçoit. Cherchez dans la sortie un paragraphe précis de votre contenu. S’il y figure, vous êtes visible. S’il manque, le robot ne le voit pas. Répétez avec -A "ClaudeBot" et -A "PerplexityBot" pour confirmer.
2. Le code source brut dans le navigateur. Sur la page à tester, faites Ctrl+U (ou clic droit, “Afficher le code source de la page”). Ce raccourci montre le HTML initial, avant exécution du JavaScript, c’est-à-dire à peu près ce que voit un crawler IA. Utilisez Ctrl+F pour chercher une phrase de votre contenu. Attention : l’inspecteur d’éléments (F12) montre le DOM après rendu, donc ne reflète pas ce que voit le robot. Il faut bien le code source, pas l’inspecteur.
3. La désactivation du JavaScript. Dans les paramètres du navigateur ou via une extension, coupez le JavaScript et rechargez la page. Si elle se vide ou affiche un message du type “activez JavaScript”, vous tenez votre réponse : sans exécution de script, il n’y a pas de contenu.

Si les trois tests convergent et que votre contenu est absent du HTML brut, le diagnostic est posé. Ce n’est pas une question d’opinion ni de sensibilité d’un moteur particulier : la matière première à citer n’est tout simplement pas livrée. C’est aussi la première chose qu’un audit GEO sérieux vérifie, à partir de 590 € livré en 10 jours (TVA non applicable, art. 293 B du CGI), avant même de parler de contenu ou de structure.

La grille de lecture des architectures

Tous les sites construits avec un framework JavaScript ne sont pas logés à la même enseigne. Ce qui compte n’est pas la technologie (React, Vue, Svelte, Angular), mais le moment et le lieu du rendu. Quatre grandes architectures, quatre verdicts pour la visibilité IA.

Architecture	Où le HTML est produit	Ce que reçoit le crawler IA	Verdict GEO
CSR (rendu client)	Dans le navigateur, après chargement	Conteneur vide + bundle JS	Bloquant : contenu invisible
SSR (rendu serveur)	Sur le serveur, à chaque requête	HTML complet	Visible
SSG (génération statique)	Au build, une fois pour toutes	HTML complet et figé	Visible et rapide
Prerendering	HTML pré-calculé servi aux robots	HTML complet	Visible (rustine efficace)

Le client-side rendering est le seul cas réellement bloquant. C’est aussi, par malchance, le mode par défaut de nombreux projets démarrés avec un create-react-app ou un Vue CLI dans les années 2018 à 2022, époque où la question de la lisibilité par les machines se résumait à Google et où Google savait à peu près faire. Ces sites fonctionnent, ils sont rapides à l’usage, et ils sont invisibles pour les moteurs de réponse.

Le rendu serveur (SSR) et la génération statique (SSG) produisent au contraire un HTML complet, dès la première réponse, sans rien attendre du navigateur. Next.js, Nuxt, SvelteKit ou Astro savent faire l’un, l’autre, ou les deux. La génération statique a un avantage supplémentaire pour le GEO : le HTML est figé au build, donc identique pour tous les visiteurs, humains comme robots, et servi instantanément. C’est l’architecture sur laquelle ce site est construit, et la documentation d’Astro explique précisément pourquoi ce choix sert la lisibilité par les machines.

Le prerendering est une voie intermédiaire : on garde une SPA, mais on génère à part des versions HTML pré-calculées des pages, servies aux robots. C’est une rustine, pas une refonte, et elle peut suffire pour débloquer une situation rapidement sans réécrire l’application.

Un site en rendu client n’est pas mal référencé pour les IA, il est absent. On ne classe pas un contenu qui n’a jamais été reçu : il faut d’abord exister dans le HTML, le reste vient ensuite.

Comment prioriser une migration sans tout refaire

La découverte qu’un site est invisible déclenche souvent une réaction démesurée : tout réécrire, changer de framework, lancer un chantier de six mois. C’est rarement la bonne décision, et c’est presque toujours inutile. La logique GEO impose de raisonner par valeur de page, pas par perfectionnisme technique.

Toutes les pages d’un site n’ont pas la même importance pour la citabilité. Un espace client, un tableau de bord, un configurateur : ces zones applicatives n’ont aucune vocation à être citées par une IA, et peuvent rester en rendu client sans dommage. Ce qui doit absolument être lisible par les machines, ce sont les pages à intention commerciale et informationnelle : pages de service, pages piliers, articles de fond, études de cas, FAQ. C’est là que se joue la visibilité dans les moteurs de réponse.

L’ordre des opérations est donc le suivant. D’abord, cartographier les pages à enjeu : celles qui répondent à des requêtes que vos prospects posent réellement aux IA. Ensuite, prérendre ou passer en statique ces pages-là en priorité, ce que tous les frameworks modernes permettent en rendu hybride, statique sur le public et client sur l’applicatif. Enfin seulement, envisager le reste, si le besoin se confirme. Cette priorisation par valeur est exactement ce que nous structurons dans nos missions d’accompagnement, à partir de 590 €/mois : on corrige d’abord ce qui rapporte de la visibilité, pas ce qui satisfait une exigence d’ingénieur.

Cette discipline rejoint un principe plus large de la méthode GEO : un site qui pratique le GEO traite la lisibilité par les machines comme une contrainte de conception, pas comme un correctif appliqué après coup. Le rendu serveur n’est pas une optimisation parmi d’autres, c’est la condition d’entrée. Sans lui, tout le travail éditorial sur la densité factuelle, les FAQ ou les données structurées tombe dans le vide, puisque rien n’est livré au robot.

Le cas vécu : d’une SPA React à un site statique

Ce sujet n’est pas théorique pour nous. seoisdead.fr a d’abord existé sous forme d’application React en rendu client, le choix par défaut de beaucoup de projets de cette génération. Le site fonctionnait, il était agréable à utiliser, et il était invisible pour exactement les moteurs que cette agence prétend maîtriser. Une incohérence intenable pour une marque dont le métier est de rendre les autres citables.

La bascule vers Astro, un générateur de sites statiques, a réglé le problème à la racine : chaque page est désormais produite en HTML complet au moment du build, servie telle quelle, lisible par n’importe quel crawler sans la moindre exécution de script. Le test au curl, qui ne renvoyait auparavant qu’un conteneur vide, renvoie maintenant l’intégralité du contenu rédactionnel. La leçon vaut au-delà de notre cas : la première question à se poser avant tout travail de contenu GEO n’est pas “que dois-je écrire”, mais “ce que j’écris est-il seulement livré aux machines”. Nous détaillons les autres prérequis techniques dans notre article sur ce que le fichier llms.txt change vraiment, où la lisibilité du HTML revient comme condition préalable à tout le reste.

À retenir

• Les principaux crawlers IA (GPTBot, ClaudeBot, PerplexityBot, CCBot) récupèrent le HTML brut mais n’exécutent pas le JavaScript. Un site en rendu client leur sert une page vide.
• Le problème n’est pas le framework (React, Vue, Angular) mais le mode de rendu. Le client-side rendering pur est le seul cas réellement bloquant ; SSR, SSG et prerendering restent visibles.
• Le diagnostic prend cinq minutes : un curl avec le user-agent d’un crawler, la lecture du code source brut, ou la désactivation du JavaScript. Si votre contenu n’est pas dans le HTML, le robot ne le voit pas.
• Compter sur le fait que les crawlers IA finiront par rendre le JavaScript comme Googlebot est un pari risqué : à date, ils ne le font pas, et l’infrastructure nécessaire est coûteuse.
• Corriger ne veut pas dire tout refaire. On prérend en priorité les pages à intention commerciale, en gardant le rendu client là où il ne nuit pas à la citabilité.