SPA (Single Page Application)

Une SPA (Single Page Application, ou application monopage) est une application web qui charge un seul document HTML puis met à jour son contenu par JavaScript, sans jamais recharger de page : la navigation entre les écrans est prise en charge côté client. Le contenu n'existant pas dans la réponse initiale du serveur, son indexation dépend du rendu JavaScript des moteurs ou d'un rendu côté serveur ajouté à l'application. Le sujet est traité dans son ensemble dans la définition du SEO JavaScript.

Définition détaillée de la SPA

Le glossaire de MDN définit la SPA comme une implémentation d'application web « qui ne charge qu'un seul document et met à jour le corps de ce document par des API JavaScript, comme Fetch, quand un contenu différent doit être affiché ». Le navigateur télécharge une page d'amorçage, le plus souvent presque vide, puis un ensemble de scripts qui prennent le relais : ils demandent les données à une API, construisent l'interface dans le DOM, et interceptent les clics sur les liens pour changer de vue sans passer par le serveur. React, Angular et Vue sont les trois frameworks cités par MDN pour ce modèle, auxquels s'ajoutent Svelte et les outils construits sur ces bases.

Le terme ne doit pas être confondu avec le site one page, qui désigne un site vitrine dont tout le contenu tient sur une seule page que l'on fait défiler. Le site one page est un choix éditorial et graphique ; la SPA est une architecture logicielle, qui peut au contraire exposer des milliers d'URL distinctes. Un site one page n'est généralement pas une SPA, et une SPA n'a rien d'un site one page.

MDN résume l'équilibre du modèle : des gains de fluidité, puisque les pages ne sont pas rechargées, contre un référencement plus difficile, une gestion de l'état et de la navigation plus complexe, et une mesure de performance moins directe. Une SPA est le cas type du rendu côté client (CSR), dont les conséquences pour les moteurs sont décrites dans la définition du SEO JavaScript.

Comment fonctionne le routage côté client

Dans un site classique, chaque URL correspond à une requête au serveur, qui répond par un document. Dans une SPA, l'URL change mais le document reste le même : c'est le routeur de l'application qui, en fonction de l'URL, décide quel composant afficher. Deux mécanismes ont permis cela.

Le fragment d'URL, méthode historique

Les premières SPA modifiaient la partie de l'URL située après le dièse (https://exemple.fr/#/produits), la seule qu'un navigateur pouvait changer sans recharger la page. Le fragment n'est jamais envoyé au serveur, ce qui convenait à l'application mais pas aux moteurs, pour qui deux URL ne différant que par leur fragment sont une seule et même page. Google avait proposé un « schéma de crawl AJAX » pour lire ces URL, puis l'a abandonné en 2015. Sa documentation demande aujourd'hui de ne plus utiliser de fragments pour charger des contenus différents.

L'API History

L'API History du navigateur permet à un script de modifier l'URL affichée et d'ajouter une entrée à l'historique (history.pushState) ou de remplacer l'entrée courante (history.replaceState), sans provoquer de rechargement. L'événement popstate signale à l'application que l'utilisateur a utilisé les boutons Précédent et Suivant. Avec cette API, une SPA expose de vraies URL (https://exemple.fr/produits) que le serveur doit savoir servir directement : un utilisateur qui recharge la page, partage le lien ou arrive depuis un moteur demande cette URL au serveur, qui doit répondre par le document d'amorçage et non par une erreur. C'est le mécanisme que Google recommande, avec des liens <a href="/produits"> dont le clic est intercepté par le routeur.

Les enjeux d'indexation

Google exécute le JavaScript et rend les pages dans un Chromium à jour, mais dans une étape séparée du crawl, avec une file d'attente dont le délai varie. Sur une SPA en rendu client, tout le contenu indexable dépend de cette étape. Les problèmes propres au modèle sont bien identifiés dans la documentation Search Central.

• La découverte des liens. Google ne suit que les éléments <a> munis d'un attribut href pointant vers une URL résolvable. Un composant de navigation qui déclenche le changement de vue par un gestionnaire d'événement sans href est invisible pour le robot, et avec lui toute la partie du site qu'il dessert. Les liens injectés par JavaScript sont suivis, à condition d'avoir cette forme.
• Les soft 404. Le serveur d'une SPA répond 200 à toutes les routes, puisqu'il sert le même document ; c'est l'application qui constate, après un appel à l'API, que le produit ou l'article n'existe pas. Google recommande deux parades : rediriger en JavaScript vers une URL pour laquelle le serveur répond 404 (par exemple /not-found), ou injecter une balise <meta name="robots" content="noindex"> quand la donnée est absente.
• Les codes HTTP et les redirections. Une page déplacée doit répondre par une redirection 301 côté serveur ; une redirection gérée par le routeur n'est vue qu'au rendu et ne transmet rien de comparable.
• Les métadonnées. Titre, meta description et balise canonical peuvent être posés par JavaScript et sont lus au rendu. Google précise toutefois qu'un script ne doit jamais remplacer la canonical par une valeur différente de celle du HTML initial, et que la balise noindex présente dans la réponse serveur empêche le rendu : un script qui la retirerait ne s'exécute pas.
• L'état. Le service de rendu de Google charge chaque URL sans mémoire : Local Storage, Session Storage et cookies sont effacés entre deux chargements. Un contenu conditionné à un choix mémorisé (langue, consentement, connexion) n'est pas rendu.
• Le contenu asynchrone. La documentation de Vue le formule ainsi : Google et Bing indexent correctement les applications JavaScript « synchrones », mais si l'application « démarre par un indicateur de chargement puis va chercher le contenu en Ajax », le robot n'attend pas nécessairement la fin de cette récupération. Les contenus dont le référencement compte ne devraient pas dépendre d'une chaîne d'appels réseau côté client.

À ces limites propres à Google s'ajoute celle des autres robots : la documentation Search Central rappelle que « tous les robots ne peuvent pas exécuter JavaScript ». Les crawlers de la plupart des assistants IA lisent le HTML servi par le serveur et rien d'autre ; une SPA en rendu client leur présente une page vide.

Les solutions : SSR, rendu statique, prérendu

Les frameworks ont tous intégré une réponse au problème, le plus souvent en permettant de choisir le mode de rendu route par route.

Le rendu côté serveur (SSR)

Les mêmes composants sont exécutés sur le serveur pour produire le HTML complet de la page, envoyé au navigateur, puis « hydratés » côté client pour devenir interactifs. Vue en donne trois bénéfices : un contenu affiché plus tôt, un modèle mental unique pour tout le code, et « un meilleur référencement, les robots des moteurs voyant directement la page entièrement rendue ». Les contreparties sont un environnement d'exécution Node.js à héberger, une charge serveur à chaque requête et des contraintes de développement (le code spécifique au navigateur ne peut s'exécuter que dans certaines étapes du cycle de vie). Angular, qui livre ses applications en rendu client par défaut, propose un « rendu hybride » où chaque route est déclarée client, prérendue ou serveur ; Next.js et Nuxt jouent le même rôle pour React et Vue.

