Crawlers IA et JavaScript : pourquoi ChatGPT peut voir une page vide

Réponse courte : Pour les crawlers IA et JavaScript, la règle est simple : un robot qui n’exécute pas les scripts ne voit que le HTML envoyé par votre serveur. Si votre texte est construit dans le navigateur, ce HTML peut n’être qu’une coquille vide. Dans une mesure de Vercel et MERJ de décembre 2024, aucun des grands crawlers IA n’exécutait JavaScript, alors que le crawler de Google et AppleBot le faisaient. C’est un instantané de 2024 : testez donc vos propres pages et placez le contenu principal dans le HTML lui-même, en le rendant côté serveur ou en le générant à l’avance.

Comment un crawler obtient-il votre page ?

Chaque récupération commence de la même façon : une requête adressée à votre serveur, à laquelle il répond par du HTML. Ce qui se passe ensuite détermine la part de votre page qui arrive.

Un navigateur charge les scripts vers lesquels pointe le HTML, les exécute et affiche le résultat. Un crawler peut s’arrêter après le premier HTML. Ou bien il effectue un rendu : il exécute les scripts, attend, et ne lit qu’ensuite.

Si le serveur envoie le texte, les deux chemins mènent au même contenu. Si la page est assemblée dans le navigateur, le premier HTML n’en contient presque pas. La documentation de Google appelle cela le modèle « app shell ». Un robot sans JavaScript reçoit à peu près ceci :

<body>
  <div id="root"></div>
  <script src="/app.js"></script>
</body>

Le titre, le texte, la liste de produits et les liens n’apparaissent qu’une fois /app.js exécuté. Tous les crawlers ne l’exécutent pas, et tout le problème tient à cela.

Ce que Google fait de JavaScript

Google est le cas facile. Sa documentation sur les bases du SEO pour JavaScript indique que :

• Google Search exécute JavaScript avec une version « evergreen » de Chromium, c’est-à-dire tenue à jour.
• Une page passe par trois phases : exploration (crawling), rendu (rendering) et indexation.
• Une page au statut 200 est placée dans une file d’attente pour le rendu, ce qui peut prendre quelques secondes ou plus. Pour une page dont le statut n’est pas 200, comme un 404, le rendu peut être sauté.
• Le title, la meta description et le canonical peuvent être définis avec JavaScript.

La même page donne aussi la raison d’être de cet article. Google écrit que le rendu côté serveur ou le pré-rendu reste une bonne idée, parce qu’il accélère la page pour les utilisateurs comme pour les crawlers, et parce que tous les robots ne savent pas exécuter JavaScript. « Google indexe ma page » ne signifie donc pas que tous les robots peuvent la lire.

Crawlers IA et JavaScript : ce que l’on sait vraiment

La mesure la plus connue vient de Vercel et de MERJ, publiée en décembre 2024 sous le titre The rise of the AI crawler. Leur constat : aucun des grands crawlers IA n’exécutait JavaScript. L’étude cite parmi eux GPTBot, OAI-SearchBot, ChatGPT-User et ClaudeBot. Googlebot (listé dans l’étude pour Gemini) et AppleBot exécutaient JavaScript.

Deux précautions s’imposent à côté de ce résultat. D’abord, c’est un instantané de 2024, et nous n’avons pas de mesure plus récente à citer. Les crawlers évoluent : voyez-y un avertissement, pas une loi. Ensuite, il dit ce qu’un robot lit, pas si une page est citée dans une réponse. Personne ne peut promettre une citation, avec ou sans JavaScript.

Les robots n’ont pas tous le même rôle. Voici ce que disent leurs exploitants :

Les sources sont OpenAI, Anthropic et Perplexity. Perplexity dispose aussi d’un robot distinct pour les consultations à la demande d’un utilisateur. Si les robots qui alimentent les réponses de recherche IA ne lisent que le HTML, une page réduite à une coquille vide ne leur donne rien à citer. Savoir lesquels exécutent les scripts, c’est justement ce qu’a mesuré l’étude de 2024, et c’est ce que vous devez vérifier sur vos propres pages.

Qui est concerné ?

Vous êtes concerné si le texte ou les liens de vos pages n’existent pas dans le HTML que votre serveur envoie :

