Un client nous a contactés récemment avec un constat troublant : son site, traduit en quatre langues, voyait son trafic anglophone stagner malgré un contenu de qualité équivalent à la version française. L’audit a révélé un problème classique mais mal connu : les balises hreflang n’étaient pas réciproques entre les pages, ce qui empêchait Google de comprendre correctement la structure multilingue du site.
Ce type de panne est silencieux : le site fonctionne, les pages s’affichent, aucun message d’erreur ne remonte dans l’administration WordPress. Seul un examen attentif du code source ou du rapport de ciblage international de Google Search Console permet de le détecter. Cet article passe en revue le fonctionnement de hreflang, les erreurs les plus fréquentes sur WordPress, et la méthode pour les corriger.
Rappel : à quoi sert vraiment hreflang
La balise hreflang n’est pas un signal de traduction au sens large : c’est une déclaration de ciblage linguistique et géographique. Elle indique à un moteur de recherche quelle version d’une page servir selon la langue et, éventuellement, la région de l’internaute qui effectue la recherche. Une implémentation correcte repose sur trois règles simples mais strictes :
- Chaque page doit déclarer un lien
hreflangvers elle-même (auto-référence). - Chaque page doit déclarer un lien vers toutes ses versions traduites, avec des codes de langue conformes à la norme ISO 639-1 (et ISO 3166-1 pour la région, si utilisée, par exemple
en-us). - Les déclarations doivent être réciproques : si la page française pointe vers la page anglaise, la page anglaise doit pointer en retour vers la page française. Sans réciprocité, Google ignore purement et simplement la déclaration.
Sur WordPress, ces balises apparaissent dans le <head> sous la forme <link rel="alternate" hreflang="en" href="https://exemple.fr/en/page/" />. Elles sont générées automatiquement par les extensions multilingues (WPML, Polylang, TranslatePress) ou, en leur absence, doivent être ajoutées manuellement via le hook wp_head.
Les erreurs les plus fréquentes sur WordPress
Trois causes reviennent régulièrement dans nos audits de sites multilingues WordPress :
1. Rupture de réciprocité après une migration de contenu
Lorsqu’une page est supprimée ou dépubliée dans une langue sans que sa contrepartie dans les autres langues soit mise à jour, la déclaration hreflang continue de pointer vers une URL qui renvoie une erreur 404 ou une redirection. Google traite alors l’ensemble du groupe de traductions comme suspect et peut ignorer toutes les balises associées à ce groupe.
2. Cache statique qui sert une ancienne version des balises
Sur un site utilisant un cache de page agressif (Varnish, un CDN mal configuré), il arrive que les balises hreflang générées par le plugin multilingue restent figées dans une version mise en cache avant l’ajout d’une nouvelle langue. Le symptôme typique : la nouvelle langue fonctionne parfaitement en navigation mais n’apparaît dans aucune balise hreflang tant que le cache n’a pas été purgé sur l’ensemble des pages concernées, pas seulement sur la page d’accueil.
3. Codes de langue mal formés
Une erreur fréquente consiste à utiliser des codes de région sans code de langue de base valide, ou à confondre le code de langue avec le nom du drapeau utilisé dans l’interface. Un code comme hreflang="uk" pour cibler le Royaume-Uni est incorrect : uk est le code ISO de l’ukrainien. Le code correct pour l’anglais britannique est en-gb.
Méthode de diagnostic pas à pas
Pour auditer les balises hreflang d’un site WordPress multilingue, la méthode la plus fiable ne dépend d’aucune extension tierce :
- Ouvrir le code source d’une page représentative de chaque langue (clic droit → afficher le code source, ou
curl -s https://exemple.fr/page/ | grep hreflangen ligne de commande). - Relever toutes les balises
hreflangprésentes sur cette page. - Ouvrir chacune des URL listées et vérifier qu’elle renvoie bien un code HTTP 200, sans redirection.
- Sur chacune de ces pages cibles, vérifier que la balise
hreflangpointe en retour vers la page de départ. - Consulter le rapport Ciblage international dans Google Search Console (sous Ancien rapport, ou via l’API d’inspection d’URL) pour confirmer que Google interprète correctement les relations.
Un script bash simple permet d’automatiser la première étape sur plusieurs URL :
#!/bin/bash
for url in "https://exemple.fr/page/" "https://exemple.fr/en/page/"; do
echo "=== $url ==="
curl -s "$url" | grep -o '<link rel="alternate"[^>]*>'
done
Corriger la réciprocité avec les plugins multilingues
Avec WPML, la réciprocité est normalement automatique tant que les traductions sont correctement liées via icl_translations (voir notre article sur l’architecture de WPML). Un problème de réciprocité signale donc presque toujours une liaison de traduction cassée, pas un bug de génération des balises elles-mêmes.
Avec Polylang, la fonction responsable est interne au plugin et s’appuie sur les traductions déclarées pour chaque post. Si une langue n’a pas de traduction assignée pour une page donnée, aucune balise hreflang n’est générée pour cette langue sur cette page précise — ce qui est le comportement attendu, à ne pas confondre avec un bug.
Sur nos audits, la règle empirique est simple : si une page a une traduction visible dans le menu de langue mais absente de ses balises
hreflang, le problème vient presque toujours d’un cache non purgé ou d’une extension de sitemap qui génère ses propres balises en doublon et en conflit avec le plugin multilingue.
Le cas des doublons de balises
Un piège moins connu : certaines extensions SEO ajoutent leurs propres balises hreflang en plus de celles du plugin multilingue, créant des doublons contradictoires dans le <head>. C’est le cas lorsque Yoast SEO ou Rank Math sont configurés avec leurs propres réglages de site multirégional en parallèle d’un plugin comme WPML qui gère déjà cette fonctionnalité. Il faut alors désactiver la génération hreflang côté extension SEO pour ne laisser qu’une seule source de vérité.
En résumé
Une balise hreflang mal configurée coûte cher en visibilité internationale sans jamais provoquer d’erreur visible côté visiteur, ce qui la rend particulièrement difficile à détecter sans audit dédié. La réciprocité entre toutes les versions linguistiques d’une page reste la règle la plus souvent violée sur WordPress, généralement à cause d’un cache non purgé ou d’une liaison de traduction cassée en base de données. Un contrôle régulier avec Google Search Console et un script de vérification simple suffit à éviter la grande majorité de ces pertes de trafic silencieuses.
