Googlebot suit-il vraiment tous les liens JavaScript de votre site ?

Pourquoi cette distinction entre balises d'ancrage et éléments onclick ?

Googlebot analyse le DOM après exécution du JavaScript — ça, c'est acquis depuis des années. Mais l'interprétation des signaux de navigation reste strictement liée à la sémantique HTML. Une balise <a href="..."> est un signal de lien universel, reconnu nativement par tous les robots et navigateurs.

Un <span onclick="navigateTo('/page')">, même s'il déclenche une navigation pour l'utilisateur, n'existe pas en tant que lien dans le DOM. Googlebot ne simule pas les clics utilisateur — il extrait les URLs des éléments structurellement identifiés comme des liens. Pas de balise d'ancrage, pas de crawl.

Les frameworks JavaScript modernes sont-ils concernés ?

La plupart des frameworks modernes (React, Vue, Angular, Svelte) génèrent des balises <a> correctes quand vous utilisez leurs composants de navigation standards (<Link>, <router-link>, etc.). Le problème survient quand les développeurs créent des composants custom avec des gestionnaires d'événements sur des divs ou des spans.

Cas typique : un menu burger en mobile qui utilise des <div> cliquables au lieu de vrais liens. Pour l'utilisateur, ça marche. Pour Googlebot, ces sections du site n'existent tout simplement pas. Et c'est là que ça coince sur des sites entiers parfois.

Qu'en est-il des attributs href vides ou des liens JavaScript : void(0) ?

Un lien avec href="javascript:void(0)" ou href="#" reste une balise d'ancrage, mais l'URL de destination est inexploitable. Si le routing se fait entièrement en JavaScript sans mettre à jour le href, Googlebot n'a aucune URL à crawler.

La bonne pratique : utiliser des hrefs réels qui pointent vers les URLs canoniques, puis intercepter le clic en JavaScript pour la navigation côté client (progressive enhancement). Ainsi, même si JS échoue ou que le bot ne simule pas l'événement, le lien reste crawlable.

• Googlebot extrait les liens du DOM post-JavaScript, mais uniquement depuis des balises <a> valides
• Les événements onclick sur des éléments non-sémantiques (span, div) ne génèrent aucune découverte d'URL
• Les frameworks modernes produisent généralement du code conforme, sauf implémentations custom hasardeuses
• Un href vide ou en javascript:void(0) rend le lien techniquement présent mais inutilisable pour le crawl
• Progressive enhancement : toujours partir d'un lien HTML fonctionnel, enrichir ensuite avec JavaScript

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

Oui, et c'est même documenté depuis des années. Les tests de crawl sur des sites JavaScript montrent systématiquement que Googlebot ne déclenche pas les gestionnaires d'événements onclick, onmouseover ou autre. Il parse le DOM, extrait les attributs href des balises <a>, et c'est tout.

Là où ça devient intéressant : certains sites e-commerce ont perdu 30-40% de leurs pages indexées après une migration vers un framework JS mal configuré. Diagnostic récurrent ? Des liens produits générés en span cliquables, parfaitement fonctionnels en navigation utilisateur, totalement invisibles pour le bot. L'équipe dev n'avait rien vu venir — tout marchait en staging.

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

Google dit "balises d'ancrage appropriées" — qu'est-ce que ça signifie exactement ? Un lien avec href="#" est-il "approprié" ? [A vérifier] dans des tests, mais en pratique, un href vide ou en ancre interne ne donne aucune URL à crawler. Donc techniquement conforme, mais fonctionnellement inutile.

Autre nuance : certains sites utilisent des data-attributes pour stocker les URLs (<a data-url="/page">) et les injectent dynamiquement dans le href via JS. Si le script s'exécute avant que Googlebot ne parse le DOM, ça peut passer. Mais c'est jouer avec le feu — aucune garantie de timing d'exécution. Autant mettre le href direct dès le départ.

Dans quels cas cette règle ne suffit-elle pas ?

Avoir des balises <a> correctes ne garantit pas le crawl. Il faut aussi que ces liens soient présents dans le HTML initial ou dans le DOM après le premier rendu JS. Si vos liens ne s'affichent qu'après un scroll infini, un lazy-loading agressif ou une interaction utilisateur (clic sur "Voir plus"), Googlebot peut ne jamais les voir.

Exemple classique : les filtres de facettes e-commerce qui rechargent les listings en AJAX sans mettre à jour les URLs ni créer de vrais liens. Pages filtrées = pages inexistantes pour Google, même si elles génèrent du trafic organique via la recherche interne du site. C'est un trou noir SEO fréquent.

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

Première étape : vérifier la structure HTML post-rendu. Utilisez l'outil d'inspection d'URL de la Search Console, section "Page rendue", et examinez le code source. Tous vos liens de navigation critiques doivent apparaître comme <a href="URL_REELLE">. Si vous voyez des divs ou spans avec des classes qui suggèrent une navigation, vous avez un problème.

Deuxième vérification : testez le crawl avec un outil comme Screaming Frog en mode JavaScript activé. Comparez le nombre de pages découvertes avec JS activé vs désactivé. Un écart massif indique que votre maillage repose sur du JS, mais si même avec JS activé certaines sections ne sont pas crawlées, c'est un signal que vos liens ne sont pas standards.

Comment corriger les erreurs de navigation JavaScript ?

Cas n°1 : vous utilisez des composants custom qui génèrent des éléments non-sémantiques. Refactorisez en utilisant les composants natifs du framework (<Link> en React, <router-link> en Vue). Ils produisent des balises <a> par défaut et gèrent le routing côté client proprement.

Cas n°2 : votre site legacy utilise des onclick sur des spans pour des raisons historiques. Solution pragmatique : remplacez par des balises <a> avec hrefs réels, puis interceptez le clic en JavaScript pour la navigation SPA. Le lien fonctionne sans JS (progressive enhancement), et Google peut le crawler. C'est du travail, mais c'est le seul moyen de corriger structurellement.

Quelles erreurs éviter lors d'une migration JavaScript ?

Erreur classique n°1 : migrer vers un framework JS sans faire d'audit de crawlabilité préalable. Vous découvrez le problème 3 mois après, quand les positions ont chuté. Testez le rendu et le crawl en staging, systématiquement.

Erreur n°2 : supposer que "si ça marche en navigateur, ça marche pour Google". Googlebot ne simule pas les interactions utilisateur — il parse le DOM. Un menu déroulant qui s'ouvre au survol de la souris ? Les liens à l'intérieur peuvent être invisibles si le CSS les masque par défaut et que JS/hover est requis pour les afficher.

• Inspecter le DOM rendu via Search Console (outil d'inspection d'URL) pour vérifier la présence de balises <a> valides
• Crawler le site avec Screaming Frog en mode JavaScript activé et comparer avec un crawl sans JS
• Auditer les composants de navigation custom : remplacer divs/spans cliquables par des vraies balises d'ancrage
• Vérifier que tous les hrefs contiennent des URLs réelles, pas des #, javascript:void(0) ou des data-attributes
• Tester le lazy-loading et le scroll infini : s'assurer que les liens critiques sont présents dès le premier rendu
• Mettre en place un monitoring continu du nombre de pages crawlées/indexées après toute modification JS majeure