Pourquoi la recherche IA ne voit pas votre site React ou SPA — et le correctif sans tout reconstruire
Vous avez construit une single-page app soignée. Elle est belle, rapide, elle marche parfaitement dans votre navigateur. Puis vous interrogez ChatGPT sur votre produit : il ne vous connaît pas. Idem avec Perplexity. Idem avec les AI Overviews de Google.
Le problème, en général, ce n'est pas votre contenu. C'est le moment où votre contenu apparaît.
À retenir
- Beaucoup de robots IA lisent le HTML brut envoyé par votre serveur — pas la page que votre navigateur construit après avoir exécuté le JavaScript.
- Une single-page app en rendu côté client (CSR) envoie souvent une coquille HTML quasi vide : le robot voit une page blanche.
- Ça touche React, Vue et la plupart des sites vibe-codés (Lovable, Bolt, v0) par défaut.
- Pas besoin de tout reconstruire : prerendering, SSR/SSG ou un fallback statique rendent votre vrai contenu visible.
- Vous pouvez vérifier ce que voit un robot en une soixantaine de secondes.
Ce que « rendu côté client » veut dire
Quand on visite une page rendue côté serveur, le serveur renvoie du HTML qui contient déjà les mots, les titres et les liens. Le navigateur se contente de les afficher.
Une app en rendu côté client fonctionne autrement. Le serveur envoie un fichier quasi vide — souvent juste ceci :
<div id="root"></div>
<script src="/app.js"></script>
Votre navigateur télécharge ensuite le JavaScript, l'exécute, appelle vos API et construit la page en direct. Un humain ne remarque rien ; ça prend quelques millisecondes. Mais une machine qui ne lit que la première réponse voit <div id="root"></div> et rien d'autre.
Pourquoi les robots IA s'arrêtent souvent à la coquille vide
Le Google classique a passé des années à construire un moteur de rendu en deux temps qui exécute le JavaScript avant d'indexer. Beaucoup de moteurs de réponse IA, non. Leurs robots sont souvent plus légers : ils récupèrent le HTML, en extraient le texte, et passent à la suite. Si le texte utile n'existe qu'après l'exécution du JavaScript, il n'y a rien à extraire.
Le modèle n'ingère donc jamais votre proposition de valeur, votre liste de fonctionnalités, votre FAQ ou vos tarifs. Quand un utilisateur pose plus tard une question à laquelle votre page répond parfaitement, vous n'êtes tout simplement pas dans la course — non pas parce que vous êtes mal classé, mais parce que vous n'avez jamais été lu.
Comment savoir si mon site est en rendu côté client ?
Deux tests rapides :
- « Afficher la source », pas « Inspecter ». Clic droit → « Afficher le code source de la page » (pas « Inspecter »). Vous voyez le HTML brut envoyé par le serveur. Si vous n'y trouvez pas votre vrai titre et votre texte — seulement des balises
<script>et un<div>vide — votre contenu est rendu côté client. - Désactivez le JavaScript dans les outils développeur et rechargez. Si la page devient blanche ou tourne indéfiniment sur un spinner, c'est à peu près ce qu'obtient un robot qui n'exécute pas le JS.
Le correctif — et pourquoi vous n'avez sans doute pas à tout reconstruire
Trois approches pratiques, de la plus légère à la plus lourde :
1. Le prerendering (le plus léger). Un service de prerendering ou une étape de build génère un instantané HTML statique de chaque route et le sert aux robots. Votre app reste exactement la même pour les humains ; les robots reçoivent du HTML complet. C'est le gain le plus rapide pour une SPA existante qu'on ne veut pas toucher.
2. La génération statique (SSG). Si votre contenu ne change pas à chaque requête — pages marketing, docs, blog — générez du vrai HTML au moment du build. Des frameworks comme Next.js, Astro ou Nuxt le font nativement. La page part complète dès la première réponse.
3. Le rendu côté serveur (SSR). Le serveur rend le HTML complet à chaque requête, puis « hydrate » en app interactive dans le navigateur. Idéal pour du contenu dynamique et public qui doit toujours être à jour.
Pour la plupart des sites marketing vibe-codés, le SSG ou le prerendering suffit — et aucun des deux n'oblige à réécrire votre app.
Le compromis à faible effort : même en gardant votre SPA, assurez-vous que votre texte le plus important vit dans le HTML initial — un vrai
<h1>, un paragraphe décrivant ce que vous faites, et vos liens clés. Une page interactive à 90 % mais qui livre son message central en HTML brut a déjà une longueur d'avance sur un<div id="root">vide.
Où ça se situe dans le reste de votre visibilité IA
Le rendu, c'est le socle. Si le robot ne peut pas lire votre texte, rien d'autre ne compte — ni vos données structurées, ni vos sections FAQ, ni vos titres. Tout cela doit exister dans un HTML analysable par une machine avant même qu'elle n'exécute du JavaScript.
Dans notre audit de 301 sites vibe-codés, la plus grande fracture n'était pas l'outil — c'était la configuration du domaine : les sites sur un vrai domaine propre affichaient un Score de Visibilité IA moyen de 43,8, contre seulement 24,3 pour ceux coincés sur un sous-domaine partagé. Le rendu relève du même type de problème invisible et structurel : réparez la tuyauterie, et votre contenu atteint enfin les modèles.
Vérifiez ce que voit le robot — en 60 secondes
N'essayez pas de deviner si votre contenu survit au trajet jusqu'à un robot IA. Lancez un scan SearchAudit gratuit : collez votre URL et nous vous montrons ce qu'une IA lit réellement, si votre texte central a bien atterri dans le HTML, et exactement quoi corriger en premier — sans compte, sans carte bancaire.
→ Lancez votre audit gratuit en 60 secondes
Liens internes suggérés (A1) :
/fr/blog/pourquoi-recherche-ia-ne-voit-pas-votre-site/fr/blog/json-ld-donnees-structurees-recherche-ia/fr/blog/rendre-site-lovable-visible-chatgpt/fr/blog/meme-correctif-visibilite-ia-cinq-stacks/fr/blog/audit-301-sites-vibe-codes-visibilite-ia
