Comment implémenter les balises hreflang pour un WordPress multilingue
Vous avez traduit l'intégralité de votre site WordPress en six langues. Les fichiers .po sont propres, les fichiers .mo sont compilés, chaque chaîne s'affiche parfaitement en français, allemand et japonais. Pourtant, des semaines après le lancement, vous consultez Google Search Console et découvrez quelque chose d'étonnant : votre page française est classée pour des requêtes allemandes, votre page espagnole pour le Mexique est servie aux internautes en Espagne, et deux de vos versions linguistiques se cannibalisent discrètement dans les classements. Le contenu est bon. Le problème est que Google n'a aucune idée de la version qui appartient à quelle audience.
C'est exactement ce que les balises hreflang WordPress sont conçues pour corriger. Hreflang est le signal qui indique aux moteurs de recherche quelle version linguistique et régionale d'une page servir à quel utilisateur. Si vous vous trompez, vous subissez une dilution due au contenu dupliqué, des résultats dans la mauvaise langue et un gaspillage de budget de crawl. Si vous le faites correctement, chaque page traduite atteint l'audience pour laquelle elle a été écrite. Ce guide couvre la syntaxe, la différence entre les codes de langue et de langue-région, le x-default obligatoire, la réciprocité des balises de retour et trois façons pratiques de l'implémenter dans WordPress.
Ce que hreflang fait réellement
Hreflang ne traduit rien. C'est une carte de relations. Lorsque vous avez la même page dans plusieurs langues, les annotations hreflang indiquent à Google « cette URL est la version anglaise, celle-ci est la version allemande, celle-ci est pour les hispanophones au Mexique ». Google utilise cette carte pour afficher la bonne version dans les résultats de recherche en fonction des paramètres de langue et de la localisation de l'utilisateur.
L'annotation se trouve dans le <head> de votre HTML sous forme d'un ensemble d'éléments <link>. Chaque élément nomme une page cible et la langue (et éventuellement la région) qu'elle dessert. Voici un ensemble correct de balises hreflang pour une page disponible en anglais américain, anglais britannique et espagnol mexicain, avec une option de secours par défaut :
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />
Chaque page de l'ensemble doit produire ce même bloc, listant chaque alternative y compris elle-même. Ce dernier point déroute la plupart des gens, et nous y reviendrons.
Pourquoi cela compte pour le SEO
Sans hreflang, Google considère vos pages traduites comme des quasi-doublons en concurrence pour les mêmes mots-clés. Le résultat est une dilution : les signaux de classement sont divisés entre les versions au lieu de se consolider. Avec un hreflang correct, chaque version hérite de l'autorité de l'ensemble et apparaît aux bons chercheurs. C'est l'une des actions SEO les plus efficaces qu'un site multilingue puisse entreprendre, et elle complète plutôt qu'elle ne remplace la traduction de contenu réelle dans vos fichiers .po. Nous couvrons le côté contenu en profondeur dans notre guide sur l'impact de la traduction des fichiers PO sur le classement Google.
Codes langue vs langue-région
Lequel devriez-vous utiliser, en ou en-GB ? Utilisez le code le plus simple et le plus juste. Si votre contenu anglais est générique et que vous ne maintenez pas de versions britanniques et américaines distinctes, utilisez en seul. N'ajoutez un sous-tag de région que lorsque vous servez réellement un contenu différent à différents pays.
Les valeurs hreflang suivent le format language ou language-region. La partie langue est un code ISO 639-1 (en, es, de, pt). La région optionnelle est un code de pays ISO 3166-1 Alpha 2 (US, GB, MX, BR). Ainsi :
encible tous les anglophones, quel que soit le pays.en-GBcible les anglophones au Royaume-Uni.escible tous les hispanophones.es-MXcible spécifiquement les hispanophones au Mexique.
Un détail crucial : le sous-tag de région est un pays, pas une variante linguistique. es-MX ne signifie pas « dialecte espagnol mexicain », cela signifie « espagnol, affiché aux utilisateurs au Mexique ». Google le sert toujours en fonction de la localisation de l'utilisateur. Si vous maintenez des dialectes régionaux dans vos traductions, le code de région est la façon dont vous les acheminez. Nous approfondissons l'aspect linguistique de ce sujet dans notre guide sur les variantes régionales espagnoles et portugaises.
Un exemple d'erreur courant
Voici un bloc hreflang incorrect que nous voyons constamment :
<link rel="alternate" hreflang="en-uk" href="https://example.com/uk/" />
<link rel="alternate" hreflang="sp" href="https://example.com/es/" />
<link rel="alternate" hreflang="pt-PT_BR" href="https://example.com/pt/" />
Trois erreurs. en-uk est invalide car le code pays du Royaume-Uni est GB, pas UK. sp n'est pas du tout un code de langue ; l'espagnol est es. Et pt-PT_BR mélange deux régions avec un underscore qui n'a aucune signification dans hreflang. Les moteurs de recherche ignorent silencieusement les valeurs malformées, vous n'obtenez donc aucune erreur et aucun avantage, juste des heures de débogage à vous demander pourquoi rien n'a changé.
Notez que hreflang utilise un trait d'union (en-GB), tandis que les fichiers de localisation WordPress utilisent un underscore (en_GB). Ne copiez pas directement les codes de vos noms de fichiers .po dans les balises hreflang.
Le x-default et la réciprocité des balises de retour
Deux règles sont à l'origine de plus d'échecs silencieux de hreflang que toute autre chose : le x-default manquant et la réciprocité brisée.
La valeur x-default indique à Google quelle page servir lorsqu'aucune autre langue ne correspond à l'utilisateur. C'est votre solution de secours, généralement votre sélecteur de langue ou votre page d'accueil pour votre marché principal. Ce n'est pas strictement obligatoire selon la spécification, mais en pratique, vous devriez toujours l'inclure. Sans elle, un visiteur lusophone pour lequel vous n'avez pas de version portugaise obtient un tirage au sort au lieu d'une valeur par défaut délibérée.
La réciprocité des balises de retour est non négociable. Chaque page d'un ensemble hreflang doit pointer vers toutes les autres pages, y compris elle-même. Si votre page anglaise liste l'allemand comme alternative, votre page allemande doit lister l'anglais comme alternative. Si la page allemande omet la référence de retour, Google se méfie de toute la relation et ignore les annotations.
<!-- On the German page, the set must still list ALL versions -->
<link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
L'auto-référence (de pointant vers la page allemande lors de la consultation de la page allemande) est requise, pas optionnelle. Un ensemble de cinq versions linguistiques signifie que chacune des cinq pages produit les cinq balises <link> plus le x-default.
Trois façons d'implémenter hreflang dans WordPress
Vous avez trois options pratiques, allant du contrôle manuel total à l'automatisation complète.
Méthode 1 : Manuelle via wp_head
Pour un petit ensemble de pages statiques, vous pouvez injecter des balises hreflang directement via l'action wp_head dans le fichier functions.php de votre thème :
add_action( 'wp_head', function () {
if ( ! is_page( 'pricing' ) ) {
return;
}
$alternates = array(
'en-US' => 'https://example.com/en-us/pricing/',
'es-MX' => 'https://example.com/es-mx/pricing/',
'x-default' => 'https://example.com/pricing/',
);
foreach ( $alternates as $lang => $url ) {
printf(
'<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
esc_attr( $lang ),
esc_url( $url )
);
}
} );
Cela vous donne un contrôle précis mais ne s'adapte pas. Maintenir la réciprocité manuellement sur des centaines d'articles est un piège de maintenance.
Méthode 2 : Un plugin multilingue
Si vous utilisez Polylang, WPML ou TranslatePress, hreflang est généré automatiquement en fonction de vos relations de traduction. C'est la bonne solution pour la plupart des sites car le plugin sait déjà quel article est la traduction de quel autre, de sorte que la réciprocité et x-default sont gérés pour vous. Le coût est la surcharge d'exécution que ces plugins ajoutent, ce qui est le compromis que nous examinons dans notre comparaison des approches de traduction manuelle versus IA.
Méthode 3 : Plan de site XML avec xhtml:link
Au lieu de placer hreflang dans le <head> de chaque page, vous pouvez déclarer les relations dans votre plan de site XML en utilisant l'espace de noms xhtml:link. Chaque entrée <url> liste toutes ses alternatives linguistiques :
<url>
<loc>https://example.com/en/about/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
</url>
Cela maintient votre HTML de page léger et centralise la carte linguistique dans un seul fichier explorable, que Google lit volontiers. La plupart des plugins SEO peuvent générer cela automatiquement.
hreflang complète la traduction, il ne la remplace pas
Voici le point que tout le monde manque : hreflang est inutile si les pages sous-jacentes ne sont pas réellement traduites. La balise indique à Google « c'est la version allemande », mais si l'URL allemande affiche toujours des chaînes de plugin anglaises, des étiquettes de caisse non traduites ou des fichiers .po à moitié terminés, vous avez simplement dit à Google de servir du contenu cassé aux utilisateurs allemands en toute confiance.
Le véritable SEO multilingue se compose de deux couches. La couche de contenu est constituée de vos fichiers .po, .pot, .json et .xliff traduits qui transforment chaque chaîne de thème et de plugin dans la langue cible. La couche de signal est hreflang qui achemine chaque version finalisée à son public. Les deux doivent être solides. Un ensemble hreflang impeccable sur un site traduit à 40 % garantit simplement une expérience pire plus rapidement.
C'est là que maintenir la couche de traduction propre est le plus important. Lorsque vous traduisez vos fichiers d'interface, les placeholders comme %s, %1$s et {name} doivent rester intacts, sinon votre page allemande « traduite » s'affiche avec des jetons %s littéraux qui semblent cassés tant pour les utilisateurs que pour les moteurs de recherche. Un pipeline de traduction compatible gettext avec le Verrouillage de syntaxe protège automatiquement ces jetons, de sorte que chaque page alternative vers laquelle vous pointez hreflang est véritablement prête pour la production. Parce qu'il fonctionne dans le cloud avec le Traitement intelligent par lots, vous pouvez y faire passer un site entier multilingue sans installer de plugins de traduction qui alourdissent le temps d'exécution qui sert ces mêmes pages.
Obtenez d'abord le bon contenu, puis laissez hreflang faire son travail. Les deux combinés sont ce qui consolide les signaux de classement, élimine les résultats dans la mauvaise langue et place chaque page traduite devant les personnes qui peuvent la lire.
Prêt à corriger les résultats de recherche dans la mauvaise langue à la source ? Essayez SimplePoTranslate gratuitement — aucune carte de crédit requise. Traduisez vos fichiers
.po,.potet.jsonavec le forfait gratuit, puis pointez vos balises hreflang vers des pages réellement prêtes pour chaque marché.