hreflang dit à un moteur de recherche : “cette page existe dans ces langues, sers la bonne.” Il échoue en silence : rien ne casse, vos pages ne remontent simplement jamais dans leur langue.

Trois points méritent d’être posés avant les règles, parce que la plupart des guides les ratent.

Ce n’est pas un facteur de classement. La documentation de Google présente le hreflang comme un moyen d‘“orienter les utilisateurs vers la version la plus appropriée de votre page”. Il échange l’URL qui se classe déjà contre celle qui correspond à la locale. Il ne fait monter personne. John Mueller l’a répété. Le geotargeting promeut, le hreflang échange.

Il ne déclare pas la langue de votre page. Google est explicite : “Google n’utilise ni hreflang ni l’attribut HTML lang pour détecter la langue d’une page ; nous utilisons des algorithmes pour la déterminer.” Le hreflang dit que ces pages sont des variantes les unes des autres, rien de plus.

Search Console ne vous préviendra pas quand ça casse. J’y reviens, parce que c’est le point le plus périmé de tous les articles hreflang écrits avant 2023.

Les trois méthodes, et pourquoi n’en choisir qu’une

Google supporte exactement trois façons de déclarer des alternates, et précise qu’elles sont “équivalentes de son point de vue”. Surtout : “Vous pouvez utiliser les trois en même temps, mais il n’y a aucun bénéfice pour la recherche”, et ce sera “beaucoup plus difficile à gérer que d’en choisir une seule”.

Les balises <link> dans le <head>. Le choix pratique pour un site Framer.

<link rel="alternate" hreflang="en" href="https://votresite.com/en/a-propos/" />
<link rel="alternate" hreflang="fr" href="https://votresite.com/fr/a-propos/" />
<link rel="alternate" hreflang="x-default" href="https://votresite.com/en/a-propos/" />

Les balises doivent vivre dans un <head> bien formé, et Google déconseille de combiner le hreflang avec d’autres attributs comme media dans une même balise.

Un en-tête HTTP Link:. L’usage que Google en donne est étroit : “utile pour les fichiers non-HTML (comme les PDF)”.

Un sitemap XML, via le namespace xhtml. Le choix pratique à grande échelle, parce qu’il ne demande aucune modification des gabarits. Chaque entrée <url> liste tous les alternates, elle-même comprise.

Les cinq règles

1. Ça doit être réciproque. Google : “Si deux pages ne pointent pas l’une vers l’autre, les balises seront ignorées. Cela empêche quelqu’un, sur un autre site, de créer arbitrairement une balise se désignant comme version alternative de l’une de vos pages.” Dans sa section Erreurs courantes, Google formule un peu plus doucement : “peuvent être ignorées ou mal interprétées”. Dans les deux cas, une annotation à sens unique ne vaut rien. C’est l’erreur numéro un de la liste de Google.

2. Chaque version doit se référencer elle-même. Google : “Chaque version linguistique doit se lister elle-même ainsi que toutes les autres.” Ce n’est pas optionnel. Sans l’auto-référence, l’ensemble est invalide.

3. Les URLs doivent être absolues. Google : “Les URLs alternatives doivent être pleinement qualifiées, protocole compris : https://example.com/foo, et non //example.com/foo ou /foo.”

4. Les codes doivent être valides, et les règles de Google sont plus strictes que celles du HTML. La langue suit ISO 639-1, deux lettres. La région, si tant est qu’il vous en faille une, suit ISO 3166-1 alpha-2. Google écrit noir sur blanc que “seuls les codes de langue listés dans ISO 639-1 et les codes de région listés dans ISO 3166-1 Alpha 2 sont supportés ; les autres codes, comme es-419, ne le sont pas”.

C’est là que vit une demi-vérité répandue. Les articles SEO affirment que le hreflang suit BCP 47. La norme HTML exige bien un tag BCP 47 valide. Mais Google en applique un sous-ensemble : il rejette les codes de région UN M.49 que BCP 47 autorise, es-419 étant l’exemple donné par Google lui-même. Les deux affirmations sont vraies, à deux étages différents. Ne les confondez pas.

Les conséquences à retenir :

en-UK est invalide. Le code pays du Royaume-Uni est GB. Google précise qu’utiliser EU, UN ou UK “n’a aucun effet sur Google Search”.
Les codes de langue à trois lettres échouent. ISO 639-1, c’est le jeu à deux lettres.
Une région seule est invalide. hreflang="us" ne veut rien dire. Google : “Spécifier la région seule n’est pas valide.”
fr-FR est presque toujours une erreur. Cela cible les francophones en France. À moins de servir réellement un contenu différent à la Belgique ou au Canada, utilisez fr.

5. hreflang et canonical doivent concorder. Chaque version linguistique est sa propre URL canonique. La doc de canonicalisation de Google dit : “Si vous utilisez des éléments hreflang, veillez à spécifier une page canonique dans la même langue.”

Si votre page française se canonicalise vers l’anglaise, vous avez dit à Google que la française est un doublon à ne pas indexer. Une page que Google refuse d’indexer ne peut pas être échangée, et tout le groupe s’effondre. Le canonical est le signal d’indexation, le hreflang est la couche de localisation posée par-dessus.

