Comment rendre une single-page app crawlable par Google sans perdre son indexation ?

Pourquoi Googlebot a-t-il besoin de l'API History pour indexer une SPA ?

Les single-page applications chargent une seule page HTML initiale, puis modifient dynamiquement le contenu sans recharger la page. Si aucun mécanisme n'expose les différentes vues comme des URLs distinctes, Googlebot ne voit qu'une seule URL — celle du point d'entrée.

L'API History (history.pushState() et history.replaceState()) permet de manipuler l'URL dans la barre d'adresse sans déclencher de rechargement de page. Chaque navigation interne peut donc créer une nouvelle entrée dans l'historique du navigateur, avec une URL unique. C'est cette URL que Googlebot va découvrir, crawler et indexer.

Que signifie « un balisage de liens approprié avec des attributs href » ?

Splitt insiste sur un point souvent négligé : les liens internes doivent être de vrais liens HTML, avec des attributs href pointant vers les URLs des vues. Pas des <div onclick="loadView()"> ou des <a href="#"> qui déclenchent du JavaScript.

Googlebot suit les liens href. Si vos « liens » ne sont que des événements JavaScript attachés à des éléments non-sémantiques, le moteur ne peut pas les découvrir. Même si votre SPA fonctionne parfaitement pour un utilisateur, elle reste invisible pour le crawler si les URLs ne sont pas exposées dans le DOM.

Cette approche garantit-elle une indexation complète ?

Non, pas automatiquement. L'API History et les liens avec href sont des conditions nécessaires, mais pas suffisantes. Googlebot doit encore exécuter le JavaScript, attendre que le contenu soit rendu, et découvrir les liens — ce qui peut échouer si le JS est bloqué, si le temps de rendu dépasse le budget crawl, ou si les liens sont injectés trop tard.

Il faut aussi s'assurer que chaque URL retourne un code 200, que le contenu principal est présent dans le DOM après le rendu JavaScript, et que les balises meta (title, description, canonicals) sont correctement mises à jour pour chaque vue.

• Chaque vue de la SPA doit avoir une URL unique manipulée via l'API History.
• Les liens internes doivent être des <a href="..."> pointant vers ces URLs, pas des événements JavaScript.
• Googlebot suit les liens href et crawle les URLs exposées — mais il faut aussi que le contenu soit rendu correctement après exécution du JS.
• Une SPA sans API History ni liens href reste une page unique pour Google, avec un seul point d'entrée indexable.
• Vérifier que les URLs des vues sont bien découvrables dans le DOM et retournent un contenu distinct après rendu.

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

Oui, largement. Les audits de sites SPA montrent régulièrement que l'absence d'URLs distinctes et de liens href est la cause n°1 de sous-indexation. Les frameworks modernes (React Router, Vue Router, Angular Router) implémentent déjà l'API History par défaut — mais il reste fréquent de voir des développeurs casser cette logique avec des liens mal formés ou des redirections côté client sans mise à jour de l'URL.

Là où ça coince : beaucoup de sites utilisent bien l'API History, mais oublient de rendre les liens crawlables. Un <button onClick={navigate}> fonctionne pour l'utilisateur, mais Googlebot ne clique pas sur des boutons. Il suit des href. Splitt rappelle ici un fondamental souvent négligé dans les stacks JS modernes.

Quelles nuances faut-il apporter ?

Cette déclaration est correcte, mais elle ne dit rien sur le timing de rendu. Une SPA peut exposer des URLs et des liens href parfaits, mais si le contenu met 5 secondes à se charger après l'exécution du JS, Googlebot peut abandonner avant d'avoir capturé le DOM final. [A vérifier] — Google n'a jamais communiqué de seuil officiel pour le timeout de rendu JS.

Autre point : l'API History ne suffit pas si les balises meta ne sont pas mises à jour dynamiquement. Une SPA qui affiche 10 vues différentes avec la même balise <title> et la même meta description va créer des problèmes de contenu dupliqué et de pertinence. Les frameworks comme React Helmet ou Vue Meta existent précisément pour ça.

Dans quels cas cette approche montre-t-elle ses limites ?

Les SPAs avec navigation côté client uniquement (pas de rendu serveur) restent dépendantes de l'exécution JavaScript par Googlebot. Si le JS échoue — ressources bloquées, erreurs réseau, timeouts — le contenu n'est pas indexé, même avec des URLs et des href parfaits. C'est pour ça que le server-side rendering (SSR) ou la génération statique restent des solutions plus fiables.

Autre limite : les sites avec un très grand nombre de vues dynamiques (e-commerce avec des milliers de produits, par exemple) peuvent saturer le budget crawl si chaque vue nécessite une exécution JS complète. Dans ces cas, un mix SSR/CSR ou une architecture hybride (pages critiques en SSR, interactions en CSR) est préférable.

Que faut-il faire concrètement pour respecter cette recommandation ?

Auditer tous les liens internes de votre SPA. Chaque lien doit être un <a href="/chemin"> pointant vers une URL réelle, pas un élément cliquable sans href. Utilisez les DevTools pour inspecter le DOM et vérifier que les liens sont bien présents avant l'interaction utilisateur — pas injectés après un clic.

Ensuite, vérifier que chaque navigation interne met bien à jour l'URL dans la barre d'adresse via history.pushState() ou history.replaceState(). Testez en naviguant dans votre SPA : chaque vue doit avoir une URL unique, et un rafraîchissement de la page doit recharger la même vue (pas rediriger vers l'accueil).

Comment vérifier que Googlebot crawle correctement les vues de votre SPA ?

Utilisez Google Search Console pour vérifier l'indexation des URLs de vos vues. Si des URLs sont découvertes mais non indexées, inspectez-les avec l'outil de test des URLs enrichies : le contenu rendu correspond-il à ce que vous attendez ? Les liens internes sont-ils présents dans le DOM capturé par Google ?

Complétez avec un crawl JavaScript activé via Screaming Frog ou OnCrawl. Comparez le nombre d'URLs découvertes avec et sans exécution JS. Si l'écart est important, c'est que vos liens ne sont pas crawlables sans JS — problème. Vérifiez aussi que les temps de rendu restent raisonnables : un délai supérieur à 3-4 secondes peut causer des abandons de crawl.

Quelles erreurs éviter absolument ?

Ne pas utiliser de liens href="#" ou href="javascript:void(0)" pour déclencher des navigations internes. Googlebot ne les suit pas. Ne pas non plus encapsuler toute la navigation dans des événements onClick sans attribut href — même si ça fonctionne pour l'utilisateur, c'est invisible pour le crawler.

Autre erreur fréquente : oublier de mettre à jour les balises meta (title, description, canonical) pour chaque vue. Une SPA avec 50 vues et un seul titre de page crée un cauchemar de contenu dupliqué. Utilisez une bibliothèque de gestion des meta tags ou implémentez un système de mise à jour dynamique dans votre router.

• Auditer tous les liens internes : chaque lien doit être un <a href="..."> avec une URL valide.
• Vérifier que chaque navigation met à jour l'URL via history.pushState() ou history.replaceState().
• Tester le rafraîchissement de page sur chaque vue : elle doit recharger le même contenu, pas rediriger.
• Utiliser Google Search Console pour vérifier l'indexation des URLs de vos vues.
• Crawler le site avec JS activé et comparer les URLs découvertes avec un crawl sans JS.
• Mettre à jour dynamiquement les balises meta (title, description, canonical) pour chaque vue.