Les crawlers IA peuvent-ils lire votre site ? Nous avons vérifié 342 sites de lancement sans JavaScript

En octobre 2026, nous avons interrogé 365 sites de produits lancés sur aat.ee comme le ferait un crawler qui n'exécute pas JavaScript, et nous avons compté le texte présent dans le HTML renvoyé. Sur les 342 qui ont répondu avec un code HTTP 200, 37 (10,8 %) renvoyaient moins de 50 mots de texte dans le corps. Presque tous avaient encore un titre et une méta-description, si bien que la page semble correcte dans un aperçu de lien alors que le contenu n'arrive qu'après l'exécution de JavaScript. Lorsque nous avons chargé ces mêmes 37 pages dans un vrai navigateur, 23 des 30 qui ont fini de charger affichaient 150 mots ou plus.

Cela compte parce qu'on a observé que les crawlers derrière ChatGPT, Claude et Perplexity n'exécutent pas JavaScript. Si la description de votre produit n'existe que dans la page rendue, ces systèmes risquent de ne jamais la voir. Voici les chiffres, la cause, et une vérification que vous pouvez faire sur votre propre site en deux minutes.

Quels crawlers exécutent JavaScript

OpenAI, Anthropic, Meta, ByteDance et Perplexity ne documentent pas si leurs crawlers rendent le JavaScript. La meilleure preuve disponible est une étude de décembre 2024 menée par Vercel et MERJ. Elle a constaté qu'aucun des principaux crawlers d'IA qu'elle a examinés ne rendait le JavaScript : OAI-SearchBot, ChatGPT-User et GPTBot d'OpenAI, ClaudeBot d'Anthropic, Meta-ExternalAgent, Bytespider de ByteDance et PerplexityBot. Les crawlers de ChatGPT et de Claude téléchargeaient bien les fichiers JavaScript (11,50 % et 23,84 % de leurs requêtes), mais ne les exécutaient pas. Gemini, qui utilise l'infrastructure de Googlebot, rendait bien le JavaScript. AppleBot aussi.

Googlebot rend le JavaScript, mais en une étape séparée. Le guide JavaScript SEO de Google indique que les pages sont mises en file d'attente et que « lorsque les ressources de Google le permettent, un Chromium headless rend la page et exécute le JavaScript ». Google recommande toujours le rendu côté serveur ou le pré-rendu, car « cela rend votre site plus rapide pour les utilisateurs et les crawlers, et tous les bots ne peuvent pas exécuter JavaScript ».

L'étude est une seule observation, vieille de presque deux ans, et le comportement des crawlers peut changer sans préavis. C'est néanmoins la meilleure donnée disponible, et aucune des entreprises ne l'a contredite.

Comment nous avons mesuré

• Échantillon : 400 URL de projets tirées au hasard parmi les produits lancés sur aat.ee dans les 120 jours précédant l'audit. Nous avons gardé une URL par nom d'hôte et écarté 14 liens qui pointaient vers GitHub, des app stores ou Hugging Face plutôt que vers le site propre du produit, ce qui a laissé 365 sites. 342 ont renvoyé un code HTTP 200 et constituent la base des chiffres ci-dessous.
• Requête : un seul GET par site avec un user agent portant le jeton OAI-SearchBot d'OpenAI, en suivant les redirections, sans exécuter JavaScript.
• Mesure : mots de texte visible dans le corps après suppression des éléments <script>, <style>, <noscript>, <template> et <svg>. Nous avons aussi relevé si le HTML contenait un titre, une méta-description, un lien canonical, du JSON-LD et un <h1>.
• Limites : nous n'avons récupéré que l'URL soumise par le fondateur, généralement la page d'accueil. Nos requêtes venaient de notre propre réseau, pas des plages d'IP d'OpenAI, si bien qu'un site qui traite différemment les crawlers vérifiés pourrait leur servir autre chose. Le texte à l'intérieur des balises script n'a pas été compté. L'étude de Vercel note que les données intégrées au HTML initial, comme le JSON, « peuvent tout de même être indexées », donc pour certains frameworks notre comptage sous-estime ce que reçoit un crawler. La plupart des pages vides ci-dessous sont des applications monopages dont le contenu réside dans des bundles JavaScript séparés, que l'étude a constaté que ces crawlers téléchargent mais n'exécutent pas.

