{{text}}
Partager
L'obfuscation de liens consiste à remplacer un lien HTML classique par un élément que le navigateur rend cliquable en JavaScript, mais qu'un robot d'exploration ne reconnaît pas comme un lien. Le visiteur clique et arrive sur la page. Le crawler ne voit aucune destination à suivre. Le lien disparaît du graphe sans disparaître de l'écran.
La technique circule depuis des années dans le SEO français, presque toujours présentée comme un moyen de mieux répartir le PageRank interne. Ce n'est pas faux. C'est surtout, pour l'immense majorité des sites, une réponse à un problème qu'ils n'ont pas. Synqro est une agence Webflow Premium Partner à Paris, et nous posons de l'obfuscation sur une minorité de projets, toujours pour la même raison : un volume d'URL qui a échappé au contrôle.
Cet article dit ce que la technique fait réellement, ce qui la sépare du nofollow, ce que Google écrit dans sa documentation, et à partir de quel seuil elle vaut le travail qu'elle coûte.
Ce que l'obfuscation fait, et ce qu'elle ne fait pas
Google est explicite sur ce qu'il sait suivre. Sa documentation sur les liens explorables, mise à jour le 10 décembre 2025, tient en une phrase : Google ne peut explorer un lien que s'il s'agit d'un élément HTML a doté d'un attribut href. La même page liste ce que ses robots ne suivent pas de façon fiable : un a sans href, un span porteur d'un href, un lien déclenché par un onclick, une URL en javascript:.
L'obfuscation applique cette règle telle quelle. Elle ne trompe rien, elle n'écrit simplement pas de lien. C'est sa différence avec toutes les autres méthodes de contrôle du crawl, qui laissent le lien en place et ajoutent une instruction par-dessus.
| Méthode | Le lien existe dans le HTML | Google suit le lien | La page cible est indexable | Ce qu'elle règle |
|---|---|---|---|---|
| Lien normal | Oui | Oui | Oui | Rien à régler |
| Attribut nofollow | Oui | Traité comme une indication | Oui | Qualifier un lien commercial ou non vérifié |
| Balise noindex | Oui | Oui, il doit explorer pour lire l'instruction | Non | Sortir une page de l'index |
| Blocage robots.txt | Oui | Non, la cible n'est pas explorée | Possible sans être lue | Économiser l'exploration d'un répertoire |
| Obfuscation | Non | Non, il ne le voit pas | Oui, si elle est atteignable autrement | Retirer un lien du graphe interne |
Une conséquence est presque toujours passée sous silence. Un lien obfusqué n'est pas seulement invisible pour Google, il l'est pour tout ce qui lit le HTML sans exécuter le JavaScript. La navigation au clavier saute l'élément si vous ne la recréez pas à la main, les lecteurs d'écran ne l'annoncent pas comme un lien, et l'ouverture dans un nouvel onglet ne fonctionne plus. C'est un coût d'accessibilité réel, pas une formalité.
Pourquoi ce n'est pas un nofollow
La confusion est constante et elle date de 2009. Matt Cutts avait alors annoncé, comme le rapporte Search Engine Land le 16 juin 2009, que Google avait modifié son algorithme plus d'un an auparavant : les liens en nofollow ne sont plus exclus du calcul de répartition. Sur une page qui porte dix liens dont cinq en nofollow, la valeur ne se concentre pas sur les cinq restants. Elle se divise toujours par dix, et la part attribuée aux liens nofollow n'est transmise à personne.
Le nofollow ne redirige donc pas la valeur, il la supprime. L'obfuscation retire le lien avant le décompte : la page en porte cinq, la division se fait par cinq. C'est la seule différence qui compte, et c'est aussi ce qui rend la technique sérieuse, puisqu'elle modifie la structure du site telle que Google la voit.
Le revers arrive avec. Une erreur d'obfuscation supprime une page de l'exploration sans laisser de trace lisible dans le HTML, donc sans alerte. C'est le genre de panne qu'on met trois mois à diagnostiquer.
Est-ce que Google considère ça comme du cloaking ?
Non, tant que la page servie est la même pour tout le monde. Les règles anti-spam de Google, mises à jour le 28 août 2026, définissent le cloaking comme le fait de présenter un contenu différent aux utilisateurs et aux moteurs de recherche dans l'intention de manipuler le classement et d'induire les utilisateurs en erreur. Les deux exemples donnés sont une page de destinations de voyage montrée aux moteurs pendant que l'internaute voit une page de médicaments, et l'insertion de mots-clés déclenchée uniquement quand l'agent qui demande la page est un robot.
L'obfuscation ne fait ni l'un ni l'autre. Le contenu servi est identique, c'est la navigation qui change. La nuance tient à une condition unique : si vous obfusquez en détectant le user-agent, pour servir un HTML aux robots et un autre aux humains, vous avez quitté l'obfuscation pour le cloaking. Le test tient en une ligne, le HTML doit être le même quel que soit le visiteur.
Il faut être honnête sur un point. Google n'a jamais publié de page qui autorise explicitement la pratique. Les articles qui affirment que Google l'accepte extrapolent. Ce qui est vérifiable, c'est que la technique ne coche aucun critère de la définition du cloaking, et qu'elle n'apparaît dans aucune liste de pratiques sanctionnées, contrairement à d'autres méthodes recensées dans notre article sur le black hat SEO.
Les trois cas où l'obfuscation se justifie
Les facettes et les filtres d'un catalogue
Un catalogue e-commerce à filtres croisés génère une URL par combinaison. Trois filtres à dix valeurs produisent déjà un millier de pages qui n'ont aucune raison d'exister. Le canonical et le noindex traitent l'indexation, ils ne réduisent pas le nombre de liens que le crawler découvre en arrivant sur la page. L'obfuscation, elle, le réduit.
Les blocs de navigation répétés à grande échelle
Un menu de 80 liens présent sur 50 000 pages, cela fait quatre millions de liens internes dont la quasi-totalité pointe vers une poignée de destinations. Obfusquer la partie du menu qui sert la navigation et pas le référencement change la carte du site de façon mesurable. Sur un site de 200 pages, le même geste ne change rien du tout.
Les pages utiles aux visiteurs, sans intérêt en recherche
Comparateurs internes, espaces de connexion, tunnels de réservation, formulaires en plusieurs étapes. Ces pages doivent rester atteignables et n'ont pas à peser dans le maillage. La balise noindex les sort de l'index, mais Google continue de les explorer pour lire l'instruction. Obfusquer les liens qui y mènent règle le problème plus haut.
Les cas où elle ne sert à rien, c'est-à-dire presque tous
La justification la plus courante est le budget de crawl. Or Google chiffre lui-même le périmètre concerné. Sa documentation sur la gestion du budget d'exploration, mise à jour le 22 juillet 2026, vise les sites de plus d'un million de pages uniques dont le contenu évolue modérément, et les sites de plus de dix mille pages uniques dont le contenu évolue très rapidement. Google précise que ces nombres sont une estimation grossière et non des seuils exacts, puis ajoute une phrase qui vaut instruction : si votre site n'a pas un grand nombre de pages qui changent rapidement, ou si vos pages semblent explorées le jour même de leur publication, vous n'avez pas besoin de lire ce guide.
Un site vitrine, un blog de 200 articles, un site d'agence, un SaaS de quelques centaines d'URL ne gagnent donc rien à obfusquer quoi que ce soit. Le temps passé à écrire le script, à le maintenir et à réparer l'accessibilité qu'il casse serait mieux employé à reprendre le maillage interne pour de bon, à supprimer les pages vides, à nettoyer les chaînes de redirection.
Notre position est nette. L'obfuscation est un outil de fin de liste. Elle arrive après l'architecture, après l'élagage des pages inutiles, après la correction des redirections. Un site qui la déploie avant d'avoir fait ce travail déplace un symptôme au lieu de traiter la cause.
Comment ça se met en place
Le principe tient en trois éléments. Un élément neutre porte l'ancre visible, un attribut de données porte la destination sous une forme que le crawler ne lira pas comme une URL, un écouteur d'événement rétablit la navigation au clic.
Côté balisage, le lien <a href="/page-cible">Ancre</a> devient un <span class="obf" data-o="L3BhZ2UtY2libGU=" role="link" tabindex="0">Ancre</span>, où la valeur de data-o est la destination encodée en base64. Un script écoute le clic et la touche Entrée sur les éléments de classe obf, décode la valeur avec atob et déclenche la navigation.
L'encodage en base64 n'est pas une sécurité, c'est une précaution pour éviter qu'une URL en clair soit reconnue comme telle. Deux points à ne pas négliger : sans role="link", sans tabindex="0" et sans gestion de la touche Entrée, vous rendez la navigation impossible au clavier. Prévoyez aussi le clic du milieu si vos visiteurs ouvrent des onglets.
Sur Webflow, concrètement
Webflow ne propose pas d'option d'obfuscation. La mise en place passe par du code personnalisé, placé avant la balise de fermeture du body au niveau du site ou de la page, et par des éléments auxquels vous ajoutez une classe et des attributs personnalisés dans le Designer. Un lien issu du CMS ne peut pas être obfusqué depuis le champ de lien, il faut le reconstruire en élément générique.
Dans les faits, la question se pose rarement sur Webflow. Les sites qui atteignent le volume d'URL où l'obfuscation devient pertinente sont rarement des sites Webflow, et quand ils le sont, le travail utile est en amont : réduire le nombre d'URL générées, hiérarchiser les collections, vérifier ce que le robot explore réellement. C'est précisément ce que couvre un audit technique SEO.
Comment vérifier que l'obfuscation fonctionne
Trois contrôles suffisent, dans cet ordre.
- L'outil d'inspection d'URL de la Search Console, onglet HTML rendu. Le lien ne doit apparaître sous forme de balise
ani dans le code source ni dans le rendu. - Un crawler lancé deux fois, sans puis avec exécution du JavaScript. La page cible doit sortir de la liste des URL découvertes en interne dans le premier passage.
- Un test manuel au clavier, tabulation puis Entrée, et un passage au lecteur d'écran. C'est le contrôle qu'on saute, c'est aussi celui qui produit les régressions les plus chères.
Le réflexe qui compte plus que la technique
Sur Les Fermes de Marie, hôtellerie de luxe à Megève, notre intervention a porté sur un audit SEO et plus de cinquante corrections techniques. L'obfuscation n'en faisait pas partie, et c'est exactement le point : à cette échelle, les gains étaient ailleurs, dans la structure et la propreté du code. Le détail est dans le cas client Les Fermes de Marie.
Si vous hésitez entre obfusquer et refaire votre architecture, la réponse est dans vos logs d'exploration, pas dans un article. Notre équipe d'agence SEO Webflow sait lire ces fichiers. Parlons de votre projet.
Questions fréquentes sur l'obfuscation de liens
L'obfuscation de liens est-elle pénalisée par Google ?
Aucune règle anti-spam de Google ne vise l'obfuscation. La définition du cloaking, mise à jour le 28 août 2026, suppose de servir un contenu différent aux robots et aux utilisateurs dans une intention de manipulation, ce que l'obfuscation ne fait pas puisque le HTML servi est identique pour tous. En revanche, Google n'a jamais publié de texte qui l'autorise explicitement.
Quelle est la différence entre obfuscation et nofollow ?
Le nofollow laisse le lien dans le HTML et demande à Google de ne pas le suivre, mais la part de valeur qui lui revient est perdue plutôt que redistribuée. L'obfuscation retire le lien du HTML, donc du décompte : la valeur se répartit entre les liens restants.
Est-ce que l'obfuscation fait gagner des positions ?
Pas directement. Elle modifie la répartition des liens internes et ce que le robot explore. Un gain n'apparaît que si le problème traité était réellement un problème de volume d'URL ou de dilution du maillage. Sur un site de taille normale, l'effet est nul.
À partir de combien de pages faut-il y penser ?
Google situe le sujet du budget d'exploration au-dessus d'un million de pages uniques à évolution modérée, ou de dix mille pages uniques à évolution très rapide, en précisant que ce sont des ordres de grandeur et non des seuils. En dessous, la documentation indique explicitement qu'il n'y a pas lieu de s'en préoccuper.
L'obfuscation pose-t-elle un problème d'accessibilité ?
Oui, si elle est mal faite, et c'est le cas le plus fréquent. Un élément non lié n'est pas atteignable au clavier et n'est pas annoncé comme un lien. Il faut ajouter un rôle, un ordre de tabulation et la gestion de la touche Entrée, puis vérifier au lecteur d'écran.
Peut-on obfusquer un lien sur Webflow ?
Oui, avec du code personnalisé et des attributs ajoutés dans le Designer. Un lien généré depuis un champ de lien du CMS doit être reconstruit en élément générique, l'option n'existe pas dans l'interface.
Comment savoir si un site utilise l'obfuscation ?
Comparez le code source et le HTML rendu, puis lancez un crawl sans exécution du JavaScript. Si des éléments cliquables à l'écran n'apparaissent nulle part comme balise a avec un href, le site pratique l'obfuscation.
Faut-il obfusquer les liens du footer ?
Rarement. Un footer de dix à vingt liens sur un site de taille normale ne pose aucun problème. La question ne se pose que sur des dizaines de milliers de pages, et seulement pour les liens qui n'ont aucune valeur de référencement, comme les mentions légales ou les pages de compte.




