Corriger les erreurs hreflang dans WordPress multilingue (et restaurer le ciblage linguistique Google)

Ce que hreflang fait réellement (et ce qu’il ne fait pas)

hreflang n’est pas un code de triche pour le classement. Ce n’est pas un interrupteur magique « faites-moi ranker en Allemagne ». C’est un signal de désambiguïsation qui dit à Google : « Ces URLs sont des pages équivalentes en différentes langues ou variantes régionales. Merci d’afficher la bonne version selon l’utilisateur. »

En termes opérationnels : hreflang est une table de routage pour les résultats de recherche. Si la table de routage est incohérente, les paquets circulent toujours — simplement vers le mauvais endroit.

Ce que hreflang influence

• Le ciblage langue/région dans les résultats : aide Google à choisir la variante adaptée.
• La gestion des contenus dupliqués entre locales : réduit la probabilité que Google traite les traductions comme des duplicatas en concurrence.
• L’hygiène de l’index : aide à regrouper les variantes en un ensemble propre.

Ce que hreflang ne fait pas

• Il ne remplace pas la qualité de la traduction. Un contenu de mauvaise qualité restera un contenu de mauvaise qualité.
• Il ne remplace pas la balise canonical. La balise canonical est un signal de consolidation plus fort ; si canonical entre en conflit avec hreflang, Google suit généralement canonical et ignore hreflang.
• Il ne résout pas les problèmes de géolocalisation/IP. Si votre serveur redirige selon l’IP ou Accept-Language sans URLs stables, hreflang ne pourra pas vous sauver.

Conseil tranché : si vous faites du multilingue, vous devez avoir des URLs stables et crawlables pour chaque locale. Si vous ne les avez pas, arrêtez de trifouiller les balises et repensez d’abord la stratégie d’URL.

Une citation à garder sur votre bureau, utile pour le signalement SEO :

John Allspaw (idée paraphrasée) : « La fiabilité vient de la conception de systèmes qui s’attendent à l’échec — et qui le gèrent avec élégance. »

hreflang, c’est de l’ingénierie de fiabilité pour le ciblage de recherche. Vous concevez pour le mode de défaillance où Google se trompe, parce que Google finira par se tromper.

Faits intéressants et contexte historique

Un peu de contexte aide, car les problèmes hreflang ne sont rarement « juste un bug de plugin ». Ce sont souvent d’anciennes décisions web qui entrent en collision avec le comportement moderne d’indexation.

1. hreflang existait avant la plupart des plugins multilingues WordPress. Il s’est popularisé au début des années 2010, lorsque des sites globaux ont réalisé que canonical seul ne gérait pas proprement les variantes linguistiques.
2. Google et autres moteurs ont implémenté hreflang différemment au départ. Cet héritage explique pourquoi on voit encore des rapports « ça marche pour Bing, échoue pour Google ».
3. « x-default » a été introduit comme échappatoire. Il sert pour une page de sélection générique ou un fallback, pas comme un dépotoir de « je ne sais pas ».
4. hreflang est un hint, pas une directive. Même parfait, Google peut choisir une URL différente si d’autres signaux (canonical, liens internes, sitemaps, redirections) divergent.
5. Les balises de retour sont obligatoires en pratique. La spécification peut être lue de façon lâche, mais Google attend un lien réciproque entre alternates (A pointe vers B, B pointe vers A).
6. Les codes de locale sont stricts. « en-UK » est faux ; « en-GB » est correct. Ces petites erreurs provoquent des désordres disproportionnés.
7. Les sitemaps XML peuvent aussi porter hreflang. Utile si le HTML est mis en cache ou généré de façon incohérente, mais cela introduit un second endroit susceptible de rompre.
8. WordPress n’a pas été conçu à l’origine pour des URLs multilingues. Multisite, locales basées sur des répertoires et traductions gérées par plugins s’ajoutent à un noyau qui suppose « un site = une langue ».

Mode opératoire pour un diagnostic rapide

Si vous êtes de garde pour des incendies SEO (félicitations, vous avez rejoint un club spécial), vous avez besoin d’un chemin court vers la vérité. Voici la façon la plus rapide de trouver le goulot sans lire 40 pages d’interface Search Console.

Première étape : déterminer si Google voit le mauvais HTML

• Récupérez le HTML de la page comme un client de type bot et inspectez les balises hreflang.
• Comparez le HTML servi avec et sans cookies, et avec différents en-têtes Accept-Language.
• Vérifiez que les caches ne servent pas la mauvaise locale (en-têtes Vary, règles CDN, clés de cache full-page).

