Le balisage hreflang d’un site multilingue comporte régulièrement des erreurs : comment les diagnostiquer ?

« La page a clairement été traduite, alors pourquoi Google affiche-t-il encore la page anglaise aux utilisateurs allemands ? » De nombreuses entreprises de commerce extérieur rencontrent ce type de problème lorsqu’elles développent leur site web multilingue. Plus fréquemment encore : les développeurs ont ajouté hreflang, mais les outils pour webmasters signalent continuellement des incohérences, des liens retour manquants, ou l’indexation et le trafic organique des pages dans chaque langue ne progressent toujours pas.

Comment résoudre les erreurs récurrentes des balises hreflang sur un site multilingue ? L’essentiel n’est pas de modifier sans cesse une ligne de balise, mais de l’examiner comme un mécanisme par lequel les pages de différentes versions déclarent mutuellement leurs relations. hreflang indique aux moteurs de recherche quels URL correspondent à des versions d’un même contenu destinées à des utilisateurs de langues ou de régions différentes. Il ne garantit pas le classement, mais peut réduire le risque de mauvaise correspondance entre les versions linguistiques et donner davantage de chances aux utilisateurs d’arriver sur une page adaptée à leur lecture, à leurs demandes de renseignements et à leurs commandes.

À confirmer d’abord : votre site a-t-il réellement besoin de hreflang ?

Si le site ne possède que des versions chinoise et anglaise, et que le contenu, la devise, la logistique et les coordonnées sont identiques, avec pour seule différence la langue de l’interface, il suffit généralement d’utiliser zh et en. Si les deux versions sont en anglais, mais que le site américain utilise le dollar américain et les pouces tandis que le site britannique utilise la livre sterling et les millimètres, il est alors plus approprié de les distinguer en en-US et en-GB.

Ne générez pas mécaniquement des dizaines de codes régionaux dans le but de « couvrir davantage de marchés ». Une page qui ne présente aucune différence propre en matière de contenu, de prix, de service ou de parcours de conversion, si elle est artificiellement divisée en versions telles que en-DE et en-FR, augmentera au contraire les coûts de maintenance et empêchera facilement les moteurs de recherche de déterminer les relations entre les pages. Pour les sites B2B de commerce extérieur, créer des versions selon les langues clés et les marchés prioritaires est souvent plus fiable qu’un grand nombre de pages régionales peu différenciées.

La règle la plus souvent négligée : chaque version doit se « reconnaître » mutuellement de façon complète

hreflang ne s’arrête pas au fait de faire pointer la page anglaise vers la page chinoise. Un groupe de versions linguistiques valide doit inclure toutes les pages correspondantes, et chaque URL doit contenir le même ensemble de déclarations, y compris lui-même. Par exemple, pour trois pages produit en chinois, anglais et japonais, les trois doivent toutes répertorier simultanément les liens correspondants pour zh, en et ja.

<link rel="alternate" hreflang="zh" href="https://example.com/zh/product-a/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/product-a/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/product-a/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Parmi eux, x-default convient pour pointer vers une page de sélection de langue, une page d’accueil internationale ou une page par défaut permettant aux utilisateurs de changer eux-mêmes de langue. Il n’est pas obligatoire, mais il est très utile pour les sites de marque qui acquièrent des clients dans plusieurs pays. Notez que la page par défaut elle-même doit être une page réelle, accessible et indexable, et non une adresse intermédiaire qui redirige immédiatement de manière forcée.

Suivre cette chaîne de vérification est plus efficace que de « fixer les balises » en permanence

1. Les URL correspondent-ils un à un, plutôt que tout le site ne pointe vers la page d’accueil ?

Il s’agit du risque caché le plus courant sur les boutiques multilingues et les sites marketing. Une page de détail de produit en anglais doit correspondre aux pages de détail du même produit en chinois et en japonais ; un article de blog en anglais doit correspondre aux articles sur le même sujet dans les autres langues. Si toutes les pages internes anglaises utilisent hreflang vers la page d’accueil chinoise, ou si le contenu traduit n’est pas encore en ligne et pointe temporairement vers une page de catégorie, il est difficile pour les moteurs de recherche de les considérer comme des versions équivalentes.

Pour les contenus qui ne sont pas encore traduits, il vaut mieux ne pas établir de correspondance hreflang dans cette langue plutôt que de les associer arbitrairement. Lors de la création de sites en lot, vérifiez notamment si les produits retirés, les refontes d’URL, les pages de pagination et de filtrage ont laissé des mappages obsolètes.

2. Des liens retour sont-ils manquants ou les listes de versions sont-elles incohérentes ?

Supposons que la page A déclare que la page B est sa version anglaise, mais que la page B ne déclare pas que A est sa version chinoise : c’est ce que l’on appelle couramment un « lien retour manquant ». Une autre situation plus discrète est la suivante : la page chinoise répertorie zh/en/ja, tandis que la page anglaise ne répertorie que zh/en. Même si chaque page semble comporter des balises, les ensembles de langues sont en réalité incohérents, ce qui peut également rendre le signal inefficace.

Il est recommandé de gérer d’abord les relations entre pages dans un tableau : chaque ligne représente un groupe de contenus et chaque colonne une langue ou une région ; une fois les URL confirmés, le système les génère de façon uniforme. Ne vous fiez pas au copier-coller manuel dans différents modèles : dès qu’un site compte plusieurs centaines de pages produit, oublier des modifications devient presque inévitable.

