Hreflang : comment configurer correctement les versions par langue et par pays

En bref : hreflang indique à Google quelle version linguistique ou nationale d'une page afficher à chaque internaute. Chaque version liste toutes les versions, y compris elle-même, avec un code de langue ISO 639-1 et une région ISO 3166-1 alpha-2 facultative (en, de, en-GB, pt-BR), plus un repli x-default facultatif. Les liens doivent être absolus et réciproques, sinon Google les ignore. Chaque version doit avoir une canonique qui pointe vers elle-même ; une canonique qui pointe vers une autre langue annule toute la configuration. Google détecte la langue de la page à partir du contenu : la traduction doit donc être réelle.

Les sites internationaux perdent du trafic de manière discrète. La page anglaise se positionne en Allemagne, la page espagnole s'affiche au Mexique alors que vous aviez créé une version mexicaine, ou la boutique britannique apparaît pour des internautes américains avec des prix en livres. Rien n'est cassé sur le site : Google a simplement deviné quelle version afficher. hreflang sert à l'empêcher de deviner.

Ce guide explique comment fonctionne hreflang d'après la documentation de Google, les règles de codes qui piègent la plupart des sites, l'interaction avec les canoniques, ce que teste notre outil de vérification hreflang gratuit, et comment corriger chaque problème.

Ce que hreflang fait, et ce qu'il ne fait pas

Les annotations hreflang décrivent un ensemble de pages qui sont des versions les unes des autres : le même contenu dans une autre langue, ou la même langue adaptée à un autre pays. Google s'en sert pour afficher la version correspondante dans ses résultats.

Ce qu'il ne fait pas :

• Il ne détecte pas la langue. Google indique qu'il « n'utilise ni hreflang ni l'attribut HTML lang pour détecter la langue d'une page » ; il se fie au contenu visible (sites multirégionaux). Une page balisée de avec un texte anglais reste une page anglaise.
• Il ne transforme pas des traductions faibles en doublons ou en originaux. Google précise que les versions localisées « ne sont considérées comme des doublons que si le contenu principal de la page reste non traduit ». Une page avec un menu traduit et un corps de texte en anglais est un doublon.
• Il ne redirige personne. Il change seulement l'URL qui apparaît dans les résultats. Les visiteurs peuvent toujours ouvrir n'importe quelle version.

Les trois façons d'ajouter hreflang

Google indique que les trois méthodes sont « équivalentes du point de vue de Google ». Utilisez-en une seule par page ; les mélanger ne fait qu'ajouter des sources d'erreurs.

1. Éléments link HTML dans le <head>, le choix le plus courant. Sur https://example.com/en/pricing :

<link rel="alternate" hreflang="en" href="https://example.com/en/pricing" />
<link rel="alternate" hreflang="de" href="https://example.com/de/preise" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/tarifs" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing" />

Les pages allemande et française comportent exactement les mêmes quatre lignes. Google exige que les balises soient « dans une section <head> bien formée » ; un élément parasite que le navigateur déplace dans le body, comme une image ou une balise non fermée placée avant les liens, peut interrompre le head trop tôt.

2. En-têtes HTTP Link, la seule option pour les fichiers non HTML comme les PDF :

Link: <https://example.com/en/guide.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/de/guide.pdf>; rel="alternate"; hreflang="de"

Google précise que l'en-tête doit être identique pour toutes les versions.

3. Sitemap XML, pratique pour les grands sites car aucune modification de template n'est nécessaire :

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/en/pricing</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/preise"/>
  </url>
  <url>
    <loc>https://example.com/de/preise</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/preise"/>
  </url>
</urlset>

Chaque <url> liste toutes les versions, y compris elle-même.

Les règles que Google applique

Liens retour et auto-référence

« Si deux pages ne se pointent pas mutuellement, les balises seront ignorées. » C'est la règle à l'origine de la plupart des configurations défaillantes. Si la page anglaise liste la page allemande mais que la page allemande ne liste pas l'anglaise, Google écarte la paire. Google précise aussi que « chaque version linguistique doit se lister elle-même ».

Codes de langue et de région

« Seuls les codes de langue de la norme ISO 639-1 et les codes de région de la norme ISO 3166-1 alpha-2 sont pris en charge. » La langue vient en premier ; la région est facultative. Google prend aussi en charge les sous-balises de script pour les langues écrites dans plusieurs écritures, comme zh-Hant et zh-Hans, ainsi que des combinaisons telles que zh-Hans-US.

Pour l'espagnol en Amérique latine, utilisez soit es pour une seule version espagnole partagée, soit la liste des pays ciblés (es-MX, es-AR, es-CO) pointant vers la même URL.

x-default

« La valeur réservée x-default est utilisée lorsqu'aucune autre langue/région ne correspond aux paramètres du navigateur de l'utilisateur. » Faites-la pointer vers une page de sélection de langue ou votre version internationale principale. Elle est facultative mais utile : sans elle, un internaute dont la langue n'est pas proposée obtient la version choisie par Google.

URL absolues

