Obfuscation de liens en SEO et problèmes d’accessibilité

Je suis tombée sur un site e-commerce que je ne connaissais pas. Comme d’habitude, j’ai donc cherché la page des mentions légales dans le pied de page pour aller chercher le numéro de SIRET de l’entreprise et faire une recherche sur société.com.

J’étais sur une fiche produit donc j’ai voulu ouvrir ce lien dans un nouvel onglet mais je ne pouvais pas le faire. Je suis donc allée dans le code et j’ai trouvé un faux-lien : un élément HTML span était utilisé au lieu d’un élément a avec un attribut href. Le code était le suivant :

<span data-lien="/mentions-legales">Mentions légales</span>

Ce faux-lien n’est donc absolument pas accessible au clavier, ni via un lecteur d’écran, ni via le pilotage à la voix. Par conséquent, de nombreuses personnes handicapées se retrouvent à ne pas pouvoir accéder aux pages derrière ces faux-liens. Et pour les autres qui ne sont pas handicapées par ce faux-lien, on a quand même un défaut d’utilisabilité certain avec impossibilité de choisir d’ouvrir ce lien dans un nouvel onglet, impossibilité d’accès au menu contextuel habituel des liens, impossibilité de voir l’URL en bas à gauche du navigateur, impossibilité de glisser ce lien dans les favoris, etc.

Cette pratique s’appelle « l’obfuscation de liens » ; c’est une pratique « SEO » (Search Engine Optimization) soit, une pratique d’optimisation pour les moteurs de recherche tels que Google, qui permet de masquer un lien aux moteurs de recherche tout en le laissant, en théorie, utilisable pour les humains. Grosso modo, ça sert à éviter d’indexer la page, à éviter que les moteurs de recherche n’accède à cette page, ou encore à optimiser la répartition de ce qu’on appelle le « jus SEO » (la popularité transmise par un lien). L’attribut rel="nofollow" placé sur un lien ne semble plus être forcément suffisant.

Notez qu’il est fort probable que cette pratique ne soit pas du tout approuvée par Google puisqu’il s’agit de biaiser son algorithme donc, si vous l’utilisez, c’est à vos risques et périls (ou aux risques et périls de vos clients et clientes, en l’occurrence).

Sur Twitter, j’ai donc demandé quelles sont les preuves que cette pratique fonctionne parce que je trouve plein d’articles qui expliquent à quoi ça sert mais je suis bien en peine de trouver des articles qui prouvent que c’est véritablement utile. Personne ne m’a donné de preuve formelle (des études, quoi) donc je ne sais pas si ça veut dire qu’elles n’existent vraiment pas.

Bref, en l’absence de preuve d’efficacité pour le SEO à ce jour et vu les problèmes que cette technique pose pour l’accessibilité et l’utilisabilité, la solution simple et efficace pour les humains est : n’obfusquez pas les liens et utilisez des vrais liens HTML.

Une idée pour obfusquer les liens de façon accessible

Si vous êtes malgré tout une personne convaincue que l’obfuscation de liens est une chose à faire, alors vous ne devez pas le faire n’importe comment pour que cela reste accessible aux personnes handicapées.

Il y a deux choses à savoir sur les liens :

  1. Un lien doit être atteignable au clavier, ou via un lecteur d’écran qui liste les liens, ou via pilotage à la voix ;
  2. Un lien doit avoir un rôle de lien afin que les personnes utilisant un lecteur d’écran ou pilotant leur ordinateur à la voix sachent qu’il s’agit d’un lien et que ce lien puisse être listé dans la liste des liens générée par les logiciels d’assistance.

Ok, ça ne vous parle sans doute pas mais, en conséquence, certaines personnes vous diront qu’il suffit d’ajouter des attributs role="link" tabindex="0" sur ces span et le tour est joué. Cela donne ce code :

<span data-lien="/mentions-legales" role="link" tabindex="0">Mentions légales</span>

Dans ce code, l’attribut role="link" permet de donner le rôle de lien à l’élément et l’attribut tabindex="0" permet d’accéder à ce lien au clavier et le rend donc effectivement cliquable. Toutefois, cela ne résout pas les problèmes d’utilisabilité mentionnés plus haut (menu contextuel, ouverture en nouvel onglet, etc.). Cette solution n’est donc absolument pas optimale car cela continuera à poser des difficultés.

En discutant avec Romain Gervois ce soir, il a trouvé une idée qui me semble intéressante car prenant mieux en compte les défauts d’utilisabilité même si, ce n’est pas parfait (un vrai lien dès le départ sera toujours beaucoup mieux). Nous y avons donc réfléchi plus en détails ensemble et je vous présente ici le résultat de ces réflexions.

Le code HTML par défaut