3. Les pages cibles peuvent-elles être explorées et indexées normalement ?

Les URL ciblés par hreflang doivent renvoyer un code d’état 200. Ils ne peuvent pas être des adresses de redirection 301 ou 302, ni des pages 404, des soft 404, des pages bloquées par robots.txt ou portant la balise noindex. Les problèmes fréquents comprennent : la redirection automatique sur mobile vers un autre domaine, les extensions de détection régionale imposant une redirection, les règles CDN réécrivant les URL et les liens d’environnement de test qui sont envoyés par erreur vers le site de production.

Vérifiez également la canonical. En général, la canonical de chaque version linguistique doit pointer vers elle-même ; si la canonical de la page anglaise renvoie vers la page chinoise tout en utilisant hreflang pour indiquer qu’il s’agit d’une version anglaise indépendante, ces deux signaux entreront en conflit. Les moteurs de recherche traitent souvent en priorité les problèmes de canonicalisation, ce qui empêche hreflang de jouer son rôle efficacement.

4. Les codes de langue et de région sont-ils corrects ?

Utilisez les codes de langue à deux lettres ISO 639-1, tels que en, de, fr et zh ; lorsqu’une région doit être spécifiée, utilisez le format « langue-région », tel que en-US, pt-BR et zh-CN. N’utilisez pas uniquement le code pays US, et ne mélangez pas des abréviations personnalisées inexistantes ou non standardisées.

Par ailleurs, l’attribut lang d’une page et hreflang ont des fonctions différentes : le premier aide les navigateurs et les outils d’assistance à comprendre la langue de la page, tandis que le second sert à faire correspondre les versions dans la recherche. Il est recommandé de les maintenir cohérents, mais ils ne peuvent pas se substituer l’un à l’autre.

Où placer les balises : choisissez une des trois méthodes et assurez-en la maintenance

hreflang peut être placé dans le <head> du HTML, ou soumis via les en-têtes de réponse HTTP ou un Sitemap XML. Les sites web d’entreprise classiques et les sites de contenu utilisent majoritairement les balises head ; les fichiers non HTML tels que les PDF peuvent utiliser les en-têtes HTTP ; les boutiques transfrontalières comptant de nombreuses versions linguistiques et un grand volume de pages peuvent générer un Sitemap XML par le système afin de faciliter une gestion centralisée.

Techniquement, plusieurs méthodes peuvent coexister, à condition que les données soient entièrement cohérentes. Dans la pratique, les balises de modèles, les extensions et les Sitemaps sont souvent maintenus par des équipes différentes, ce qui entraîne facilement des conflits du type « un ensemble dans les pages et un autre dans le plan du site ». En l’absence de capacités de gestion clairement définies, il est recommandé de déterminer une source de données principale et de ne pas reproduire la sortie sur les autres canaux.

Après les modifications, ne vous contentez pas de consulter le code source

Ouvrir le code source de la page pour vérifier la présence des balises n’est que la première étape. Il faut également contrôler individuellement si les liens sont des URL absolus, s’ils renvoient 200, si la canonical pointe vers elle-même et si les pages dans les langues correspondantes comportent des déclarations inverses complètes. Pour les sites de grande taille, vous pouvez d’abord sélectionner la page d’accueil, les pages produit principales, les pages de destination prioritaires et les articles à fort trafic comme échantillons, puis exporter les problèmes en lot au moyen d’outils de crawl.

L’outil d’inspection d’URL de Google Search Console peut aider à confirmer si une page peut être explorée et comment la page canonique est déterminée ; les journaux du serveur peuvent aider à observer si les moteurs de recherche accèdent avec succès aux différentes versions linguistiques. Après les modifications, ne vous attendez pas à des changements immédiats : les moteurs de recherche doivent à nouveau explorer et traiter les relations entre les pages. À ce stade, il est plus important de maintenir la stabilité des URL, des balises et du plan du site, et d’éviter de modifier les répertoires aujourd’hui puis de changer les règles de redirection demain.

Intégrez hreflang au processus de création du site, plutôt que de l’utiliser comme correctif après la mise en ligne

La difficulté du SEO multilingue ne réside généralement pas dans la balise elle-même, mais dans la synchronisation entre le contenu, l’architecture des URL, l’avancement des traductions et les modèles techniques. Pour les sites qui ajoutent continuellement des produits, des blogs et des pages de destination publicitaires, il est préférable d’intégrer au processus de publication quatre vérifications : « mappage des versions linguistiques, état d’indexation, canonical et hreflang ».

Les services de création de sites intelligents et de marketing destinés aux activités internationales, comme ceux de YiYingBao, mettent davantage l’accent sur la planification des parcours multilingues dès la phase de structure du site, plutôt que sur la correction page par page après l’apparition d’anomalies d’indexation. Quel que soit le système de création de site utilisé, les entreprises doivent conserver des règles de mappage linguistique maintenables : mettre à jour les balises en même temps que le contenu et supprimer les associations en même temps que les pages sont retirées. Ce n’est qu’ainsi que hreflang peut réellement devenir ce chemin clair et fiable entre les utilisateurs du monde entier et les pages appropriées.