Hreflang : définition, balise et SEO international

Hreflang : définition de l'attribut

Hreflang est un attribut HTML qui précise la langue et, en option, la région d'une page web. Il se place dans une balise link, au côté de rel="alternate" et d'un href qui désigne l'URL équivalente. Son nom vient de la fusion de href et de lang. Vous l'utilisez dès que le même contenu existe en plusieurs versions linguistiques.

Google s'en sert comme d'un signal, pas comme d'un ordre. L'attribut hreflang aide le moteur à choisir quelle version afficher selon la langue du navigateur et le pays de l'internaute. Un Belge francophone verra la page /fr-be/, un Québécois la page /fr-ca/. Pour comprendre la mécanique derrière ce choix, notre définition du moteur de recherche détaille les étapes de crawl, d'indexation et de classement.

Ce que hreflang ne fait pas

Il ne traduit rien. Il ne redirige personne. Il ne fait pas grimper une page dans les résultats d'un pays où vous n'avez aucun contenu. Il ne remplace pas non plus le lien canonique, qui règle un tout autre problème : celui des doublons à l'intérieur d'une même langue.

À quoi sert hreflang en SEO international

Le premier bénéfice est défensif. Sans signal, deux pages très proches — un texte en anglais pour le Royaume-Uni et le même texte pour les États-Unis — ressemblent à du contenu dupliqué. Google risque alors d'en ignorer une. Les balises hreflang lui disent qu'il s'agit de variantes voulues, pas de copies paresseuses.

• Regrouper les signaux : vos différentes versions se partagent la popularité au lieu de se la disputer.
• Afficher la bonne page dans la bonne SERP, sans redirection automatique agressive.
• Garder le visiteur plus longtemps : quelqu'un qui lit dans sa langue reste.
• Éviter qu'une page de prix en dollars ne s'affiche à un acheteur européen.

Faut-il spécifier la langue, la région, ou les deux ?

Vous pouvez spécifier la seule langue (fr), ou la langue et la région (fr-ca). Le second cas se justifie quand le contenu change vraiment : devise, délais de livraison, mentions légales, numéro de téléphone. Si votre page canadienne et votre page française sont identiques au mot près, une seule version suffit. Multiplier les pages localisées sans différence réelle ne vous apporte rien, à part un crawl budget gaspillé.

Comment ça marche : la syntaxe de link rel="alternate"

Anatomie d'une balise hreflang

Une déclaration complète tient en quatre morceaux : la balise link, l'attribut rel qui annonce une variante, le href qui donne l'adresse, et le code de langue. Une balise qui ne contient ni l'attribut hreflang ni l'attribut href est tout simplement ignorée. L'ordre des attributs est libre : <link rel="alternate" hreflang="en-gb" href="http://example.com/uk/" /> dit exactement la même chose qu'une écriture inversée. En revanche, chaque version de la page doit lister toutes les autres, et se citer elle-même.

• link rel="alternate" : vous annoncez une page de remplacement, pas un doublon.
• href : l'URL absolue et complète de la version cible, en https, sans paramètre de suivi.
• hreflang : le code de langue, suivi au besoin d'un tiret et du code de région.

Codes de langue et de région acceptés

Le code de langue suit la norme ISO 639-1, sur deux lettres. Le code de région suit la norme ISO 3166-1 alpha-2. La langue vient toujours en premier, la région ensuite, séparées par un tiret. Et vous ne pouvez pas cibler une région seule : hreflang="ca" désigne le catalan, pas le Canada.

• es : espagnol, toutes régions confondues — le cas de nombreux sites hispanophones.
• es-mx : espagnol du Mexique, pour des contenus spécifiques à ce marché.
• pt-br : portugais du Brésil.
• zh-Hant : chinois traditionnel, écrit avec un code de script.

La valeur hreflang="x-default"

