Les liens JavaScript sans href sont-ils vraiment invisibles pour Google ?

Pourquoi Google fait-il cette distinction technique entre ancre et bouton ?

La différence tient à la manière dont Googlebot analyse le DOM après l'exécution JavaScript. Quand une balise <a> contient un attribut href, le robot identifie immédiatement une URL de destination, même si JavaScript modifie ou enrichit le comportement du lien. Le crawler peut extraire cette URL et l'ajouter à sa file d'attente de crawl.

En revanche, un bouton sans href — typiquement un <button> ou un <div> avec un événement onclick — ne porte aucune information structurelle sur la destination. Google doit alors exécuter le JavaScript, intercepter l'événement, et deviner où pointe le lien. Cette opération coûte cher en ressources et n'est pas garantie : Googlebot ne simule pas systématiquement les clics sur tous les éléments interactifs d'une page.

Quelle est la différence concrète entre un lien JavaScript valide et un bouton non crawlable ?

Un lien JavaScript valide ressemble à ceci : <a href="/destination" onclick="maFonction()">. L'attribut href fournit une URL de repli que Googlebot peut suivre, même si JavaScript échoue ou est désactivé. Le onclick ajoute du comportement côté client (tracking, animation) sans compromettre la découvrabilité.

À l'inverse, un bouton non crawlable prend cette forme : <button onclick="navigate('/destination')"> ou <div class="link" data-url="/destination">. Ici, l'URL est encapsulée dans du code JavaScript ou un attribut non standard. Googlebot ne peut pas l'extraire sans exécuter le script et simuler l'interaction, ce qu'il ne fait généralement pas.

Quels frameworks et architectures sont particulièrement exposés à ce risque ?

Les Single Page Applications (SPA) construites avec React, Vue ou Angular sont les plus vulnérables. Ces frameworks utilisent souvent des composants de navigation personnalisés qui génèrent des boutons ou des divs cliquables au lieu d'ancres HTML classiques. Les développeurs privilégient cette approche pour maîtriser les transitions, le state management et l'UX, mais oublient les implications SEO critiques.

Les sites e-commerce avec filtres et pagination dynamiques, les interfaces de type dashboard, et les menus mobiles façon "burger" recourent fréquemment à des pseudo-liens. Si ces éléments ne reposent pas sur des balises <a href>, des pans entiers du catalogue produit ou de l'arborescence peuvent disparaître de l'index.

• Utilisez toujours <a href> pour tout lien interne, même si JavaScript enrichit le comportement.
• Les boutons <button> doivent être réservés aux actions (soumission de formulaire, ouverture de modale), jamais à la navigation.
• Testez la découvrabilité avec l'outil d'inspection d'URL de Search Console : si le lien n'apparaît pas dans le DOM rendu, il est invisible.
• Auditez les frameworks front-end pour vérifier que les composants de navigation génèrent du HTML sémantique.
• Privilégiez le rendu server-side (SSR) ou la génération statique (SSG) pour exposer les liens dès le HTML initial.

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

Oui, et c'est une confirmation bienvenue d'un phénomène documenté depuis des années. Les audits techniques révèlent régulièrement des sites où des milliers de pages orphelines ne reçoivent aucun crawl faute de liens <a href> valides. Les logs serveur montrent que Googlebot ne tente même pas d'accéder à ces URLs, alors qu'elles sont techniquement accessibles via JavaScript.

La nuance importante : Google peut suivre certains liens JavaScript injectés dynamiquement, à condition qu'ils respectent la structure <a href>. Mais cette capacité reste fragile et coûteuse en crawl budget. Sur un site de 100 000 pages avec un budget limité, compter sur l'exécution JavaScript pour découvrir des liens est un pari risqué.

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

Martin Splitt parle de liens "injectés sous forme de balises ancre" — cette formulation sous-entend que Google peut traiter des liens générés après le chargement initial, du moment qu'ils respectent la syntaxe HTML standard. Concrètement, un lien créé par React ou Vue qui aboutit à <a href="/page"> dans le DOM final sera crawlable. [A verifier] : la vitesse d'injection compte-t-elle ? Google attend-il un délai maximal avant de considérer le DOM stabilisé ?