Deuxième étape : vérifiez canonical et redirections (les « signaux forts »)

• Confirmez que chaque URL locale a un canonical auto-référentiel (ou canonicals pointant vers la bonne URL de locale) de façon cohérente.
• Confirmez qu’il n’y a pas de chaîne de redirections qui écrase les locales en une seule URL.
• Confirmez que la normalisation des slashs et des paramètres ne crée pas de duplicatas sans hreflang correspondant.

Troisième étape : validez la réciprocité et l’exhaustivité

• Pour chaque variante linguistique : toutes les alternates présentes, codes corrects, URLs absolues correctes.
• Chaque alternate renvoie le lien en retour (balises de retour).
• x-default n’existe que si vous avez réellement une expérience par défaut.

Quatrième étape : vérifiez sitemaps vs HTML

• Si vous utilisez hreflang dans les sitemaps, assurez-vous qu’il correspond exactement au HTML.
• Choisissez quelques URLs représentatives ; ne tentez pas d’inspecter 10 000 lignes à l’œil.

Cinquième étape : confirmez le comportement de clustering de Google

• Cherchez des symptômes « Dupliqué, Google a choisi un canonical différent de celui de l’utilisateur ».
• Vérifiez ponctuellement les résultats d’index par locale. Les bonnes pages sont-elles indexées ? Ou sont-elles regroupées en une seule ?

Blague #1 : déboguer hreflang, c’est comme le DNS — à la fin, vous découvrez que ce n’était pas « Google », c’était vous, il y a six semaines, après une bière.

Modes de défaillance : comment hreflang casse dans WordPress

1) Le plugin génère hreflang, le thème génère aussi hreflang

C’est le classique problème des « deux sources de vérité ». Vous obtenez des balises link rel="alternate" dupliquées, parfois avec des URLs différentes. Google ne choisit pas poliment la meilleure ; il traite l’ensemble comme peu fiable.

Que faire : choisissez exactement un générateur : WPML/Polylang/MultilingualPress/votre plugin SEO personnalisé. Désactivez tous les autres points d’injection hreflang (thème, functions personnalisées, modules SEO du plugin).

2) Le canonical pointe vers la mauvaise locale

Si votre page anglaise canonise vers la page d’accueil par défaut, vous avez dit à Google « ce sont les mêmes, consolidez ». hreflang essaie de dire « ce sont des variantes différentes ». Canonical gagne généralement.

3) Redirections automatiques basées sur la langue du navigateur

Les redirections selon la langue du navigateur semblent « conviviales » jusqu’à ce que vous réalisiez qu’elles bloquent le crawl, cassent les URLs stables et font que Googlebot voit un contenu différent selon les en-têtes. Si vous devez le faire, faites-le en douceur (bannière/suggestion) et gardez les URLs de locale accessibles.

4) Les clés de cache ne varient pas selon la locale

Les caches full-page et CDNs font souvent du cache par URL uniquement. Si votre sélection de langue repose sur des cookies ou des en-têtes, vous pouvez servir du HTML allemand à une URL anglaise — avec des balises hreflang allemandes. Ce n’est pas du « multilingue ». C’est de la roulette.

5) Mismatch des slashs et normalisation d’URL

Si hreflang pointe vers /fr/page mais que le canonical est /fr/page/, vous fabriquez des duplicatas. Idem pour http/https, www/non-www, majuscules/minuscules et paramètres de requête comme les tags de tracking.

6) Balises de retour manquantes depuis une locale

Pattern courant : l’anglais liste des alternates pour toutes les langues, mais une page traduite manque complètement les alternates (override de template, noindex ou contenu construit avec un template de type de post différent). Cela casse le cluster.

7) Mauvais codes langue-région

« en-UK » est le grand classique. Aussi « es-LA » (pas une région valide) et « cn » (la Chine est « CN », la langue est « zh »). Google ne fera pas vos devoirs.

8) Vous mélangez des modèles de traduction

Locales basées sur des répertoires (/en/, /fr/) plus domaines séparés plus paramètres. Ne le faites pas. Choisissez un modèle et implémentez-le proprement, car chaque hybride devient une carrière de débogage.

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont les vérifications de base que vous pouvez exécuter depuis un terminal. Elles ne remplaceront pas Search Console, mais elles vous diront ce que vos serveurs envoient réellement. Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie et la décision à prendre.

Task 1: Fetch HTML and extract hreflang tags

