Les liens JavaScript doivent-ils vraiment être des éléments <a> avec href pour être crawlés ?

Cette directive est-elle vraiment nouvelle ou juste un rappel ?

Soyons honnêtes : ce n'est pas une révélation. Google recommande l'usage de vrais liens HTML depuis plus d'une décennie. Ce qui change, c'est la fréquence des rappels — signe que trop de sites modernes violent encore cette règle de base. Les SPA et frameworks front-end ont multiplié les mauvaises pratiques, au point que Martin Splitt doit régulièrement marteler l'évidence.

Sur le terrain, on observe que de nombreux sites e-commerce ou médias utilisent des boutons stylisés pour la navigation catégorielle, pensant qu'un onclick suffit. Résultat : des pans entiers du site deviennent orphelins côté crawl, même si le JS fonctionne côté client. Les audits SEO révèlent régulièrement des taux de pages orphelines supérieurs à 30 % sur des sites pourtant "bien développés".

Quelles sont les exceptions ou zones grises à connaître ?

Google ne crawle pas tous les événements onclick, mais il peut indexer du contenu révélé par JavaScript s'il est présent dans le DOM après rendu. Nuance : si un bouton déclenche l'affichage d'une modale avec du texte, ce texte peut être indexé — mais le bouton lui-même ne sera jamais considéré comme un lien de navigation.

Autre zone grise : les liens dynamiques générés en JS. Si votre code crée un <a href="/page"> après le chargement, Googlebot le verra lors du rendu. Mais attention au timing : si le lien apparaît après un délai trop long ou suite à un scroll infini, il peut être manqué. [À vérifier] dans chaque cas avec la Search Console ou un outil de rendu comme Screaming Frog en mode JS.

Dans quels cas cette règle pose-t-elle un vrai dilemme technique ?

Les applications web complexes — tableaux de bord, outils SaaS, plateformes collaboratives — utilisent souvent des composants UI riches où la navigation n'est pas une priorité SEO. Dans ces contextes, imposer des <a href> partout peut complexifier l'architecture. Et c'est là que ça coince : faut-il sacrifier l'ergonomie pour le crawl ?

La réponse dépend de votre stratégie. Si votre contenu doit être indexé et découvrable, les vrais liens sont non négociables. Si vous gérez une app privée derrière authentification, la question ne se pose pas. Le piège, c'est le site hybride — partie vitrine SEO-friendly, partie app JS-first — où la frontière devient floue et les erreurs fréquentes.

Comment auditer les liens JavaScript sur mon site ?

Première étape : crawler votre site avec et sans JavaScript activé. Utilisez Screaming Frog en mode rendu JS et comparez les graphes de liens. Si des pages apparaissent uniquement dans le crawl JS mais sans lien <a href> valide, vous avez un problème. Les outils comme OnCrawl ou Botify proposent aussi des vues comparatives crawl brut vs crawl JS.

Deuxième vérification : inspectez le DOM final dans Chrome DevTools après chargement complet. Cherchez les éléments de navigation et vérifiez qu'ils sont bien des <a> avec href renseigné. Si vous voyez des <div class="link"> ou des <button onclick>, c'est un red flag immédiat.

Quelles modifications apporter aux frameworks React, Vue ou Angular ?

La plupart des frameworks modernes proposent des composants de routage qui génèrent de vrais liens. En React, utilisez <Link to="/page"> de React Router plutôt qu'un <div onClick={navigate}>. Ce composant produit un <a href> dans le DOM final, tout en gérant la navigation client-side.

Pour Vue, <router-link> fait le job. Angular propose routerLink en directive sur un <a>. Dans tous les cas, vérifiez le code HTML généré — certains devs surchargent ces composants avec des styles ou logiques qui cassent le href. Et c'est là que vous perdez le crawl sans vous en rendre compte.

Que faire si mon design impose des boutons pour la navigation ?

Vous pouvez styler un <a> pour qu'il ressemble à un bouton. CSS permet de transformer n'importe quel élément : display: inline-block, padding, border-radius, couleurs — rien n'oblige à garder le rendu par défaut d'un lien. L'important, c'est la sémantique HTML sous-jacente.

Si votre équipe design insiste sur des <button> pour des raisons d'accessibilité (et c'est légitime dans certains contextes d'interaction), alors doublez la navigation : gardez les boutons pour l'UX, mais ajoutez des liens cachés visuellement ou un sitemap HTML exhaustif. Ce n'est pas idéal, mais ça fonctionne.

• Crawler le site en mode JS activé et vérifier que tous les liens de navigation sont des <a href>.
• Inspecter le DOM final dans DevTools pour repérer les pseudo-liens (divs, spans, boutons).
• Utiliser l'outil d'inspection d'URL de la Search Console pour comparer le rendu Googlebot au rendu navigateur.
• Modifier les composants de routage (React Router, Vue Router, Angular Router) pour qu'ils génèrent de vrais liens HTML.
• Tester l'accessibilité : un vrai lien bénéficie automatiquement du focus clavier et des attributs ARIA standards.
• Documenter les règles de développement front-end pour que toute nouvelle navigation respecte la structure <a href>.