Un internaute sur Reddit voulait savoir si cacher un bouton en HTML pour “forcer” Google à lire un second lien avec une meilleure ancre pouvait améliorer son SEO. John Mueller a répondu, et la réponse est intéressante, pas pour ce qu’elle confirme, mais pour ce qu’elle refuse de valider.
Le scénario : deux liens vers la même page, une ancre plus optimisée que l’autre
La question posée sur Reddit est concrète. Une page d’accueil contient deux liens pointant vers la même page de services :
- un bouton “Services” visible en haut de page, dans la navigation principale
- un second lien dans la FAQ, plus bas, avec une ancre rédigée pour le SEO (plus descriptive, plus riche en mots-clés)
L’idée de l’internaute : retirer au premier bouton son statut de lien <a> en HTML, le garder cliquable via JavaScript, mais laisser uniquement le second lien en vrai balisage HTML. Objectif : faire en sorte que Google lise prioritairement l’ancre optimisée du second lien.
C’est là qu’intervient le concept de “first link priority” : la théorie selon laquelle Google, quand il trouve deux liens vers la même page, ne retient que le texte d’ancre du premier.
Ce que dit Mueller : ne te pose pas trop de questions
Selon Search Engine Journal, Mueller a répondu de façon assez directe : il pense que la personne se complique inutilement la vie. Google traite des millions de sites avec des structures variées, et il n’anticipe aucun changement visible dans les résultats pour ce type de manipulation.
Mais il va plus loin avec une recommandation technique claire : si tu veux vraiment tester cette approche, ne casse pas le HTML. Garde les deux liens comme de vrais éléments <a> dans le code. Utilise CSS ou JavaScript pour repositionner visuellement les éléments dans la page, de façon à modifier leur ordre dans le DOM sans sacrifier l’intégrité des balises.
Concrètement, ça veut dire : si tu veux que l’ancre du second lien soit “lue en premier” par Googlebot, fais en sorte que ce lien apparaisse en premier dans le code source (DOM), même s’il s’affiche visuellement plus bas grâce au CSS.
First link priority : un mythe vieux de 18 ans
Ce concept remonte à un post de Rand Fishkin publié en 2008. Google n’a jamais confirmé officiellement que seul le premier lien vers une page interne est pris en compte pour le texte d’ancre.
Martin Splitt, autre porte-parole de Google, avait lui aussi abordé le sujet lors d’une session SEO 101. Sa recommandation était simple : utilise toujours un balisage <a> propre plutôt que des boutons ou des handlers JavaScript pour la navigation interne. L’accessibilité et la lisibilité par les crawlers vont de pair.
Ce que Mueller ne fait pas dans sa réponse : démentir le mythe. Il ne dit pas que le first link priority est faux. Il dit simplement que la technique envisagée pour le contourner est maladroite, et qu’il existe une méthode plus propre si on veut vraiment tester.
C’est une nuance importante. Je l’interprète ainsi : le sujet est suffisamment marginal pour que Mueller ne veuille pas en faire une déclaration officielle, mais la solution propre existe si tu veux creuser.
Ce que ça change concrètement pour ton maillage interne
Si tu gères un site avec un maillage interne soigné, cette discussion pointe vers quelques principes pratiques.
Ne sacrifie pas un vrai lien HTML pour du SEO théorique. Un lien <a> propre est toujours préférable à un bouton JavaScript, pour le SEO comme pour l’accessibilité. Supprimer un lien HTML pour “favoriser” un autre lien, c’est perdre de la valeur certaine pour un gain hypothétique.
L’ordre dans le DOM a plus d’importance que l’ordre visuel. Si tu veux qu’une ancre spécifique soit associée à une page cible, assure-toi que le lien portant cette ancre apparaît en premier dans le code source, indépendamment de sa position visuelle sur la page.
Deux liens vers la même page interne ne sont pas forcément redondants. Si les deux ancres sont pertinentes, les deux liens apportent de la valeur. Le vrai problème se pose quand les ancres sont contradictoires ou quand l’une est vide de sens (“cliquez ici”, “en savoir plus”).
L’enjeu est similaire quand tu travailles sur la canonicalisation et les liens cachés : la cohérence du code source prime sur les raccourcis.
Mon avis
À mon avis, ce type de question révèle une tendance assez répandue : sur-optimiser des micro-détails alors que les bases (qualité du contenu, indexation propre, architecture cohérente) ne sont pas encore solidement en place. Mueller a raison de dire que Google gère ça sans que tu aies besoin d’intervenir. Si tu as deux liens vers la même page avec des ancres différentes, travaille sur la cohérence de ton vocabulaire plutôt que sur des acrobaties DOM. Le temps gagné sera mieux investi ailleurs. Si tu veux aller plus loin sur l’optimisation technique de ton site, mon agence AskOptimize peut t’aider à prioriser les bons chantiers.
FAQ
Le “first link priority” est-il une règle confirmée par Google ?
Non. Google n’a jamais officiellement confirmé ce concept. Il remonte à un post de Rand Fishkin publié en 2008 sur Moz. Mueller n’a pas démenti la théorie dans sa réponse, mais il a minimisé son importance pratique.
Peut-on cacher un lien en JavaScript pour influencer l’ancre lue par Google ?
Mueller déconseille cette approche. Retirer le balisage <a> d’un lien pour le remplacer par un bouton JS fait perdre les bénéfices SEO du lien. Si tu veux tester l’ordre de lecture, mieux vaut modifier l’ordre dans le DOM via CSS, en conservant les deux vrais liens HTML.
Est-ce qu’avoir deux liens vers la même page interne pose problème ?
Pas nécessairement. Deux liens avec des ancres différentes peuvent tous les deux apporter de la valeur. Le problème se pose surtout si les ancres sont vides (“cliquez ici”) ou contradictoires avec le contenu de la page cible.
Quelle est la meilleure façon de gérer l’ancre d’un lien interne ?
Utilise un balisage <a> propre avec une ancre descriptive du contenu de la page cible. Évite les ancres génériques. Si plusieurs liens pointent vers la même page, assure-toi que l’ancre la plus descriptive apparaît en premier dans le code source.
Martin Splitt a-t-il dit la même chose que Mueller sur ce sujet ?
Oui, en substance. Splitt avait déjà recommandé d’utiliser des balises <a> plutôt que des boutons ou handlers JavaScript pour la navigation interne, pour des raisons combinées d’accessibilité et de lisibilité par les crawlers.
