Hreflang et SEO multilingue : les erreurs qui coûtent cher

Ce que Google demande, en trois règles

Le hreflang est l’annotation qui dit à Google « cette page existe aussi en anglais, ici, et en allemand, là ». Sur le papier, c’est simple. La documentation de Google sur les versions localisées tient en trois règles qu’il faut connaître par cœur :

• Les liens vont dans les deux sens. Si la page X annonce la page Y, Y doit annoncer X. Sinon, écrit Google, les annotations peuvent être ignorées ou mal interprétées.
• Chaque version se liste elle-même en plus de toutes les autres.
• x-default désigne la page de repli, servie quand la langue du visiteur ne correspond à aucune version.

Google précise aussi qu’une page traduite n’est considérée comme un doublon que si son contenu principal n’a pas été traduit. Retenez-le pour la suite : traduire le menu et laisser le reste en anglais ne fait pas une version localisée.

Ce que la documentation ne dit pas, parce que cela va de soi, c’est qu’un hreflang doit pointer vers une page qui existe. C’est pourtant là que se logent les erreurs les plus coûteuses, parce qu’elles sont invisibles à l’œil nu : la page s’affiche bien, seul le code source ment.

Ce que nous avons trouvé sur Palmora, en six langues

Palmora Property, notre agence immobilière à Phuket, publie son site en anglais, français, thaï, russe, chinois et allemand. Six langues, c’est six occasions de se tromper sur chaque page. Voici les erreurs relevées et ce qui les a corrigées.

1. Des langues annoncées qui n’existent pas (corrigé le 22 juillet 2026)

Le gabarit des articles de blog émettait systématiquement les six hreflang et un x-default, que la traduction existe ou non. Or une bonne partie des articles est écrite pour une seule nationalité : un guide fiscal pour les acheteurs français n’a pas de raison d’exister en thaï. L’audit du 22 juillet 2026 a vérifié en production un article en français seulement : cinq hreflang sur six et le x-default menaient à des 404.

Vingt-quatre groupes d’articles étaient touchés : dix-neuf articles en une seule langue et cinq traduits dans cinq langues sur six. Le plus agaçant : le sitemap du blog, lui, faisait juste. Il ne listait que les langues existantes. Le site envoyait donc deux signaux contradictoires.

La correction : ne générer un hreflang que pour les langues où l’article existe réellement, avec la même logique que le sitemap. Pour le x-default, l’anglais quand il existe, sinon la langue d’origine. Aujourd’hui, l’article français seul n’annonce que lui-même, en français et en x-default.

2. La page 404 qui répondait en anglais à tout le monde (corrigé le 18 septembre 2026)

Quand une adresse n’existe pas, le site affiche la page 404 par réécriture interne. Effet de bord : après cette réécriture, le site croyait être sur /404 et perdait la langue de l’adresse demandée. Un visiteur allemand qui tapait une mauvaise adresse recevait une page d’erreur en anglais, menu et pied de page compris, dans les six langues.

La correction lit la langue dans l’adresse d’origine, pas dans l’adresse réécrite. La 404 est servie en noindex, sans canonique ni hreflang : une page d’erreur n’a pas de traduction à annoncer.

3. Des titres « traduits » qui ne l’étaient pas (corrigé le 18 septembre 2026)

Les pages de liste assemblaient leur titre en collant un type de bien et un type de contrat. En allemand, cela donnait « Villas Zu verkaufen », avec une majuscule de trop et un ordre de mots faux. En thaï, russe, chinois et allemand, les balises title et description restaient en anglais. Pour Google, une page dont le titre et la description sont en anglais mais annoncée en russe envoie un signal confus ; pour le visiteur, c’est un site qui ne parle pas vraiment sa langue.

La correction : des gabarits complets par langue, avec les formes au singulier et au pluriel, et l’accord avec le nombre (le russe en a trois). Plus jamais de concaténation de mots dans un composant. Nous revenons sur ces gabarits dans l’article sur le SEO programmatique : sur un catalogue généré, une erreur de gabarit se répète sur toutes les pages qu’il produit.

4. Une langue routée mais oubliée ailleurs (corrigé le 18 septembre 2026)