« Les URL alternatives doivent être complètes, y compris le protocole de transport. » https://example.com/de/ fonctionne ; /de/ et //example.com/de/ non.

hreflang et balises canoniques

Les deux doivent concorder. Chaque version doit avoir une canonique qui pointe vers elle-même, et non vers la version anglaise ou principale. Le guide de canonicalisation de Google recommande d'« indiquer une page canonique dans la même langue », ou « la meilleure langue de substitution possible si aucune page canonique n'existe pour la même langue », et note que les clusters hreflang influencent le choix de la canonique, en favorisant les URL qui se pointent réciproquement.

L'erreur classique : chaque version linguistique contient <link rel="canonical" href="https://example.com/en/...">. Cela indique à Google que les autres versions sont des doublons de la page anglaise, et elles sortent de l'index avec leurs annotations hreflang.

Deux autres conflits à éviter : des URL hreflang qui redirigent (indiquez l'URL finale) et des URL hreflang en noindex (une version que Google ne peut pas indexer ne peut pas être affichée).

Structure du site et redirections automatiques

Le guide multirégional de Google compare les structures d'URL :

Quel que soit votre choix, ne redirigez pas automatiquement les visiteurs selon l'IP ou la langue du navigateur. Google indique que cela « pourrait empêcher les utilisateurs (et les moteurs de recherche) de voir toutes les versions de votre site », et que Googlebot « provient généralement des États-Unis ». Affichez plutôt un bandeau de suggestion et laissez hreflang gérer les résultats de recherche.

Comment fonctionne l'outil de vérification hreflang de Searvia

L'outil de vérification hreflang utilise le même moteur que notre outil d'audit SEO de site web : vous saisissez un domaine ou l'adresse d'une page, il audite cette page (votre page d'accueil si vous saisissez seulement un domaine) et les fichiers du site associés avec 38 contrôles en environ 20 secondes, et place en premier les trois contrôles qui concernent cet outil. Voici exactement ce qu'ils testent.

Versions linguistiques, hreflang (priorité basse). L'outil lit chaque élément <link rel="alternate" hreflang="..." href="..."> du HTML de cette page, après avoir suivi les redirections jusqu'à son adresse finale.

• S'il n'y en a aucun, le résultat est informatif : « Aucune version linguistique n'est déclarée (normal pour un site monolingue). » Cela n'affecte pas votre note.
• Chaque code est comparé aux codes pris en charge par Google : x-default, ou une langue ISO 639-1 à deux lettres, éventuellement suivie d'un script à quatre lettres (zh-Hant) et d'un pays ISO 3166-1 alpha-2 à deux lettres (pt-BR, en-GB). Une erreur courante comme en-UK est signalée avec sa correction (→ en-GB) ; es-419, les langues à trois lettres et les autres codes que Google n'accepte pas sont signalés comme non valides. Chaque ligne du rapport indique le code, son URL, une coche ou une croix et cette remarque. Jusqu'à 20 lignes sont affichées.
• Il vérifie l'auto-référence : l'une des URL listées doit être la page elle-même. La comparaison ignore http ou https, un www. initial, les chaînes de requête et une barre oblique finale.
• Réussite lorsque tous les codes sont valides et que la page se liste elle-même ; s'il n'y a pas de x-default, le message ajoute que ce repli facultatif est absent. Sinon, un avertissement avec « Les versions linguistiques n'incluent pas cette page elle-même » ou « Certains codes de langue ne sont pas valides ».

Langue de la page (priorité basse). Réussite lorsque l'élément <html> possède un attribut lang et que sa langue est affichée ; avertissement s'il est absent.

URL canonique (priorité moyenne). Réussite lorsque la balise canonique pointe vers la page elle-même ; avertissement si elle est absente ou pointe vers une autre adresse, qui est alors affichée.

Ce qu'il ne teste pas

• Les liens retour. L'outil lit une seule page et ne récupère pas les autres versions ; il ne peut donc pas confirmer qu'elles pointent en retour. Ouvrez le code source de chaque version, ou utilisez un crawler, pour vérifier la réciprocité.
• Les en-têtes HTTP et les sitemaps. Seuls les éléments HTML <link> sont lus. Si vous déclarez hreflang dans un sitemap, l'outil ne signale aucune version.
• Les URL absolues et les doublons. Les URL relatives sont résolues au lieu d'être signalées, et si le même code apparaît deux fois, un seul est conservé.
• Les autres pages. Une seule page est vérifiée par analyse. Saisissez l'adresse de chaque version à vérifier (example.com/de/pricing, de.example.com), ou utilisez un crawler pour tout le site.

Lire le résultat

La note globale de A+ à F couvre les 38 contrôles, pondérés par priorité (haute 10, moyenne 5, basse 2 ; les avertissements valent la moitié), avec une liste « À corriger en premier » et un rapport partageable.

Comment corriger chaque problème hreflang

1. Aucune version linguistique n'est déclarée, alors que vous en avez

1. Listez chaque version de la page et son URL complète, par exemple /en/, /de/, /fr/.
2. Choisissez une méthode : balises HTML pour la plupart des sites, le sitemap si les templates sont difficiles à modifier.
3. Générez les balises à partir d'une seule source dans votre code ou votre CMS, afin que chaque version produise le même ensemble complet. Les balises écrites à la main dérivent.
4. Si vous utilisez un plugin multilingue ou la fonctionnalité de marchés intégrée à votre plateforme, il produit généralement hreflang pour vous ; vérifiez que chaque traduction est liée à son original et publiée, car les traductions non liées n'obtiennent aucune balise.
5. Relancez l'outil de vérification hreflang.

2. Les versions linguistiques n'incluent pas cette page elle-même

Ajoutez une ligne pour la page courante avec son propre code. Dans un template, cela signifie généralement que la boucle sur les langues saute la langue courante ; supprimez cette condition. Assurez-vous que l'URL d'auto-référence est l'URL canonique, avec le même protocole, le même hôte et la même convention de barre oblique finale.

3. Certains codes de langue ne sont pas valides

1. Repérez les lignes avec une croix dans le rapport.
2. Corrigez le format : trait d'union et non tiret bas, langue d'abord, région ensuite (en-GB, pas GB-en).
3. Remplacez les codes non pris en charge : en-UK devient en-GB (le rapport le suggère), es-419 devient es ou une liste de codes de pays, les codes à trois lettres deviennent des codes à deux lettres.
4. Vérifiez que le code correspond bien à la langue voulue : be est le biélorusse, cz n'est pas un code de langue (le tchèque est cs), jp n'est pas un code de langue (le japonais est ja), dk n'en est pas un (le danois est da).

4. La page ne déclare pas sa langue

Ajoutez la langue à l'élément racine, par exemple <html lang="en"> ou <html lang="pt-BR">. Google ne s'en sert pas pour détecter la langue, mais les navigateurs, les outils de traduction et les lecteurs d'écran, oui, comme le décrit MDN.

5. La canonique pointe vers une autre adresse

Sur un site multilingue, il s'agit souvent du problème de canonique inter-langues. Remplacez la canonique de chaque version par sa propre URL. Si la canonique pointe vers la même page sous une autre forme (http au lieu de https, ou sans www), faites-la correspondre exactement à votre adresse finale.

6. Les liens retour sont manquants (non testés par l'outil)

Ouvrez deux versions côte à côte et comparez leurs listes hreflang : ce doivent être des ensembles identiques. S'ils diffèrent, la cause est presque toujours le template ou le plugin qui les génère ; corriger le générateur une fois corrige toutes les pages.

Exemple pratique (hypothétique)

L'exemple suivant est hypothétique, ce ne sont pas des données réelles. Kestrel Gear, une marque de plein air inventée, exploite example.com en anglais avec des versions /de/, /fr/ et /es/. Les internautes allemands arrivent toujours sur les pages anglaises. L'outil de vérification hreflang indique :

Canonique : « L'URL canonique pointe vers la page elle-même. » Langue de la page : en.

La croix sur es_ES est une erreur de format. La croix sur en-UK est accompagnée de la remarque « → en-GB » : Google n'accepte pas UK comme région, la page anglaise n'avait donc aucune annotation exploitable. L'affichage du code source de la page allemande révèle un troisième problème : sa canonique pointe vers la page d'accueil anglaise, Google a donc traité /de/ comme un doublon. Les corrections :

1. Remplacement des codes par en, de, fr, es (une version par langue, sans région) et ajout de x-default pointant vers la page d'accueil anglaise.
2. Déplacement de la génération hreflang dans un template partagé, pour que chaque version affiche le même ensemble, y compris elle-même.
3. Ajout d'une canonique auto-référente à chaque version.
4. Suppression d'une redirection par IP qui envoyait automatiquement les visiteurs d'Allemagne vers /de/, remplacée par un bandeau de suggestion.

Une checklist hreflang en 20 minutes

1. Lancez l'outil de vérification hreflang gratuit sur votre page d'accueil et sur chaque version linguistique.
2. Comparez chaque code à ISO 639-1 et ISO 3166-1 alpha-2.
3. Vérifiez que chaque version se liste elle-même et liste toutes les autres.
4. Ouvrez deux versions et vérifiez que les ensembles sont identiques.
5. Vérifiez que la canonique de chaque version pointe vers elle-même.
6. Ajoutez x-default (facultatif, mais utile).
7. Assurez-vous qu'aucune redirection automatique ne masque des versions à Googlebot.

Comment Searvia vous aide

L'outil de vérification hreflang gratuit valide dans un seul rapport partageable les liens hreflang, la langue de la page et la canonique de la page saisie, avec les autres contrôles de l'outil d'audit SEO de site web. Dans un compte Searvia, connectez Search Console pour voir les clics et les positions par pays pour chaque version linguistique, et lancez l'audit de site chaque semaine pour repérer les canoniques qui pointent ailleurs, les titres en double entre versions linguistiques et les pages cassées. Si vous publiez des applications en plus de sites web, notre guide de localisation App Store traite le même problème côté store. Pour la checklist technique complète, consultez le guide d'audit SEO technique.