Un site qui publie plusieurs langues sans balisage hreflang correct s’expose à un problème silencieux : Google indexe une version, mais l’affiche parfois au mauvais public. Un lecteur en Espagne tombe sur la page anglaise, un lecteur allemand sur la version française. Le contenu existe, il est même de qualité, mais il n’atteint pas la bonne audience. Le hreflang est le mécanisme qui règle ce problème, et sa mise en œuvre tolère peu d’approximations.
À quoi sert réellement l’attribut hreflang
L’attribut hreflang indique aux moteurs de recherche qu’une page possède des équivalents dans d’autres langues ou pour d’autres régions, et précise l’URL de chacun. Il ne traduit rien et n’influence pas directement le classement d’une page : il oriente uniquement le choix de la version présentée à un internaute donné, en fonction de la langue de son interface ou de sa zone géographique de recherche.
Deux briques composent chaque déclaration : un code de langue ISO 639-1 (fr, en, es, de), éventuellement complété d’un code de région ISO 3166-1 (fr-ca pour un français canadien distinct d’un français de France). Ajouter une région n’a de sens que si le contenu diffère réellement d’une zone à l’autre ; sinon, le code de langue seul suffit et limite les risques d’erreur.
Deux méthodes, jamais les deux en même temps
| Méthode | Avantage | Limite |
|---|---|---|
Balises <link> dans le <head> | Simple à vérifier page par page, aucun fichier séparé à maintenir | Alourdit le poids du <head> sur les sites à fort volume de pages |
| Entrées dans le sitemap XML | Centralise toutes les correspondances, pertinent au-delà de quelques milliers de pages | Moins lisible à l’œil, erreurs plus difficiles à repérer sans outil dédié |
En-tête HTTP Link | Seule option viable pour un contenu non HTML (PDF notamment) | Rarement nécessaire pour un site éditorial classique |
Google accepte de combiner ces méthodes techniquement, mais le recommande rarement : dès que deux sources se contredisent sur la même URL, le moteur doit arbitrer, et l’arbitrage ne favorise pas toujours l’intention réelle du site. Choisir une seule méthode et s’y tenir sur l’ensemble du domaine évite ce risque.
La règle qui casse le plus souvent : les liens retour
Chaque page d’un groupe de traductions doit déclarer non seulement ses équivalents, mais aussi se déclarer elle-même. Si la page française pointe vers la version anglaise, la version anglaise doit pointer en retour vers la française — et vers toutes les autres langues du même groupe. Un lien manquant dans un seul sens invalide fréquemment le groupe entier aux yeux d’un moteur de recherche, sans qu’aucune erreur ne s’affiche de façon évidente côté site.
<link rel="alternate" hreflang="fr" href="https://exemple.com/fr/page/" />
<link rel="alternate" hreflang="en" href="https://exemple.com/en/page/" />
<link rel="alternate" hreflang="es" href="https://exemple.com/es/page/" />
<link rel="alternate" hreflang="de" href="https://exemple.com/de/page/" />
<link rel="alternate" hreflang="x-default" href="https://exemple.com/" />
Ce même bloc doit apparaître, à l’identique dans son ensemble de langues, sur chacune des quatre pages. La ligne x-default désigne la version montrée à un visiteur dont la langue ou la région ne correspond à aucune des versions déclarées : une page de sélection de langue, ou à défaut la version la plus neutre du site.
Un hreflang à sens unique n’est pas un hreflang incomplet : c’est un hreflang que les moteurs de recherche ignorent purement et simplement pour l’ensemble du groupe.
Les URL déclarées doivent être accessibles, pas seulement correctes
Une URL listée dans un bloc hreflang ne doit jamais rediriger, renvoyer une erreur 404, ni être elle-même canonicalisée vers une autre adresse. Ces trois cas sont fréquents après une refonte de site : les anciennes URL de langue restent référencées dans un sitemap qui n’a pas été régénéré, alors que le contenu a déjà basculé sur de nouvelles adresses.
La balise rel="canonical" de chaque version linguistique doit également pointer vers elle-même, jamais vers la version française jugée « principale ». Un canonical croisé entre langues revient à demander aux moteurs de recherche de n’indexer qu’une seule version, ce qui annule l’intérêt même du hreflang.
Un outil de validation externe (Merkle ICS, ou l’inspection d’URL de Search Console page par page) reste plus fiable qu’une relecture manuelle du code source pour repérer un lien retour manquant sur un site de plusieurs dizaines de pages traduites.
Sous-répertoires, sous-domaines ou domaines séparés
Le hreflang fonctionne quelle que soit l’architecture choisie pour héberger les langues, mais cette architecture change l’effort d’entretien. Une structure en sous-répertoires (/fr/, /en/) consolide l’autorité du domaine sur une seule adresse et reste la plus simple à maintenir pour une équipe réduite. Des sous-domaines par langue séparent davantage les configurations techniques, ce qui aide surtout quand chaque marché dispose d’une équipe éditoriale autonome. Des domaines distincts par pays (.fr, .de) ne se justifient en général que pour une présence légale ou commerciale locale, rarement pour la seule traduction d’un contenu éditorial.
Le choix de l’architecture ne dispense d’aucune des règles précédentes : liens retour complets, URL accessibles, canonical auto-référencé. Un domaine séparé par pays ajoute même un risque supplémentaire, celui d’oublier la déclaration croisée entre deux domaines distincts alors qu’elle est plus naturelle à l’œil entre deux sous-répertoires d’un même site.
Les erreurs de code et le contrôle après publication
Un code de langue ou de région mal formé n’affiche aucune erreur visible sur le site, mais fait ignorer la déclaration par les moteurs de recherche. Les cas les plus fréquents rencontrés en audit :
| Erreur constatée | Ce qui est attendu |
|---|---|
Code région seul, sans langue (hreflang="ca") | Toujours langue puis région (hreflang="fr-ca") |
Confusion entre code pays et code langue (hreflang="uk") | Code langue ISO 639-1 suivi du code pays ISO 3166-1 (hreflang="en-gb") |
| Page qui ne se déclare pas elle-même dans son propre bloc | Chaque page inclut une ligne hreflang pointant vers sa propre URL |
Un seul x-default pour tout le site, jamais mis à jour | Un x-default cohérent par groupe de pages traduites |
Le format attendu place systématiquement le code de langue en minuscules avant un éventuel code de région ; la casse n’a pas d’incidence pour les moteurs de recherche, mais la convention en minuscules évite les copier-coller incohérents entre équipes.
Un contrôle régulier, plutôt qu’une vérification unique au lancement, reste la meilleure protection contre ces erreurs : l’ajout d’une langue, une refonte partielle ou un changement d’outil de traduction sont les trois moments où un lien retour se perd le plus souvent. Les données structurées en JSON-LD se déclarent séparément sur chaque version linguistique : un schéma Article ou NewsArticle anglais ne doit pas décrire un contenu français, même si les deux pages partagent la même structure. Côté suivi, chaque version doit apparaître comme une propriété distincte dans les outils d’analyse pour permettre de vérifier, langue par langue, si le trafic organique correspond bien à la zone géographique visée — un contrôle que l’on retrouve dans le pilotage GA4 et Search Console d’un site déjà en place.
Ce qu’il faut retenir
Le hreflang ne demande pas une configuration complexe, mais une configuration exacte : une seule méthode d’implémentation, des liens retour complets et vérifiés dans les deux sens, une balise x-default explicite, et des URL toutes accessibles sans redirection ni canonical croisé. La plupart des problèmes rencontrés en audit viennent d’un oubli ponctuel après une mise à jour de contenu, pas d’une erreur de conception initiale.
Sur les projets multilingues que j’ai accompagnés, le hreflang cassé n’est presque jamais signalé par un client : il se traduit juste par un trafic organique anormalement faible sur une langue précise, découvert des mois plus tard en creusant les rapports Search Console par pays. Je recommande de le tester à chaque publication de traduction, pas seulement à la mise en ligne du site. — Simon Janvier
Pour aller plus loin : la documentation officielle de Google Search Central sur les URL localisées détaille les cas particuliers, notamment pour les sites qui combinent plusieurs domaines par langue.