Le rendu statique (SSG) et le prérendu

Quand le contenu ne dépend pas de l'utilisateur, les pages peuvent être générées à la construction du site, sous forme de fichiers HTML servis par un CDN. Le serveur n'exécute plus rien, le HTML est complet dès la réponse. Le prérendu, proche dans ses effets pour un robot, capture l'état initial de l'application client au moment de la construction ; la page s'affiche mais reste inerte tant que les scripts n'ont pas démarré. Les deux approches sont détaillées dans la définition du headless CMS et de la Jamstack.

Le rendu dynamique, à ne plus retenir

Servir aux robots une version prérendue par un service intermédiaire et aux utilisateurs l'application JavaScript a longtemps été la solution des SPA existantes. Google, qui ne considère pas cette pratique comme du cloaking si le contenu est identique, la qualifie désormais de « solution de contournement et non de solution à long terme » et recommande à la place le rendu côté serveur, le rendu statique ou l'hydratation. Elle reste rencontrée sur des applications anciennes, avec son coût : une infrastructure de rendu à maintenir et deux versions d'une même page à contrôler.

Vérifier une SPA

La méthode est celle de toute page JavaScript : comparer le HTML brut renvoyé par le serveur, le HTML rendu par Google et la page vue dans le navigateur. L'outil d'inspection d'URL de la Search Console, en test en direct, montre le HTML rendu, la capture d'écran, les ressources bloquées et les erreurs de console ; le test des résultats enrichis offre le même aperçu sans propriété vérifiée. Trois contrôles sont propres à la SPA : demander directement au serveur une URL profonde (rechargement de page) pour vérifier qu'elle répond 200 avec le bon contenu et non par une redirection vers l'accueil ; demander une URL inexistante pour vérifier le traitement des soft 404 ; et parcourir le site avec JavaScript désactivé pour mesurer ce qui reste lisible, ce qui est aussi ce que voient les robots sans rendu.

FAQ

Une SPA peut-elle être bien référencée ?

Oui, à condition que le contenu à indexer soit disponible dans le HTML servi par le serveur, par rendu côté serveur ou statique, et que les liens soient de vraies ancres avec href. Une SPA en pur rendu client est indexée par Google, mais avec un délai de rendu, des risques d'erreur (soft 404, état non conservé) et une invisibilité auprès des robots qui n'exécutent pas JavaScript.

Quelle est la différence entre une SPA et un site one page ?

Le site one page est un site vitrine dont tout le contenu tient sur une seule page que l'on fait défiler. La SPA est une architecture technique : un seul document HTML chargé, puis des vues construites par JavaScript, avec autant d'URL que d'écrans. L'un est un format éditorial, l'autre une façon de programmer.

Pourquoi Google déconseille-t-il les URL avec un dièse ?

Le fragment d'URL (ce qui suit le #) n'est pas envoyé au serveur et n'identifie pas une page distincte pour un moteur. Le schéma de crawl AJAX qui permettait de lire ces URL a été abandonné en 2015. Google recommande l'API History, qui donne à chaque vue une URL classique que le serveur sait servir.

Comment éviter les soft 404 sur une SPA ?

Quand l'application constate qu'une ressource n'existe pas, elle doit soit rediriger vers une URL pour laquelle le serveur répond réellement 404, soit ajouter une balise meta robots noindex. Sans cela, la page d'erreur répond 200 et peut être indexée.

Faut-il du SSR sur toutes les pages ?

Non. Les frameworks permettent de choisir par route : rendu serveur ou statique pour les pages destinées aux moteurs (contenus, catalogue, catégories), rendu client pour les écrans applicatifs (compte, panier, tableau de bord) qui n'ont pas vocation à être indexés.

En résumé

• SPA : une application web qui charge un seul document HTML et met à jour son contenu par JavaScript, sans rechargement de page.
• Routage : assuré côté client par l'API History (pushState, replaceState), qui a remplacé les URL en fragment, abandonnées par Google en 2015.
• Enjeux SEO : liens sans href non suivis, soft 404 sur les routes inexistantes, métadonnées posées par script, état non conservé par le rendu de Google, robots sans rendu JavaScript.
• Solutions : rendu côté serveur avec hydratation, rendu statique ou prérendu, choisis route par route ; le rendu dynamique n'est plus qu'une solution de contournement.
• À ne pas confondre : avec le site one page, format éditorial d'une seule page à faire défiler.

Abondance c'est aussi des audits SEO, un service de contenus et des formations en e-learning !