Kamaankamaan

Balises hreflang expliquées : la bonne façon de les configurer pour un blog

Hreflang est un signal de relation, pas un signal de classement. Ce guide montre où hreflang peut vivre (HTML head, sitemap XML, en-têtes HTTP), les cinq erreurs qui tuent les classements et ce que Kamaan émet automatiqu

Junaid Khalid
Junaid Khalid
28 mai 2026 · 13 min read

Votre implémentation hreflang est probablement cassée. L'erreur ne remonte généralement pas dans votre tableau de bord de trafic. Elle remonte des mois plus tard quand la version espagnole d'un article se classe à la position 4 en Espagne, la version allemande n'apparaît pas du tout en Allemagne, et la version française se classe d'une façon ou d'une autre pour des requêtes en anglais au Canada. Le correctif est rarement un changement de code. C'est presque toujours une incompréhension structurelle de ce qu'est hreflang, où il va et quelle règle de validation a été cassée.

Ce guide vous montre les trois endroits où hreflang peut vivre (HTML head, sitemap XML, en-têtes HTTP), les règles que Google applique réellement, les cinq erreurs qui causent la majorité des échecs de classement, et ce que Auto-Multilingual Delivery de Kamaan émet automatiquement pour que vous n'ayez à penser à rien de tout cela.

À retenir rapidement

  • Hreflang est un signal de relation, pas un signal de classement. Il dit à Google quelle version montrer sur quel marché. Il ne vous fait pas monter dans la SERP.
  • Trois méthodes d'implémentation existent : balises link HTML dans <head>, annotations xhtml:link dans le sitemap XML, et en-têtes HTTP Link. Choisissez-en une et tenez-vous-y. Les mélanger est la source la plus fréquente d'erreurs de validation.
  • Chaque annotation hreflang doit être réciproque. Page A pointe vers Page B, Page B pointe vers Page A. Manquez ça et Google ignore les deux annotations en silence.
  • La valeur x-default dit à Google quoi servir quand aucune version de langue ne correspond. Sans elle, Google devine.
  • Les URL hreflang doivent renvoyer HTTP 200. Une redirection 301 ou un 404 casse l'ensemble du cluster d'annotations, pas seulement la page cassée.

Miniature blog Kamaan : 'Hreflang for Blogs' avec sous-titre 'La bonne façon de configurer hreflang pour que Google classe chaque version de langue de votre blog.'

Ce que hreflang fait réellement (et ne fait pas)

Hreflang est une balise qui dit aux moteurs de recherche : "cette page existe dans une autre langue ou région à cette URL." C'est tout son périmètre. Elle ne dit pas à Google qu'une page est plus importante. Elle ne booste pas les classements. Elle ne remplace pas un sitemap. Elle ne se substitue pas au contenu traduit.

Ce que hreflang fait, c'est résoudre un problème spécifique : quand Google a crawlé cinq versions de langue du même article, laquelle doit-il faire remonter pour une recherche à Madrid versus Berlin versus Lyon ? Sans hreflang, Google devine en se basant sur des signaux comme la langue du contenu de la page, l'IP de l'utilisateur et le TLD du domaine. Avec hreflang, Google a une carte définitive.

Le mécanisme est une déclaration de relation. Chaque page d'un cluster de langues fait référence à chaque autre page du cluster, y compris elle-même. Si votre blog a des versions anglaise, espagnole, allemande, française et italienne d'un article, chacune de ces cinq pages déclare les cinq URL avec leurs codes de langue.

Le format est précis. Les codes de langue suivent ISO 639-1 (deux lettres, minuscules) : en, es, de, fr, it. Les codes de région sont optionnels et suivent ISO 3166-1 Alpha 2 (deux lettres, majuscules) : en-US, en-GB, es-MX, es-ES. Vous les combinez avec un tiret : en-US, de-AT, fr-CA. Il n'y a pas de prise en charge des codes à trois lettres. Il n'y a pas de séparateur underscore. Il n'y a pas d'imbrication.

Les trois méthodes d'implémentation comparées

Vous pouvez placer les annotations hreflang dans l'un des trois endroits. Le bon choix dépend du nombre de langues que vous servez et de votre contrôle sur la réponse du serveur.

Le tableau ci-dessous cartographie les compromis de chaque approche pour que vous choisissiez la bonne pour votre blog.

Méthodes d'implémentation hreflang comparées : balises HTML link dans head (simple, le poids de la page croît), sitemap XML xhtml:link (centralisé, zéro poids HTML), et en-têtes HTTP Link (plus propre pour non-HTML)

