Les SPA avec hash URLs sont-elles condamnées par Google ?

Qu'est-ce que le stateless signifie concrètement pour Googlebot ?

Quand Splitt parle de stateless, il évoque une contrainte technique simple : Googlebot ne mémorise rien entre deux requêtes. Contrairement à un utilisateur qui navigue dans votre app, clique, scrolle, change de page, le bot arrive directement sur l'URL qu'il veut indexer. Il ne passe pas par votre homepage, ne déclenche pas votre router JavaScript, ne charge pas votre état global.

Si votre SPA repose sur une logique type « tout passe par index.html puis JS charge la route », Google voit le même shell vide sur toutes vos URLs. Résultat : contenu dupliqué ou absence totale de contenu indexable. Le bot n'exécute pas forcément le JS au moment du crawl initial, et même s'il le fait, il ne reconstruit pas l'historique de navigation.

Pourquoi les hash URLs (#) sont-elles un problème ?

Les fragments (tout ce qui suit le #) ne sont jamais envoyés au serveur. Quand Googlebot fetch https://example.com/#/produit/123, le serveur reçoit uniquement https://example.com/. Impossible de distinguer cette requête d'une autre vers https://example.com/#/produit/456.

Historiquement, Google a tenté de pallier ce problème avec le système hashbang (#!), abandonné depuis 2015. Aujourd'hui, la position est nette : les hash URLs ne permettent pas d'indexer des contenus distincts. Si votre router utilise encore ce pattern, chaque page est vue comme la même par Google, et vous perdez toute granularité d'indexation.

Que doit renvoyer le serveur quand Googlebot accède à une URL ?

Le serveur doit livrer le contenu final de la page demandée, pas un template vide. Si Googlebot accède à /produit/chaise-eames, la réponse HTML doit contenir le titre, la description, le prix, les images de ce produit — avant même que le JS ne s'exécute.

Cela impose soit du Server-Side Rendering (SSR), soit du pre-rendering statique (Static Site Generation). Les frameworks modernes (Next.js, Nuxt, SvelteKit) gèrent cela nativement. Pour les SPA legacy (React pur, Vue CLI sans SSR), il faut ajouter une couche de pre-rendering ou migrer vers une solution hybride.

• Chaque URL doit être directement accessible sans navigation préalable dans l'app
• Eviter les hash URLs (#) : elles ne permettent pas d'indexer des contenus distincts
• Le serveur doit renvoyer le contenu complet de la page, pas un shell vide
• SSR ou pre-rendering sont indispensables pour les SPA qui veulent un SEO robuste
• Googlebot ne conserve aucun état : il ne « navigue » pas dans votre app comme un utilisateur

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est même une des rares où Google ne laisse aucune ambiguïté. Les tests montrent que les SPA mal configurées se retrouvent avec un taux d'indexation catastrophique. J'ai vu des sites React en hash URLs avec 80 % de leurs pages ignorées par Google, simplement parce que chaque URL renvoyait le même shell HTML.

La notion de stateless n'est pas nouvelle — elle est au cœur du protocole HTTP. Ce que Splitt rappelle, c'est que Googlebot respecte ce protocole à la lettre. Pas de cookies persistants entre deux crawls, pas de localStorage, pas de session. Chaque requête est isolée. Si votre app JavaScript reconstruit l'état côté client, Google ne le verra pas lors du premier passage.

Quelles nuances faut-il apporter à cette directive ?

Splitt ne dit pas « bannissez tout JavaScript ». Il dit : assurez-vous que le contenu existe dans le HTML initial. Une SPA bien faite avec SSR ou pre-rendering peut parfaitement fonctionner. Vue, React, Angular — tous peuvent être SEO-friendly si le serveur renvoie du HTML complet.

En revanche, attention aux solutions de pre-rendering type Prerender.io ou Rendertron si elles ne sont pas bien configurées. Google détecte le cloaking quand le contenu servi au bot diffère radicalement de celui servi aux utilisateurs. Le pre-rendering doit produire exactement ce que voit un humain, juste plus rapidement. [A vérifier] : certains sites signalent des pénalités après avoir mal implémenté du dynamic rendering — Google ne communique pas de seuil précis de « différence acceptable ».

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si votre SPA est une application privée (dashboard admin, CRM interne, espace client post-login), le SEO n'a aucun intérêt. Pas besoin de SSR, ni même d'URLs propres. Google ne crawlera jamais ces pages, elles sont derrière authentification.

Pour les Progressive Web Apps (PWA) où l'expérience offline prime, la logique change aussi. Vous pouvez utiliser un service worker qui sert du contenu en cache, mais là encore, l'indexation initiale exige que le serveur renvoie du HTML complet au premier chargement. Une fois l'app installée, le stateless de Googlebot n'a plus d'impact — l'utilisateur ne passe plus par la recherche.

Que faut-il faire concrètement pour rendre une SPA indexable ?

D'abord, auditer l'architecture actuelle. Tapez vos URLs principales dans un outil qui simule Googlebot (Screaming Frog en mode texte, ou curl sans JS). Si vous voyez un

Ensuite, choisir entre SSR, pre-rendering ou migration vers un framework hybride. Next.js et Nuxt sont les plus répandus, mais SvelteKit et Astro montent. Si votre stack est figée (gros legacy React), un service de pre-rendering peut suffire — mais vérifiez que le HTML généré contient tout : balises meta, structured data, contenu textuel complet.

Quelles erreurs éviter lors de la migration ?

Ne pas confondre hydratation et SSR. L'hydratation, c'est quand le JS reprend la main sur le HTML déjà rendu. Si votre HTML initial est vide et que le JS « hydrate » un DOM absent, vous n'avez rien gagné. Le SSR doit produire du HTML complet avant l'hydratation.

Autre piège : oublier les redirections. Si vous abandonnez les hash URLs pour des URLs propres, chaque ancienne route doit rediriger vers la nouvelle avec un 301. Sinon, vous perdez tout le jus SEO accumulé. Et attention aux canonical tags : ils doivent pointer vers la version SSR, pas vers l'ancienne hash URL.

Comment vérifier que le serveur renvoie bien le contenu complet ?

Utilisez la Search Console, section « Inspection d'URL ». Google vous montre exactement ce qu'il voit lors du crawl. Si le HTML rendu est vide ou générique, c'est que le SSR ne fonctionne pas. Comparez avec un curl manuel : curl -A "Googlebot" https://votresite.com/page. Le HTML retourné doit être lisible et complet.

Testez aussi les temps de réponse serveur (TTFB). Le SSR peut être lent si mal optimisé — cache Redis, CDN edge rendering, ou pré-génération statique pour les pages peu dynamiques. Un TTFB > 600 ms commence à pénaliser le crawl budget sur les gros sites.

• Abandonner les hash URLs (#) et migrer vers des URLs propres (/page au lieu de #/page)
• Implémenter du SSR ou du pre-rendering pour que chaque URL renvoie son contenu complet
• Tester chaque URL clé avec curl ou Screaming Frog en mode « sans JS »
• Configurer des redirections 301 si vous changez la structure d'URLs
• Vérifier le HTML rendu dans la Search Console (Inspection d'URL)
• Monitorer le TTFB : un SSR lent peut plomber le crawl budget