Autre point : les boutons avec role="link" et tabindex (pour l'accessibilité) ne compensent pas l'absence d'href. Google ne se fie pas aux attributs ARIA pour découvrir des liens — il cherche une URL explicite et extractible. L'accessibilité web et le SEO partagent des fondamentaux (HTML sémantique), mais leurs critères ne se recoupent pas totalement.

Dans quels cas cette règle pose-t-elle des problèmes spécifiques ?

Les sites utilisant des URL hashes (#) pour la navigation rencontrent un défi additionnel. Historiquement, Google ignorait le contenu après le #, mais les SPAs ont popularisé les hash routers. Depuis, Google peut traiter certaines architectures hash, mais la fiabilité reste inégale. Si un site combine boutons sans href et hash routing, il cumule deux obstacles au crawl.

Les Progressive Web Apps (PWA) avec service workers et navigation côté client sont également exposées. Le service worker peut intercepter les requêtes et servir du contenu en cache, mais si les liens ne sont pas dans le HTML initial ou le DOM post-JavaScript, Googlebot ne les découvrira jamais. Un PWA SEO-friendly doit impérativement exposer ses liens internes via <a href>, idéalement dans le shell HTML.

Que faut-il faire concrètement pour sécuriser la découvrabilité des liens ?

Premier réflexe : auditer le HTML source brut de vos pages stratégiques. Utilisez "Afficher le code source" dans le navigateur (Ctrl+U) et cherchez vos liens internes. S'ils n'apparaissent pas sous forme de <a href="URL">, c'est un signal d'alarme immédiat. Complétez avec l'outil d'inspection d'URL de Search Console : comparez le HTML brut et le DOM rendu pour identifier les liens injectés uniquement par JavaScript.

Ensuite, passez au crible vos composants de navigation : menu principal, pagination, filtres de catégories, liens produits. Si votre framework génère des boutons ou des divs avec onClick, refactorisez-les en balises <a>. Le JavaScript peut toujours intercepter le clic via event.preventDefault() pour gérer la navigation côté client, mais le href doit être présent dès le chargement.

Quelles erreurs éviter lors de la migration vers une architecture JavaScript ?

L'erreur classique : déléguer toute la navigation au router JavaScript (React Router, Vue Router) sans implémenter de rendu server-side (SSR). Le résultat est un shell HTML vide qui charge un bundle JS de plusieurs centaines de Ko. Googlebot doit télécharger et exécuter ce bundle pour découvrir les liens — un processus lent, fragile, et qui consomme inutilement le crawl budget.

Autre piège : utiliser des attributs data personnalisés pour stocker les URLs (data-href, data-url) en pensant que Google les extraira. Non : Googlebot cherche href, point final. Les attributs data sont invisibles pour le crawler, même si votre JavaScript les lit parfaitement. Respectez les standards HTML, c'est la seule garantie de compatibilité.

Comment vérifier que mon site est conforme après refactorisation ?

Lancez un crawl avec Screaming Frog ou Sitebulb en mode "rendu JavaScript" et comparez avec un crawl HTML pur. Les liens découverts doivent être identiques dans les deux cas. Si le crawl JS trouve 30 % de liens supplémentaires, votre site dépend trop de l'exécution JavaScript — un facteur de risque majeur.

Vérifiez aussi les logs serveur : Googlebot accède-t-il régulièrement aux pages profondes (niveau 4-5 de profondeur) ? Si non, c'est souvent un symptôme de liens non découvrables. Croisez avec les données de couverture dans Search Console pour identifier les pages détectées mais non crawlées — souvent victimes de liens JavaScript mal implémentés.

• Remplacer tous les <button> et <div> de navigation par des <a href>
• Implémenter SSR ou SSG pour exposer les liens dans le HTML initial
• Tester la découvrabilité avec Search Console (inspection d'URL, onglet "Plus d'infos" > "Liens détectés")
• Auditer les frameworks JS pour s'assurer qu'ils génèrent du HTML sémantique
• Crawler le site en mode JavaScript ET HTML pur pour comparer la couverture
• Analyser les logs serveur pour détecter les pages orphelines non crawlées