Comment Google explique hreflang et les versions localisées

Les explications de Google Search Central concernant les sites multilingues et multirégionaux reposent sur un point essentiel : le système de recherche doit identifier la langue ou la région ciblée par chaque URL et confirmer que ces pages sont des versions localisées équivalentes, plutôt que plusieurs copies créées par du contenu dupliqué, des redirections automatiques ou des paramètres désordonnés.hreflang est un signal destiné à indiquer aux moteurs de recherche la relation entre des versions alternatives ; ce n’est pas une instruction qui détermine l’indexation, le classement ou le changement forcé de page.

Par conséquent, avant le déploiement, il ne faut pas d’abord se demander « quels codes de langue ajouter », mais confirmer la relation entre les pages. Si une page produit en anglais, une page produit en allemand et une page produit en japonais répondent respectivement aux besoins de lecture de langues différentes, tout en correspondant quant au produit principal, à la description des fonctionnalités et au parcours de conversion, il convient d’établir une relation hreflang. Si plusieurs URL sont générées pour une même page linguistique uniquement en raison de paramètres de suivi publicitaire, de critères de filtrage, de pagination ou d’identifiants de session, elles ne doivent pas être étiquetées mutuellement comme des versions localisées.

Qu’est-ce qu’une « version localisée » selon les sources officielles ?

La localisation ne se résume pas à une traduction mécanique. La documentation de Google distingue les versions linguistiques des versions régionales : une version linguistique répond à la question « dans quelle langue la page est-elle rédigée ? », tandis qu’une version régionale répond à la question « quel pays ou quelle région une même langue cible-t-elle ? ». Par exemple, les pages en anglais destinées aux États-Unis et au Royaume-Uni peuvent toutes deux utiliser en, mais lorsque la devise, la zone de livraison, les informations fiscales, les coordonnées, le stock, les spécifications ou les mentions légales présentent des différences substantielles, elles peuvent utiliser respectivement en-US et en-GB.

À l’inverse, si deux pages ont exactement le même contenu, les mêmes prix et les mêmes conditions de service, mais ne diffèrent que par leur nom de domaine ou leur chemin d’accès, les segmenter de force par pays n’apporte pas nécessairement un signal plus clair. Le code régional doit refléter une différence réelle de contenu ou de service, plutôt que de créer un grand nombre de pages similaires uniquement en fonction des marchés visés. Pour les sites B2B, les paramètres produits, les quantités minimales de commande, les champs des formulaires de demande et le périmètre de livraison déterminent souvent si une page constitue réellement une version destinée à un marché distinct ; pour les boutiques transfrontalières, la devise, les zones de vente et les règles logistiques constituent plus facilement des différences de localisation identifiables.

Google souligne également que le texte principal visible de la page doit correspondre à la langue déclarée. Remplacer uniquement la navigation, le pied de page ou quelques libellés de boutons, tout en conservant dans une autre langue la description principale, la documentation technique et les informations d’achat, ne constitue pas une version linguistique fiable. La détermination de la langue ciblée par les résultats de recherche repose principalement sur le contenu de la page ; l’attribut lang aide les navigateurs et les technologies d’assistance à comprendre le document, mais ne peut pas remplacer un texte principal lisible dans la langue cible.

Les trois conditions de validité de hreflang

Premièrement, la relation alternative doit être réciproque et complète. Lorsqu’une page A déclare que B est sa version allemande, la page B doit également déclarer que A est sa version anglaise ; en l’absence de lien retour, le système de recherche peine à confirmer qu’il s’agit d’une relation correspondante maintenue. Les différentes versions linguistiques doivent se référencer mutuellement au sein d’un même groupe, et chaque page doit inclure sa propre entrée hreflang. L’autoréférence n’est pas décorative : elle garantit que chaque URL définit de manière cohérente le groupe linguistique auquel elle appartient.

Deuxièmement, les codes doivent utiliser des combinaisons de langue et de région valides. La partie langue utilise les codes ISO 639-1, tels que de, ja et zh ; la partie région utilise les codes ISO 3166-1 Alpha 2, tels que DE, JP et CN. La langue est placée en premier, suivie de la région, les deux étant reliées par un trait d’union. de-DE peut désigner l’allemand d’Allemagne, tandis que de désigne l’allemand sans région spécifiée. Utiliser uniquement un code pays comme code langue, employer des abréviations de marché personnalisées ou inverser l’ordre de la langue et de la région fera perdre à la déclaration sa signification attendue.

Troisièmement, l’URL cible doit être une page canonique accessible aux utilisateurs et aux robots d’exploration. Si hreflang pointe vers une URL qui redirige, renvoie une erreur, est empêchée d’être explorée par des règles robots ou dont la canonical pointe vers une autre adresse, les signaux entrent en conflit. Les retouches fréquentes surviennent après la mise en ligne : l’équipe de contenu modifie le chemin d’une page produit, tandis que le développement conserve les anciens mappages linguistiques ; ou une boutique redirige vers la page d’accueil les pages sans stock après avoir changé le stock selon les régions. Ces modifications détruisent le groupe alternatif initial.

Trois méthodes d’implémentation : choisissez-en une et maintenez-la de façon stable

