SEO des applications monopages (SPA) : faire indexer une SPA par Google et la rendre lisible par les IA

Le SEO des applications monopages (SPA) regroupe les techniques qui rendent une application JavaScript construite avec React, Vue, Angular ou Svelte aussi facile à explorer qu'un site classique. Le problème est bien documenté : Google explique dans ses principes de base du SEO JavaScript qu'il traite les pages JavaScript en trois phases (exploration, rendu, indexation), et chaque faiblesse d'une SPA se loge quelque part dans cette chaîne. Ce guide porte sur les SPA ; pour les sites JavaScript en général, lisez notre guide du SEO JavaScript.

Qu'est-ce qu'une application monopage, et pourquoi pose-t-elle problème en SEO ?

Un site classique renvoie un document HTML complet pour chaque URL. Une SPA renvoie presque le même document pour toutes les URL : un <div id="root"> vide, quelques balises meta et un gros fichier JavaScript. Le navigateur télécharge ce fichier, interroge une API, puis dessine la page. Quand le visiteur clique sur un lien, le JavaScript remplace le contenu sans recharger la page.

Pour un humain équipé d'un téléphone rapide, l'affichage paraît instantané. Pour un robot d'exploration, la première réponse est une coquille vide : aucun titre, aucun texte, aucun lien. Tout dépend de l'exécution du JavaScript par le robot, et du moment où elle a lieu. Ce seul fait explique la plupart des problèmes SEO des SPA :

