La configuration hreflang affecte-t-elle l’indexation d’un site multilingue ?

Après la mise en ligne d’un site multilingue, une situation fréquente se présente : la page anglaise peut être trouvée dans les résultats de recherche, tandis que les pages en allemand, en français ou en japonais tardent à être indexées ; ou bien, même lorsqu’une page correspondante apparaît dans les résultats, les utilisateurs effectuant une recherche depuis la France sont systématiquement redirigés vers la version anglaise. Les équipes suspectent souvent d’abord la qualité de la traduction du contenu, les performances du serveur ou le plan de site, avant de découvrir que le problème se concentre sur un ensemble de balises hreflang apparemment anodines.

L’indexation des sites via hreflang est effectivement liée à ce sujet, mais il faut d’abord rectifier un point : hreflang n’est pas un bouton permettant de « soumettre une page à l’indexation ». Il aide principalement les moteurs de recherche à comprendre à quelle langue et à quelle région sont destinées plusieurs pages similaires, afin de sélectionner l’URL la plus appropriée dans un contexte de recherche donné. La possibilité pour une page d’être explorée et indexée dépend toujours de conditions fondamentales telles que son accessibilité, son code d’état, les règles robots, la déclaration de page canonique, la qualité du contenu et les liens internes.

Distinguer d’abord : absence d’indexation ou mauvaise version affichée

Avant toute vérification, il est préférable de dissocier les phénomènes observés. Si une URL dans une certaine langue est totalement introuvable dans les moteurs de recherche, il faut se concentrer sur l’exploration et l’éligibilité à l’indexation ; si l’URL est déjà indexée, mais que les résultats de recherche selon les pays ou les langues affichent une version inadaptée, le problème est alors davantage susceptible de provenir d’un signal hreflang mal traité.

Par exemple, il est normal que les contenus de /en/product-a/, /de/product-a/ et /fr/product-a/ présentent une structure similaire. Les moteurs de recherche doivent s’appuyer sur les balises de langue, la langue de la page, la page canonique et les liens internes pour déterminer qu’il s’agit de versions localisées correspondantes, plutôt que de pages dupliquées. Si la page allemande pointe son canonical vers la page anglaise, ou si elle est définie avec noindex, il sera difficile d’obtenir l’affichage régional attendu, même si les hreflang sont renseignés de manière complète.

Les types de configuration les plus susceptibles de créer de la confusion

Le premier concerne une syntaxe non conforme des codes linguistiques. Les langues utilisent généralement les codes ISO 639-1, tels que en, de et fr ; les régions utilisent les codes ISO 3166-1 Alpha 2, tels que en-US et en-GB. N’utilisez pas en-UK pour désigner l’anglais britannique : le code régional du Royaume-Uni est GB. Par ailleurs, une langue et une région sont reliées par un trait d’union. Bien que l’usage des majuscules et minuscules ne soit généralement pas déterminant, un format uniforme facilite la maintenance.

Le deuxième concerne l’absence de boucle dans les références réciproques. Les pages d’un même groupe linguistique doivent se déclarer elles-mêmes et également pointer vers les autres versions alternatives. Si la page anglaise pointe vers la page allemande, mais que la page allemande ne renvoie pas vers la page anglaise, les moteurs de recherche risquent de ne pas pouvoir considérer durablement ces deux pages comme correspondantes. L’auto-référence est souvent oubliée, notamment lorsque les balises sont générées en masse à partir de modèles.

Le troisième concerne l’incohérence des URL. L’adresse renseignée dans la balise ne comporte pas de barre oblique finale, alors que la page réelle redirige vers une adresse qui en comporte une ; la balise conserve une adresse HTTP alors que le site a déjà été uniformisé en HTTPS ; des pages à paramètres, des pages paginées ou des adresses dont la casse diffère sont mélangées au sein du groupe linguistique. Ces différences apparemment mineures rendent la relation entre les pages d’un même groupe ambiguë. Les hreflang doivent, autant que possible, indiquer l’URL canonique finale renvoyant un code d’état 200, et non une adresse redirigée, en 404 ou bloquée par robots.

Examiner canonical et hreflang conjointement

Une erreur fréquente sur les pages multilingues consiste à faire pointer les canonical de toutes les versions linguistiques vers la page de la langue principale. Cette pratique revient à indiquer d’abord aux moteurs de recherche que « la page allemande n’est qu’une copie dupliquée de la page anglaise », puis à signaler via hreflang qu’« il s’agit d’une version indépendante destinée aux utilisateurs allemands ». Lorsque ces deux signaux entrent en conflit, le second ne peut généralement pas jouer son rôle.

