Pourquoi Google ignore-t-il vos liens JavaScript mal formatés ?

Qu'est-ce que Google voit vraiment dans un lien JavaScript ?

Googlebot traite les liens injectés dynamiquement, mais à une condition stricte : ils doivent respecter la sémantique HTML classique. Un lien valide pour Google est une balise <a> contenant un attribut href pointant vers une URL.

Le piège ? Beaucoup de frameworks modernes génèrent des pseudo-liens : des <div>, <span> ou <button> stylisés comme des liens, avec un gestionnaire onClick qui déclenche la navigation. Pour l'utilisateur, ça fonctionne. Pour Googlebot, c'est du vide — il n'exécute pas les handlers d'événements attachés aux éléments non-<a>.

Pourquoi cette distinction technique a-t-elle autant d'impact SEO ?

Parce qu'un lien invisible pour Google signifie une page orpheline. Si votre menu de navigation repose sur des boutons JavaScript, Googlebot ne suivra pas ces chemins. Résultat : des sections entières de votre site peuvent rester hors index.

C'est particulièrement critique pour les sites monopage (SPA) et les applications React, Vue ou Angular qui recréent la navigation de toutes pièces. Un router.push() déclenché par un onClick sur un <div> ne laisse aucune trace explorable. Google ne devine pas l'intention : il suit ce qu'il voit dans le DOM final.

Dans quels contextes cette règle pose-t-elle le plus de problèmes ?

Les architectures JavaScript-heavy sont les premières touchées. Les sites e-commerce avec pagination dynamique, les blogs à infinite scroll, les dashboards SaaS — partout où la navigation repose sur de l'interactivité complexe. Un exemple classique : une modale de filtres produits déclenchée par un bouton. Si les liens vers les pages filtrées sont générés dans cette modale via JavaScript, mais sans balises <a>, Google ne les découvrira jamais.

Autre cas fréquent : les menus mobiles. Beaucoup de hamburger menus sont implémentés avec des <button> qui révèlent des <div> contenant les liens. Si ces liens sont eux-mêmes des pseudo-liens, double peine : le menu n'est pas exploré ET les destinations restent invisibles.

• Google suit uniquement les balises <a href="URL">, même si elles sont injectées par JavaScript après le chargement initial.
• Les éléments <button>, <span>, <div> avec onClick ne sont PAS considérés comme des liens, même s'ils déclenchent une navigation côté client.
• Un site peut fonctionner parfaitement pour les utilisateurs mais échouer totalement en crawlabilité si ses liens ne respectent pas cette sémantique.
• Les frameworks JavaScript modernes nécessitent une configuration explicite pour générer des <a> exploitables (ex: <Link> en React Router avec href ou <router-link> en Vue).
• L'amélioration progressive (progressive enhancement) reste la stratégie la plus sûre : un lien doit fonctionner même si JavaScript est désactivé ou en erreur.

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

Oui, et c'est documenté depuis des années. Les tests avec Search Console et les outils de rendu montrent que Googlebot ignore systématiquement les événements onClick sur les éléments non-<a>. Soyons honnêtes : Google a progressé sur le rendu JavaScript, mais il reste prudent. Il ne prend aucun risque avec des patterns ambigus ou non-standards.

Ce qui est moins clair — et Google reste évasif là-dessus — c'est le délai de traitement. Un lien JavaScript valide est-il suivi aussi vite qu'un lien HTML statique ? [À vérifier]. Les observations suggèrent un léger retard, mais aucune donnée officielle ne quantifie ce différentiel. En production, on constate que des liens injectés après plusieurs secondes de rendering peuvent passer à la trappe si le crawl budget est serré.

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

La déclaration de Splitt est binaire, mais la réalité est plus floue. Google peut théoriquement découvrir des URLs via d'autres canaux : sitemaps XML, liens externes, historique d'exploration. Un bouton onClick qui mène vers /produit-X ne transmettra pas le lien, mais si /produit-X est déclaré dans le sitemap, Google le crawlera quand même.