Méthode Où elle vit Idéal pour Ce qui la casse
Balises HTML <link> Dans <head> de chaque page Sites avec 5 langues ou moins Le poids de la page croît avec chaque langue. Facile d'en oublier une.
Sitemap XML Dans xhtml:link à l'intérieur de chaque <url> Sites avec 6+ langues, 100+ pages Discipline sitemap requise. Latence de re-crawl.
En-têtes HTTP Link Dans les en-têtes de réponse serveur Fichiers non-HTML (PDF, JSON, images) Config serveur requise. Les couches CDN suppriment les en-têtes.

Les balises HTML <link> se trouvent dans le <head> de chaque page du cluster :

<link rel="alternate" hreflang="en" href="https://example.com/blog/article" />
<link rel="alternate" hreflang="es" href="https://example.com/es/blog/article" />
<link rel="alternate" hreflang="de" href="https://example.com/de/blog/article" />
<link rel="alternate" hreflang="x-default" href="https://example.com/blog/article" />

Faciles à inspecter avec Afficher la source. L'inconvénient apparaît au-delà de cinq langues : le poids HTML grimpe à chaque ajout.

Les annotations sitemap XML déplacent la carte hreflang dans le sitemap sous forme d'éléments xhtml:link à l'intérieur de chaque <url> :

<url>
  <loc>https://example.com/blog/article</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/blog/article" />
  <xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/blog/article" />
</url>

Bon choix au-delà de cinq langues ou cent pages. Centralisé, auditable, HTML propre. Le coût est la latence de re-crawl.

Les en-têtes HTTP Link sont le bon choix uniquement pour les fichiers non-HTML (PDF, endpoints JSON). Le serveur émet un en-tête Link. Nécessite une config serveur et est fragile à travers les couches CDN qui suppriment les en-têtes personnalisés. Ne l'utilisez pas pour les pages HTML quand une alternative existe.

Les cinq erreurs qui tuent les classements

La plupart des échecs hreflang tombent dans l'une des cinq catégories. Chacune est réparable en moins d'une heure une fois que vous savez quoi chercher.

Erreur un : balises de retour manquantes. Chaque déclaration hreflang doit être réciproque. Si votre article anglais déclare la version espagnole à /es/blog/article, l'article espagnol doit déclarer la version anglaise à /blog/article. Si l'une des deux directions manque, Google appelle cela une erreur "no return tag" dans Search Console et ignore les deux annotations. C'est la règle de validation la plus échouée en SEO international, et elle remonte généralement des mois après un déploiement partiel de traductions, quand une version de langue a été publiée et les autres oubliées.

Erreur deux : codes de langue ou région incorrects. Les codes sont précis et impitoyables. Utilisez uk pour ukrainien, jamais ua. Utilisez zh-Hans pour chinois simplifié, pas zh-CN. Les codes à trois lettres ne fonctionnent pas. Un échec silencieux courant : écrire en-UK au lieu de en-GB (le Royaume-Uni est GB dans ISO 3166-1, pas UK).

Erreur trois : x-default manquant. La valeur x-default dit aux moteurs de recherche quelle page servir quand aucune version de langue ne correspond à l'utilisateur. Sans elle, Google décide par lui-même, servant généralement la version qu'il a le plus crawlée. Incluez toujours un x-default pointant vers votre version principale. Pour un blog dont la langue principale est l'anglais, fixez x-default à l'URL anglaise.

Erreur quatre : hreflang pointant vers une URL non-200. Chaque URL de votre cluster d'annotations doit renvoyer HTTP 200. Une redirection 301, un 404 ou un 500 casse l'ensemble du set d'annotations. Si vous redirigez /de/blog/old-slug vers /de/blog/new-slug, votre hreflang doit pointer vers le nouveau slug, pas vers la redirection. Si la traduction allemande n'existe pas encore, ne déclarez pas hreflang pour l'allemand. Un pointeur cassé est pire qu'un pointeur absent.

Erreur cinq : conflit avec la balise canonical. Si votre page espagnole a hreflang vers https://example.com/es/blog/article mais que cette page a un <link rel="canonical"> pointant vers l'URL anglaise, Google suit le canonical et ignore le hreflang. Chaque page d'un cluster hreflang doit s'auto-canoniser. La page espagnole canonise vers elle-même. La page allemande canonise vers elle-même. Les canonicals inter-langues annulent hreflang en silence.

Comment vérifier votre implémentation

Trois vérifications couvrent la plupart des modes de défaillance.

Utilisez Google Search Console. Naviguez vers Outils et rapports hérités, puis vers Ciblage international. Le rapport "No return tags" liste chaque page où la réciprocité est cassée. Le rapport "Unknown language code" liste chaque code invalide. Ces deux rapports font remonter la majorité des vraies erreurs hreflang.