Dans le code HTML, l’idée est la suivante :

  1. Utiliser un élément HTML a ;
  2. Ne pas utiliser, par défaut, l’attribut href pour y placer l’URL mais utiliser un attribut data-href (mettez ce que vous voulez après data-) ;
  3. Lui ajouter un attribut role="link" pour qu’il ait le rôle de lien malgré l’absence d’attribut href (oui, un élément a sans attribut href n’est pas un lien) ;
  4. Lui ajouter un attribut tabindex="0" pour qu’il soit atteignable au clavier (un élément a sans attribut href n’étant pas atteignable au clavier).

Ça donne ceci :

<a data-href="/mentions-legales" tabindex="0" role="link">Mentions légales</a>

Les interactions JavaScript à prévoir

Bien sûr, ce code HTML nous permet de dire qu’il s’agit d’un lien et on peut l’atteindre au clavier. Toutefois, pour qu’il soit fonctionnel et nous emmène sur la page, il faut ajouter quelques interactions via JavaScript.

  1. Tout d’abord, on va récupérer tous nos faux-liens dans une variable ;
  2. Ensuite, au survol du document (et non pas du lien), on va aller transformer tous les faux-liens en vrai lien en remplaçant l’attribut data-href par href. Pourquoi au survol du document ? Car cela nous permettra de bénéficier de l’affichage de l’URL en bas à gauche du navigateur. Les personnes naviguant à la souris auront donc accès à des vrais liens ;
  3. Nous ferons de même au focusin du document pour que les personnes naviguant au clavier aient accès à des vrais liens ;
  4. Enfin, nous ajouterons un évènement clic pour chaque faux-lien afin de transformer les faux-liens en vrais liens : cela permettra aux personnes qui pilotent à la voix sans toucher ni à la souris ni au clavier d’activer ces liens.

Bien sûr, je vous ai codé rapidement une démo (avec jQuery, oui !) :

Démo sur CodePen

Ensuite, libre à vous d’encoder l’URL au départ puis de la décoder au moment de la transformation de l’attribut data-href en attribut href si vous pensez que c’est utile…

Chacune des étapes décrites est absolument essentielle et aucune ne doit être oubliée pour que ce soit accessible.

À vous de tester côté SEO

Bien sûr, la spécialiste du SEO, ce n’est pas moi. J’expose ici une idée. Je vous laisse tester pour voir si cela fonctionne comme souhaité du point de vue SEO. N’hésitez pas à me faire vos retours en commentaire et je pourrais modifier ce chapitre en conséquence.

Vigilance sur la maintenabilité et la robustesse du code

Ce genre de pratique pose également un sérieux problème pour la maintenabilité du code. N’importe quelle personne n’y connaissant rien et devant modifier le code pourrait en retirer un morceau et ainsi casser soit la mise en place spécifique pour l’accessibilité, soit la mise en place spécifique au SEO. Si vous l’utilisez, documentez bien chaque point partout dans le code !

De plus, la pratique de l’obfuscation de liens repose sur le fait que le JavaScript est activé. Ainsi, si le JavaScript est désactivé sur le navigateur de l’utilisatrice ou si celui-ci n’est pas chargé ou contient une erreur, alors les liens ne seront plus disponibles. Comme on peut le lire dans cet article en anglais, Martin Splitt, de Google, recommande de ne surtout pas retirer l’attribut href et de ne pas encoder les URL. Par ailleurs, si des liens sont obfusqués dans le corps d’un article, ils ne fonctionneront pas en mode lecture des navigateurs ou dans les lecteurs de flux RSS.

L’avis de Myriam Jessier, experte SEO

L’accessibilité est centrale à l’approche de Google ces dernières années, tout comme l’expérience utilisateur, comme on peut en juger par la PRE (Page Rank Experience). Cela veut dire que certaines tactiques visant à mieux contrôler le robot de Google impactent négativement l’expérience des humains et donc qu’elles ne sont plus compatibles avec un bon référencement sur le long terme.

De plus, le robot de Google a un processus d’exploration sophistiqué qui ne nécessite plus ce genre de pratiques.

À la fin de la journée, le bot est un utilisateur comme un autre et Google a été clair que de faire des choses avec pour objectif exclusif d’impacter le bot n’est pas une bonne pratique, surtout, si cela impacte des humains.

Myriam Jessier

Je conclus donc sur le fait qu’utiliser un lien HTML classique sera toujours la meilleure des solutions, la plus accessible, la plus utilisable, la plus fiable, la plus robuste, la plus maintenable.


Merci à toutes les personnes qui m’ont apportée des réponses constructives qui ont étayé ma réflexion.

