Pourquoi Googlebot rate-t-il systématiquement vos pages si l'URL ne change pas ?

Googlebot navigue-t-il comme un utilisateur humain ?

Non. Voilà la première chose à se mettre dans le crâne. Googlebot utilise les URLs comme seul point d'entrée pour identifier et classer les contenus distincts. Contrairement à un visiteur humain qui peut cliquer, scroller, et interagir avec une interface riche sans jamais quitter la même URL, le bot de Google a besoin d'un signal explicite : une nouvelle URL = une nouvelle page.

Cette logique vient de l'architecture historique du web, où chaque ressource avait son identifiant unique. Mais avec l'essor des Single Page Applications (SPAs) construites en React, Vue ou Angular, beaucoup d'applications chargent du contenu dynamiquement sans toucher à l'URL. Résultat : Googlebot arrive sur la homepage, ne voit aucun lien interne pointant vers d'autres URLs, et repart en indexant strictement rien d'autre.

Que se passe-t-il concrètement quand l'URL reste figée ?

Prenons un cas classique : un site e-commerce construit en SPA où les fiches produits s'affichent via des appels AJAX, mais l'URL reste en permanence sur https://exemple.com/. L'utilisateur clique sur un produit, voit la fiche complète, peut même ajouter au panier — mais l'URL dans la barre d'adresse ne bouge pas.

Pour Googlebot, ce site n'a qu'une seule page : la homepage. Tous les produits, toutes les catégories, tout le contenu stratégique est invisible. Le bot ne peut pas deviner qu'il existe d'autres vues : il n'a ni lien cliquable, ni URL distincte à explorer. Votre budget crawl est entièrement dépensé sur une page unique, et vos fiches produits ne remonteront jamais dans les SERPs.

Quelle est la différence entre URL et vue applicative ?

Une vue applicative est une interface utilisateur rendue côté client par JavaScript. Dans une SPA moderne, vous pouvez avoir des dizaines de vues différentes (profil utilisateur, dashboard, liste de résultats, détail produit) toutes servies depuis la même URL racine. C'est pratique pour l'expérience utilisateur, mais catastrophique pour le SEO si aucune URL distincte n'est associée.

Google a besoin d'URLs pour créer son index. Chaque URL est traitée comme une entité à part entière : elle reçoit son propre PageRank, ses propres signaux de pertinence, son propre positionnement dans les résultats. Sans URL unique, pas de différenciation possible. Votre application peut contenir 10 000 produits — si tout est derrière la même URL, Google n'en indexera aucun.

• Googlebot identifie les pages uniquement par leur URL — pas par le contenu affiché côté client.
• Les applications JavaScript qui ne modifient pas l'URL lors de la navigation ne sont crawlées que sur leur point d'entrée.
• Même si le contenu est visible pour l'utilisateur, il reste invisible pour le bot sans URL distincte.
• La gestion de l'historique (pushState, replaceState) est essentielle pour exposer les vues à Googlebot.
• Un sitemap XML ne compense pas l'absence d'URLs internes : le bot doit pouvoir découvrir les pages via des liens.

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Absolument. On observe depuis des années que les SPAs mal configurées souffrent d'indexation catastrophique. Les audits SEO révèlent régulièrement des sites où seule la homepage est indexée, alors que des centaines de pages théoriquement accessibles restent hors radar. Cette déclaration de Splitt ne fait que confirmer ce qu'on sait empiriquement : pas d'URL distincte = pas d'indexation.

Là où ça devient intéressant, c'est quand on croise cette affirmation avec les tests de rendu JavaScript de Google. Le bot peut exécuter du JS et afficher du contenu dynamique — mais uniquement s'il a une raison de crawler l'URL en question. Si l'URL ne change jamais, le bot n'a aucune incitation à revisiter la page pour voir si le contenu a évolué. Il la considère comme statique.

Quelles nuances faut-il apporter à cette règle ?

Google ne dit pas que toutes les vues applicatives doivent être indexées. Certaines interfaces (dashboard privé, tunnel de paiement, page de paramètres) n'ont aucun intérêt à apparaître dans l'index. Ce que Splitt pointe, c'est le cas où du contenu public stratégique est masqué derrière une seule URL.

