Hreflang : implémentation, erreurs fréquentes et contrôles

À quoi sert hreflang, et à quoi il ne sert pas

Hreflang déclare une relation entre plusieurs URL qui portent le même contenu dans des langues ou des régions différentes. La documentation de Google sur les versions localisées décrit trois cas typiques : un gabarit traduit alors que le contenu principal reste dans une seule langue, un contenu identique décliné par région, et un site entièrement traduit.

Deux limites sont écrites noir sur blanc dans cette documentation. D’abord, Google n’utilise ni hreflang ni l’attribut HTML lang pour déterminer la langue d’une page : il s’appuie sur ses propres algorithmes. Ensuite, les versions localisées ne sont considérées comme des doublons que si le contenu principal n’est pas traduit. Un hreflang correct ne répare donc pas une page anglaise dont seuls les menus ont été traduits.

Si le problème porte sur deux pages françaises proches, ce n’est pas un sujet international : relisez notre article sur la cannibalisation SEO avant de toucher aux annotations. Et si des URL doivent être consolidées, c’est la canonique qui joue ce rôle, dans un mécanisme séparé.

Head, en-têtes HTTP ou sitemap : laquelle choisir ?

Celle que votre stack tient dans le temps. Google indique que les trois méthodes sont équivalentes de son point de vue, et qu’utiliser les trois simultanément ne présente aucun avantage en recherche tout en multipliant les implémentations à maintenir.

Balises dans le head

C’est le choix naturel pour un site rendu par pages, y compris quand les balises sont posées côté application. Sur digitalfranck.com, chaque article français déclare son équivalent anglais et lui-même dans le head, et l’article anglais fait l’inverse : c’est l’implémentation visible sur cette page, vérifiable dans son code source. La contrainte connue est que l’ensemble de liens doit être identique sur chaque version, et se trouver dans un head bien formé.

En-têtes HTTP

Utile pour les fichiers non HTML. Un livre blanc en PDF décliné en deux langues se signale avec un en-tête Link qui liste chaque variante, y compris la version demandée. C’est le seul cas où cette méthode s’impose vraiment pour un SaaS.

Sitemap XML

C’est la méthode la plus économe quand le nombre de paires devient grand ou que le head est déjà encombré. Chaque élément url reçoit un enfant xhtml:link par version, page elle-même incluse, avec l’espace de noms xmlns:xhtml déclaré. Google précise que ces éléments enfants ne comptent pas dans la limite d’URL du sitemap, et que les règles générales des sitemaps s’appliquent aussi aux extensions.

Pourquoi vos annotations sont ignorées

Parce qu’une condition documentée n’est pas remplie, pas parce que Google tarde. Deux causes reviennent dans la documentation officielle, et elles sont vérifiables en quelques minutes.

Le lien de renvoi manquant

Si la page A déclare la page B sans que B déclare A, les annotations peuvent être ignorées ou mal interprétées. Google explique la raison : sans cette réciprocité, n’importe quel site pourrait déclarer arbitrairement l’une de vos pages comme sa variante. En pratique, le défaut apparaît dès qu’une langue est générée par un autre gabarit ou un autre CMS que la langue d’origine.

La documentation admet un arbitrage utile quand l’ensemble complet devient ingérable : certaines langues peuvent être omises sur certaines pages, les paires qui se renvoient correctement restant traitées. La priorité donnée est explicite : lier de façon bidirectionnelle les nouvelles langues à la langue d’origine ou principale, avant de relier les nouvelles variantes entre elles.

Les codes invalides

Le premier code est la langue au format ISO 639-1, éventuellement suivi d’une région au format ISO 3166-1 Alpha 2. Indiquer seulement une région ne suffit pas : Google ne déduit pas la langue du pays. L’exemple donné dans la documentation est net, be désigne le biélorusse et non la Belgique, d’où fr-be, nl-be ou de-be selon le dialecte visé. Les codes réservés comme EU, UN ou UK n’ont aucun effet en recherche.

Autres points de forme à ne pas négliger : des URL complètes avec leur protocole, jamais de chemin relatif, et pas de combinaison des annotations hreflang avec d’autres attributs comme media dans une même balise link.

Quand plusieurs gabarits produisent les deux langues et que les ensembles divergent selon les modèles, un chantier de SEO technique sur l’indexation et les signaux d’URL règle la cause au niveau du gabarit, plutôt que page par page.

x-default : utile, mais pas partout

La valeur réservée x-default désigne la page à servir quand aucune version déclarée ne correspond aux paramètres de l’internaute. Elle n’attend aucun code de langue, puisque la langue de cette page n’est pas le critère. Google précise qu’elle a été conçue pour les pages de sélection de langue et les pages d’accueil qui redirigent, et que c’est là qu’elle fonctionne le mieux.

Pour un SaaS qui n’a pas de sélecteur, le choix consiste à désigner comme repli la version la plus complète ou la plus légitime commercialement. Google recommande par ailleurs une URL collectrice sans région quand plusieurs variantes ciblent la même langue dans des pays différents, par exemple une page en générique au-dessus de en-ie, en-ca et en-au.

Les contrôles à passer avant mise en ligne

Un hreflang se vérifie sur le rendu réel, pas sur l’intention du développeur. Cinq contrôles suffisent à écarter la quasi-totalité des défauts documentés.

• Ouvrir le code source rendu des deux versions et confirmer que chacune déclare l’autre et elle-même, avec des URL absolues.
• Comparer les ensembles ligne par ligne : une variante présente d’un côté et absente de l’autre est un défaut, pas une approximation.
• Valider chaque code contre les listes ISO 639-1 et ISO 3166-1 Alpha 2, en traitant UK comme une erreur.
• Vérifier qu’une seule méthode est en place, et qu’un ancien sitemap ne contredit pas les balises du head.
• Contrôler la canonique de chaque version : elle doit désigner cette version, pas la version d’une autre langue.

Google ne fournit plus de rapport d’internationalisation dans Search Console ; la documentation de dépannage renvoie explicitement à des outils tiers, en précisant qu’ils ne sont ni gérés ni vérifiés par Google. Le contrôle manuel des paires reste donc la référence, et il est court quand le site n’a que deux langues.

Si le sujet dépasse les annotations et touche la structure des deux versions, un audit SEO qui hiérarchise les blocages évite de traiter la traduction, l’indexation et l’architecture comme un seul chantier.

Un contenu traduit ne suffit pas à mériter sa version

C’est la limite la plus souvent ignorée. Un hreflang parfait ne donne aucune raison à une version anglaise d’exister si elle reprend mot pour mot une page française sans adapter les exemples, les preuves ni les intentions de recherche du marché visé.

La documentation Google sur la gestion des sites multirégionaux traite justement la question en amont : quelle structure d’URL, quel ciblage, quelle version pour quel public. Ces décisions précèdent l’attribut, et c’est là que se joue la performance réelle d’un site multilingue.

Sur un SaaS, la version anglaise sert souvent une demande différente, avec d’autres concurrents et d’autres requêtes. Une stratégie de contenu construite par marché produit plus de résultats qu’une traduction propre correctement annotée.