Comment résoudre les erreurs récurrentes des balises hreflang sur un site multilingue

Les balises hreflang d’un site multilingue génèrent des erreurs à répétition, souvent pas uniquement parce qu’« une ligne de code est erronée ». Cela affecte directement la capacité des moteurs de recherche à afficher la bonne version linguistique ou régionale aux bons utilisateurs : une page en anglais peut être proposée à des utilisateurs allemands, un site national peut être remplacé par le site principal, ou une page peut être indexée sans parvenir à obtenir durablement du trafic organique sur son marché cible.

Pour traiter ce type de problème, ne vous précipitez pas pour corriger une à une les erreurs signalées dans Search Console. Il est plus efficace de confirmer d’abord l’architecture linguistique du site, puis de vérifier que les relations entre les balises forment une boucle complète, et enfin d’éliminer les conflits entre les URL, les redirections et l’état d’indexation. De nombreuses erreurs qui semblent indépendantes proviennent en réalité d’un même problème structurel.

À déterminer d’abord : vos pages ont-elles réellement besoin de hreflang ?

hreflang convient aux pages dont le contenu correspond étroitement, mais qui s’adressent à des utilisateurs de langues ou de régions différentes. Par exemple, un même équipement industriel dispose de pages détaillées en anglais, français et espagnol ; une même page produit propose pour les États-Unis, le Royaume-Uni et l’Australie des devises, des informations de livraison ou des informations de conformité différentes.

S’il s’agit seulement d’une page chinoise à laquelle un plugin de traduction automatique a été ajouté, que le contenu de la page ne dispose pas d’URL indépendantes et stables, ou que les pages de langues différentes redirigent en réalité toutes vers la même adresse, l’ajout de hreflang ne résout généralement pas le problème. Les moteurs de recherche doivent pouvoir explorer, accéder à et indexer chaque version afin de comprendre leurs relations de substitution.

En particulier pour les sites B2B de commerce extérieur, une erreur fréquente consiste à faire pointer toutes les versions linguistiques vers la page d’accueil, ou à ne baliser dans chaque page détaillée de produit que les versions linguistiques de la page d’accueil. hreflang doit être fondé sur une correspondance « page à page » : la page anglaise du produit A doit être associée aux pages allemande, française ou japonaise du produit A, et non reliée de manière générale aux pages d’accueil de chaque langue.

L’erreur la plus fréquente : les balises réciproques ne forment pas une boucle complète

hreflang établit une relation bidirectionnelle, voire multidirectionnelle. Si une page anglaise déclare une page allemande comme version alternative, la page allemande doit également déclarer en retour la page anglaise ; s’il existe aussi des versions française et italienne, chaque page participante doit déclarer un ensemble complet et cohérent de versions. Ajouter des balises uniquement sur la page de langue principale, sans lien retour depuis les autres pages linguistiques, est l’un des problèmes les plus courants.

Un groupe de pages conforme comprend généralement trois niveaux de relations :

• chaque page déclare sa propre version linguistique, c’est-à-dire un hreflang autoréférent ;
• chaque page renvoie vers les autres versions linguistiques ou régionales du même contenu ;
• l’ensemble des URL répertoriées par toutes les pages d’un même groupe reste cohérent.

Par exemple, les pages produit en anglais, allemand et français appartiennent au même groupe. La page anglaise répertorie EN, DE, FR ; la page allemande répertorie également EN, DE, FR ; il en va de même pour la page française. Les codes de langue peuvent différer, mais les ensembles de pages vers lesquels ils pointent ne doivent pas comporter d’omissions ni inclure d’autres pages.

Certains CMS ne mettent à jour que la page actuelle après l’ajout d’une langue, sans générer simultanément de nouveaux liens sur les anciennes pages linguistiques ; d’autres sites, après une migration de domaine ou une modification des règles d’URL, ont mis à jour les hreflang dans le plan de site tout en conservant les anciennes adresses dans les balises head des pages. Cela peut entraîner des problèmes de « lien retour manquant » ou d’« impossibilité de confirmer la page alternative ».

Un code de langue correct ne garantit pas que le code régional le soit aussi

Les valeurs hreflang utilisent généralement un code de langue, auquel un code régional est ajouté si nécessaire, par exempleen, de, fr-CA, es-MX. Le problème vient souvent de la confusion entre langue, pays et marché.

Une page en allemand destinée aux utilisateurs allemands peut utiliserde-DE, tandis qu’une page en allemand destinée à l’Autriche peut utiliser de-AT. Toutefois, si le contenu, les prix et les modalités de livraison des deux pages sont strictement identiques et que les pages ne sont dupliquées que pour couvrir différents pays, créer de force plusieurs versions régionales n’apporte pas nécessairement de bénéfices ; cela peut au contraire accroître la complexité de maintenance et de l’évaluation des contenus dupliqués.

À l’inverse, si des pages en anglais servent respectivement les États-Unis et le Royaume-Uni, et que la devise, les unités de mesure, les conditions de service ou les coordonnées diffèrent, il convient d’utiliser clairement en-US et en-GB. Indiquer seulement en n’est pas non plus une erreur, mais cela désigne une version générale « applicable à tous les utilisateurs anglophones » et ne permet pas de distinguer précisément les versions régionales.

Au niveau du code, évitez les formats inventés, par exemple en-UK pour désigner l’anglais du Royaume-Uni. Les codes de langue et de région doivent être conformes aux normes et rester uniformes sur l’ensemble du site. Pour une version de secours lorsqu’il est impossible de déterminer la langue ou la région de l’utilisateur, vous pouvez utiliser x-default, qui pointe généralement vers une page de sélection de langue ou une page mondiale par défaut. Il ne peut pas remplacer une version linguistique spécifique, et toutes les pages ne doivent surtout pas pointer uniquement vers x-default.