Crawlez avec un outil. Screaming Frog, Sitebulb ou Ahrefs Site Audit valident les clusters hreflang à grande échelle. Crawlez votre site entier, filtrez par erreurs hreflang, et vous verrez chaque cluster avec balise de retour manquante, code incorrect ou cible non-200. Une vérification ponctuelle sur cinq articles ne suffit pas. Un blog multilingue a typiquement des centaines de clusters.

Testez les en-têtes et les balises directement. curl -I https://example.com/blog/article montre les en-têtes de réponse, y compris tout en-tête Link. Afficher la source sur la page montre les balises <link>. Le sitemap XML est à une URL de distance. Si vous ne trouvez votre hreflang dans aucun de ces trois endroits, vous n'avez pas hreflang implémenté, peu importe ce que prétend le tableau de bord de votre CMS.

Ce que Kamaan émet automatiquement

La diffusion multilingue automatique de Kamaan gère l'implémentation hreflang pour vous. Quand vous publiez un article en anglais, Kamaan crée automatiquement les versions espagnole, allemande, française et italienne, donne à chacune un slug localisé, et émet le set complet d'annotations hreflang réciproques sur chaque version. Les valeurs par défaut sont correctes dès le départ.

Concrètement, Kamaan émet des balises HTML <link> dans le <head> de chaque page de blog, avec le set complet d'alternatives de langue, y compris x-default pointant vers la version anglaise. Les URL traduites suivent le pattern /{lang}/blog/{slug} (préfixe de langue avant blog), ce qui correspond à la recommandation de Google pour les sites multilingues basés sur sous-dossiers. Chaque URL s'auto-canonise. La réciprocité est garantie parce que la même action de publication crée les cinq versions en une transaction.

Pour les blogs plus grands avec de nombreuses langues, Kamaan émet en plus la carte hreflang dans le sitemap XML sous forme d'annotations xhtml:link. Vous obtenez les deux méthodes gratuitement, ce qui est la redondance que la documentation de Google recommande pour les blogs qui opèrent à grande échelle.

L'enjeu n'est pas que Kamaan fasse quelque chose que personne d'autre ne peut faire. L'enjeu est que vous arrêtez de dépenser du temps d'ingénierie sur hreflang. Auto-Multilingual Delivery publie des versions espagnole, allemande, française et italienne de chaque article au moment où vous publiez en anglais, avec un hreflang valide sur chacune, et zéro étape supplémentaire.

Une checklist de configuration pratique