Le problème, c'est le PageRank interne. Même si la page est indexée, l'absence de liens <a> signifie zéro transmission de jus SEO. Un produit stratégique caché derrière un bouton JavaScript ne recevra aucun poids depuis la page d'accueil. C'est l'angle mort de beaucoup de sites SPA : les pages existent, mais elles sont SEO-orphelines, sans autorité transmise.

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

Il y a une exception notable : les liens découverts via le rendu côté serveur (SSR). Si votre framework (Next.js, Nuxt, Angular Universal) génère du HTML statique avec des <a> dès la première réponse serveur, Google les voit immédiatement, sans attendre l'exécution JavaScript. Le JavaScript peut ensuite upgrader ces liens en navigation client-side, mais le fallback HTML reste exploitable.

Autre cas limite : les Single Page Apps avec prerendering. Des outils comme Prerender.io ou Rendertron servent à Googlebot une version pré-rendue avec tous les liens <a> présents. Techniquement conforme, mais attention : Google peut détecter un cloaking si le contenu servi au bot diffère trop de celui vu par l'utilisateur. La frontière est mince.

Que faut-il auditer en priorité sur un site JavaScript ?

Commence par crawler ton site avec un outil qui simule Googlebot : Screaming Frog en mode JavaScript, Sitebulb, ou directement l'outil d'inspection d'URL de Search Console. Compare le nombre de liens découverts avec JavaScript activé versus désactivé. Un écart important signale un problème.

Ensuite, inspecte le DOM final dans Chrome DevTools. Clique sur un élément de navigation suspect et vérifie s'il s'agit d'un <a> ou d'un <button> / <div>. Si tu vois onclick="navigateTo('/page')" sans attribut href, c'est un lien fantôme pour Google. Remplace-le par une vraie balise <a>, même si tu gardes un handler JavaScript pour le routing côté client.

Comment refactoriser un composant de navigation problématique ?

La solution technique dépend de ton framework. En React Router, utilise le composant <Link to="/page"> qui génère un <a href="/page"> tout en gérant le routing client. En Vue, c'est <router-link :to="/page">. Pour Angular, <a [routerLink]="'/page'">. Ces composants garantissent la sémantique HTML tout en préservant l'expérience SPA.

Si tu ne peux pas toucher au JavaScript (contraintes legacy, CMS fermé), une alternative est d'ajouter des liens statiques en HTML pur dans le footer ou un menu secondaire. Moins élégant, mais ça assure la crawlabilité. Pense aussi au plan de site HTML classique, avec des <a> vers toutes les pages stratégiques. Google adore ce format old-school.

Quelles erreurs éviter absolument ?

Ne confonds pas amélioration progressive et dégradation gracieuse. L'amélioration progressive signifie que le site fonctionne SANS JavaScript et que JS ajoute du confort. La dégradation gracieuse suppose que JS marche et prévoit un fallback minimal si ça casse. Pour le SEO, seule l'amélioration progressive garantit la crawlabilité.

Autre erreur fréquente : croire qu'un <a> sans href mais avec onClick suffit. Non. Sans href, ce n'est pas un lien valide HTML — même si ça ressemble à un lien. Google ignore purement et simplement ces éléments. Le href est obligatoire pour qu'un <a> soit considéré comme exploitable.

• Auditer tous les composants de navigation (menus, paginateurs, filtres, calls-to-action) et vérifier qu'ils génèrent des <a href="...">.
• Tester le site avec JavaScript désactivé ou via l'outil d'inspection Search Console pour identifier les liens invisibles.
• Privilégier le rendu côté serveur (SSR) ou la génération statique (SSG) pour les pages stratégiques.
• Implémenter un sitemap XML complet, mais ne pas s'y fier exclusivement — le maillage interne prime.
• Ajouter un plan de site HTML avec des liens <a> vers toutes les sections importantes du site.
• Former les équipes dev sur la sémantique HTML et l'importance des balises <a> pour le SEO.