Les résultats

Le site médian renvoyait environ 1 180 mots, donc la plupart des sites de lancement sont en bonne forme. Le problème est concentré : 37 sites, presque tous avec quasiment rien dans le corps.

L'en-tête est rempli et le corps est vide. Sur les 37 pages pauvres, 36 avaient un <title> et 34 une méta-description. Seules 4 avaient un <h1>, et seules 4 avaient cinq liens ou plus. Un crawler qui lit ce HTML apprend le nom du produit et un argumentaire d'une ligne, et rien sur les fonctionnalités, le prix ou le public visé.

Un seul schéma en explique la plupart. 30 des 37 servaient un <div id="root"> ou un <div id="app"> vide et construisaient toute la page dans le navigateur, ce qui est le comportement par défaut d'une application monopage créée avec Vite ou Create React App. 12 étaient des builds Vite. À l'inverse, sur les 165 sites Next.js de l'échantillon, un seul était pauvre. Next.js rend les pages côté serveur par défaut, donc le contenu est dans la première réponse.

Les templates fuient. 16 des 37 avaient encore la méta-description par défaut de Create React App, « Web site created using create-react-app ». Ces 16 provenaient de trois comptes de soumission lançant une même famille de produits similaires, ce qui gonfle le total. Si on les exclut, la part de pages pauvres est de 21 sur 326, soit 6,4 %. Cela reste environ un lancement sur seize.

Dans un navigateur, le contenu est là

Nous avons ensuite chargé les 37 pages pauvres dans Chromium headless, attendu cinq secondes après l'événement load, et recompté le texte visible. 30 pages ont fini de charger. 7 ont expiré après trois tentatives.

La page médiane est passée de 0 mot dans le HTML brut à environ 475 après rendu. Donc pour la plupart de ces sites, le texte existe, et un visiteur dans un navigateur le voit. Il n'est simplement pas dans le HTML que le serveur envoie, qui est la seule partie que lit un crawler qui ne rend pas le JavaScript. Les cinq qui restaient sous 50 mots étaient un écran de connexion, une page qui s'affichait vide et trois pages très courtes. Celles-là sont pauvres pour tout le monde, pas seulement pour les crawlers.

Une découverte annexe : certaines protections anti-bots bloquent aussi le crawler

Trois sites ont répondu à notre requête OAI-SearchBot par un code HTTP 403 et à la même requête avec un user agent Chrome par un code 200. Deux d'entre eux renvoyaient un challenge Cloudflare (cf-mitigated: challenge). Aucun de leurs fichiers robots.txt n'interdisait les crawlers d'IA, donc les propriétaires ne cherchaient probablement pas à les bloquer.

Nous ne pouvons pas en déduire si le vrai crawler d'OpenAI est bloqué. Les protections anti-bots comme celle de Cloudflare peuvent reconnaître les bots vérifiés par leurs adresses IP, et nos requêtes ne venaient pas d'OpenAI. Considérez cela comme une raison de vérifier : si vous utilisez Cloudflare, contrôlez les réglages relatifs aux crawlers d'IA et à la lutte anti-bots dans le tableau de bord et assurez-vous qu'ils correspondent à ce que dit votre robots.txt.

Vérifiez votre propre site en deux minutes

1. Récupérez-le comme le fait un crawler.

   UA='Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)'
   curl -sL -A "$UA" -o raw.html -w '%{http_code}\n' https://yoursite.com
   grep -c 'a sentence from your hero section' raw.html

   UA='Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)'
   curl -sL -A "$UA" -o raw.html -w '%{http_code}\n' https://yoursite.com
   grep -c 'a sentence from your hero section' raw.html

   Un statut autre que 200 signifie généralement que le crawler reçoit une page d'erreur ou de challenge au lieu de votre contenu. Un compte de 0 signifie que cette phrase exacte n'est pas dans le HTML. Choisissez une phrase courte, car le balisage peut en scinder une longue.