• Contenu différé ou absent : le texte n'existe qu'après le rendu, que Google effectue plus tard et que les autres robots ignorent.
• Une seule URL pour plusieurs vues : les anciennes SPA gèrent la navigation avec des fragments (/#/pricing), et la partie située après le # n'est jamais envoyée au serveur, si bien que toutes les vues se confondent en une seule URL.
• Titres et descriptions identiques : la coquille porte un seul <title> et, si le routeur ne le met pas à jour, toutes les pages le partagent.
• Liens sans href : les boutons et les gestionnaires onClick font naviguer les visiteurs mais ne donnent rien à suivre aux robots.
• Fausses erreurs 404 (soft 404) : le serveur répond 200 pour chaque chemin, y compris pour les pages qui n'existent pas, et les vues d'erreur sont indexées comme des pages pauvres.
• JavaScript trop lourd : les gros fichiers ralentissent le premier affichage et les interactions, ce qui pénalise les Core Web Vitals.

Comment Google explore-t-il et rend-il une SPA ?

Googlebot récupère d'abord le HTML brut et lit les liens et les directives qu'il y trouve. Les pages qui renvoient un statut 200 sont ensuite placées dans la file d'attente du Web Rendering Service, un Chromium sans interface. Google précise qu'une page « peut rester dans cette file d'attente quelques secondes, mais cela peut prendre plus de temps ». Une fois la page rendue, le HTML obtenu est de nouveau analysé pour son contenu et ses liens, puis indexé.

Quatre détails de la documentation de Google comptent pour les SPA :

1. Seuls les éléments <a> dotés d'un href sont des liens fiables. Les liens injectés par JavaScript conviennent tant qu'ils respectent ce format.
2. Les fragments ne sont pas des pages distinctes. Google demande d'utiliser l'API History (pushState) plutôt que des routes en #. Il a abandonné son ancien schéma d'exploration AJAX (les URL en #!) en octobre 2015.
3. Un noindex dans le HTML d'origine l'emporte. Google peut sauter le rendu lorsqu'il voit un noindex : le retirer ensuite en JavaScript ne fonctionne donc pas.
4. Le rendu utilise des fichiers en cache. Googlebot met le JavaScript et le CSS en cache de façon agressive : utilisez des noms de fichiers versionnés (une empreinte du contenu dans le nom du fichier) pour éviter de servir des fichiers périmés.

La conséquence est directe : Google peut indexer une SPA rendue côté client, mais vous ajoutez à chaque page une deuxième étape, un délai et un point de défaillance. Un temps d'attente dépassé, un appel d'API bloqué ou une erreur JavaScript pendant le rendu, et la version indexée reste vide. Vérifiez ce que voit Google avec l'outil d'inspection d'URL de la Search Console, et lisez notre guide sur le fonctionnement de l'indexation Google si des pages restent hors de l'index.

ChatGPT, Claude et Perplexity lisent-ils le JavaScript ?

Pour l'essentiel, non. Dans une étude publiée en décembre 2024 sur le trafic de son réseau, Vercel et MERJ ont constaté qu'« aucun des principaux robots d'exploration des IA n'exécute actuellement le JavaScript » : GPTBot, OAI-SearchBot et ChatGPT-User (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Meta-ExternalAgent et Bytespider lisent tous uniquement le HTML brut. Ils téléchargent bien les fichiers JavaScript (environ 11,5 % des requêtes de ChatGPT et 23,8 % de celles de Claude) mais ne les exécutent pas. Les exceptions sont Gemini, qui s'appuie sur l'infrastructure de rendu de Google, et AppleBot, qui utilise un robot fondé sur un navigateur.

Pour une SPA rendue côté client, cela signifie que les robots d'exploration des IA qui alimentent ChatGPT, Claude et Perplexity voient une page vide. Votre produit peut se positionner sur Google et rester invisible dans les réponses des IA, car l'assistant n'en a jamais lu un mot. Il en va de même pour la plupart des robots d'aperçu de liens des réseaux sociaux et des messageries, qui lisent les balises Open Graph dans le HTML brut. Une fois le contenu présent dans le HTML, vérifiez aussi que votre robots.txt autorise les robots des IA que vous souhaitez accueillir.

Quelle stratégie de rendu choisir pour une SPA ?

La solution consiste à envoyer du vrai HTML dès la première réponse. Dans sa documentation sur le rendu dynamique, Google présente le rendu dynamique (servir une version prérendue aux seuls robots) comme « une solution de contournement » qu'il ne recommande pas, et oriente plutôt vers le rendu côté serveur, le rendu statique ou l'hydratation. Les définitions ci-dessous suivent la référence Rendering on the Web publiée sur web.dev.

La plupart des frameworks modernes permettent de mélanger les stratégies selon la route : statique pour les pages marketing, rendu serveur pour le catalogue, rendu client pour l'application connectée. Ce montage hybride donne aux robots un HTML complet là où arrive le trafic de recherche et garde l'expérience SPA là où elle apporte de la valeur.

Options par framework

Les sites produits par les créateurs de sites à base d'IA méritent une mention à part : beaucoup exportent une application React rendue côté client. Si vous avez construit votre site avec l'un d'eux, consultez nos notes sur le SEO et le GEO de Lovable avant de supposer que Google et ChatGPT peuvent le lire.

Liste de contrôle SEO pour une SPA : quoi corriger route par route

1. Donnez à chaque vue une URL propre et explorable

Utilisez l'API History (/pricing, jamais /#/pricing), une URL par contenu, et la même URL que le visiteur arrive directement ou par la navigation interne. Chaque URL doit charger le bon contenu quand on l'ouvre dans un nouvel onglet : c'est le test que fait un robot d'exploration.

2. Utilisez de vrais liens

Chaque élément de navigation qui mène à une page indexable doit être un <a href="/path">. Les composants de lien des frameworks (Link, NuxtLink, routerLink) produisent ce balisage ; les gestionnaires de clic personnalisés sur des éléments div ou button ne le font pas. De bons liens portent aussi votre architecture de site : si une page n'est reliée à aucune autre, les robots la trouvent rarement.

3. Mettez à jour le titre, la description et l'URL canonique de chaque route

Chaque route a besoin de son propre titre, de sa méta description, de sa balise canonique et de ses balises Open Graph, générés sur le serveur si possible. Notre page sur les balises meta liste les éléments à renseigner. Gardez une seule balise canonique : Google recommande de la définir dans le HTML et, si le JavaScript la modifie, le résultat ne doit pas contredire l'original.

4. Renvoyez des codes de statut honnêtes

Les produits manquants et les articles supprimés ne doivent pas répondre 200 avec un message d'erreur. Avec le SSR, renvoyez une vraie 404 ou 410 depuis le serveur. Dans une SPA pure, Google accepte deux solutions de repli : rediriger en JavaScript vers une URL qui renvoie une 404, ou ajouter une balise meta robots noindex à la vue d'erreur.

5. Placez le contenu principal et les données structurées dans le HTML

Titres, texte, prix, FAQ et données structurées JSON-LD doivent figurer dans la réponse du serveur, et non être chargés après un clic ou un défilement. Le contenu placé derrière des onglets rendus à la demande, ou derrière des boutons « Charger plus », est souvent manqué.

6. Gardez le JavaScript léger

Découpez le code par route, différez ce qui n'est pas utile au premier affichage et évitez de rendre de nouveau toute la page pendant l'hydratation. Notez que les données terrain de Chrome (CrUX) attribuent les métriques des navigations internes à l'URL chargée en premier par le visiteur : testez donc vos modèles de page clés un par un.

7. Testez ce que reçoivent les robots

Comparez trois versions de chaque modèle de page clé : le HTML brut (affichez le code source ou récupérez la page avec un outil en ligne de commande), le HTML rendu par Google (Inspection de l'URL, puis « Afficher la page explorée ») et la page avec le JavaScript désactivé. Si le texte principal n'apparaît que dans la deuxième version, les robots des IA ne le voient pas. Notre audit d'explorabilité pour les IA gratuit et le vérificateur d'indexabilité effectuent ces contrôles sur n'importe quelle URL.

Comment savoir si votre SPA a un problème SEO ?

SEO et GEO des SPA : être trouvé sur Google et cité par les IA

Pendant des années, le rendu côté client restait un risque maîtrisable, car Google finissait par exécuter le JavaScript. Maintenant qu'une partie de la découverte se fait dans ChatGPT, Claude, Gemini et Perplexity, le coût a changé : une page qui n'existe qu'après l'exécution du JavaScript est absente des sources que la plupart des assistants peuvent lire. L'explorabilité dans le HTML brut est devenue la première condition de l'optimisation pour les moteurs génératifs (GEO).

Une fois le HTML complet, le reste suit les règles habituelles : les pages qui répondent clairement à une question, avec des faits sourcés et des données structurées, sont celles que les assistants citent. Les fonctions d'optimisation GEO de Sorank vous aident à rédiger et à publier ce contenu, et le suivi des mentions dans les IA montre si ChatGPT, Claude et Gemini citent votre marque après la correction du rendu.

La règle clé du SEO des applications monopages tient en une phrase : tout ce que vous voulez voir classé par Google et cité par les IA doit se trouver dans le HTML envoyé par le serveur. Gardez la SPA pour l'espace connecté, rendez les pages publiques sur le serveur ou à la compilation, puis testez ce que reçoivent les robots avant et après chaque mise en production.