Autre point : la déclaration ne précise pas comment Google traite les fragments d'URL (hash #). Historiquement, Google ignore les fragments — mais avec des frameworks comme Angular qui utilisaient le routing par hash, des mécanismes de contournement ont été introduits (le fameux _escaped_fragment_, maintenant obsolète). Aujourd'hui, la recommandation est claire : utiliser l'API History (pushState) pour manipuler l'URL propre, sans hash.

Dans quels cas cette règle pose-t-elle problème ?

Les sites qui ont construit leur architecture frontend avant de penser SEO se retrouvent coincés. Réécrire un système de routing complet pour ajouter des URLs distinctes peut représenter des mois de développement. Beaucoup tentent des solutions hybrides : pré-rendre les pages critiques côté serveur (SSR ou SSG) pour que Googlebot reçoive du HTML statique avec URLs propres, tout en conservant la SPA pour l'expérience utilisateur.

Le vrai piège, c'est quand les équipes techniques ne comprennent pas l'enjeu. Elles voient une application qui « fonctionne » parfaitement pour les utilisateurs, et ne réalisent pas que Googlebot vit une expérience radicalement différente. [A vérifier] : Google affirme exécuter JavaScript « comme un navigateur moderne », mais la réalité est plus nuancée — le bot ne scrolle pas automatiquement, n'attend pas indéfiniment les appels API, et ne déclenche pas tous les événements utilisateur. Si votre contenu n'apparaît qu'après interaction, même avec une URL distincte, il peut rester invisible.

Que faut-il faire concrètement pour exposer vos pages à Googlebot ?

La première étape : auditer votre routing actuel. Utilisez la Search Console et vérifiez combien d'URLs sont effectivement indexées versus le nombre de pages que vous pensez avoir. Un écart massif signale un problème. Ensuite, inspectez manuellement quelques URLs dans l'outil de test d'URL de Google — regardez le HTML rendu, pas seulement le HTML source. Si vos liens internes n'apparaissent pas dans le HTML rendu, Googlebot ne les verra jamais.

Pour les SPAs, vous devez implémenter l'API History (méthodes pushState et replaceState) pour modifier l'URL à chaque changement de vue. Chaque état applicatif doit correspondre à une URL unique et accessible directement (deep linking). Testez en collant l'URL dans un nouvel onglet : si la page ne se charge pas correctement, Googlebot aura le même problème.

Quelles erreurs éviter lors de la migration vers un routing SEO-friendly ?

Erreur classique : utiliser des hash fragments (#) pour le routing. Google ne les interprète pas comme des URLs distinctes. Autre piège : mettre en place des URLs propres, mais oublier de générer un sitemap XML à jour avec toutes ces nouvelles URLs. Le sitemap aide Google à découvrir vos pages plus rapidement, surtout si votre maillage interne est faible.

Ne négligez pas non plus les liens internes en HTML pur. Même si vos URLs changent correctement, Googlebot doit pouvoir les découvrir via des balises <a href> présentes dans le HTML initial. Les liens générés uniquement par JavaScript après un événement utilisateur restent invisibles lors du premier crawl. Assurez-vous que votre navigation principale et vos liens critiques sont dans le DOM dès le chargement.

Comment vérifier que votre site est conforme aux attentes de Googlebot ?

Utilisez l'outil Inspection d'URL dans la Search Console pour chaque type de page stratégique (homepage, fiche produit, catégorie, article). Regardez le screenshot rendu par Googlebot : si le contenu affiché ne correspond pas à ce que vous voyez dans un navigateur, c'est un red flag. Vérifiez aussi les logs serveur pour tracer les requêtes de Googlebot — si le bot ne visite qu'une poignée d'URLs alors que vous en avez des centaines, votre architecture bloque la découverte.

Enfin, testez la vitesse de rendu. Google a un budget crawl limité et un timeout pour l'exécution JavaScript. Si votre application met 10 secondes à afficher le contenu, Googlebot risque d'abandonner avant que les liens ne soient rendus. Optimisez le chargement initial : code splitting, lazy loading, server-side rendering — tout compte.

• Auditer le nombre d'URLs indexées versus le nombre de pages réelles du site
• Implémenter l'API History (pushState/replaceState) pour créer des URLs distinctes par vue
• Générer un sitemap XML exhaustif incluant toutes les URLs publiques
• Vérifier que les liens internes sont présents dans le HTML initial, pas uniquement après JS
• Tester chaque type de page avec l'outil Inspection d'URL de Google Search Console
• Analyser les logs serveur pour détecter les patterns de crawl de Googlebot