2. Regardez la page sans JavaScript. Dans les DevTools de Chrome, ouvrez le menu des commandes (Ctrl+Shift+P ou Cmd+Shift+P), lancez « Disable JavaScript » et rechargez. Ce que vous voyez correspond à peu près à ce que lit un crawler qui ne rend pas le JavaScript.

3. Vérifiez Google séparément. L'inspection d'URL de la Search Console montre le HTML rendu par Googlebot. Elle ne vous renseigne que sur Google.

4. Répétez l'opération pour vos pages de tarifs et de fonctionnalités, pas seulement pour la page d'accueil. Ce sont les pages dont un assistant a besoin pour décrire votre produit.

Comment corriger, selon votre stack

Trois règles s'appliquent quel que soit votre outil :

• Mettez les faits dans la première réponse. C'est-à-dire le nom du produit, ce qu'il fait, à qui il s'adresse, le prix et les liens principaux, dans le HTML que le serveur renvoie.
• Servez aux bots la même page qu'aux humains. Google qualifie le rendu dynamique, une version pré-rendue séparée pour les crawlers, de « contournement et non de solution recommandée ». Le guide GEO de Microsoft indique : « Assurez-vous que le DOM rendu contient les mêmes faits que ceux que voient les consommateurs — ne servez jamais un HTML différent aux bots. »
• Ne vous arrêtez pas au <head>. Un bon titre et une bonne description aident pour les aperçus de lien. Ils ne suffisent pas à un crawler pour décrire votre produit.

FAQ

Google voit-il mon contenu rendu côté client ? Généralement, à terme. Googlebot met les pages en file d'attente pour le rendu et exécute le JavaScript avec Chromium headless. Cela couvre Google Search et Gemini. Pour être un lien de support dans les AI Overviews, une page « doit être indexée et pouvoir être affichée dans Google Search avec un extrait », donc un rendu lent ou échoué peut encore vous coûter cher à ce niveau. Cela ne couvre pas ChatGPT, Claude ou Perplexity, dont les crawlers n'ont pas été observés en train de rendre le JavaScript.

Un <div id="root"> vide est-il une pénalité de classement ? Non. Rien ne le pénalise. Le coût, c'est qu'un crawler qui ne rend pas le JavaScript n'a rien à lire, donc il ne peut ni citer ni décrire la page.

Mon site a une bonne méta-description. Cela ne suffit-il pas ? Elle donne au crawler une phrase. Un assistant à qui l'on demande ce que fait votre produit, ou comment il se compare à une alternative, a besoin du texte du corps : fonctionnalités, prix, cas d'usage.

Dois-je reconstruire mon application ? Généralement non. Pré-rendre les pages publiques, comme l'accueil, les tarifs, les fonctionnalités et la documentation, suffit. L'application connectée peut rester rendue côté client.

Corriger cela me vaudra-t-il d'être cité par ChatGPT ? Personne ne peut le promettre. Être lisible est une condition préalable. Le fait d'être cité dépend de ce que disent d'autres sources à votre sujet et de la qualité avec laquelle votre page répond à la question. Notre playbook d'optimisation pour la recherche IA couvre le reste.

Lectures associées

• Le guide du fondateur 2026 sur les crawlers d'IA : robots.txt, llms.txt et citation
• Lire les logs des crawlers d'IA : ce que GPTBot demande réellement
• La checklist de lancement de site web
• 7 affirmations GEO vérifiées à la lumière de la documentation de Google

Sources

• Vercel et MERJ : The rise of the AI crawler (décembre 2024)
• Google Search Central : Understand JavaScript SEO basics
• Google Search Central : Dynamic rendering as a workaround
• Google Search Central : AI features and your website
• Next.js : Server and Client Components
• Microsoft Advertising : From discovery to influence: a guide to GEO
• aat.ee : audit du HTML brut de 365 sites de produits lancés (342 analysés), octobre 2026

Chaque produit sur aat.ee dispose d'une page de présentation permanente rendue côté serveur, afin que les crawlers puissent lire une description de votre produit avant même que votre propre site ne soit prêt à les recevoir. Soumettez votre produit, ou consultez les options de présentation.