Comment configurer correctement les balises hreflang sur WordPress (et les erreurs qui peuvent les rendre inopérantes)

Réponse courte : pour configurer correctement les balises hreflang sur WordPress, chaque version linguistique d'une page doit disposer d'un ensemble complet de balises hreflang qui :

1. se désignent eux-mêmes,
2. indiquer toutes les versions alternatives
3. se renvoient l'un à l'autre, et
4. inclure un x-par défaut en dernier recours, en utilisant tous des codes de langue valides et des URL absolues.

Si vous vous trompez sur l'un de ces éléments, les moteurs de recherche ignorent l'ensemble. Bien que cela rende le processus fastidieux, la solution la plus simple consiste à utiliser un plugin qui génère automatiquement ces balises. Il est toutefois utile de connaître les règles afin de pouvoir vérifier vous-même le résultat.

Mettons les choses au clair : ajouter des balises hreflang et les ajouter correctement sont deux choses bien distinctes. WordPress n'ajoute pas automatiquement les balises hreflang ; c'est pourquoi la plupart des gens ont recours à un plugin ou à un snippet, voient les balises apparaître dans le code source de la page et pensent que le tour est joué. Ce qui, si vous avez utilisé un plugin bien conçu, devrait suffire.

Mais si vous constatez soudainement que le trafic provenant d'une version traduite commence à stagner et que la mauvaise langue apparaît dans les résultats de recherche, ce sont là de bons indices qui vous inciteront à vérifier votre mise en œuvre de la balise hreflang.

En général, les balises sont bien présentes ; il y a juste de fortes chances qu'elles soient erronées d'une manière ou d'une autre – mais ce n'est rien que vous ne puissiez corriger vous-même.

Ce guide explique ce que signifie réellement le terme « correct », passe en revue les erreurs les plus courantes et vous indique comment vérifier votre configuration. Si vous souhaitez découvrir en détail toutes les méthodes permettant d'ajouter des balises hreflang à WordPress (plugins, outils de référencement et modification manuelle du code), notre guide complet sur les balises hreflang dans WordPress aborde ce sujet de manière approfondie.

Que signifie réellement un attribut « hreflang » correct ?

Hreflang est un attribut HTML qui indique aux moteurs de recherche la langue et, éventuellement, la région auxquelles une page est destinée, afin qu'ils puissent proposer la bonne version à la bonne personne (fr-FR pour un visiteur américain, fr-FR (pour le Royaume-Uni). Google considère un ensemble de balises hreflang comme un seul groupe, et un groupe n'est valide que si toutes ces règles sont respectées simultanément.

1. Chaque page renvoie à elle-même

Chaque version linguistique doit comporter une balise hreflang renvoyant vers sa propre URL, ainsi que des balises pour toutes les autres versions. La page en anglais mentionne l'anglais (elle-même), le français, l'allemand et x-par défaut. L'inclusion de l'auto-référence est indispensable ; sinon, le groupe est incomplet et vous rencontrerez immédiatement des erreurs hreflang.

2. Les balises sont réciproques (balises de retour)

Si votre page en anglais renvoie vers la version française, la version française doit à son tour renvoyer vers la version anglaise. On appelle cela des balises de renvoi, et elles doivent être présentes dans les deux sens sur chaque page du cluster. Lorsqu'une balise de renvoi est manquante, Google peut supprimer complètement l'annotation plutôt que de se livrer à des conjectures.

3. Il y a un x-default

Le x-par défaut La balise sert de solution de secours pour les visiteurs dont la langue ou la région n'est pas explicitement ciblée. Elle renvoie généralement vers votre page d'accueil ou vers un menu de sélection de la langue. Tous les modèles et outils de référencement la signalent, et ce à juste titre : sans elle, les moteurs de recherche n'ont aucune valeur par défaut sur laquelle se rabattre.

4. Les codes de langue et de région sont valides

Les codes de langue sont conformes à la norme ISO 639-1 (fr, fr, de, etc., zh). Le code de région facultatif respecte la norme ISO 3166-1 Alpha-2 (US, GB, FR), et les deux éléments s'associent sous la forme langue-RÉGION, comme en-GB. Un code de région utilisé seul n'est pas valide ; la langue doit toujours précéder le code de région.

Veillez à ne pas présumer des codes de langue et consultez toujours la liste au préalable. Par exemple, si vous souhaitez définir votre page en anglais britannique, le code est fr-FR plutôt que fr-FR. Le code est entièrement incorrect ; « UK » est le code de langue de l'ukrainien (et son code pays est UA), de sorte que ce code correspond davantage à une classification par langue qu'à une classification par région.

5. Les URL sont absolues

Les URL hreflang doivent comporter l'adresse complète, y compris le protocole (https://example.com/fr/page/), et non un chemin relatif tel que /fr/page/. Les URL relatives constituent l'une des causes les plus courantes d'erreurs silencieuses.

6. La liste des balises canoniques

La balise canonique de chaque version doit pointer vers elle-même, et non vers la version originale. Une balise canonique qui redirige la page française vers la page anglaise indique à Google d'ignorer la version française, ce qui annule le travail effectué avec les balises hreflang et fait en sorte que la mauvaise page soit classée pour un mot-clé dans la mauvaise langue. C'est pourquoi les balises canoniques et hreflang autoréférencées vont de pair.

Un exemple correct

Un ensemble valide se présente comme suit dans le <head> d'une page en anglais qui existe également en français, avec une solution de secours x-default :

<link rel="alternate" hreflang="en" href="https://example.com/page/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page/" />