Avant de publier un blog multilingue, parcourez cette liste une fois. Puis automatisez-la (ou utilisez un CMS qui s'en charge pour vous).

  1. Choisissez une méthode d'implémentation. Balises HTML pour 5 langues ou moins. Sitemap XML pour 6 ou plus. En-têtes HTTP uniquement pour non-HTML.
  2. Confirmez que chaque page dans chaque langue a une annotation x-default pointant vers la version de langue principale.
  3. Confirmez la réciprocité. Chaque page du cluster fait référence à chaque autre page, y compris elle-même.
  4. Confirmez que chaque URL dans chaque annotation renvoie HTTP 200 (pas de redirections, pas de 404).
  5. Confirmez que chaque page du cluster a un canonical auto-référencé, pas un canonical inter-langues.
  6. Soumettez le sitemap (ou attendez le re-crawl).
  7. Vérifiez Ciblage international de Search Console après 7-14 jours pour les erreurs de balise de retour.

Si une étape de cette liste est automatisée par votre CMS, vous avez une chose de moins à casser. Si votre CMS ne fait aucune de ces choses, vous le faites manuellement et vous finirez par vous tromper sur l'une d'elles.

Scénarios du monde réel

Un fondateur qui exploite un outil SaaS de facturation B2B publie un article sur sa nouvelle fonctionnalité de facturation récurrente. En dix minutes, Kamaan a auto-publié les versions espagnole, allemande, française et italienne à /es/blog/, /de/blog/, /fr/blog/ et /it/blog/, chacune avec le bloc hreflang réciproque complet émis en HTML <head> et reflété dans le sitemap XML. Le rapport Ciblage international de Google Search Console montre zéro erreur "no return tag". Le fondateur n'a pas écrit une ligne de configuration hreflang.

Un développeur solo avait un blog Next.js avec hreflang manuel dans <head> pour trois langues. Ajouter une quatrième langue a cassé la réciprocité sur 60 pour cent des anciens articles parce que la nouvelle balise n'a été ajoutée qu'aux nouveaux posts. La migration vers Kamaan a aussi géré les articles historiques : la publication suivante a déclenché une ré-émission complète de la carte hreflang pour chaque article publié dans chaque langue. Le nombre d'erreurs dans Search Console est passé de 412 à 0 en un cycle de re-crawl.

FAQ

Ai-je besoin de hreflang si je n'ai qu'une seule langue ?

Non. Hreflang est un signal de relation entre variantes de langue ou région. Avec une seule langue, il n'y a rien à mettre en relation. Sautez-le.

Les balises hreflang aident-elles le SEO directement ?

Non, pas au sens du classement. Hreflang ne vous fait pas monter dans la SERP. Ce qu'il fait, c'est garantir que la bonne version de votre page se classe sur le bon marché. Cela peut se traduire par des gains de trafic, mais c'est une amélioration de routage, pas un boost de classement.

Puis-je utiliser hreflang sur une single-page app avec routage côté client ?

Oui, mais avec des réserves. L'annotation hreflang doit être dans la réponse HTML initiale, pas injectée après l'exécution de JavaScript. Googlebot lit la réponse initiale. Si vos balises <link rel="alternate"> n'apparaissent qu'après l'hydratation côté client, Google ne les verra pas. Rendez le head côté serveur ou utilisez la méthode sitemap.

Quelle est la différence entre x-default et en ?

x-default est un repli pour le cas où aucune langue ne correspond à l'utilisateur. en cible spécifiquement les chercheurs anglophones. Vous avez besoin des deux. x-default n'est pas un substitut de en, et en n'est pas un substitut de x-default.

Combien de temps faut-il pour que les changements hreflang prennent effet ?

Google doit re-crawler chaque page du cluster, ce qui peut prendre des jours à des semaines selon votre budget de crawl. Le rapport Ciblage international de Search Console se met à jour selon son propre calendrier et peut accuser un retard de 7-14 jours même après que Google a re-crawlé.

Pourquoi mon hreflang basé sur sitemap fonctionne mais pas mon hreflang HTML ?

Deux causes courantes. Soit les balises HTML sont injectées côté client après que Googlebot a fini de lire la page, soit vous avez un conflit canonical où la page cible hreflang vers une URL mais canonise vers une autre. Vérifiez les deux.

À lire aussi sur Kamaan

Démarrer avec Kamaan

Hreflang valide à chaque publication, zéro config

Kamaan vous donne un tableau de bord pour tous vos blogs produits, auto-traduits en 99+ langues à chaque publication. Un compte couvre des sites illimités à tarif forfaitaire. Le MCP Server vous permet de publier depuis Claude ou ChatGPT. Premier mois gratuit.

Démarrer gratuitement sur kamaan.io

Frequently asked

FAQ · 6 ITEMS
Ai-je besoin de hreflang si je n'ai qu'une seule langue ?

Non. Hreflang est un signal de relation entre variantes de langue ou région. Avec une seule langue, il n'y a rien à mettre en relation. Sautez-le.

Les balises hreflang aident-elles le SEO directement ?

Non, pas au sens du classement. Hreflang ne vous fait pas monter dans la SERP. Ce qu'il fait, c'est garantir que la bonne version de votre page se classe sur le bon marché. Cela peut se traduire par des gains de trafic, mais c'est une amélioration de routage, pas un boost de classement.

Puis-je utiliser hreflang sur une single-page app avec routage côté client ?

Oui, mais avec des réserves. L'annotation hreflang doit être dans la réponse HTML initiale, pas injectée après l'exécution de JavaScript. Googlebot lit la réponse initiale. Si vos balises `<link rel="alternate">` n'apparaissent qu'après l'hydratation côté client, Google ne les verra pas. Rendez le head côté serveur ou utilisez la méthode sitemap.

Quelle est la différence entre `x-default` et `en` ?

`x-default` est un repli pour le cas où aucune langue ne correspond à l'utilisateur. `en` cible spécifiquement les chercheurs anglophones. Vous avez besoin des deux. `x-default` n'est pas un substitut de `en`, et `en` n'est pas un substitut de `x-default`.

Combien de temps faut-il pour que les changements hreflang prennent effet ?

Google doit re-crawler chaque page du cluster, ce qui peut prendre des jours à des semaines selon votre budget de crawl. Le rapport Ciblage international de Search Console se met à jour selon son propre calendrier et peut accuser un retard de 7-14 jours même après que Google a re-crawlé.

Pourquoi mon hreflang basé sur sitemap fonctionne mais pas mon hreflang HTML ?

Deux causes courantes. Soit les balises HTML sont injectées côté client après que Googlebot a fini de lire la page, soit vous avez un conflit canonical où la page cible hreflang vers une URL mais canonise vers une autre. Vérifiez les deux.

Junaid Khalid
Written by
Junaid Khalid

Junaid Khalid is the founder of Kamaan, a headless blog CMS that auto-publishes in five languages and lets you manage every product blog from one dashboard.