Pourquoi Google insiste-t-il autant sur les vraies balises <a href> ?

Qu'est-ce qui différencie un vrai lien d'un lien simulé ?

Un vrai lien HTML utilise la balise <a href="URL"> avec une URL directement accessible dans l'attribut href. Le navigateur et Googlebot peuvent immédiatement identifier la destination sans exécuter de code.

Un lien simulé, c'est un <button>, un <span> ou même un <div> qui déclenche une navigation via JavaScript (onClick, eventListener). L'URL de destination est cachée dans le code JS, pas dans le HTML brut.

Pourquoi Googlebot galère avec les liens JavaScript ?

Googlebot doit d'abord télécharger le HTML, puis exécuter le JavaScript, puis identifier les URLs cachées dans les gestionnaires d'événements. Ce processus consomme du crawl budget et n'est pas garanti à 100%.

Avec un <a href>, l'URL est immédiatement visible dans le DOM initial. Pas besoin de phase de rendering pour découvrir la page. Le lien est crawlable dès la première passe.

Cette règle s'applique-t-elle vraiment à tous les liens ?

Martin Splitt parle des liens de navigation structurelle — menus, pagination, maillage interne. Les liens qui permettent à Googlebot de découvrir vos contenus.

Pour des boutons d'actions ponctuelles (ouverture modale, soumission AJAX), le problème est moindre. Mais dès qu'il s'agit de faire découvrir une URL, la balise <a> reste incontournable.

• Les balises <a href> sont crawlées instantanément sans rendering JavaScript
• Les liens simulés en JS nécessitent une phase de rendering coûteuse et non garantie
• Cette contrainte impacte directement la découvrabilité des pages et le crawl budget
• La règle concerne principalement la navigation structurelle (menus, pagination, maillage)
• Google privilégie toujours les fondamentaux HTML sur les solutions JS complexes

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Complètement. Les audits de crawl montrent systématiquement que les sites avec navigation JS-heavy ont des taux de découverte plus faibles. Google crawle moins de pages, met plus de temps à indexer les nouveautés.

J'ai vu des sites perdre 30-40% de pages indexées après une migration vers une architecture SPA mal fichue, avec des liens simulés partout. Retour aux <a href> propres = retour à un crawl normal en quelques semaines.

Quelles nuances faut-il apporter ?

Google peut découvrir des liens JS — mais c'est moins fiable et plus lent. Si ton site a 10 000 pages et un crawl budget serré, tu ne peux pas te permettre cette inefficacité.

Autre point : l'accessibilité. Un bouton qui simule un lien casse l'expérience pour les lecteurs d'écran et les navigations clavier. Le SEO et l'UX convergent ici — ce qui devrait toujours être un signal d'alerte quand on envisage des shortcuts techniques.

Dans quels cas cette règle peut-elle être assouplie ?

Pour des interactions purement applicatives — zone membre, tableaux de bord, filtres dynamiques sans changement d'URL — tu peux utiliser des boutons sans problème. Google ne cherche pas à crawler ces éléments.

Mais dès qu'une action change l'URL ou affiche un nouveau contenu indexable, reviens au <a href>. Soyons honnêtes : 90% des cas d'usage navigation tombent dans cette catégorie.

Que faut-il auditer en priorité sur son site ?

Commence par la navigation principale : header, footer, menus déroulants. Ouvre l'inspecteur, vérifie que chaque lien de navigation est bien un <a href="URL"> avec une URL complète ou relative valide.

Ensuite, regarde la pagination — catégories e-commerce, archives blog, listings. Les boutons "Page suivante" doivent être des vrais liens. Pareil pour les filtres qui modifient l'URL (tri, filtres produits).

Comment corriger les liens simulés existants ?

Si tu as des <button onClick="navigateTo('/page')">, remplace-les par <a href="/page">. Tu peux garder ton JS pour des animations ou du tracking, mais l'URL doit être dans le href.

Pour les SPAs, utilise le progressive enhancement : le lien fonctionne en HTML pur, le JS intercepte le clic pour faire une transition douce. Next.js <Link> fait exactement ça.

• Auditer la navigation principale (header, footer, menus) avec l'inspecteur HTML
• Vérifier que tous les liens de pagination utilisent <a href>
• Remplacer les boutons onClick par des liens avec href + interception JS facultative
• Tester le site avec JavaScript désactivé pour identifier les liens cassés
• Contrôler les logs de crawl pour détecter les pages non découvertes
• Utiliser des composants framework qui génèrent du vrai HTML (Next Link, Nuxt NuxtLink)
• Valider l'accessibilité des liens avec un lecteur d'écran