La valeur x-default sert à indiquer la page à servir quand aucune version ne correspond à l'internaute. C'est souvent une page d'accueil internationale, ou un sélecteur de pays. Pour les langues sans correspondance, Google se rabat dessus. Un seul hreflang="x-default" par grappe, et il doit pointer vers une URL réellement neutre.

Les trois méthodes pour déclarer vos versions

Google accepte trois méthodes, et une seule suffit. Choisissez celle qui colle à votre site, puis tenez-vous-y. Les mélanger produit des signaux contradictoires, très pénibles à déboguer six mois plus tard.

1. Les balises HTML dans le head

C'est la méthode la plus lisible. Les balises se placent dans la section head du document, avant tout contenu visible. Elle convient aux sites de quelques dizaines de pages. Au-delà, le poids du code devient absurde : vingt langues sur mille pages, cela fait vingt mille lignes à maintenir.

2. Les en-têtes HTTP

Pour un PDF, une image ou tout fichier sans head, le serveur renvoie l'information dans les en-têtes HTTP. Le format reprend les mêmes éléments : un Link, l'URL entre chevrons, la valeur rel="alternate" puis le code. C'est la seule voie pour les documents non HTML, et elle demande un accès à la configuration serveur.

3. Le sitemap hreflang

La méthode la plus confortable pour les gros catalogues. Chaque URL du sitemap XML reçoit autant d'éléments xhtml:link qu'il existe de versions. Le code source des pages reste léger et la mise à jour se fait dans un seul fichier. C'est l'option que nous retenons presque toujours sur un e-commerce multilingue.

• Réciprocité obligatoire : si A cite B, B doit citer A. Sinon la paire est ignorée.
• Chaque version se déclare elle-même, avec son propre code.
• Une seule méthode par site, jamais deux en parallèle.
• Chaque version doit aussi être atteignable par un lien interne, pas seulement par la balise de la page.
• Les URL déclarées doivent répondre en 200, rester indexables et ne pas être bloquées par le robots.txt.

Erreurs fréquentes et dépannage

Dans la plupart des audits de référencement SEO que nous menons, le problème ne vient pas de la stratégie mais d'une faute de frappe. Voici celles que nous croisons le plus souvent.

• Une URL sans protocole : <link rel="alternate" href="www.example.com/fr/" hreflang="fr" /> ne sera pas comprise.
• Un code pays glissé à la place d'un code langue, comme uk au lieu de en-gb.
• Un underscore au lieu d'un tiret : fr_be ne vaut rien.
• Des balises injectées en JavaScript après le chargement de la page.
• Aucun x-default sur un site qui vend dans trente pays.
• Des déclarations qui mènent à des redirections ou à des 404.

Canonical et hreflang : le piège le plus coûteux

L'erreur la plus répandue consiste à faire pointer la balise canonique de toutes les versions vers une seule page. Vous demandez alors à Google d'oublier vos traductions, et vos déclarations deviennent muettes. La règle est simple : chaque page localisée porte une canonique qui pointe vers elle-même, et uniquement vers elle-même.

Déboguer les erreurs : les outils à utiliser

Un hreflang checker en ligne lit vos balises et signale les paires non réciproques. La Search Console ne propose plus de rapport dédié, mais l'inspection d'URL montre le code source réellement vu par Google. Les crawlers type Screaming Frog, Semrush ou Ahrefs remontent les anomalies à l'échelle du site entier. Pour un test rapide, l'affichage du code source suffit à vérifier que les balises sont bien là.

WordPress, Webflow, sur-mesure : qui pose les balises ?

Sur WordPress, un plugin multilingue comme Polylang ou WPML génère les déclarations seul ; son utilisation évite la saisie à la main. Sur Webflow, la localisation native s'en charge depuis le panneau de configuration. Sur un site sur mesure, c'est au développeur de construire la grappe à partir des traductions disponibles en base. Dans tous les cas, contrôlez le résultat : un module mal réglé déclare des versions qui n'existent pas.

Questions fréquentes