L’allemand avait toutes ses adresses, mais il manquait dans plusieurs listes de langues du code, si bien que certaines pages répondaient 200 avec un corps vide. Rien d’hreflang ici, mais la même cause : une langue ne se résume pas à ses adresses. Elle doit exister partout où le code liste les langues.

Ce que nous avons fait sur notre propre site

Brain Plus AI montre l’erreur inverse. Le site a longtemps été produit en quatre langues : anglais, français, espagnol et chinois. Le 24 juillet 2026, nous avons décidé de ne garder que l’anglais et le français. Seize mois de Search Console montraient 15 clics sur la partie espagnole et aucun sur la partie chinoise, presque tous sur des requêtes de marque que l’anglais captait aussi bien.

Sauf que la décision n’avait pas été exécutée. L’audit du 9 septembre 2026 a trouvé 18 pages espagnoles et chinoises toujours produites, déclarées au sitemap et annoncées en hreflang depuis toutes les pages, avec l’ancien positionnement traduit.

Nous les avons archivées le jour même : pages supprimées, redirections 301 de /es/ et /zh/ vers l’équivalent anglais, hreflang limité à l’anglais et au français. Deux règles sont depuis écrites dans le code du gabarit : un hreflang ne pointe jamais une 404, et une page en noindex n’en émet aucun.

La leçon : une langue qu’on arrête se retire comme une page qu’on supprime, avec ses redirections et ses annotations. La laisser en place « en attendant » coûte plus cher que de trancher.

La liste de contrôle

Avant de mettre en ligne un site multilingue, ou pendant l’audit d’un site existant :

1. Suivre chaque hreflang servi et vérifier qu’il répond 200. Pas sur un échantillon : sur toutes les pages, par script. Un gabarit qui ne traduit que le préfixe de langue d’une adresse traduite (/fr/produits/ annoncé en /en/produits/ au lieu de /en/products/) passe inaperçu sur un échantillon, parce que les pages construites autrement sont justes.
2. Vérifier la réciprocité. Chaque version annonce toutes les autres, elle comprise, et toutes l’annoncent en retour.
3. Comparer les hreflang des pages et ceux du sitemap. Deux sources qui disent des choses différentes, c’est au mieux un signal ignoré.
4. Choisir le x-default en connaissance de cause : la version générale, ou la langue d’origine quand il n’y a qu’une version.
5. Lire les balises, pas seulement la page : title, description et H1 traduits, pas collés mot à mot.
6. Taper une mauvaise adresse dans chaque langue et vérifier que la 404 répond dans la bonne langue, en noindex.
7. Retirer proprement une langue abandonnée : 301, plus aucun hreflang, plus rien au sitemap.

Ces contrôles font partie de notre audit SEO, et toute migration vers un site statique les refait : changer de moteur est le moment où l’on reconstruit le gabarit, donc le moment où l’on corrige ou casse les hreflang. Ils entrent aussi dans le socle de notre moteur SEO et GEO, qui répare le site avant d’écrire le moindre article.

Le multilingue n’est qu’un volet d’un audit : nous décrivons le reste dans ce qu’une agence SEO doit livrer à l’heure de l’IA.

Questions fréquentes

Faut-il traduire toutes les pages dans toutes les langues ? Non. Un article écrit pour un public précis peut n’exister que dans une langue : un guide fiscal pour les acheteurs français n’a pas sa place en thaï. Il suffit que son hreflang le dise, en n’annonçant que les versions qui existent, et que le sitemap dise la même chose. Annoncer une traduction absente envoie le moteur vers une 404.

Le hreflang suffit-il à faire ranker une page traduite ? Non. Il aide Google à servir la bonne version au bon visiteur, mais il ne fait pas monter une page dans les résultats. Il ne remplace ni un contenu réellement traduit, titre et description compris, ni des liens internes dans la bonne langue. Une page traduite sans liens qui y mènent reste une page que le moteur trouve mal.

Hreflang dans les pages ou dans le sitemap ? Les trois méthodes que Google accepte, balises dans la page, en-têtes HTTP (utiles pour un PDF) et sitemap, se valent à ses yeux. Les cumuler n’apporte rien, et Google note que trois mises en œuvre se gèrent plus mal qu’une. Si vous en gardez deux, elles doivent annoncer exactement les mêmes versions : sur un site généré, produisez-les depuis la même liste de traductions.