cr0x@server:~$ curl -sS -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/en/product/widget/ | grep -i 'rel="alternate"'
<link rel="alternate" hreflang="en" href="https://example.com/en/product/widget/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/produit/widget/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/produkt/widget/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/product/widget/" />

Ce que cela signifie : hreflang existe dans le HTML pour cette page. Bon début.

Décision : Si les balises manquent ou sont manifestement incorrectes, corrigez la génération à la source (plugin/thème). Si elles semblent correctes, passez aux vérifications de réciprocité et de canonical.

Task 2: Verify canonical on each locale page

cr0x@server:~$ curl -sS https://example.com/fr/produit/widget/ | grep -i 'rel="canonical"'
<link rel="canonical" href="https://example.com/en/product/widget/" />

Ce que cela signifie : La page française canonise vers l’anglais. Cela indique à Google de consolider le français dans l’anglais.

Décision : Corrigez le canonical pour qu’il soit auto-référentiel par locale (ou canonical vers la bonne URL de locale). Puis revalidez hreflang.

Task 3: Check redirect behavior (are locales collapsing?)

cr0x@server:~$ curl -sS -I https://example.com/de/produkt/widget/ | sed -n '1,10p'
HTTP/2 301
date: Sat, 27 Dec 2025 10:11:12 GMT
location: https://example.com/en/product/widget/
cache-control: max-age=3600

Ce que cela signifie : L’URL allemande redirige vers l’anglais. hreflang ne peut pas fonctionner si la cible ne reste pas en place.

Décision : Supprimez ou scopez les redirections. Chaque URL locale doit renvoyer 200 avec le contenu de la locale.

Task 4: Detect cookie-based language switching issues

cr0x@server:~$ curl -sS -I https://example.com/product/widget/ | grep -i 'set-cookie'
set-cookie: pll_language=fr; path=/; secure; HttpOnly

Ce que cela signifie : L’URL « par défaut » définit un cookie de langue. Cela peut aller, mais c’est un signal d’alerte pour le caching et la cohérence côté bot.

Décision : Assurez-vous que les bots reçoivent des balises hreflang et canonical cohérentes, et que le cache varie correctement (ou évitez la locale basée sur cookie sur des URLs partagées).

Task 5: Compare output with different Accept-Language headers

cr0x@server:~$ curl -sS -H "Accept-Language: de-DE,de;q=0.9" https://example.com/en/product/widget/ | grep -i 'html lang=' | head -n 1
<html lang="de-DE">

Ce que cela signifie : Vous avez demandé /en/ mais reçu du HTML en allemand. C’est un bug sévère : l’URL et la langue ne doivent pas être en désaccord.

Décision : Désactivez la commutation basée sur les en-têtes pour les URLs de locale ; réservez-la à une page sélectrice ou seulement à la racine avec un x-default approprié.

Task 6: Check Vary header (cache correctness)

cr0x@server:~$ curl -sS -I https://example.com/en/product/widget/ | grep -i '^vary:'
Vary: Accept-Encoding

Ce que cela signifie : Le cache ne varie pas selon les cookies ou Accept-Language. Si votre site change la langue selon l’un ou l’autre, votre cache peut mélanger les langues.

Décision : Soit cessez de varier le contenu par cookie/en-tête pour la même URL, soit ajoutez un comportement Vary correct et segmentez les caches (souvent difficile avec les CDN).

Task 7: Confirm sitemap contains expected locale URLs

cr0x@server:~$ curl -sS https://example.com/sitemap_index.xml | grep -Eo '<loc>[^<]+' | head
<loc>https://example.com/page-sitemap.xml
<loc>https://example.com/product-sitemap.xml
<loc>https://example.com/fr/page-sitemap.xml
<loc>https://example.com/de/page-sitemap.xml

Ce que cela signifie : Vous avez des entrées de sitemap par locale (bien). Vérifiez maintenant qu’elles contiennent les bonnes URLs et extensions hreflang si utilisées.

Décision : Si le sitemap manque d’URLs locales, corrigez la configuration du plugin SEO ; ne comptez pas sur la découverte automatique.

Task 8: Extract hreflang annotations from a sitemap (if present)

cr0x@server:~$ curl -sS https://example.com/product-sitemap.xml | grep -i 'xhtml:link' | head -n 6
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/product/widget/" />
<xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/produit/widget/" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/produkt/widget/" />

Ce que cela signifie : Hreflang au niveau du sitemap existe. Super — sauf s’il est en désaccord avec le HTML.

