Masquer un lien à Google pour concentrer la puissance de son maillage interne : l’idée séduit dès qu’un site dépasse quelques centaines de pages. La bonne nouvelle, c’est que Google ne sanctionne pas cette pratique. La mauvaise, c’est que la méthode enseignée depuis dix ans est en train de devenir doublement perdante : de moins en moins efficace côté robots, et juridiquement risquée depuis que l’accessibilité numérique est devenue une obligation pour la plupart des e-commerçants français. Voici comment décider si votre site en a réellement besoin, et comment le faire sans exclure une partie de vos visiteurs.
Qu’est-ce que l’obfuscation de liens, concrètement ?
L’obfuscation de liens est une technique de maillage interne qui rend un lien invisible aux robots des moteurs de recherche tout en le laissant parfaitement cliquable pour l’internaute.
Le mécanisme repose sur une contrainte technique documentée par Google : le moteur ne suit un lien que s’il s’agit d’un élément <a> doté d’un attribut href. La documentation officielle sur les bonnes pratiques de liens est explicite sur ce point, et précise que Googlebot exécute le JavaScript mais ne clique sur rien : il suit des attributs href, pas des gestionnaires d’événements. La même question se pose maintenant pour les moteurs de réponse, qui ont chacun leur crawler et leurs propres règles — PerplexityBot alimente un index entièrement distinct — et rien ne garantit qu’ils traitent un lien émulé comme Googlebot.
Obfusquer, c’est donc exploiter cette limite. On remplace la balise <a href="..."> par un élément neutre, souvent un <span> portant l’URL encodée dans un attribut de données, et on rétablit la navigation au clic via JavaScript. Le robot lit un bloc de texte, l’utilisateur voit et utilise un lien.
L’objectif n’est pas de cacher une page. Une page obfusquée reste accessible par le sitemap, par une autre page, par un lien externe. L’objectif est de ne pas dépenser en liens de navigation la valeur qu’on veut faire circuler vers les pages stratégiques.
Pourquoi ne pas simplement utiliser nofollow
C’est la question qui revient systématiquement. Un lien en nofollow reste un lien aux yeux du moteur : il est vu, compté dans le total des liens de la page, et Google se réserve la possibilité de le suivre. Un lien obfusqué n’existe tout simplement pas dans le graphe. La différence est réelle, même si son ampleur est discutée.
Est-ce que Google pénalise l’obfuscation de liens ?
Non, et c’est le point sur lequel la plupart des articles s’attardent alors qu’il est tranché depuis longtemps.
La confusion vient d’un rapprochement fait avec le cloaking, qui figure bien dans les règles anti-spam de Google. Mais le cloaking consiste à servir deux contenus différents selon l’identité du visiteur. L’obfuscation sert la même page à tout le monde. Le robot ne reçoit pas une version édulcorée : il reçoit exactement ce que reçoit l’internaute, et se trouve simplement incapable d’interpréter un élément comme un lien.
Cela dit, l’absence de sanction ne vaut pas recommandation. Interrogé sur une technique de dissimulation de liens en page d’accueil, John Mueller a répondu en substance qu’on surpensait le problème, et a souligné le risque de casser du HTML fonctionnel pour un gain non mesurable. C’est une nuance importante : Google ne vous punira pas, mais ne promet pas non plus que l’effort en vaille la peine. C’est aussi la limite d’un raisonnement purement technique : l’absence de sanction ne dit rien de la clarté envers le visiteur, une frontière que je détaille dans ce qu’est un SEO éthique.
Pourquoi la méthode historique ne tient plus
La recette classique — un <span> avec l’URL en base64 et un écouteur de clic — a été conçue à une époque où Googlebot ne rendait quasiment pas le JavaScript. Ce n’est plus le cas.
Le point de bascule est le suivant : si votre script reconstruit un vrai attribut href au chargement de la page, le lien redevient visible pour le crawl. Beaucoup d’implémentations, notamment celles vendues comme extensions clés en main, font exactement cela pour préserver le comportement natif du navigateur, l’ouverture dans un nouvel onglet ou le clic milieu. Elles obfusquent aux yeux de qui lit le code source brut, pas aux yeux du moteur qui rend la page.
Le résultat est le pire des deux mondes : le maillage n’est pas modifié, et le site a quand même hérité des inconvénients de la technique.
Le vrai risque en France n’est plus Google, c’est l’accessibilité
C’est le point que la plupart des ressources francophones sur le sujet traitent en une ligne, alors qu’il a changé de statut.
Remplacer un <a> par un <span> cliquable casse des mécanismes que les utilisateurs de technologies d’assistance considèrent comme acquis : l’élément n’est plus annoncé comme un lien par un lecteur d’écran, il sort du parcours de tabulation, il ne reçoit plus de focus visible. Benjamin Thiers, auditeur RGAA certifié, recense les critères directement mis en défaut : 7.1, 7.3 et 7.4 sur les scripts, 10.6 et 10.7 sur la présentation des liens.
Jusqu’en 2025, c’était une question de qualité. Depuis le 28 juin 2025, c’est une question de conformité : la directive européenne sur l’accessibilité (European Accessibility Act, 2019/882) étend l’obligation d’accessibilité au secteur privé. En France, elle vise notamment les entreprises de plus de 10 salariés réalisant plus de 2 millions d’euros de chiffre d’affaires sur un service grand public — le commerce en ligne en premier lieu. La conformité s’apprécie via le RGAA, et le manquement expose à des sanctions financières pouvant atteindre 50 000 € par service.
Autrement dit : la cible naturelle de l’obfuscation, le gros site e-commerce, est précisément celle qui n’a plus le droit de casser ses liens.
Comment obfusquer sans casser l’accessibilité
Il existe une voie praticable, décrite par le même auditeur : ne pas émuler un lien, mais le déclarer correctement puis le transformer.
L’élément est servi avec les attributs qui le rendent compréhensible pour les technologies d’assistance, mais sans href exploitable par le crawl :
<span role="link" tabindex="0" aria-label="Conditions générales de vente"
data-url="L2NndS8=">Conditions générales de vente</span>role="link" l’annonce comme un lien, tabindex="0" le remet dans le parcours clavier, aria-label donne son intitulé. Un script le convertit ensuite en véritable balise <a> à la première interaction humaine : mouvement de souris, appui clavier, toucher, ou prise de focus par la touche Tab. Comme aucune de ces interactions ne se produit pendant un crawl, le moteur ne voit jamais le lien final.
Deux points de vigilance sur cette approche. Le focus doit rester visible au clavier, sans quoi on corrige un critère RGAA en en cassant un autre. Et l’élément doit réagir à la touche Entrée, ce qu’un <span> ne fait pas nativement — c’est au script de le gérer.
Faut-il obfusquer votre site ?
La question préalable, que presque personne ne pose, est une question de volume. Faites le calcul avant de toucher au code.
Prenez le nombre de liens de navigation présents sur chaque page — menu, méga-menu, footer, fil d’Ariane — et multipliez-le par le nombre de pages. Un site de 1 000 URLs avec 40 liens de navigation émet 40 000 liens internes qui pointent toujours vers les mêmes destinations, avant même le premier lien contextuel. C’est là que l’obfuscation a un sens : elle change l’échelle du graphe.
Refaites le même calcul sur un site vitrine de huit pages : vous obtenez quelques centaines de liens, et le gain théorique disparaît dans le bruit. Sur les sites Webflow que je construis pour des PME, comme la vitrine d’ONIS, le levier utile n’est jamais l’obfuscation : c’est le fait d’avoir des pages qui méritent d’exister et des liens contextuels qui ont du sens. Le raisonnement vaut aussi pour un blog éditorial — sur juste1cafe, que je gère en propre, la croissance organique est venue de la profondeur des contenus et du maillage entre articles, pas d’une manipulation du graphe de liens.
Trois cas où la technique se défend vraiment :
- un e-commerce à facettes, où les combinaisons de filtres génèrent des milliers d’URLs de faible valeur ;
- un site à silos étanches, quand une navigation transversale relierait des univers sémantiques qu’on veut garder distincts ;
- un catalogue volumineux où le budget de crawl est réellement contraint, ce qui se constate dans les logs, pas à l’intuition.
Dans les trois cas, l’ordre des opérations compte : mesurez d’abord, obfusquez ensuite, et vérifiez que la méthode retenue reste conforme au RGAA. Si votre site ne relève d’aucun de ces cas, le temps investi dans l’obfuscation sera plus rentable ailleurs — à commencer par la suppression des pages qui n’auraient jamais dû exister.