En SEO, on entend souvent parler d’optimisation des liens, en travaillant les signaux sémantiques. L’un de ces signaux historiques, très important pour le référencement, est le texte de l’ancre de lien : la phrase ou expression clé habituellement surlignée en bleu et cliquable afin de nous emmener vers d’autres pages, en interne ou en externe, et qu’on retrouve quasiment partout sur le web.
Ce lien bleu, c’est la base de la notion de web, puisqu’il relie une page d’un site à une autre page d’un autre site web (formant ainsi une toile de liens : toile = web en anglais). C’est une notion fondamentale en SEO, et c’est pour ça qu’on va commencer par expliquer ce qu’est l’ancre de lien.
Qu’est-ce qu’une ancre ?
Définition classique
On va le voir plusieurs fois ici, « ancre » est un terme qui peut avoir plusieurs significations. A la fois en HTML, pour le SEO et pour le moteur de recherche. La définition de ce mot est assez ardue. (Même Google a du mal avec cette définition).
Le mot « ancre » quand on parle du web correspond généralement à la traduction d’ « anchor text », le texte qui est présent sur une balise <a> en HTML (le a, c’est pour « anchor » justement).
Voici comment on encode une ancre en HTML :
On ouvre une balise ancre, on y glisse dans l’entête l’attribut href pour indiquer la destination de l’ancre, on rajoute le texte qui doit apparaître, et on referme la balise.
En SEO on a tendance à banaliser l’usage du terme « ancre » pour parler du texte qui apparaît, et qui ressemble à un texte en bleu souligné sur lequel les utilisateurs peuvent cliquer.
Attention, à ne pas confondre avec une ancre représentée par un # : c’est un concept d’ancrage légèrement différent qui permet de renvoyer les utilisateurs vers une part bien spécifique de la page.
Quand on parle de l’ancre de lien, on parle donc généralement du texte qui accompagne le lien et qui permet à l’utilisateur de comprendre ce qu’il y a derrière le lien avant de cliquer. Il est donc logique que ce texte serve également de contextualisation pour les moteurs de recherche, ce qui est assez facile à prendre en compte lorsque le moteur de recherche s’amuse à crawler le web : une balise HTML <a> est bien normée, simple à comprendre et les instructions qu’on peut y passer (avec les attributs « rel » par exemple) sont un tag d’autant plus simple pour la compréhension de ce que l’éditeur de site essaye de faire avec ce lien.
Cette définition est rendue un peu floue dans ce qu’on comprend que Google a comme définition pour une ancre (et on suspecte que c’est donc aussi flou pour eux).
Le point de vue de Google
Pour Google, le terme « Anchors » ne fait pas aussi simplement référence aux ancres de liens considérées en SEO. Anchors peut faire référence à plusieurs éléments qui contextualisent le lien concerné.
La partie qui suit s’appuie sur des suppositions qu’on peut faire en lisant les Leaks. Gardez en tête que malgré le fait que ces informations soient tirées d’une documentation officielle, il n’est pas possible de savoir quel est l’usage réel de ces informations. En revanche, les routes existent, et c’est donc un élément qui a eu assez d’intérêt et de valeur pour avoir été observé à un moment (la documentation regroupe beaucoup de signaux depuis 2003).
Je vous invite à aller regarder cette documentation en particulier :
GoogleApi.ContentWarehouse.V1.Model.AnchorsAnchor (et au passage, ceci est un lien)
Et plus spécifiquement, on va aller regarder ces 5 éléments suivants :
- origText (type: String.t, default: nil) – Original text, including capitalization and punctuation. Runs of whitespace are collapsed into a single space.
- Signifierait que la ponctuation et la capitalisation des lettres ne sont pas normalisées pour en garder la variété (on ne peut pas tenter de faire des ancres directes discrètement).
- context2 (type: integer(), default: nil) – This is a hash of terms near the anchor. (This is a second-generation hash replacing the value stored in the ‘context’ field.)
- Signifierait que le texte autour du lien, en plus du texte originel du lien, serait également pris en compte. Pas de notion de taille de ce contexte, mais on peut raisonnablement envisager que le paragraphe contenant le lien ou les paragraphes autour du lien seraient concernés.
- fontsize (type: integer(), default: nil)
- La taille de la police du lien peut être importante ?
- anchorPhraseCount (type: integer(), default: nil) – The number of unique anchor phrases. Capped by the constant kMaxAnchorPhraseCountInStats (=5000) defined in indexing/docjoiner/anchors/anchor-manager.cc.
- Au-delà de 5000 d’ancres différentes, Google ne considèrerait pas les nouvelles ancres de lien.
- anchorMismatchDemotion (type: integer(), default: nil) – anchor_mismatch_demotion: converted from QualityBoost.mismatched.boost.
- Si l’ancre de lien ne correspond pas à la destination, elle serait déclassée. (Et donc il faut s’assurer que lorsqu’on fait un lien vers une page, ce lien soit logique avec le contenu de la page).
Pour résumer :
- Google utiliserait le texte et le format de l’ancre et le contexte autour.
- Mais il prendrait aussi le texte cible en compte.
- Et il ne prendrait en compte que 5000 ancres de lien maximum (ça fait pas mal de choix pour travailler ses mots clés via des ancres de lien exactes).
Qu’est-ce qu’une ancre apporte en SEO
L’usage historique des ancres
Initialement, les SEOs ont utilisé les ancres de liens pour pousser leurs urls (les destinations desdits liens) sur un mot clé exact. Du fait du fonctionnement de Google, le résultat a permis à de nombreux SEO d’en faire une arme facile à utiliser pour l’optimisation des positions, ce qui a alimenté des business de « fermes de liens », vendant des ancres exactes ou un volume de liens avec une seule ancre, pendant des années.
Du point de vue de Google, la baisse du niveau de qualité des résultats allant à l’encontre de leur promesse de service, une réaction était à prévoir, et lorsque la mise à jour a été publiée, les business de fermes de liens ont été massivement impactés.
Penguin et les pénalités
Le 24 avril 2012, Google introduit une mise à jour au nom rafraîchissant : « Google Penguin ». Après la « légère » panique générale pour certains, c’est le tour du constat : les ancres suroptimisées ne fonctionnent plus comme avant. C’est une période de tests pour les SEO qui finissent par comprendre que le taux d’ancres de lien optimisées peut être visé par Penguin pour définir une limite acceptable. Bien sûr, il y a aussi la notion de spam qui est visée par Penguin, mais c’est un sujet pour une autre fois.
Les Leaks nous apprennent néanmoins quelques informations sur ce qui pourrait constituer la prise en compte des ancres en fonction de la pénalité Penguin :
- penguinEarlyAnchorProtected (type: boolean(), default: nil) – Doc is protected by goodness of early anchors.
- Des ancres de bonne qualité (point de vue algorithmique, pas humain), tôt dans la vie de la page ont un impact pour protéger la page des signaux de spam à posteriori (aucune notion de durée indiquée).
- penguinTooManySources (type: boolean(), default: nil) – Doc not scored because it has too many anchor sources. END: Penguin related fields.
- Trop de sources diverses pour l’ancre d’un document résultent en l’absence de score pour le document : ici, le champ mentionne le lien direct avec Penguin.
- badbacklinksPenalized (type: boolean(), default: nil) – Whether this doc is penalized by BadBackLinks, in which case we should not use improvanchor score in mustang ascorer.
- penguinPenalty (type: number(), default: nil) – Page-level penguin penalty (0 = good, 1 = bad).
- 2 pénalités différentes mentionnées, et pour le premier cas, le score improvanchor n’est pas utilisée dans mustang. Pour le deuxième cas, c’est la pénalité penguin qui s’applique, ce qui se traduit probablement par un « plafond de verre » en termes de positions.
Depuis, les Leaks nous ont également permis d’envisager certaines choses :
Les Leaks et le top 22% à 29%
Dans les Google Leaks, spécifiquement sur l’entrée suivante, une ligne nous met la puce à l’oreille :
GoogleApi.ContentWarehouse.V1.Model.IndexingDocjoinerAnchorStatistics
- topPrOnsiteAnchorCount (type: integer(), default: nil) – According to anchor quality bucket, anchor with pagrank > 51000 is the best anchor. anchors with pagerank < 47000 are all same.
On y apprend également que la Valeur du PageRank est un nombre compris entre [0, 65535].
Ce qu’on pourrait en déduire :
Si le PageRank de la page est compris entre 51000 et 65535, l’ancre aurait de la valeur et va pouvoir être utilisé.
Si le PageRank de la page est inférieur à 47000 : l’ancre aurait autant de valeur que toutes les autres ancres du même niveau sur le web.
De cette façon, on n’autoriserait qu’aux 22% meilleures urls du web d’avoir un impact avec les ancres sur les liens sortants, et on rend les ancres des 71% moins bonnes urls du web inefficace.
(Mais Pierre, 22% + 71% ça fait pas 100% ! Oui, oui, il y a un écart de 4000 points dans lequel on ne sait pas ce que fait Google. Mais il ne pénalise pas ni ne définit l’url comme qualitative, on ne sait juste pas).
Ce que ça veut dire :
Optimiser ses ancres, ce ne serait possible que sur les liens qui viennent du haut du panier (Littéralement les urls source de bonne qualité sur l’échelle du PageRank utilisé). Les véritables meilleures urls du web seraient les seules à transmettre l’information sémantique de l’ancre.
Comment optimiser l’usage des ancres ?
La vision du site web :
Pour éviter Penguin, on sait qu’il vaut mieux éviter un taux d’ancres de liens optimisées exactes sur une expression clé trop important. En moyenne, tous sujets confondus, la limite du taux acceptable est d’environ 4.5 à 5% (ça varie selon les thèmes). Cette limite ne s’applique pas aux ancres de marque (là on parle plutôt d’un taux acceptable de 15 à 30%).
Mais : On sait que les ancres optimisées des urls faisant partie des 71% les moins bonnes sur l’échelle du PageRank n’ont pas de valeur, alors autant éviter de les utiliser pour activer ce signal.
Pourquoi ?
Supposons une minute que vous obteniez uniquement une ancre optimisée sur des nouveaux liens depuis divers urls avec des niveaux de qualités variables. Le taux de présence de cette ancre monte obligatoirement. Vous atteindrez plus rapidement la limite d’usage de cette ancre, et si vous montez trop haut, c’est un risque de pénalité via penguin.
L’usage est donc au cas par cas :
- Pour les liens provenant d’urls sources du top 22%, il faut demander une ancre optimisée, pour le SEO, c’est d’une efficacité assurée.
- Pour les liens provenant d’urls sources du « flop » 71%, il faut éviter une ancre optimisée (l’url en texte d’ancre, ça conviendra).
- Pour les liens entre le top 22 et le flop 71, il faut essayer, et espérer que ça serve.
Lorsqu’on voit que la limite d’ancres optimisées va être atteinte, que faire ?
On peut réduire le taux d’ancres optimisées en réduisant le nombre d’ancres concernées ou en augmentant le nombre d’ancres non optimisées. Pour un site, ça revient à obtenir des liens sans optimisation vers la home page par exemple.
Comment l’usage de l’ancre peut-il être optimisé ?
Du fait de la définition d’un lien (composé d’une source et d’une destination), il y a 2 textes qui vont devoir résonner avec l’ancre de lien :
- Le texte du contexte du lien (les paragraphes avant et après le lien)
- Le texte de la page de destination.
Il y a de fortes chances que si vous réclamiez l’obtention d’un lien avec une ancre optimisée, vous ayez déjà eu recours à l’optimisation sémantique de votre page cible pour la requête (et par extension l’ancre associée) visée. Mais si ce n’est pas le cas je ne saurais vous inciter assez de travailler correctement la sémantique de votre page cible (Si ce n’est pas possible, c’est sans doute que ce n’est pas la bonne page web pour cette requête).
Et le contexte du lien, lorsque vous l’obtenez, doit être logique avec le texte de l’ancre et la page cible du lien. En réalité c’est comme une transition qui doit permettre aux utilisateurs de suivre le cheminement de l’auteur et aller voir le lien qui suit.
Est-ce que l’ancrage utilisé dans le cadre de liens de maillage interne peut également servir ?
Très peu. L’éditeur du site web ayant la main sur les liens qu’il fait au sein de son site, une ancre optimisée en interne d’un site, voire d’un groupe de sites pouvant appartenir au même Autonomous System (écosystème de sites web ayant une forte probabilité de dépendre d’un seul éditeur, comme un PBN), pour le moteur, c’est en général un signal qu’un contenu a suivi des recommandations pour optimiser son référencement naturel, ce qui, par déduction, ne sera pas aussi naturel qu’attendu.
Sources :
Leaks Google
https://hexdocs.pm/google_api_content_warehouse/0.3.0/api-reference.html
La Data Science au service du netlinking
SEO CAMP’us Paris 2022
Sylvain & Guillaume Peyronnet