Décision : Faites correspondre HTML et sitemap. Choisissez une source de vérité pour le mapping d’URL (généralement le plugin de traduction) et alimentez-en les deux sorties.

Task 9: Check for multiple hreflang generators (duplicate tags)

cr0x@server:~$ curl -sS https://example.com/en/product/widget/ | grep -ic 'rel="alternate"'
12

Ce que cela signifie : Douze balises alternate est suspect à moins que vous n’ayez réellement de nombreuses variantes. Souvent ce sont des blocs dupliqués.

Décision : Affichez la section head et identifiez quel composant émet chaque bloc. Désactivez l’émetteur supplémentaire.

Task 10: Confirm HTTP status is 200 for all alternates

cr0x@server:~$ for u in \
https://example.com/en/product/widget/ \
https://example.com/fr/produit/widget/ \
https://example.com/de/produkt/widget/ ; do
  printf "%s " "$u"
  curl -sS -o /dev/null -w "%{http_code}\n" "$u"
done
https://example.com/en/product/widget/ 200
https://example.com/fr/produit/widget/ 200
https://example.com/de/produkt/widget/ 404

Ce que cela signifie : Une alternate est cassée (404). Cela casse le cluster et provoque des symptômes « pas de balises de retour » / « hreflang invalide ».

Décision : Corrigez l’URL de traduction manquante ou retirez-la de hreflang jusqu’à son existence. N’annoncez pas des endpoints morts.

Task 11: Validate language-region codes used on the site

cr0x@server:~$ curl -sS https://example.com/en/product/widget/ | grep -Eo 'hreflang="[^"]+"' | sort -u
hreflang="de-DE"
hreflang="en-UK"
hreflang="fr-FR"
hreflang="x-default"

Ce que cela signifie : « en-UK » est invalide. Utilisez « en-GB ». Décidez aussi si vous avez vraiment besoin de variantes régionales ; sinon contentez-vous de la langue seule (en, fr, de).

Décision : Normalisez les codes sur tout le site. Dans les plugins WordPress, c’est généralement un paramètre par langue.

Task 12: Detect canonical/hreflang target mismatch quickly

cr0x@server:~$ curl -sS https://example.com/fr/produit/widget/ | awk 'BEGIN{IGNORECASE=1} /rel="canonical"/{print} /rel="alternate"/{print}'
<link rel="canonical" href="https://example.com/en/product/widget/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/produit/widget/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/product/widget/" />

Ce que cela signifie : La page prétend être française, mais le canonical dit « traitez-moi comme anglais ». C’est un conflit.

Décision : Corrigez les règles de canonical. Pour les pages multilingues, le canonical auto-référentiel par locale est le modèle sûr par défaut.

Task 13: Confirm robots directives aren’t blocking a locale

cr0x@server:~$ curl -sS https://example.com/de/produkt/widget/ | grep -i 'meta name="robots"' || echo "no meta robots tag found"
<meta name="robots" content="noindex,follow" />

Ce que cela signifie : Vous dites à Google de ne pas indexer la page allemande. hreflang ne peut pas afficher une page qui n’est pas indexée.

Décision : Retirez l’attribut noindex accidentel des pages locales en production ; gardez noindex pour les environnements de staging uniquement.

Task 14: Verify robots.txt isn’t blocking locale paths

cr0x@server:~$ curl -sS https://example.com/robots.txt | sed -n '1,120p'
User-agent: *
Disallow: /wp-admin/
Disallow: /de/
Sitemap: https://example.com/sitemap_index.xml

Ce que cela signifie : /de/ est bloqué. C’est un auto-coup franc.

Décision : Retirez le Disallow pour les locales en production. Le recrawl prendra du temps, mais il faut arrêter le blocage d’abord.

Task 15: Find mixed hostnames (www vs non-www) in alternates

cr0x@server:~$ curl -sS https://example.com/en/product/widget/ | grep -i 'hreflang' | grep -Eo 'https?://[^"]+' | sort -u
https://example.com/en/product/widget/
https://www.example.com/fr/produit/widget/

Ce que cela signifie : Les alternates mélangent les hostnames. Cela crée des identités d’URL dupliquées et rend les clusters fragiles.

Décision : Normalisez les réglages d’URL du site dans WordPress et appliquez des redirections pour que hreflang utilise toujours l’hôte canonique.

Erreurs courantes : symptômes → cause → correction

1) Symptôme : les résultats montrent la mauvaise langue pour beaucoup d’utilisateurs