Une configuration de base plus pertinente consiste à faire pointer le canonical de chaque version linguistique réelle, pouvant servir les utilisateurs de manière indépendante, vers elle-même ; les pages correspondantes dans les différentes langues sont ensuite reliées au moyen de hreflang. Ce n’est que lorsqu’une page est réellement une page dupliquée à paramètres, une version imprimable ou une variante sans valeur propre qu’il faut envisager de faire pointer son canonical vers la version principale. La similarité des contenus ne justifie pas à elle seule une canonicalisation systématique entre langues.

Une vérification doit commencer par un seul groupe de pages

Ne commencez pas par analyser l’ensemble du site. Sélectionnez d’abord une page de détail produit ou une page de destination essentielle, listez toutes ses URL dans les différentes langues et vérifiez que chaque adresse peut être ouverte dans un environnement sans connexion ni restriction géographique. Examinez ensuite dans le code source de la page les link rel="alternate", puis contrôlez les codes linguistiques, les URL cibles, la présence de l’auto-référence ainsi que le fait que chaque version renvoie le même groupe linguistique complet.

Vérifiez ensuite les en-têtes de réponse et les déclarations de page. Assurez-vous qu’il n’y a ni noindex, ni X-Robots-Tag erroné, ni règle robots.txt empêchant l’exploration, et que le serveur ne redirige pas de force les visiteurs vers une autre page linguistique selon leur adresse IP. La recommandation automatique de langue peut être conservée, mais les utilisateurs doivent disposer d’une option de changement claire ; si un moteur de recherche est systématiquement redirigé vers la page d’accueil anglaise lorsqu’il accède à une URL allemande, l’indexation et la correspondance linguistique seront affectées.

Examinez également la page canonique, le plan de site et les liens internes. Le XML Sitemap peut compléter les informations hreflang, et l’en-tête HTTP convient aussi aux fichiers non HTML tels que les PDF, mais il est préférable que les mêmes pages ne reçoivent pas de mappages contradictoires provenant de plusieurs sources. Pour les pages web ordinaires, la maintenance dans le <head> HTML est généralement plus intuitive. Le sélecteur de langue, la navigation et les listes de contenu doivent également renvoyer vers les véritables pages dans la langue cible, plutôt que de rediriger systématiquement vers la page d’accueil.

x-default n’est pas obligatoire, mais ne doit pas être mal interprété

Lorsqu’un site dispose d’une page de sélection de langue, d’une page mondiale par défaut ou qu’il est impossible d’établir une correspondance claire avec une langue ou une région donnée, x-default peut être utilisé pour indiquer une URL de secours. Il ne s’agit pas d’une version linguistique pour un pays particulier et il ne peut pas remplacer des déclarations spécifiques telles que en ou zh-CN. Si le site ne comporte pas de page indépendante de sélection de langue, il suffit de désigner directement une page dans une langue par défaut appropriée, tout en veillant à ce que cette page soit accessible, indexable et cohérente dans sa relation avec les autres versions.

Une fois les ajustements terminés, ne jugez pas la réussite uniquement selon la présence des balises dans le code source. Il convient de suivre conjointement l’état d’indexation, l’évaluation de la page canonique et les indications relatives à l’internationalisation dans les outils pour webmasters des moteurs de recherche. Si la page n’est toujours pas indexée, revenez aux résultats d’inspection de l’URL et traitez en priorité les échecs d’exploration, les pages dupliquées exclues, les pages découvertes mais non indexées et autres problèmes similaires ; si la page est indexée mais que l’affichage régional reste instable, continuez à vérifier les différences de contenu linguistique, l’intégrité des liens réciproques et la stratégie de redirection.

En définitive, la valeur de hreflang pour un site multilingue consiste à réduire la probabilité que « la bonne page soit vue par le mauvais utilisateur », et non à contourner les conditions d’indexation. Assurez d’abord que chaque URL linguistique dispose de conditions d’indexation indépendantes, puis reliez les pages au moyen de balises linguistiques cohérentes, réciproques et sans conflit. Les problèmes liés à l’indexation des sites via hreflang seront alors généralement plus faciles à identifier et moins susceptibles de réapparaître lors de l’ajout ultérieur de nouvelles langues.