Lorsque les erreurs se répètent, vérifiez en priorité si les URL sont indexables

Les moteurs de recherche n’acceptent pas les URL hreflang « présentes en apparence mais inutilisables en pratique ». Chaque adresse figurant dans les balises doit renvoyer une page officielle accessible, et non une page de redirection, une page 404, une page dont l’exploration est interdite par robots ou une page comportant noindex.

Les situations suivantes sont particulièrement fréquentes sur les sites multilingues :

• hreflang indique encore des adresses http, alors que le site a entièrement migré vers HTTPS ;
• l’URL contient des paramètres de session, de suivi ou de filtrage, tandis que canonical pointe vers une autre adresse ;
• après avoir accédé à une URL dans une certaine langue, l’utilisateur est redirigé de force vers une autre langue par des règles IP ou de langue du navigateur ;
• la page a été supprimée ou refondue, mais les balises pointent encore vers l’ancien lien produit ;
• la canonical d’une page dans une langue donnée pointe vers la page anglaise, conduisant les moteurs de recherche à la considérer comme une page dupliquée plutôt que comme une version indépendante.

Parmi ces situations, les redirections forcées sont les plus faciles à négliger. Afin d’« automatiser la localisation », certains sites redirigent directement les visiteurs venant de France d’une URL anglaise vers une URL française. Cela peut sembler pratique pour les utilisateurs ordinaires, mais les moteurs de recherche risquent également d’être redirigés lorsqu’ils explorent la page anglaise et de ne plus pouvoir valider correctement cette page ni ses relations linguistiques. Une approche plus fiable consiste à conserver l’URL d’origine accessible volontairement par l’utilisateur et à fournir un sélecteur de langue ou une suggestion, plutôt que d’effectuer une redirection inconditionnelle.

canonical et hreflang doivent également être cohérents. Chaque page pouvant participer aux liens réciproques entre langues doit généralement avoir une canonical pointant vers sa propre URL canonique. Si la canonical d’une page française pointe vers la page anglaise tout en étant définie dans hreflang comme version alternative française, les deux signaux se contredisent et les moteurs de recherche ignorent souvent en priorité une partie d’entre eux.

Choisissez une seule méthode d’implémentation afin d’éviter que plusieurs sources ne se chevauchent

hreflang peut être placé dans le head des pages HTML ou soumis via un XML Sitemap ; certains fichiers non HTML peuvent également utiliser les en-têtes de réponse HTTP. Pour la plupart des sites officiels d’entreprise et des boutiques transfrontalières, le head HTML ou le Sitemap est suffisant. L’essentiel n’est pas de multiplier les méthodes, mais d’avoir une source de données unique et des mises à jour synchronisées.

Si le head des pages, le Sitemap et un plugin du back-office génèrent tous des hreflang, mais que leur contenu diffère, le diagnostic devient très difficile. Par exemple, les liens dans la page pointent vers de nouvelles URL, le plan de site conserve les anciennes URL, et un plugin SEO tiers ne reconnaît qu’une partie des langues ; il en résulte un ensemble de relations qui semblent toutes « balisées », mais qui ne peuvent pas être validées en pratique.

Lorsque le site est de petite taille et que les versions linguistiques des pages sont stables, la génération des balises dans le head est plus intuitive ; pour les boutiques ou les sites de contenu comportant de nombreux SKU, de nombreuses langues et des mises à jour groupées fréquentes, il est plus approprié de générer un XML Sitemap à partir d’une source de données unifiée. Quelle que soit la méthode adoptée, les relations entre langues, régions et pages doivent être maintenues comme une partie des données du site, plutôt que de reposer sur la copie manuelle de balises par les équipes opérationnelles.

Validez à l’aide d’un « groupe de pages » plutôt que de corriger aveuglément tout le site

Lors de la correction, il est recommandé de sélectionner d’abord un groupe de pages représentatif, tel qu’une page détaillée de produit à fort trafic ou une page de service principale, et de placer toutes ses versions dans une même grille de contrôle. Vérifiez point par point les URL, les codes d’état, les canonical, l’état d’indexation, les codes de langue, les références réciproques et les destinations x-default. Une fois ce groupe de pages entièrement validé, examinez ensuite les modèles et la logique de génération par lots.

Ne considérez pas hreflang comme un outil de positionnement. Il aide principalement les moteurs de recherche à faire correspondre les versions entre des pages multilingues déjà existantes ; il ne peut pas compenser une mauvaise qualité de traduction, un contenu de page trop limité, un site impossible à explorer ou l’absence de demande de recherche sur le marché cible. Pour les entreprises qui souhaitent acquérir durablement des clients à l’international, les règles d’URL multilingues, les processus de production de contenu, les règles canonical et la source de données hreflang doivent être conçus de manière unifiée dès la phase de création du site ; attendre que le nombre de pages ait déjà augmenté pour les corriger une à une coûtera beaucoup plus cher.

Lorsque les erreurs persistent, vérifiez d’abord si les pages signalées restent des pages officielles importantes du site. Il n’est pas nécessaire de restaurer d’anciennes relations uniquement pour faire disparaître les avertissements historiques dans les rapports concernant des URL déjà supprimées, redirigées ou non indexées. En concentrant les efforts de maintenance sur les groupes de pages essentiels, indexables, capables de convertir et destinés au marché cible, hreflang pourra réellement jouer son rôle.