• Les pages entièrement assemblées dans le navigateur. Le serveur répond avec une coquille et un paquet de scripts, et le script écrit le titre, le texte et la navigation.
• Les contenus que des scripts chargent après coup. Listes de produits, prix, avis, onglets ou sections « Charger plus » qui proviennent d’un appel d’API une fois la page chargée.
• Les liens qui n’existent qu’après l’exécution des scripts. Un crawler sans JavaScript ne peut suivre que les liens présents dans le HTML. Le parcours de site de SEOgrinder se heurte lui aussi à ce point : il note que les liens qui n’apparaissent que dans le navigateur ne peuvent pas être suivis.
• Les balises title, description, canonical et Open Graph qu’un script définit. Google l’accepte. Un robot qui saute les scripts ne les voit jamais.

Vous n’êtes pas concerné si le serveur envoie déjà le texte. Des extras interactifs, comme un menu, un graphique ou une calculatrice, peuvent toujours être construits dans le navigateur. SEOgrinder signale les pages qui n’existent que dans le navigateur par « La page n’est construite que dans le navigateur », car de nombreux crawlers IA n’exécutent pas JavaScript et y voient une page presque vide.

Trois tests en une minute

Vous n’avez pas besoin d’un outil pour le savoir. Les trois tests répondent à la même question : mon texte est-il dans le HTML que le serveur envoie ?

1. Afficher le code source de la page. Ouvrez votre page et choisissez « Afficher le code source de la page » (Ctrl+U, ou Cmd+Option+U sur Mac). N’utilisez pas « Inspecter » : l’inspecteur montre la page après l’exécution des scripts. Cherchez dans le code source une phrase que vous pouvez lire sur la page.
2. Récupérer la page avec curl. Dans un terminal, exécutez curl -sL https://example.com/votre-page | grep -io "une courte expression de votre page", en remplaçant l’expression par un court extrait de votre propre page. Si l’expression s’affiche, elle figure dans le HTML, sauf si elle apparaît uniquement dans un élément script, ce qui ne compte pas. Si rien ne s’affiche, vérifiez d’abord l’orthographe et les caractères spéciaux ; sinon, elle n’est pas dans le HTML.
3. Désactiver JavaScript. Ouvrez les outils de développement, ouvrez le menu de commandes (Ctrl+Maj+P, ou Cmd+Maj+P sur Mac), tapez « JavaScript », choisissez « Désactiver JavaScript » (« Disable JavaScript » dans l’interface en anglais) et rechargez la page. Si le contenu principal a disparu, un robot sans JavaScript voit la même chose.

Comment lire le résultat :

Deux limites : curl montre ce que votre serveur envoie à curl, pas ce qu’il envoie à un robot précis, par exemple lorsqu’un pare-feu traite les robots autrement. Et pour voir ce que Google a rendu, utilisez l’inspection d’URL de la Google Search Console.

Comment corriger : mettre le contenu dans le HTML

L’objectif est que les titres, le texte courant et les liens internes soient visibles dans le code source. Il y a deux façons courantes d’y arriver :

• Le rendu côté serveur (SSR). Le serveur construit le HTML final à chaque requête.
• Le pré-rendu, aussi appelé génération statique (SSG). Les pages sont générées à l’avance, par exemple lors de la construction du site, et le serveur se contente de livrer les fichiers.

Les deux placent le contenu dans la première réponse. Par ailleurs :

• Commencez par les pages qui comptent. Une refonte complète est rarement nécessaire. Débutez par les pages qui doivent se classer ou être citées.
• Mettez l’essentiel dans le premier HTML. C’est-à-dire le title, la meta description, le canonical, les balises Open Graph, le texte principal et les liens de navigation écrits comme de vrais éléments <a href>.
• Donnez le même contenu aux crawlers et aux visiteurs. Google ne présente le « dynamic rendering », où les robots reçoivent une version pré-construite, que comme un pis-aller. Montrer aux crawlers autre chose qu’aux visiteurs, c’est du cloaking.
• Vérifiez le résultat dans le code source. Refaites les trois tests après la modification.

Rien de tout cela n’est une garantie de classement. Cela supprime un obstacle technique, rien de plus.

Comment SEOgrinder détecte les pages construites dans le navigateur

SEOgrinder examine le HTML que livre votre serveur, pas ce qu’un navigateur en fait. Saisissez une adresse, lancez l’analyse, et les tâches apparaissent dans l’onglet Tâches, triées par effet. Trois constats concernent ce sujet :