x-default, en bref

Recommandé, pas obligatoire. Google : “la valeur réservée x-default est utilisée quand aucune autre langue ou région ne correspond au réglage du navigateur.” Elle a été introduite en 2013 spécifiquement pour les pages de sélection de langue et les accueils qui redirigent. La langue de la page x-default n’a aucune importance.

Google Search Console ne vous alertera pas

C’est le point que la plupart des articles ratent, y compris une version antérieure de celui-ci.

Search Console avait un rapport Ciblage international, avec un onglet hreflang qui listait les erreurs du type “pas de balises de retour”. Google l’a déprécié le 24 août 2022 et retiré le mois suivant, expliquant que le réglage de ciblage pays “apportait peu de valeur à l’écosystème”, tout en précisant que “Google continuera de supporter et d’utiliser les balises hreflang”.

Rien ne l’a remplacé. En 2026, il n’existe aucun rapport hreflang dans Search Console. Il ne vous dira ni que votre réciprocité est cassée, ni que vos codes sont invalides.

Ce qui reste possible dans GSC est indirect :

L’inspection d’URL confirme qu’un alternate renvoie 200, est indexable, et quelle canonique Google a retenue. Elle ne valide pas le hreflang.
Le rapport Indexation des pages montre le symptôme en aval, des alternates exclus de l’index, pas la cause.

Les vrais outils sont donc hors de Search Console, et la documentation de Google en met deux en lien dans sa section de débogage : le générateur hreflang d’Aleyda Solis et l’outil de test hreflang de Merkle sur technicalseo.com, qui valide les balises HTML comme les en-têtes HTTP et attrape les défauts de réciprocité. Pour auditer les balises de retour sur tout un site, crawlez avec Screaming Frog ou Sitebulb.

Le contrôle qui attrape presque tout

Prenez une page. Listez chacune de ses versions linguistiques. Pour chacune, posez deux questions :

Pointe-t-elle vers toutes les autres ?
Pointe-t-elle vers elle-même ?

Si les deux réponses sont oui pour chaque version, et que chaque alternate renvoie 200, est indexable et se canonicalise elle-même, le groupe est presque certainement sain. C’est tout le travail.

Un dernier point, souvent oublié : les alternates hreflang ne doivent pointer ni vers des redirections ni vers des pages en noindex. La doc de Google ne l’énonce pas en une phrase citable, traitez-le donc comme un raisonnement et non comme une écriture : le hreflang échange une URL qui se classe déjà, et une 3xx ou une page noindex ne peut jamais être cette URL. Mueller a dit séparément que noindex et canonical sont des signaux contradictoires ; la même logique s’applique ici.

Et Bing

L’affirmation périmée selon laquelle “Bing ignore le hreflang” ne tient plus. En décembre 2025, le blog webmaster de Bing le recommandait explicitement : “Utilisez le hreflang pour définir le ciblage linguistique et régional.” Bing exécute aussi moins de JavaScript que Google, ce qui compte pour la section suivante.

Où Page Translator se situe, honnêtement

Page Translator injecte les balises hreflang en Pro. Il le fait avec un script qui s’exécute dans le navigateur et ajoute les balises à document.head au runtime. Ce n’est aucune des trois méthodes côté serveur ci-dessus.

La raison est une contrainte de plateforme, pas un raccourci. Framer rend l’attribut lang et les balises hreflang à partir de ses Locales natives payantes et les verrouille : sa documentation indique que les services de traduction tiers ne peuvent modifier ni ces attributs ni le code source du site. Le seul levier d’un plugin, c’est le custom code, qui est site-wide et que l’utilisateur peut désactiver à tout moment.

Ce que ça implique en pratique :

Google exécute le JavaScript et peut voir ces balises. Ce n’est pas rien, mais c’est plus faible que des balises présentes dans le HTML servi, et cela suppose que Google rende chaque page alternative pour que la réciprocité se résolve.
Bing et les autres crawlers exécutent moins fiablement le JavaScript : partez du principe qu’ils ne les verront peut-être pas.
Si le custom code des plugins est désactivé dans les réglages de votre site Framer, les balises disparaissent, et le plugin ne peut pas le réactiver.

Si un hreflang rendu côté serveur est une exigence ferme pour votre projet, les Locales natives de Framer sont la bonne réponse, tout comme Weglot et Linguana, qui le servent tous depuis le serveur. Nous préférons vous le dire plutôt que de vous vendre un plugin qui vous laisserait vous demander pourquoi vos alternates ne sont jamais pris en compte.

Quoi que vous utilisiez : ouvrez le code source, passez la page dans l’outil de Merkle, vérifiez que les balises sont là et réciproques. Search Console ne le fera pas pour vous.

Sources primaires : Google Search Central, Tell Google about localized versions of your page (mis à jour le 22 décembre 2025) ; Consolidate duplicate URLs (mis à jour le 27 mars 2026) ; The International Targeting report is deprecated ; Bing Webmaster Blog, décembre 2025. Vérifié le 9 juillet 2026.