# La naissance du hreflang chez Google en 2011, et le problème qu’il devait régler
> Retour sur l'annonce qui a introduit le hreflang : quelle confusion linguistique elle devait résoudre, et pourquoi la balise a fini par s'imposer partout.
- Auteur : WordPress Développement
- Publié le : 2020-01-04
- Mis à jour le : 2020-01-04
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/naissance-hreflang-google-2011/
## L’essentiel
- Annoncée par Google en décembre 2011
- Distingue enfin la langue du pays ciblé
- Reprise ensuite par Yandex et Bing
Le 12 décembre 2011, l'équipe Webmaster Central de Google publie un billet de blog technique qui va, sans grand tapage, changer la façon de construire un site en plusieurs langues. Le billet introduit un attribut jusque-là inconnu des développeurs : `hreflang`. Peu de sites l'adoptent tout de suite, mais le problème qu'il règle est déjà bien identifié par les équipes de Google depuis plusieurs années.
Comprendre ce contexte n'est pas un exercice d'archéologie gratuit. Un développeur qui pose une balise `hreflang` aujourd'hui sans savoir ce qu'elle corrige finit tôt ou tard par la mal configurer, en la confondant par exemple avec un simple marqueur de traduction. Ce n'est pas ça : c'est un outil de désambiguïsation entre variantes linguistiques d'une même intention de recherche.
## Avant 2011 : un web multilingue sans signal commun
Au début des années 2010, un site publié en plusieurs langues n'avait aucun moyen standard de dire à un moteur de recherche : « cette page en anglais et cette page en espagnol traitent du même sujet, choisis celle qui convient au visiteur ». Chaque moteur bricolait sa propre heuristique, fondée sur la détection de langue du contenu, la structure des URL, ou de simples suppositions statistiques.
Résultat : des pages presque identiques, publiées pour des marchés différents, se retrouvaient traitées comme du contenu dupliqué. Un site qui proposait un contenu en anglais britannique et un contenu en anglais américain, quasiment identiques à quelques mots près, voyait souvent l'une des deux versions reléguée dans les résultats, ou pire, mal servie à la mauvaise audience.
## Le problème que Google voulait résoudre
L'enjeu n'était donc pas la traduction en tant que telle, mais le ciblage. Une entreprise proposant un contenu en français pour la France et un contenu en français pour la Belgique n'a pas deux traductions différentes : elle a deux variantes régionales d'un même texte, avec parfois des prix, des mentions légales ou des coordonnées différentes. Sans signal explicite, le moteur ne pouvait pas deviner laquelle montrer à quel visiteur, ni comprendre que les deux méritaient d'exister sans se cannibaliser.
La balise proposée en 2011 répond exactement à ce cas : elle relie explicitement des URL entre elles en précisant la langue, et éventuellement la région, de chacune. Elle ne dit rien sur la qualité du contenu ni sur son originalité : elle indique un groupe d'équivalents, à charge pour le moteur de servir le bon.
> L'essentiel à retenir : Annoncée par Google en décembre 2011 ; Distingue enfin la langue du pays ciblé ; Reprise ensuite par Yandex et Bing
## Comment fonctionne la balise techniquement
Techniquement, l'implémentation initiale proposait deux formes : une balise `` dans le ``, ou un en-tête HTTP pour les documents non HTML comme les PDF. La syntaxe de base ressemble à ceci :
```
```
Le code de langue suit la norme ISO 639-1, et peut être complété d'un code pays ISO 3166-1 séparé par un tiret, jamais un tiret bas. La valeur spéciale `x-default`, ajoutée peu après l'annonce initiale, permet de désigner la page à montrer quand aucune variante ne correspond à la langue du visiteur.
- Le code de langue seul cible une langue, indépendamment du pays.
- Le code langue-pays cible une combinaison précise, par exemple les francophones de Belgique.
- `x-default` sert de filet de sécurité, pas de traduction supplémentaire.
## Une adoption progressive par les autres moteurs
L'attribut est resté longtemps une spécificité Google avant que d'autres acteurs ne s'y intéressent. Bing a fini par documenter un support partiel dans ses propres directives pour les webmasters. Yandex, moteur dominant en Russie, a également reconnu la balise dans son écosystème. Aucun de ces moteurs n'a inventé de norme concurrente équivalente : le format proposé en 2011 est resté la référence de fait pour signaler des variantes linguistiques, faute d'alternative standardisée par un organisme comme le W3C.
> Un repère utile pour ne jamais s'emmêler : le hreflang ne remplace ni une redirection, ni un contenu traduit. Il ne fait que relier des pages qui existent déjà et qui se ciblent mutuellement.
## Pour aller plus loin
Retenir l'origine de cette balise aide à éviter deux erreurs fréquentes chez les développeurs qui la découvrent sur le tas : la traiter comme un outil de traduction automatique, ou l'ajouter sur des pages qui n'ont pas de véritable équivalent linguistique en face. Le hreflang n'a jamais eu vocation à corriger un problème de contenu manquant ; il a été conçu pour un problème très précis, celui de plusieurs variantes légitimes d'une même page qui se disputaient la même requête.
Douze ans après son annonce, la balise reste identique dans sa syntaxe, ce qui en fait l'un des rares standards du référencement à n'avoir jamais changé de forme. Un développeur qui comprend ce contexte historique pose généralement une implémentation plus sobre et plus correcte, sans multiplier les combinaisons de langues qui ne servent à rien.