Cause racine : Canonical pointe vers une langue « principale » unique, écrasant toutes les locales. Ou des redirections forcent les utilisateurs vers une seule locale.

Correction : Canonical auto-référentiel par locale. Supprimez les redirections qui écrasent les locales. Assurez-vous que chaque URL locale renvoie 200 et est indexable.

2) Symptôme : Search Console signale « No return tags »

Cause racine : Une ou plusieurs alternates ne renvoient pas le lien en retour (template manquant, 404 ou noindex). Parfois seuls certains types de post sont concernés.

Correction : Assurez-vous que le mapping de traduction est complet. Confirmez que chaque variante locale émet l’ensemble complet d’alternates, y compris elle-même.

3) Symptôme : « Unknown language code » ou « invalid hreflang »

Cause racine : Codes ISO erronés (« en-UK »), régions fantaisistes (« es-LA ») ou utilisation de underscores (« en_US ») au lieu de traits d’union.

Correction : Normalisez aux tags valides style BCP 47 utilisés par Google : language-region avec trait d’union, région en majuscules (en-GB), ou langue seule (en).

4) Symptôme : les balises hreflang sont présentes, mais Google les ignore

Cause racine : Signaux forts en conflit : mismatch canonical, liens internes incohérents, hostnames mélangés, ou désaccord sitemap vs HTML.

Correction : Alignez canonical + hreflang + liens internes + sitemaps. Google fait davantage confiance à la cohérence qu’à une balise isolée.

5) Symptôme : une locale s’indexe bien ; d’autres presque pas

Cause racine : robots.txt en disallow, meta noindex ou blocs serveur (règles WAF) appliqués seulement à certains chemins.

Correction : Vérifiez robots et en-têtes par locale, pas seulement « site-wide ». Retirez les blocages, puis demandez le réindexing des pages clés.

6) Symptôme : les alternates mènent à des chaînes 301/302

Cause racine : Le plugin émet des URLs non-canonique (http vs https, slash manquant), ou le CDN applique des redirections après coup.

Correction : Faites en sorte que les URLs hreflang soient les URLs finales (200). Corrigez les réglages « Site URL », permaliens WordPress et toute règle de redirection en périphérie.

7) Symptôme : les utilisateurs rebondissent car on les envoie dans la mauvaise locale après clic

Cause racine : La redirection selon la langue du navigateur s’enclenche après l’arrivée depuis la recherche, envoyant les utilisateurs ailleurs (parfois vers la page d’accueil). Cela casse l’intention et l’attribution analytics.

Correction : Stoppez les redirections forcées. Utilisez une bannière : « On dirait que vous préférez l’allemand — basculer ? » avec un choix persistant.

8) Symptôme : beaucoup d’avertissements « Duplicate, Google chose different canonical than user »

Cause racine : Pages similaires entre locales avec des canonicals pointant incorrectement, ou contenus identiques entre « traductions » (copie paresseuse) poussant Google à consolider.

Correction : Corrigez les canonicals. Assurez-vous que les traductions sont réellement traduites. Si le contenu est volontairement identique entre régions, questionnez la nécessité d’avoir des URLs séparées.

Listes de contrôle / plan étape par étape

Étape 1 : Choisissez et documentez votre modèle d’URL

• Un domaine, répertoires : /en/, /fr/ (commun pour WordPress).
• Domaines séparés : example.fr, example.de (séparation forte, plus de charge opérationnelle).
• Sous-domaines : fr.example.com (option intermédiaire).

À faire : choisissez-en un et tenez-vous-y.

Éviter : mélanger répertoires, paramètres et domaines séparés « parce que le marketing l’a demandé ». Le marketing demande beaucoup de choses.

Étape 2 : Rendre les canonicals ennuyeux

• Chaque page locale devrait généralement avoir un canonical auto-référentiel.
• Si vous avez des variantes régionales qui sont de véritables duplicatas, la canonicalisation peut les consolider — mais alors hreflang doit correspondre à cette logique avec soin.

Étape 3 : Générer hreflang à partir d’un mappage unique et faisant autorité

• Le mapping du plugin de traduction (IDs de post liés entre langues) est la source de vérité habituelle.
• Ne modifiez pas manuellement hreflang par page en production à moins d’aimer la corvée permanente.

Étape 4 : Faire respecter la cohérence en périphérie

• Forcer https et un seul hostname (www ou non).
• Normaliser les trailing slashes selon le style de permaliens WordPress.
• Veiller à ce que hreflang utilise les URLs normalisées.