• « La page n’est construite que dans le navigateur ». Le constat indique combien de mots, de titres et de liens internes contient le HTML livré, et précise que Google rend ces pages avec un décalage et que de nombreux crawlers IA voient une page presque vide.
• « N pages ne sont construites que dans le navigateur ». Le parcours de site indique combien de pages explorées livrent une coquille HTML presque vide. Les pages en noindex et les pages de connexion ou d’inscription ne sont pas comptées.
• « N pages de connexion ou d’inscription naissent dans le navigateur ». C’est généralement sans gravité, car de telles pages fonctionnent pour les visiteurs sans rendu côté serveur. Si l’une d’elles doit se classer, rendez-la côté serveur.

Après une correction, cliquez sur Réanalyser : les rapports restent jusqu’à 24 heures en cache, et ce bouton force une nouvelle analyse (quelques fois par heure). Confier à l’IA transforme le rapport en ordre de travail Markdown pour un agent de programmation comme Claude Code, Cursor ou GitHub Copilot, avec une condition d’arrivée vérifiable pour chaque constat.

Ce que SEOgrinder ne fait pas : il ne mesure pas si ChatGPT, Gemini ou Perplexity citent réellement votre marque. Il vérifie la base technique, c’est-à-dire si le contenu peut tout simplement être lu.

Erreurs fréquentes

• Tester avec « Inspecter » plutôt qu’avec « Afficher le code source ». L’inspecteur montre le résultat après l’exécution des scripts, c’est-à-dire exactement ce qu’un robot sans JavaScript ne reçoit pas.
• Conclure « Google l’indexe, donc tous les robots peuvent le lire ». Google exécute JavaScript, et sa propre documentation précise que tous les robots ne le font pas.
• Définir le title et les balises meta uniquement avec un script. Google l’autorise, mais un robot qui n’exécute pas les scripts ne les voit jamais. Mettez-les dans le premier HTML.
• Des liens qui ne sont que des gestionnaires de clic. Utilisez de vrais liens <a href>, pour qu’un crawler puisse les suivre sans exécuter de scripts.
• Faire du dynamic rendering le plan permanent. Google parle d’un pis-aller.
• Répondre à chaque adresse inconnue par la coquille avec le statut 200. Les applications rendues côté client le font souvent, et de telles pages peuvent être traitées comme des soft 404. Une page absente doit renvoyer un vrai 404 (ou 410).
• Autoriser les robots dans le robots.txt et les refuser au pare-feu. Le texte existe, mais le robot reçoit une erreur. SEOgrinder a un constat pour ce cas : « Robots d’IA autorisés mais refusés par le serveur — à vérifier ». Lisez aussi notre article sur le robots.txt pour les crawlers IA.

Questions fréquentes

Google voit-il ma page JavaScript ?

Généralement oui, mais plus tard. Google exécute JavaScript avec un Chromium evergreen, et les pages au statut 200 attendent dans une file pour le rendu. L’indexation n’est jamais garantie. L’inspection d’URL de la Google Search Console montre ce que voit Googlebot.

Un sitemap suffit-il ?

Non. Un sitemap indique aux crawlers quelles adresses existent. Il ne place aucun texte dans le HTML de ces pages.

ChatGPT et Claude exécutent-ils JavaScript ?

Dans la mesure de Vercel et de MERJ de 2024, les crawlers d’OpenAI et d’Anthropic qui y sont cités ne le faisaient pas. Nous n’avons pas de mesure plus récente à citer : testez donc vos propres pages plutôt que de vous fier à l’une ou l’autre réponse.

Dois-je refaire tout mon site ?

Pas nécessairement. Le rendu côté serveur ou le pré-rendu des pages qui doivent se classer ou être citées est la première étape habituelle. Les parties interactives peuvent rester dans le navigateur.

Les assistants IA me citeront-ils si je rends mes pages côté serveur ?

Personne ne peut le promettre. Vous vous assurez ainsi que le texte peut être lu, et c’est la condition préalable à tout le reste.

Votre prochaine étape

Choisissez une page importante et faites les trois tests. Si le texte manque dans le code source, lancez l’analyse gratuite dans SEOgrinder et ouvrez l’onglet Tâches. Corrigez les pages les plus importantes en les rendant côté serveur ou en les générant à l’avance, puis cliquez sur Réanalyser.