6 commentaires sur « Obfuscation de liens en SEO et problèmes d’accessibilité »… Et vous, qu’en pensez-vous ?

  1. Bonjour Julie, ton approche est très louable car tu apportes une solution qui ménage les objectifs du SEO et ceux de l’accessibilité. Pour ce qui est de Google, je me permets juste de préciser que c’est bien la firme de Mountain View qui a mis en place l’attribut « nofollow », pas le W3c, l’iETF ou autres. GG a depuis complété son arsenal de pratiques non standards avec des attributs « ugc », « sponsored » et cie… Alphabet est donc la première à ne pas respecter les règles, mais est-ce vraiment une surprise ?

  2. Bonjour et merci.

    Je ne comprends pas bien où tu veux en venir car, sauf erreur de ma part, ces attributs ne posent pas de problèmes d’accessibilité ? Ne pas respecter les règles si ça n’a pas d’impact sur l’accessibilité ou l’utilisabilité n’est pas pareil que ne pas les respecter en causant du tort aux utilisatrices et utilisateurs à la fin. Et, je vais renvoyer à un autre article que j’ai écrit sur le fait que ce n’est pas parce que Google/Alphabet et consorts font n’importe quoi qu’on peut/doit faire pareil : « Accessibilité : personne ne le fait donc on s’en fiche ».

  3. Merci pour l’article, très intéressant !

    Juste un élément, l’obfuscation de liens est de plus en plus utilisée, surtout pour les sites ecommerce car c’est le seul moyen d’éviter l’indexation de contenus non pertinents. Un exemple type, les facettes sur un site ecommerce qui servent à filtrer les éléments d’une catégorie. On se retrouve vite avec un souci d’« index bloating » (plein de contenus indexés qui n’aident pas les utilisateurs, un effet de dilution du contenu…)
    Le souci, même en mettant des instructions dans le robots.txt ou un noindex dans le header http, dès qu’un bot voit un href dans le code source, il l’ajoute à sa liste. Quand tu vas voir dans la search console, section pages, indexed though blocked by robots.txt, n’importe quel SEO va commencer à avoir quelques gouttes de sueur…

    Malheureusement, par expérience, quand tu laisses la voie libre au bot de Google, on obtient rarement la solution attendue.

    C’est un point délicat, il faut faire des compromis dans ce genre de cas.

  4. Bonjour Jean-François,

    Quand il est question de droits humains (oui, l’accessibilité est un droit humain), les compromis ne doivent pas se faire à leur encontre. Ainsi, le compromis n’est pas à faire du côté de l’accessibilité mais du SEO même si je sais que c’est parfois difficile à entendre. Je signale d’ailleurs que l’obligation d’accessibilité pour les sites e-commerce est quelque chose qui va arriver dans la prochaine mise à jour de la loi sur l’accessibilité (prévue en fin d’année si tout va bien) car c’est une exigence d’une directive européenne.

    Les contenus que vous jugez non-pertinents le sont en réalité très certainement pour les utilisateurs et utilisatrices. La page des mentions légales est, par exemple, très importante puisqu’elle contient des informations légales.

    Bref, tout l’objet de cet article est d’apporter une solution pour que les personnes en charge du référencement d’un site cessent de faire de l’obfuscation de façon inaccessible sans que ça les empêche de le faire puisqu’elles ne sont pas prêtes à abandonner cette pratique. Il n’y a donc même pas de compromis ici.

  5. Bonjour Julie,

    super ton article pour les pro du SEO et les devs aussi.

    Y’a un point que je ne comprends pas.

    Je ne connais pas l’algo de Google mais j’imagine qu’il va aussi regarder les éléments avec un role="link".
    Quand tu cherche un lien dans un code tu cherches normalement les balise <a> avec un href + les éléments qui ont un role="link".
    Si l’algo de Google recherche bien les role="link", je ne vois pas trop ce qui est possible de faire pour satisfaire le SEO en rendant les liens accessibles.

    Ou alors il faudrait tout faire en JS et ajouter les role="link" sur des balise <a> sans href, c’est possible ?

  6. Bonjour Sélim,

    Jusqu’à preuve du contraire, Google ne prend pas en compte les attributs ARIA (role en est un). Comme souvent avec Google, il n’y a pas de documentation sur le sujet. J’ai trouvé une réponse d’une personne sur un forum et c’est à peu près tout.

    J’estime ici avoir fait ma part du travail en cherchant une solution avec Romain et en la publiant, démonstration à l’appui. C’est pour cela que j’attends que les SEO qui pratiquent ce genre de choses fassent leurs tests et me disent ce qu’il en est. Après tout, la spécialiste du SEO, ce n’est pas moi, même si je connais des choses.

    Concernant l’idée d’ajouter les role="link" en JavaScript, cela n’aurait pas beaucoup de sens car Googlebot charge bien les sites avec leur JavaScript (sinon les sites qui chargent leur contenu en JS ne seraient pas indexés) donc autant les avoir directement dans le HTML au chargement. Le script qu’on propose réside non pas sur l’idée que Googlebot ne charge pas le JS mais sur l’idée qu’il n’interagit pas réellement avec la page.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.