Étape 5 : Empêcher l’empoisonnement du cache entre langues

• Si la locale varie par chemin d’URL, le caching est simple.
• Si la locale varie par cookie/en-tête, vous devez varier correctement les clés de cache — sinon vous servirez du HTML multilingue mixé sur la même URL.

Étape 6 : Valider la réciprocité sur un échantillon

• Choisissez 20 URLs représentatives : page d’accueil, catégorie, produit, article, landing page.
• Pour chacune, confirmez : alternates complets, balises de retour présentes, cibles 200, canonicals sensés.

Étape 7 : Décider comment utiliser x-default

• Utiliser x-default lorsqu’il existe une page sélectrice de langue ou une landing générique non liée à une locale.
• Ne pas utiliser x-default comme « la page anglaise », sauf si l’anglais est vraiment l’expérience par défaut mondiale.

Blague #2 : x-default n’est pas une poubelle. Si vous l’utilisez comme telle, Google recyclera votre trafic ailleurs.

Étape 8 : Déployer les modifications en sécurité

• Changez une chose à la fois : logique de canonical d’abord, puis hreflang, puis sitemaps.
• Purgez les caches après déploiement (cache applicatif, cache d’objets si pertinent, CDN).
• Relancez un recrawl d’un jeu de test avec vos vérifications en commande avant de célébrer.

Trois mini-récits d’entreprise du terrain

Mini-récit 1 : L’incident causé par une fausse hypothèse

Ils ont supposé que Google « comprendrait ». L’entreprise avait un site WordPress multilingue : anglais, français, allemand. L’implémentation était assez propre visuellement. Les utilisateurs pouvaient changer de langue. Le tableau de bord exécutif montrait du trafic international. Tout le monde s’est détendu.

Puis une équipe régionale s’est plainte d’une chute brutale du trafic allemand. L’équipe SEO a ouvert Search Console et vu un marécage : les pages allemandes étaient indexées, mais elles continuaient d’apparaître pour des requêtes anglaises, et des pages anglaises se classaient en Allemagne. hreflang était présent, donc l’hypothèse fut : « hreflang fonctionne ».

En fait non. Le canonical de chaque page traduite pointait vers l’original anglais parce que quelqu’un avait configuré le plugin SEO avec « canonicaliser les traductions vers l’original ». Ce réglage semble propre. Il est aussi catastrophique si votre objectif est le ciblage linguistique. Google a fait exactement ce qu’on lui avait dit : consolider les signaux vers l’anglais, puis parfois afficher la page allemande parce que le contenu semblait pertinent.

La correction fut douloureusement peu glamoureuse : rendre les canonicals auto-référentiels, régénérer hreflang depuis les mappings de traduction, purger les caches et resoumettre les sitemaps. Les classements se sont stabilisés en quelques semaines. Pas du jour au lendemain — les systèmes d’indexation sont distribués et d’une patience redoutable.

La leçon : si canonical et hreflang sont en désaccord, canonical gagne généralement. Ne supposez pas que Google « comprendra ». Google est une machine qui récompense la cohérence, pas l’optimisme.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait des performances globales plus rapides. Ils ont mis un CDN devant WordPress et activé « cache everything ». Le temps au premier octet s’est amélioré instantanément. Tout le monde s’est félicité. Puis le support client a reçu des plaintes étranges : des utilisateurs en Espagne voyaient des pages allemandes. Les Allemands voyaient des chaînes UI en anglais. L’équipe marque a dit que le site avait l’air « aléatoire ».

Le site stockait la préférence de langue dans un cookie. Le CDN mettait en cache le HTML par URL uniquement. Donc le premier visiteur arrivant sur /product/widget/ en allemand remplissait le cache avec du HTML allemand. Le visiteur suivant — quelle que soit sa langue — recevait cette page mise en cache. Avec le hreflang allemand. À l’URL anglaise.

Les bots de recherche crawlaient des versions mélangées selon le timing. Certaines pages se sont retrouvées indexées avec le mauvais signal de langue, et les clusters hreflang sont devenus incohérents. Search Console affichait des erreurs de balises de retour et des incohérences. Rien n’était aligné parce que le système n’était plus déterministe.

L’« optimisation » fut annulée : le caching fut reconfiguré pour varier par cookie pour le petit ensemble d’URLs où la locale dépendait du cookie, et ils sont passés à des URLs de locale basées sur le chemin pour le reste. Les performances sont restées bonnes, et l’aléatoire a disparu.