La version française est disponible à l'adresse https://example.com/fr/page/ comporte les trois mêmes balises, renvoyant vers les mêmes URL. C'est cette symétrie qui rend le cluster valide. Choisissez un emplacement où placer les balises (le <head>, un plan de site XML ou des en-têtes HTTP) et veillez à la cohérence. Sur WordPress, le <head> c'est le choix le plus courant.

Les erreurs qui compromettent votre balise hreflang

La plupart des configurations hreflang défectueuses présentent un de ces problèmes, même si les balises semblent correctes dans le code source de la page.

• Il manque des balises de retour. La page A renvoie vers B, mais B ne renvoie pas vers A. L'absence de balises réciproques est la raison la plus courante pour laquelle Google ignore une configuration par ailleurs correcte.
• Pas d'autoréférence. Une page énumère ses variantes, mais oublie de s'inclure dans la liste. C'est un peu comme si, en comptant le nombre de personnes dans le groupe pour une réservation au restaurant, on oubliait de se compter soi-même.
• URL relatives. /fr/page/ au lieu de https://example.com/fr/page/. Même si cela semble logique, cela ne fonctionne tout simplement pas.
• Codes incorrects. « en-UK » au lieu du code correct « en-GB », des traits de soulignement à la place des tirets (en_US), ou des codes qui n'existent pas. Vérifiez toujours vos codes ; c'est le moyen le plus simple d'éviter les erreurs.
• Conflits de balises canoniques. La balise canonique d'une page traduite renvoie vers la version originale, ce qui indique aux moteurs de recherche que la traduction n'est pas la page à indexer.
• Deux méthodes à la fois. Un plugin multilingue génère des balises hreflang, tandis qu’un autre plugin SEO ou snippet manuel snippet un deuxième ensemble, qui entre en conflit avec le premier. Vous vous retrouverez alors avec des balises en double ou incohérentes qui semeront la confusion chez les robots d’indexation. N’utilisez qu’une seule méthode.
• Non x-par défaut. Il n'existe aucune solution de secours pour les langues et les régions non prises en charge.

Si vous ajoutez manuellement des balises hreflang sur un nombre important de pages, chacune d'entre elles s'ajoute au nombre total de vos pages, ce qui explique pourquoi la configuration manuelle devient rapidement difficile à gérer.

Comment vérifier que votre configuration est correcte

Vérifiez que les balises sont valides avant de leur accorder votre confiance, et non après que les classements aient changé.

Tout d'abord, une petite précision : Google a supprimé le rapport dédié au ciblage international dans Search Console dès 2022; l'ancienne recommandation consistant à « consulter le rapport hreflang dans Search Console » n'est donc plus d'actualité. Google continue de prendre pleinement en charge et d'analyser les balises hreflang ; le rapport a simplement été déplacé ailleurs. Voici les outils qui fonctionnent désormais :

• VérificationGoogle Search Console . Vérifiez que les URL alternatives renvoient un statut 200, qu'elles sont indexées et qu'elles ne sont pas remplacées par une URL canonique inattendue.
• Screaming Frog SEO Spider. Il extrait les groupes hreflang, suit les URL alternatives et signale les balises de retour manquantes, les codes invalides et les incohérences sur l'ensemble du site. Le moyen le plus rapide de réaliser un audit à grande échelle.
• Un validateur hreflang dédié (comme le nôtre). Plusieurs outils gratuits permettent de vérifier la réciprocité et la validité du code d'un ensemble d'URL, ce qui est utile pour effectuer des contrôles ponctuels.
• Audits de sites avec Ahrefs ou Sitebulb. Ces deux outils intègrent des vérifications internationales qui signalent les erreurs hreflang dans le cadre d'une analyse technique plus large.

Effectuez une vérification après chaque mise à jour importante ou modification de modèle, car c'est à ce moment-là que les clusters ont tendance à tomber en panne.

La manière la plus rapide d'y arriver : confiez cette tâche à un plugin

Toutes les règles ci-dessus peuvent être appliquées manuellement, ce qui est tout à fait raisonnable pour un petit site. Le problème, c'est qu'il est facile de respecter 90 % des règles hreflang tout en échouant, car celles-ci sont interdépendantes et difficiles à suivre. Une seule balise de retour manquante suffit à compromettre un ensemble par ailleurs parfait, et pour trouver la cause du problème, il faut passer au crible votre code avec minutie – et qui a envie de consacrer son temps précieux à cela ?

C'est pourquoi la plupart des sites WordPress utilisent un plugin multilingue qui génère automatiquement les balises hreflang. Avec Weglot, les balises sont créées et synchronisées au fur et à mesure que vous ajoutez des langues et publiez du contenu : balises d'autoréférence, balises de renvoi réciproques, x-par défaut, des codes valides et des URL absolues, conformément auxbonnes pratiques SEO multilingue définiesbonnes pratiques . Ainsi, vous n'avez pas à gérer manuellement ces éléments sur chaque page ; le plugin s'en charge et les met à jour lorsque votre contenu change.

Quelle que soit la méthode choisie, les règles restent les mêmes. Un plugin se charge simplement de les appliquer à votre place, afin qu’une balise de fin manquante ne vous coûte jamais un marché.

Pour configurer correctement les balises hreflang, il suffit d'appliquer quelques règles de manière cohérente sur toutes les pages ; les erreurs sont faciles à repérer une fois que l'on sait ce qu'il faut rechercher. Si vous préférez ne pas avoir à gérer manuellement ces groupes à mesure que votre site se développe, Weglot les Weglot et les synchronise automatiquement pour vous. Commencez votre essai gratuit de 14 jours et disposez d'un site multilingue optimisé pour les moteurs de recherche en quelques minutes.