Faut-il vraiment combiner pushState et liens statiques pour le SEO ?

Pourquoi Google insiste sur cette double approche ?

Google pousse depuis des années pour que les développeurs arrêtent de tout miser sur JavaScript. La raison tient à l'architecture même du crawl et de l'indexation : Googlebot fonctionne en deux temps. D'abord, il récupère le HTML brut. Ensuite, il place les pages dans une file d'attente pour le rendu JS, qui peut prendre des heures voire des jours.

Si tes liens n'existent que dans le JavaScript (via des event listeners onClick sans href réel), Googlebot ne les découvre pas lors de la première passe. Tu perds du temps, du budget crawl, et tu risques que certaines pages ne soient jamais découvertes si la file de rendu est saturée.

Qu'est-ce que pushState et pourquoi l'utilise-t-on ?

L'API History.pushState() permet de modifier l'URL visible dans le navigateur sans recharger la page entière. C'est la base des Single Page Applications (SPA) et des sites qui veulent offrir une navigation fluide et rapide.

Le problème ? pushState ne crée aucun signal HTML visible dans le source. Si tu changes l'URL de /page-a à /page-b avec pushState, mais que tu n'as aucun lien statique pointant vers /page-b, Googlebot ne trouvera jamais cette page sauf s'il exécute ton JS — et même là, rien ne garantit qu'il cliquera sur ton bouton virtuel.

En quoi les liens statiques changent-ils la donne ?

Un lien statique, c'est un bon vieux <a href="/page-b"> dans le HTML. Pas de dépendance JS, pas de condition, juste un lien crawlable immédiatement.

Quand tu combines pushState et liens statiques, tu gardes l'expérience utilisateur moderne (navigation rapide sans rechargement) tout en offrant à Googlebot un chemin de secours direct. Si le JS plante, si le rendu est différé, si un bot ancien passe, le lien reste découvrable.

• pushState gère l'expérience utilisateur fluide et la cohérence d'URL côté client
• Liens statiques garantissent la découvrabilité pour les crawlers et l'accessibilité sans JS
• Cette double approche couvre tous les scénarios : JS actif, JS désactivé, rendu différé, bots tiers
• Le budget crawl est mieux utilisé car Googlebot découvre tout dès la première passe HTML
• Les pages deviennent indexables plus rapidement, sans attendre la file de rendu JavaScript

Cette recommandation est-elle vraiment suivie sur le terrain ?

Soyons honnêtes : la majorité des frameworks JS modernes (React Router, Vue Router, Next.js en mode SPA) génèrent des liens statiques par défaut. Si tu utilises un composant <Link> ou <router-link>, il produit généralement un href HTML valide, même s'il intercepte le clic en JS pour faire du pushState.

Là où ça coince, c'est sur les sites custom ou les vieux projets où les développeurs ont codé la navigation à la main avec des div cliquables, des boutons sans href, ou des data-attributes parsés en JS. Ces implémentations passent complètement sous le radar de Googlebot en première passe.

Quand cette règle ne suffit-elle pas ?

Avoir des liens statiques, c'est bien. Mais si ton contenu lui-même n'est chargé qu'en JS après le clic, tu n'as résolu qu'une partie du problème. Google va découvrir l'URL, oui, mais il devra quand même exécuter le JavaScript pour voir le contenu réel.

Dans ce cas, tu restes dépendant de la file de rendu. La vraie robustesse, c'est d'avoir le contenu critique dans le HTML initial (SSR ou SSG), et d'enrichir progressivement avec JS. [A vérifier] sur des très gros sites : même avec des liens statiques parfaits, si tu as 500 000 pages et que tout le contenu nécessite du rendu JS, tu vas saturer ton budget crawl et ralentir l'indexation.

Google a-t-il vraiment besoin de cette béquille en 2025 ?

Googlebot exécute du JavaScript depuis des années, et son moteur de rendu s'est amélioré. Alors pourquoi continuer à insister sur les liens statiques ? Parce que le rendu JS coûte cher à Google en ressources serveur.

Chaque page qui nécessite du rendu consomme du CPU, de la mémoire, et introduit de la latence. Google préférera toujours un site qui lui mâche le travail avec du HTML pur. De plus, tous les bots ne sont pas Googlebot : Bing, Yandex, les scrapers de réseaux sociaux, les outils d'accessibilité… beaucoup n'exécutent pas ou mal le JS. Les liens statiques, c'est une assurance universelle.

Comment vérifier que ton site respecte cette règle ?

Première étape : inspecte le HTML source brut. Fais un clic droit > Afficher le code source de la page (pas l'inspecteur, qui montre le DOM après JS). Cherche tes liens de navigation. S'ils apparaissent avec un href valide pointant vers les bonnes URLs, c'est bon signe.

Deuxième étape : désactive JavaScript complètement dans ton navigateur (Chrome DevTools > Settings > Preferences > Debugger > Disable JavaScript). Navigue sur ton site. Si les liens fonctionnent et mènent aux bonnes pages (même si le design est cassé ou le contenu incomplet), c'est que la structure de liens est solide.

Quelles erreurs critiques faut-il éviter ?

Ne confie jamais la navigation uniquement à des event listeners onClick sans href. Un bouton ou une div avec onclick="navigateTo('/page')" sans <a href> associé, c'est invisible pour Googlebot en première passe.

Autre piège classique : les liens avec href="#" ou href="javascript:void(0)". Techniquement, c'est un lien, mais il ne pointe nulle part. Googlebot ne suivra jamais ça. Si tu utilises pushState, le href doit contenir l'URL réelle de destination, même si tu interceptes le clic en JS pour charger le contenu dynamiquement.

Quelle architecture adopter pour combiner les deux ?

L'idéal reste le rendu côté serveur (SSR) ou la génération statique (SSG). Next.js, Nuxt, SvelteKit et consorts font ça nativement : ils génèrent du HTML complet avec tous les liens, puis hydratent en JS pour activer pushState et navigation client-side.

Si tu es bloqué en SPA pur, configure au minimum un système de prerendering pour les pages clés, ou utilise du dynamic rendering (servir du HTML statique aux bots, JS aux utilisateurs). Et assure-toi que chaque route accessible via pushState a un lien <a href> quelque part dans ton HTML initial ou dans un menu.

• Vérifie que tous tes liens de navigation utilisent des balises <a href> avec URLs complètes
• Teste la navigation avec JavaScript désactivé : les liens doivent mener aux bonnes pages
• Inspecte le HTML source brut (pas le DOM après JS) pour confirmer la présence des href
• Évite href="#" ou href="javascript:void(0)" : ils cassent la découvrabilité
• Si tu utilises un framework JS, vérifie que les composants Link génèrent bien des href HTML
• Pour les SPAs, mets en place du SSR, SSG ou au minimum du prerendering pour les pages stratégiques