La leçon : le caching est un amplificateur. Si votre sélection de langue ne fait pas partie de la clé de cache, vous ne gérez pas du multilingue — vous gérez une loterie linguistique.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe enterprise a fait quelque chose qui semble douloureusement lent en réunion : ils ont rédigé un « Contrat URL Locale » d’une page. Il documentait les codes de langue autorisés, les patterns d’URL, les règles de canonical et qui était propriétaire de la génération hreflang. Il incluait aussi un petit script de test lancé dans le CI qui récupérait 10 pages représentatives par locale et vérifiait : statut 200, canonical auto-référentiel, présence de tous les alternates et pas de hostnames mélangés.

Des mois plus tard, une mise à jour de thème a modifié le template d’en-tête et enlevé le hook du plugin qui injectait les balises hreflang — mais seulement pour un type de post personnalisé utilisé par les campagnes. L’équipe campagne aurait lancé un ensemble de pages de landing multilingues sans hreflang et avec des canonicals incohérents, directement dans le search payant et organique.

Le check CI l’a détecté le jour même. La release a été bloquée. Les gens ont râlé, car bloquer des releases est impopulaire jusqu’à ce que cela vous évite d’expliquer des variations de revenus à la direction. La correction fut un petit patch de thème : restaurer le hook, confirmer la sortie, déployer.

La leçon : les vérifications ennuyeuses empêchent des drames coûteux. hreflang n’est pas une configuration ponctuelle ; c’est un contrat à maintenir.

Comment penser hreflang dans WordPress : choix d’architecture qui réduisent la douleur

Les locales basées sur des répertoires sont les moins surprenantes opérationnellement

Pour WordPress, les locales basées sur le chemin (/en/, /fr/) sont généralement le bon compromis : caching simple, séparation claire et moins de complications cross-domaines. Les domaines séparés conviennent aussi, mais sont plus lourds opérationnellement : certificats, redirections, propriétés Search Console et plus de points à mal configurer.

Un seul système de mapping de traduction, un seul système SEO, une seule stratégie de cache

Si vous retenez une chose de ceci : évitez les responsabilités qui se chevauchent. WPML/Polylang gère les relations de traduction. Un plugin SEO peut produire canonicals et sitemaps. Votre thème peut émettre des meta tags. Votre CDN peut réécrire des en-têtes. Si deux de ces couches « aident » avec hreflang, vous aurez des duplications ou des conflits.

Ne comptez pas sur la détection automatique de la langue pour les crawlers

La détection de langue pour les humains est une fonctionnalité UX. Pour les bots, c’est une source de nondéterminisme. Gardez des URLs de locale stables. Offrez un sélecteur. Si vous devez détecter, faites-le seulement sur la racine et gardez les URLs de locale déterministes et crawlables.

Validation opérationnelle : à quoi ressemble le « correct »

Un cluster hreflang correct (minimum viable)

• Chaque URL locale renvoie 200.
• Chaque URL locale inclut rel="alternate" pour toutes les variantes de locale, y compris elle-même.
• Chaque URL locale inclut un canonical qui correspond à l’URL d’indexation prévue pour cette locale.
• Toutes les cibles alternates sont des URLs canoniques et finales (pas de redirection, pas bloquées, pas de noindex).
• Les codes langue/région sont valides et cohérents.
• Les liens internes pointent majoritairement vers des pages de la même locale (ne croisez pas tout vers l’anglais).

Quand utiliser langue seule vs langue-région

Si vous n’avez pas de différences régionales significatives, n’en inventez pas. Utilisez en, fr, de. Les variantes régionales (en-GB, en-US) sont pour des différences réelles : tarification, mentions légales, orthographe, contraintes d’expédition ou contenu véritablement régional.

Opinion : le ciblage par région coûte cher. Si vous ne pouvez pas énoncer la différence en une phrase, vous créez probablement des URLs inutiles qui se font concurrence.

FAQ

1) Ai-je besoin de hreflang si je n’ai qu’une langue mais plusieurs pays ?

Si le contenu est vraiment le même et que vous voulez une seule page anglaise mondiale, ne créez pas plusieurs URLs par pays. Si vous avez des URLs distinctes (tarification, expédition, mentions légales), alors oui : hreflang avec variantes régionales peut aider.

2) Dois-je mettre hreflang dans le HTML, dans les sitemaps ou les deux ?

