hreflang

Ce que hreflang fait réellement

Quand la même page existe en plusieurs langues, un moteur de recherche se pose deux questions : s'agit-il de la même page, et laquelle cet internaute précis devrait-il voir ? hreflang répond aux deux. Il regroupe les versions comme des traductions les unes des autres plutôt que comme des quasi-doublons qui se font concurrence pour la même requête, et il étiquette chacune avec le public pour lequel elle a été écrite. Sans cela, le moteur devine, et le symptôme visible est un internaute à São Paulo qui atterrit sur votre page en anglais et repart aussitôt.

Il vaut la peine d'être précis sur ce que hreflang ne fait pas. hreflang ne fera pas classer une page, ne consolidera pas les signaux de classement comme le fait une balise canonique, et ne sauvera pas une traduction que personne ne recherche. Une page doit d'abord gagner sa position dans sa propre langue ; hreflang s'assure seulement que la bonne version d'une page déjà compétitive est celle qui s'affiche. Cette distinction explique pourquoi traduire un site qui ne se classe nulle part ne produit rien — la décision de traduire ou non est traitée dans faut-il traduire son site pour le SEO.

Comment hreflang est mis en œuvre

Il existe trois emplacements valides pour le déclarer, et vous en choisissez exactement un par site plutôt que de les mélanger. Quel que soit votre choix, les mêmes règles concernant les codes et la réciprocité s'appliquent.

• Balises link dans le head — un élément link alternate par version, présent sur chaque version. L'approche la plus courante, et la plus facile à générer à partir d'une table de routage.
• En-têtes HTTP Link — la même information envoyée sous forme d'en-tête de réponse. C'est l'option pour les fichiers non-HTML comme les PDF, qui n'ont pas de head où placer des balises.
• Entrées dans le sitemap XML — chaque URL du sitemap liste ses alternatives. Utile pour les grands sites, car cela regroupe les annotations dans un seul fichier plutôt que sur des milliers de pages.
• Une valeur x-default — le repli pour les internautes dont vous ne ciblez pas la langue, pointant généralement vers votre page dans la langue par défaut ou vers un sélecteur de langue. Optionnel, mais cela supprime l'ambiguïté de savoir qui est servi quand rien ne correspond.

La valeur est un code de langue issu d'ISO 639-1, éventuellement suivi d'une région issue d'ISO 3166-1 Alpha 2 — en, pt-br, zh-Hans. La langue seule est valide ; la région seule ne l'est pas. Chaque version doit référencer chaque autre version *et elle-même*, et ces références doivent être réciproques : si la page A affirme que B est sa version espagnole mais que B ne pointe jamais en retour, les moteurs considèrent l'affirmation comme non confirmée et l'ignorent.

Où hreflang tourne mal

Presque tous les échecs sont mécaniques plutôt qu'éditoriaux, ce qui explique pourquoi les problèmes de hreflang survivent à d'excellentes traductions et sont généralement découverts longtemps après le lancement.

• Annotations à sens unique — l'erreur la plus fréquente, de loin. Les liens de retour doivent être confirmés des deux côtés, sinon tout le cluster est écarté.
• Codes inventés ou incohérents — en-uk n'est pas valide, car le code de région pour le Royaume-Uni est gb. Une seule valeur malformée invalide silencieusement cette annotation.
• Supposer que le jeton d'URL est le tag de langue — un site peut tout à fait légitimement servir du portugais brésilien depuis un chemin /pt tout en l'annotant pt-BR. Déduire le tag à partir du chemin est une source discrète d'étiquettes erronées.
• Pointer vers des URL qui redirigent, renvoient une 404, ou portent un noindex — la cible doit être la version en ligne et indexable, sinon le signal est abandonné.
• Rediriger automatiquement les visiteurs selon la langue du navigateur — cela annule complètement l'annotation, puisqu'un robot renvoyé vers une version n'atteint jamais les autres versions qui lui avaient été signalées.