Les liens en JavaScript onclick sont-ils réellement explorés par Google ?

Pourquoi Google fait-il cette distinction entre href et onclick ?

La déclaration de Mueller pointe un problème d'architecture web fréquent : les développeurs implémentent parfois des liens uniquement via JavaScript, sans structure HTML sous-jacente. Un élément <div onclick="navigate()"> ressemble visuellement à un lien pour l'utilisateur, mais Googlebot ne le reconnaît pas comme tel.

Le moteur s'appuie d'abord sur le HTML brut avant exécution JavaScript. Si l'attribut href est présent dans la balise <a>, Google peut extraire l'URL directement du DOM initial, même si JavaScript modifie ensuite le comportement. Sans href, le bot doit exécuter le JavaScript, analyser les gestionnaires d'événements et deviner où mène le clic — un processus coûteux et incertain.

Quelle est la différence pratique entre ces deux approches ?

Un lien standard <a href="/page"> fonctionne même si JavaScript est désactivé ou échoue. C'est la base de l'amélioration progressive (progressive enhancement) : le HTML fournit la fonctionnalité minimale, JavaScript l'enrichit. Cette approche garantit que Googlebot trouve l'URL dans tous les cas.

À l'inverse, un bouton <button onclick="goTo('/page')"> n'a aucune sémantique de navigation dans le HTML. Le bot doit deviner que goTo déclenche une navigation, puis extraire l'URL de la chaîne passée en paramètre. Ce parsing heuristique n'est pas garanti — surtout si la logique est complexe ou obfusquée.

Google explore-t-il vraiment tout le JavaScript moderne ?

Google exécute effectivement JavaScript avec un moteur Chromium récent, mais des limites budgétaires et techniques persistent. L'exécution JavaScript consomme du crawl budget : les sites avec des milliers de pages ne peuvent pas compter sur une exploration exhaustive de chaque fonction onclick.

De plus, certains patterns (navigation conditionnelle, événements délégués, code asynchrone complexe) restent difficiles à interpréter. Mueller recommande implicitement la simplicité : si l'URL est dans un href, pas d'ambiguïté possible.

• Privilégier systématiquement les balises <a href> pour tous les liens internes et externes
• Utiliser JavaScript pour enrichir le comportement (tracking, animations), pas pour créer la navigation de base
• Auditer le code pour identifier les faux liens (div, span, button avec onclick) et les refactoriser
• Tester avec un navigateur sans JavaScript activé : si le lien ne fonctionne pas, Googlebot aura le même problème
• Surveiller les rapports de couverture Search Console pour détecter les pages orphelines potentiellement causées par des liens non explorables

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

Totalement. Les audits SEO révèlent régulièrement des pages orphelines créées par des liens JavaScript mal implémentés. Les frameworks modernes (React, Vue, Angular) génèrent souvent des Single Page Applications où la navigation repose sur des composants <router-link> ou <Link> qui, mal configurés, n'exposent pas d'attribut href dans le DOM initial.

Google a progressé dans l'exécution JavaScript, mais le rendu différé reste coûteux. Lors de tests avec des sites React non optimisés, on observe parfois des délais de 3 à 7 jours entre le crawl HTML et l'indexation post-rendu JavaScript. Ce décalage peut pénaliser les sites d'actualité ou e-commerce avec des stocks limités.

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

La distinction href/onclick n'est pas binaire. Un lien peut avoir href="#" avec une logique onclick qui change complètement la destination — c'est un anti-pattern que Google peine à gérer. Le bot voit le href mais l'URL pointe vers un fragment vide.

Autre subtilité : les liens ajoutés dynamiquement après interaction utilisateur (scroll infini, boutons "Voir plus") ne sont pas toujours explorés, même avec des href valides. Si le contenu apparaît uniquement après un clic ou un scroll, il faut soit pré-rendre ces liens dans le HTML initial, soit fournir une pagination classique en fallback. [À vérifier] dans quelle mesure Googlebot simule le scroll ou les interactions — les déclarations officielles restent floues sur les déclencheurs d'événements complexes.

Dans quels cas cette règle peut-elle poser problème ?

Les applications web modernes utilisent parfois des liens conditionnels basés sur l'authentification ou la géolocalisation. Un href peut pointer vers /login par défaut, tandis que JavaScript redirige les utilisateurs connectés vers /dashboard. Google verra systématiquement /login, ce qui fausse la compréhension de l'architecture du site.

Pour les sites avec des milliards de pages potentielles (facettes e-commerce, paramètres d'URL infinis), exposer tous les liens en HTML peut créer un crawl budget ingérable. Dans ces cas, une stratégie hybride s'impose : href pour les pages prioritaires, robots.txt ou nofollow pour limiter l'exploration des variantes, et du JavaScript onclick pour les filtres secondaires que Google n'a pas besoin d'indexer.

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

Commencer par un crawl avec JavaScript désactivé (Screaming Frog en mode "Render: Text", ou curl simple). Comparer le nombre de pages découvertes avec un crawl JavaScript activé. Un écart significatif indique des liens non explorables par Google dans le pire des cas.

Ensuite, inspecter le code source HTML des templates principaux : chercher les patterns onclick=, onmousedown= sans href correspondant. Les éléments <div> et <button> avec événements de navigation sont des red flags. Utiliser les DevTools Chrome pour filtrer le DOM : $$('[onclick]:not(a[href])') liste tous les éléments cliquables sans href.

Comment refactoriser du code JavaScript pour le rendre SEO-friendly ?

La règle d'or : toujours partir d'un lien HTML fonctionnel, puis ajouter du JavaScript par-dessus. Un pattern propre ressemble à <a href="/page" class="js-track"> avec un écouteur d'événement attaché via addEventListener qui envoie des analytics mais laisse le navigateur suivre le href par défaut.

Pour les Single Page Applications, configurer le routeur pour qu'il génère des href réels. En React Router, <Link to="/page"> produit un <a href="/page"> — vérifier que cette transformation se produit bien côté serveur (SSR ou pré-rendu). Si le framework ne le fait pas par défaut, implémenter un pré-rendu HTML des routes critiques avec des outils comme Prerender.io ou Rendertron.

Quels outils permettent de vérifier la conformité ?

L'outil Inspection d'URL de Search Console montre le DOM tel que Googlebot le voit après rendu JavaScript. Comparer la version "explorée" avec la version live dans un navigateur. Si des liens manquent dans la version Google, le problème est confirmé.

Le rapport de couverture Search Console signale parfois des pages "Détectée, actuellement non indexée" — un symptôme fréquent de pages orphelines accessibles uniquement via onclick. Croiser ces URLs avec un crawl interne pour identifier les chemins d'accès.

Pour une vérification continue, mettre en place des tests end-to-end (Playwright, Puppeteer) qui vérifient la présence d'attributs href sur tous les éléments de navigation avant chaque déploiement. Un test simple : expect(link.getAttribute('href')).not.toBeNull().

• Crawler le site avec JavaScript désactivé et comparer le nombre de pages découvertes
• Auditer le code source pour identifier les éléments cliquables sans href
• Refactoriser les liens onclick en balises <a href> avec JavaScript en amélioration progressive
• Configurer le routeur SPA pour générer des href réels côté serveur
• Tester chaque template avec l'outil Inspection d'URL de Search Console
• Automatiser la vérification des href dans la CI/CD avant déploiement