Choisissez une méthode sauf si vous avez une raison opérationnelle forte. Le HTML est direct et facile à auditer. Les sitemaps sont utiles si le HTML est difficile à contrôler ou fortement mis en cache. Si vous faites les deux, ils doivent correspondre exactement, sinon vous créerez des signaux en split-brain.

3) Quelle est la relation entre hreflang et canonical ?

Canonical indique à Google quelle URL est privilégiée pour l’indexation. hreflang indique à Google comment choisir parmi des équivalents pour différentes locales. Si canonical consolide les variantes en une URL, hreflang perd une grande partie de sa valeur.

4) x-default est-il requis ?

Non. C’est optionnel. Utilisez-le quand il y a une page fallback neutre (comme un sélecteur de langue) ou quand votre expérience racine n’est pas liée à une locale spécifique. Ne l’imposez pas « parce que c’est une bonne pratique ». Les bonnes pratiques sans contexte provoquent des incidents.

5) Puis-je utiliser hreflang avec des plugins de traduction automatique ?

Techniquement oui, mais ne confondez pas « traduit » avec « utile ». Google peut toujours juger les pages de faible qualité ou trop similaires et les consolider. hreflang ne sauvera pas un contenu médiocre.

6) Pourquoi Search Console montre des erreurs hreflang alors que le trafic semble correct ?

Parce que le web est désordonné et que Google compense — jusqu’à ce qu’il ne compense plus. Les erreurs indiquent souvent une fragilité : une mise à jour de thème, un changement de cache ou une migration peut transformer « à peu près correct » en « mauvaise langue partout ». Corrigez-le quand c’est un avertissement, pas quand c’est une panne.

7) Dois-je traduire les slugs pour que hreflang fonctionne ?

Non. Les slugs peuvent rester identiques entre locales. Ce qui compte, c’est que chaque locale ait une URL stable et un mapping hreflang correct. Traduire les slugs peut améliorer l’UX et le CTR dans certains marchés, mais cela augmente le risque lors des migrations.

8) Combien de temps faut-il à Google pour refléter des corrections hreflang ?

Prévoyez de quelques jours à quelques semaines selon la fréquence de crawl et la taille du site. Vous pouvez accélérer la découverte avec des sitemaps mis à jour et des liens internes. Vous ne pouvez pas forcer un re-clustering instantané. Si quelqu’un vous promet l’instantané, il vous vend une impression.

9) Que faire si une traduction n’existe pas pour une page ?

N’incluez pas d’alternate hreflang pour une page qui n’existe pas. Soit omettez cette langue pour cette URL, soit orientez soigneusement les utilisateurs vers une page de substitution locale — avec prudence. Les alternates factices créent des erreurs de retour et un mauvais clustering.

10) WordPress multisite facilite-t-il hreflang ?

Parfois. Il peut rendre la séparation des locales plus propre (sites séparés par langue), mais cela ajoute de la complexité opérationnelle (déploiements, plugins, gestion des utilisateurs, mapping cross-site). « Plus facile » dépend de la capacité de votre équipe à l’opérer.

Conclusion : prochaines étapes qui font vraiment la différence

Les erreurs hreflang dans WordPress multilingue ne sont que rarement une balise cassée isolée. Elles sont généralement une défaillance de cohérence à travers les couches : sortie du plugin, logique de canonical, redirections, caching et génération de sitemaps. Traitez-le comme un incident de production : établissez une source de vérité, éliminez les signaux contradictoires et validez le comportement depuis l’extérieur.

Prochaines étapes pratiques (à faire dans cet ordre)

1. Choisissez 10 URLs représentatives à travers templates et locales. Exécutez les commandes ci-dessus et enregistrez les sorties.
2. Corrigez d’abord les conflits de canonical. Si le canonical est faux, hreflang ne sera jamais stable.
3. Assurez-vous que chaque URL locale est déterministe : pas de redirections forcées, pas de commutation de langue sur les chemins locaux.
4. Faites de la génération hreflang une source unique (un plugin/module), puis purgez les caches.
5. Normalisez codes et hosts (en-GB pas en-UK ; https seulement ; www vs non-www).
6. Alignez sitemap et HTML si vous publiez hreflang dans les deux.
7. Mettez en place un petit contrôle automatisé (CI ou cron) pour détecter les régressions après des mises à jour de thème/plugin.

Si vous effectuez ces étapes, Google restera Google — lent, distribué, parfois mystérieux — mais votre système cessera de lui fournir des contradictions. C’est alors que le ciblage linguistique commence à fonctionner comme de l’ingénierie et non comme du folklore.