Pourquoi vos liens JavaScript doivent absolument utiliser des balises A avec href valide ?

Pourquoi Google insiste-t-il autant sur les balises A avec href valide ?

La réponse tient en un mot : fiabilité. Googlebot découvre les liens en parsant le HTML brut avant d'exécuter le moindre JavaScript. Si votre lien n'existe pas dans le DOM initial sous forme de <a href="URL">, vous prenez un risque inutile.

Même si Google exécute JavaScript — et il le fait — le processus n'est pas instantané. Le moteur doit attendre le chargement, l'exécution, puis analyser le DOM modifié. Un lien présent dès le HTML initial est découvert immédiatement, sans dépendance au budget JS ou aux erreurs d'exécution.

Qu'est-ce qu'un 'lien JavaScript' problématique concrètement ?

Tout ce qui n'est pas une balise <a> avec un href pointant vers une URL HTTP(S) valide. Les cas typiques : <a href="javascript:doSomething()">, <div onclick="navigate()">, ou encore des <a> sans href du tout, entièrement pilotés par des événements JS.

Ces patterns forcent Googlebot à compter exclusivement sur l'exécution JavaScript. Si le script échoue, si le budget crawl JS est dépassé, ou si le rendu est partiel — votre lien n'existe tout simplement pas pour le moteur.

Google suit-il quand même ces liens mal formés ?

Parfois oui, souvent non. Google peut découvrir certaines URL via l'exécution JS ou d'autres sources (sitemaps, backlinks). Mais vous perdez le contrôle : pas de garantie de découverte, pas de transmission de PageRank prévisible, pas de signal d'ancre texte clair.

Soyons honnêtes : pourquoi parier sur le comportement aléatoire du moteur quand la solution — utiliser un href — prend 30 secondes à implémenter ?

• Balise <a> obligatoire — pas de div, span ou autre élément détourné
• Attribut href avec URL valide — HTTP(S), pas javascript: ou #
• Découverte garantie dès le HTML — indépendamment de l'exécution JS
• Transmission de PageRank fiable — Google traite ces liens comme des signaux standards
• Ancre texte exploitable — le moteur comprend le contexte sémantique du lien

Cette recommandation est-elle vraiment respectée par les gros sites ?

Non. De nombreux sites à fort trafic utilisent encore des patterns JavaScript non conformes — et s'en sortent. Amazon, Airbnb, des plateformes SaaS majeures ont des liens pilotés par JS sans href valide. Pourquoi ? Parce qu'ils bénéficient d'un budget crawl massif, d'un maillage externe solide et que Google investit davantage de ressources JS sur eux.

Mais voilà le piège : ce qui fonctionne pour un site avec 10 millions de visites mensuelles ne fonctionne pas pour vous. Votre budget JS est limité, votre autorité aussi. Vous n'avez pas le luxe de compter sur la bienveillance de Google.

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

Martin Splitt dit « utilisez href », mais il ne précise pas ce qui se passe si vous avez un href ET un événement onclick qui modifie le comportement. Cas typique : <a href="/page" onclick="trackEvent()">. Est-ce que ça passe ?

Oui, tant que le href pointe vers une URL valide. Google suit le href dans le HTML initial, ignore l'événement onclick pour la découverte de liens. Le JS peut enrichir l'expérience utilisateur (tracking, animations) sans casser le SEO — à condition que le lien fonctionne sans JS.

[À vérifier] : Google ne documente pas explicitement le comportement avec des href dynamiquement modifiés par JS après le chargement. Si votre script change l'URL de destination après le rendu initial, rien ne garantit que Googlebot suive la version modifiée plutôt que l'originale.

Dans quels cas cette règle ne s'applique-t-elle pas strictement ?

Les interactions qui ne sont pas des liens de navigation. Boutons d'actions (ouvrir une modale, soumettre un formulaire, déclencher une animation) n'ont pas besoin d'être des <a>. Un <button> avec onclick est parfaitement légitime — tant qu'il ne mène pas vers une nouvelle page que vous voulez indexer.

Le problème surgit quand des développeurs utilisent des boutons ou des divs pour ce qui devrait être un lien. Si ça mène vers du contenu indexable, c'est un <a href>. Point final.

Que faut-il faire concrètement sur un site existant ?

Auditez vos liens de navigation. Tous. Utilisez un outil comme Screaming Frog en mode JavaScript activé/désactivé et comparez les liens découverts dans les deux cas. Si des URL critiques n'apparaissent que dans le crawl JS, vous avez un souci.

Inspectez manuellement quelques pages clés avec Chrome DevTools. Désactivez JavaScript (Settings > Debugger > Disable JavaScript) et rechargez. Vos liens de navigation fonctionnent-ils encore ? Si non, ils ne sont pas fiables pour Googlebot.

Comment corriger les liens JavaScript problématiques ?

Remplacez tout ce qui n'est pas un <a> par un vrai lien HTML. Si vous utilisez onclick pour la navigation, convertissez en <a href="URL" onclick="fonction()"> et assurez-vous que le href pointe vers la bonne destination.

Pour les frameworks JS : configurez votre routeur pour qu'il génère de vraies balises <a>. React Router, Vue Router et Angular Router le font par défaut — mais vérifiez que vos composants custom n'écrasent pas ce comportement. Un <Link> React doit produire un <a href> dans le DOM final.

Si vous devez absolument utiliser JavaScript pour la navigation (single-page apps complexes), implémentez au minimum un fallback href fonctionnel. Même si l'utilisateur ne le voit jamais, Googlebot doit pouvoir suivre ce lien sans exécuter une ligne de JS.

• Crawler le site avec JS désactivé et lister les liens manquants
• Remplacer les href="javascript:" par des URL HTTP(S) valides
• Convertir les div/span onclick en vraies balises <a>
• Vérifier que chaque lien de navigation a un href fonctionnel, même si JS enrichit le comportement
• Tester le rendu HTML initial (View Source) vs DOM final (Inspect Element) pour détecter les liens uniquement générés par JS
• Auditer les composants de framework (React Router, Vue Router) pour confirmer qu'ils produisent des <a href>
• Implémenter des tests automatisés qui vérifient la présence de href valides sur les liens critiques