Google permet d’ajouter dans le <head> HTML une balise <link rel="alternate" hreflang="..." href="...">, mais prend également en charge les en-têtes de réponse HTTP et la soumission via un Sitemap XML. Ces trois méthodes expriment le même type de relation ; il suffit généralement de choisir celle qui correspond le mieux à l’architecture de publication. Pour les pages HTML ordinaires, les balises head sont faciles à générer à partir du modèle de page ; les documents non HTML tels que les PDF sont mieux adaptés aux en-têtes HTTP ; lorsque le nombre de versions linguistiques est important et qu’elles sont gérées par un système de contenu centralisé, le Sitemap peut réduire les sorties répétées dans les modèles de page.

Il n’est pas recommandé de considérer plusieurs sources comme des mécanismes de compensation mutuelle. Si les ensembles d’URL ou les codes diffèrent entre le HTML, le Sitemap et les en-têtes de réponse, le diagnostic perd toute base claire. Quelle que soit la méthode adoptée, un tableau de mappage au niveau de la page doit servir de source unique de vérité : l’URL d’origine, l’URL canonique, le code langue, le code région, la version correspondante et le statut de retrait doivent être mis à jour de manière synchronisée. Lorsqu’un produit est retiré, qu’un catalogue est migré ou qu’un nom de domaine est modifié, ce tableau de mappage est plus fiable que le remplacement temporaire et massif de code.

Rôle et limites de x-default

x-default sert à désigner la page par défaut lorsqu’il n’existe pas de correspondance linguistique ou régionale plus adaptée. Il est couramment utilisé pour les pages de sélection de langue, les pages d’entrée mondiales ou les versions par défaut permettant aux visiteurs de choisir eux-mêmes leur marché. Ce n’est pas une étiquette fixe pour la « page d’accueil internationale », et il ne doit pas remplacer la déclaration hreflang de chaque page linguistique spécifique.

Une prudence particulière est requise lorsque des pages de géolocalisation automatique sont marquées par x-default. Google recommande explicitement d’éviter de rediriger de force les robots d’exploration et les utilisateurs vers des pages différentes selon l’adresse IP ou la langue du navigateur. Les redirections automatiques empêchent les utilisateurs d’accéder facilement à l’URL souhaitée et peuvent aussi empêcher les robots d’obtenir de manière stable le contenu des différentes versions. Une approche plus sûre consiste à conserver des URL de version accessibles et à fournir sur la page un sélecteur visible de langue ou de région ; les préférences ne doivent être enregistrées qu’après un choix explicite de l’utilisateur.

canonical et hreflang ne peuvent pas être configurés indépendamment

canonical résout la question de savoir quelle version est préférée parmi plusieurs URL similaires, tandis que hreflang définit la correspondance entre différentes versions linguistiques ou régionales. Les deux sont souvent confondus. Même si une page anglaise et une page française ont une structure identique, la page française ne doit pas avoir pour canonical la page anglaise sous prétexte que leur contenu est similaire ; cela indiquerait au moteur de recherche que la page française n’est pas une page préférée indépendante, ce qui contredit sa déclaration en tant que version alternative française.

Une configuration plus appropriée est la suivante : chaque page linguistique ou régionale utilise une canonical autoréférencée, puis hreflang établit les liens avec les autres versions équivalentes. Ce n’est que lorsqu’une même version linguistique présente des paramètres d’URL, des différences de majuscules et minuscules, des barres obliques finales, des pages imprimables ou des chemins dupliqués qu’une canonical doit être choisie au sein de cette langue. Organiser d’abord la canonicalisation, puis établir le mappage international, permet d’éviter de confondre un problème de nettoyage d’URL avec un problème de version linguistique.

Les signaux à surveiller après la publication

La validation ne doit pas se limiter à vérifier si les balises apparaissent dans le code source. Commencez par examiner un groupe de pages : chaque href renvoie-t-il une réponse réussie indexable, mène-t-il directement à l’URL canonique finale, la page contient-elle un lien retour, et le code langue correspond-il au texte principal ainsi qu’aux conditions du marché ? Vérifiez ensuite le plan du site, le rendu des modèles et la couche de cache afin de confirmer que les visites depuis différentes régions ne produisent pas des ensembles hreflang différents.

Dans Search Console, les anomalies liées au ciblage international, les pages alternatives détectées mais non traitées correctement et les résultats de sélection des pages canoniques peuvent tous servir à identifier les problèmes. Il faut ici distinguer deux phénomènes : le fait que les résultats de recherche n’affichent pas la page de la région cible ne signifie pas nécessairement que hreflang est défaillant, car la langue de la requête, la localisation de l’utilisateur, la pertinence de la page et son état d’indexation influencent tous l’affichage ; en revanche, lorsqu’une page alternative ne peut pas être explorée pendant longtemps, que les références réciproques sont absentes ou que la canonical pointe vers une page dans une autre langue, il s’agit de signaux de configuration à corriger en priorité.

La valeur de hreflang réside dans la réduction des suppositions du système de recherche concernant les relations entre les versions linguistiques. La condition préalable n’est pas d’avoir suffisamment de balises, mais que les URL, la langue du contenu, la stratégie de canonicalisation et la portée réelle des services du site renvoient à une même réalité.