À quoi sert vraiment une balise hreflang ?

Elle déclare à Google que deux URL sont la même page dans deux langues ou deux marchés, pour qu'il serve la bonne version au bon utilisateur au lieu d'arbitrer entre des pages qu'il pourrait juger dupliquées. Elle ne pousse aucune page dans le classement : elle oriente l'affichage, elle ne crée pas de position.

Quelle est l'erreur hreflang la plus fréquente ?

Sur notre panel, ce n'est pas une erreur de syntaxe : c'est l'absence de hreflang sur une partie des gabarits du site, relevée sur 4 sites sur 19. Pagination de blog, pages de catégorie et sections profondes portent zéro balise là où l'accueil en porte jusqu'à 116. Les quatre erreurs de syntaxe classiques, elles, n'apparaissent pas une seule fois.

Le x-default est-il obligatoire ?

Non. Google le recommande sans l'exiger, et 7 des 19 sites mesurés n'en servent aucun. Il est utile si vous avez une page de choix de langue ou une version par défaut pour les visiteurs qui ne correspondent à aucune locale déclarée. Compter son absence comme une erreur fausserait tout barème.

Faut-il mettre le hreflang dans le HTML, le sitemap ou l'en-tête HTTP ?

Les trois canaux sont valides pour Google. Sur nos 790 déclarations, les 790 viennent du <head> HTML et aucune de l'en-tête HTTP, et un site du panel ne publie son hreflang que dans son sitemap. Le sitemap allège les pages et centralise la maintenance ; le HTML se vérifie d'un simple curl. Ce qui compte, c'est de n'en utiliser qu'un seul et de s'y tenir.

Pourquoi mon outil d'audit signale-t-il des erreurs hreflang qui n'existent pas ?

Souvent parce qu'il envoie un en-tête Accept-Language. Sur notre premier passage, un Accept-Language: fr-FR fabriquait 5 redirections de cible et 3 canoniques variables qui disparaissent sans l'en-tête. Un robot d'indexation n'en envoie pas : auditez comme lui, sans en-tête de langue. Deuxième cause : les réponses vides ou en 202 lues comme des pages sans balise.

Comment vérifier son hreflang sans outil payant ?

Un curl -sL avec un User-Agent navigateur, sans Accept-Language, plus un grep sur <link[^>]*hreflang. Ouvrez ensuite chaque cible et relevez son code HTTP, son URL finale, ses propres balises et sa canonique. Comptez une page par gabarit, pas une page par section : c'est le seul moyen de voir le défaut le plus fréquent.

hreflang, SEO international : le gabarit oublié

Points clés de l'article

25 domaines multilingues publics figés avant la mesure, 23 mesurés, 110 pages, 790 déclarations hreflang, 305 cibles ouvertes. Relevé en HTTP seul, le 28 août 2026
Quatre erreurs de syntaxe classiques n'apparaissent pas une seule fois : auto-référence manquante 0 site sur 19, URL relative 0 déclaration sur 790, doublon conflictuel 0, balise hors du <head> 0
Le défaut le plus répandu est une balise absente, pas une balise fautive. 4 sites sur 19 servent du hreflang sur une partie seulement de leurs pages, et ce sont toujours les mêmes gabarits qui sautent : pagination de blog, pages de catégorie, sections profondes
2 sites multilingues ne servent aucun hreflang dans leur HTML alors qu'ils exposent 9 et 19 locales dans leurs propres liens
Aucun taux mesuré ne dépasse 4 sites sur 19, et tous sont des planchers : 5 pages par site ne disent rien de la sixième

Le scénario est toujours le même. Le hreflang est en place, l'agence l'a livré, l'outil d'audit affiche vert, et Google continue de servir l'anglais à des visiteurs français. La liste des six erreurs classiques circule depuis dix ans : auto-référence oubliée, URL relative, code de langue inventé, balise hors du <head>. On voulait la publier.

On a mesuré d'abord. La liste ne tient pas. Quatre de ces erreurs n'apparaissent pas une seule fois sur les 19 sites qui servent du hreflang dans notre panel. Le défaut dominant n'est pas une balise mal écrite, c'est une balise absente d'un gabarit entier. Voici le relevé, la méthode pour le refaire, et les trois vérifications à la main qui ont changé le résultat.

Ce qu'on a mesuré

25 domaines multilingues publics, figés avant la mesure sur critères éditoriaux : 8 SaaS français, 5 e-commerce, 5 marques internationales, 5 outils SEO, plus vydera.com et un second site de référence sur lequel on travaille. Un domaine par grappe hreflang, pour éviter de compter deux fois le même balisage.

23 ont été mesurés. Deux, blablacar.fr et decathlon.fr, répondent 403 dès l'accueil : c'est une mesure ratée, pas un résultat. On ne peut rien dire de leur hreflang, et ils sortent du dénominateur.

Sur chaque site, 5 pages tirées de façon déterministe : l'accueil après redirection, 2 pages de premier niveau réparties sur la liste des liens, 2 pages atteintes au second saut, les plus profondes disponibles. 113 pages tirées, 110 mesurées : trois échecs, un 403 derrière une protection anti-robot et deux URL d'obfuscation d'e-mail qui ne sont pas des pages.

Total : 790 déclarations hreflang, 564 cibles distinctes déclarées, 305 ouvertes, 570 requêtes HTTP. Aucun navigateur, aucun rendu JavaScript : User-Agent navigateur, requêtes HTTP nues, et surtout sans en-tête Accept-Language, parce qu'un robot d'indexation n'en envoie pas. On verra plus loin que ce détail change les chiffres.

Une précaution vaut pour tout ce qui suit. Tous les compteurs sont des planchers. Un défaut absent de 5 pages n'est pas un défaut absent du site. On écrit « au moins 4 sites sur 19 », jamais « 21 % des sites ».

Quatre erreurs de manuel, zéro occurrence

Le résultat le plus utile est un résultat négatif. Sur les 19 sites qui servent du hreflang :

Auto-référence manquante : 0 site sur 19. Les 80 pages porteuses de balises se déclarent toutes elles-mêmes.
URL relative : 0 déclaration sur 790. Toutes sont absolues, protocole et domaine compris.
Même code vers deux URL différentes : 0 site sur 19.
Balises servies hors du <head> : 0 site sur 19.

Deux contrôles supplémentaires ressortent aussi à zéro : aucune cible en 4xx sur les 305 ouvertes, et aucune cible qui retombe sur sa page de départ.

Le hreflang mal écrit est un problème largement résolu sur des sites de ce calibre. Les CMS génèrent le balisage, et un générateur ne se trompe pas de syntaxe. Il se trompe de périmètre.

Le défaut n°1 : le gabarit que le CMS oublie

Un seul contrôle dépasse 2 sites : le hreflang présent sur une partie seulement des pages du site. 4 sites sur 19, et le mécanisme est identique chez les quatre.

dashlane.com : accueil et page à propos portent 5 déclarations. Les trois pages de /resources/category/* en portent zéro.
ahrefs.com : accueil et page à propos portent 14 déclarations. Les deux pages de /blog/category/* en portent zéro.
oncrawl.com : accueil, blog et page produit portent 3 déclarations. /blog/page/2/ et /blog/page/3/ en portent zéro.
ikea.com : l'accueil global porte 116 valeurs hreflang. Les quatre pages de /global/en/* en portent zéro.

Le motif saute aux yeux : le balisage est posé par les gabarits d'accueil et de contenu, et il disparaît sur les gabarits de liste, de catégorie et de pagination. Personne ne l'a supprimé. Personne ne l'a jamais ajouté, parce que ces gabarits ont été écrits ailleurs, souvent plus tard, souvent par quelqu'un d'autre.

La conséquence est mécanique, et il faut la formuler pour ce qu'elle est : sur ces pages, Google n'a aucun signal de locale déclaré. Ce que le moteur décide de servir à leur place, notre mesure ne le dit pas : on n'a relevé aucune SERP et aucune donnée de position par langue. Mais l'absence de signal, elle, est mesurée.

D'où une règle de travail simple : auditez par gabarit, pas par page. Listez les gabarits de votre site, prenez-en un exemplaire de chaque, et commencez par ceux que personne ne regarde jamais : page 2 d'un blog, page de catégorie, archives par auteur, résultats de recherche interne, pages légales, sections corporate sous un chemin à part.

SEO international : le trou le plus large est l'absence totale

Avant même de parler d'erreurs, il y a les sites qui ne servent rien. Sur les 23 domaines mesurés, 3 ne servent aucune balise hreflang, ni dans leur HTML ni dans leur sitemap. Le cas est plus intéressant qu'il n'en a l'air, parce que les trois ne se ressemblent pas.

qonto.com : zéro hreflang, et 9 segments de locale exposés dans les liens de sa propre page d'accueil (de, de-at, en, es, fr, fr-be, it, nl, pt).
deepl.com : zéro hreflang, et 19 segments de locale dans les liens de son accueil.
screamingfrog.co.uk : zéro hreflang, et zéro segment de locale. Le site est monolingue : son absence de hreflang est le comportement correct, pas un défaut. Le compter comme fautif serait une erreur de lecture.

Reste donc 2 sites multilingues sur 22 qui ne déclarent aucune correspondance de langue dans le HTML servi. Un quatrième, pennylane.com, n'en sert aucun dans son HTML mais en publie dans son sitemap, qui est un canal reconnu par Google.

Une réserve capitale ici, et elle tient à la méthode : on parle du HTML servi, pas du DOM rendu. Sans navigateur, un hreflang injecté en JavaScript reste invisible. On ne sait donc pas si qonto.com et deepl.com en injectent côté client. Ce qu'on sait, c'est qu'aucun n'est présent dans la réponse HTTP, et c'est déjà un pari : la question du HTML servi contre le rendu, on l'a traitée en détail dans notre mesure sur le rendu JavaScript.

Les défauts de balise, tous à 1 ou 2 sites

Les cinq autres contrôles positifs concernent 1 ou 2 sites chacun. L'écart entre ces rangs ne veut rien dire : à ces effectifs, aucun test statistique n'a de sens, et un site de plus ou de moins renverse le classement. Ils valent comme cas, pas comme fréquences.

Codes hors ISO, 2 sites. ikea.com déclare in-ID (le code de langue in a été retiré au profit de id pour l'indonésien), es-SP (l'Espagne est ES, SP n'est pas un pays) et es-CE (aucune région CE dans ISO 3166-1). ovhcloud.com déclare asia, qui n'est pas un code de langue : le premier segment d'un hreflang est toujours une langue, jamais une zone géographique. Couvrir une région demande une ligne par pays.

Cible qui redirige vers une troisième URL, 2 sites. 360learning.com déclare des pages /lp/ qui redirigent vers /use-cases/. similarweb.com déclare une page produit redirigée vers sa catégorie, dans 4 locales d'un coup. Dans les deux cas, le couple annoncé n'existe pas tel quel : c'est la trace d'une refonte d'URL que le balisage n'a pas suivie.

Auto-référence approximative, 1 site. dashlane.com sert /about et y déclare hreflang="en" vers /about/, avec le slash final que la page servie n'a pas. L'auto-référence est là, elle n'est simplement pas exacte. C'est le genre d'écart qu'aucune relecture humaine ne voit et que seule une comparaison caractère par caractère attrape.

Canonique de la cible qui désigne une autre URL, 1 site. oncrawl.com déclare fr vers fr.oncrawl.com, dont la canonique pointe vers www.oncrawl.com, la version anglaise. Le balisage envoie vers une page qui dit elle-même ne pas être la bonne. Canonique et hreflang doivent raconter la même histoire, sinon la canonique gagne. Le même conflit revient dans les causes de non-indexation.

Réciprocité contredite, 1 site. ikea.com de nouveau. Sur 8 cibles testées depuis l'accueil global, 7 servent une page canonique d'elle-même, avec zéro balise hreflang. La huitième, ikea.gr/en/, ne déclare que el-gr et en-gr et ne renvoie pas vers le point de départ.

Réciprocité : 287 sur 305, et pourquoi ce n'est pas un taux

Sur les 305 cibles ouvertes, 287 renvoient bien vers leur page de départ, 10 redirigent vers une autre URL, 7 ne servent aucune balise, 1 en sert qui ne renvoient pas à la source.

Le chiffre a l'air excellent. Il faut le lire deux fois. 305 cibles ouvertes sur 564 déclarées, soit 54 %. La sonde plafonne à 8 cibles par page, et 19 pages ont été tronquées à ce plafond. La réciprocité des 259 autres n'est pas connue. On mesure donc un plancher sur un échantillon lui-même plancher.

Ce que le chiffre établit malgré tout : quand une cible est ouverte, elle confirme la paire dans la grande majorité des cas. La réciprocité n'est pas une politesse, c'est la condition de validité. Un hreflang que la cible ne confirme pas est ignoré.

Trois vérifications à la main qui ont changé le résultat

C'est la partie que les audits publient rarement, et c'est celle qui a le plus de valeur pour quiconque refait ce genre de mesure. Trois fois, le premier passage a produit un résultat faux.

1. Un HTTP 202 avec 0 octet n'est pas une page sans hreflang. similarweb.com répondait 202 et un corps vide sur ses pages de locale. Le script en concluait « zéro balise » et fabriquait 8 fausses ruptures de réciprocité. Requalifié en mesure ratée, puis détecté par le script. La règle générale : une réponse vide, un 202, un 403, un 429 ou une page de vérification anti-robot se classent non mesurés, jamais « sans hreflang ».

2. Un en-tête Accept-Language fabrique des défauts qui n'existent pas. Le premier passage envoyait Accept-Language: fr-FR, comme le ferait un navigateur français. Résultat : 5 redirections de cible apparaissaient, la version anglaise de payfit.com, spendesk.com et dashlane.com retombant sur la page française. Sans l'en-tête, elles disparaissent toutes. Ces trois sites servent aussi une canonique différente selon la langue annoncée : dashlane.com/business-password-manager/buy se déclare canonique d'elle-même sans en-tête, et canonique de sa version française avec Accept-Language: fr-FR. Ce n'est pas une erreur hreflang, et un robot d'indexation ne le verra jamais. Auditez toujours sans en-tête de langue. Sinon vous auditez ce que votre navigateur voit, pas ce que le moteur voit.

3. Deux clients HTTP ne comptent pas la même chose. curl annonçait 0 balise sur ikea.gr/en/ et sur ikea.com/ee/et/ là où le fetch de Node en voyait 2 et 0. Les 7 cibles à zéro balise ont donc été rouvertes par une requête indépendante : canoniques d'elles-mêmes, zéro balise confirmée. Quand deux outils divergent, aucun des deux n'est la mesure : la mesure, c'est le troisième relevé.

vydera.com passe au même banc

Notre site est passé par le même code que les 24 autres, sans traitement particulier. 5 pages sur 5 portent du hreflang, 3 valeurs déclarées (fr, en, x-default), auto-référence stricte sur les 5, réciprocité vérifiée avec la version anglaise, canonique cohérente. Aucun des 12 défauts relevé.

Deux réserves, parce qu'un plancher n'est pas un quitus. D'abord, 5 pages sur un site qui en compte 168 ne prouvent rien des 163 autres : la règle du plancher vaut pour nous exactement comme pour ikea. Ensuite, notre x-default désigne la version française, pas l'anglaise. C'est un choix assumé pour une agence dont le marché premier est la France, et on ne prétend pas savoir ce que Google en fait.

Le second site de référence du panel, sur lequel on travaille et qu'on ne nomme donc pas ici, affiche 5 pages sur 5, 5 valeurs déclarées et aucun défaut relevé. Même réserve de plancher.

Refaire la mesure chez vous

Rien de tout ceci ne demande d'outil payant. Le protocole tient en quatre étapes.

Listez vos gabarits, pas vos pages. Un exemplaire de chaque : accueil, page de contenu, page produit, page de catégorie, page 2 d'une pagination, page légale, section corporate. C'est là que se trouve le défaut n°1.
Récupérez le HTML servi, sans en-tête de langue. Un curl -sL avec un User-Agent navigateur suffit. Pas de Accept-Language.
Ouvrez chaque cible déclarée et relevez quatre choses : le code HTTP, l'URL finale après redirection, les balises hreflang de la cible, sa canonique. Une paire n'est valide que si les quatre concordent.
Classez les échecs comme échecs. 403, 429, 202 vide, timeout : non mesuré. Un site qu'on n'a pas ouvert n'est pas un site sans hreflang.

Le bloc ci-dessous fait les six contrôles qui se lisent dans le HTML d'une seule page, et vous génère la boucle curl pour les contrôles qui demandent d'ouvrir les cibles. Rien de ce que vous saisissez ne quitte votre navigateur.

Ce que cette mesure ne dit pas

Le plus important d'un relevé, c'est son périmètre. Celui-ci s'arrête net à plusieurs endroits.

Le hreflang injecté en JavaScript. Aucun rendu n'a été fait. Tout ce qui précède porte sur le HTML servi.
blablacar.fr et decathlon.fr. 403 dès l'accueil, donc rien à en dire.
259 cibles déclarées sur 564 n'ont pas été ouvertes, faute de place sous le plafond de 8 par page.
Aucune donnée de position, de trafic ou d'impression par locale. Rien ici ne relie une erreur hreflang à une perte mesurée, et personne ne devrait le déduire de ces chiffres.
Aucune SERP relevée. On ne sait pas quelle version linguistique Google sert réellement pour ces domaines.
Aucun historique. C'est une photo prise le 28 août 2026, pas une tendance.

Ce qu'il reste, une fois ces réserves posées, tient en une phrase : sur des sites de ce niveau, la syntaxe hreflang est un problème réglé, et la couverture ne l'est pas. Cherchez les gabarits, pas les fautes de frappe.

Pour les définitions : indexation et crawl. Et si le sujet est le déploiement d'un site sur plusieurs marchés, c'est notre offre de localisation.

À quoi sert vraiment une balise hreflang ?
Elle déclare à Google que deux URL sont la même page dans deux langues ou deux marchés, pour qu'il serve la bonne version au bon utilisateur au lieu d'arbitrer entre des pages qu'il pourrait juger dupliquées. Elle ne pousse aucune page dans le classement : elle oriente l'affichage, elle ne crée pas de position.
Quelle est l'erreur hreflang la plus fréquente ?
Sur notre panel, ce n'est pas une erreur de syntaxe : c'est l'absence de hreflang sur une partie des gabarits du site, relevée sur 4 sites sur 19. Pagination de blog, pages de catégorie et sections profondes portent zéro balise là où l'accueil en porte jusqu'à 116. Les quatre erreurs de syntaxe classiques, elles, n'apparaissent pas une seule fois.
Le x-default est-il obligatoire ?
Non. Google le recommande sans l'exiger, et 7 des 19 sites mesurés n'en servent aucun. Il est utile si vous avez une page de choix de langue ou une version par défaut pour les visiteurs qui ne correspondent à aucune locale déclarée. Compter son absence comme une erreur fausserait tout barème.
Faut-il mettre le hreflang dans le HTML, le sitemap ou l'en-tête HTTP ?
Les trois canaux sont valides pour Google. Sur nos 790 déclarations, les 790 viennent du <head> HTML et aucune de l'en-tête HTTP, et un site du panel ne publie son hreflang que dans son sitemap. Le sitemap allège les pages et centralise la maintenance ; le HTML se vérifie d'un simple curl. Ce qui compte, c'est de n'en utiliser qu'un seul et de s'y tenir.
Pourquoi mon outil d'audit signale-t-il des erreurs hreflang qui n'existent pas ?
Souvent parce qu'il envoie un en-tête Accept-Language. Sur notre premier passage, un Accept-Language: fr-FR fabriquait 5 redirections de cible et 3 canoniques variables qui disparaissent sans l'en-tête. Un robot d'indexation n'en envoie pas : auditez comme lui, sans en-tête de langue. Deuxième cause : les réponses vides ou en 202 lues comme des pages sans balise.
Comment vérifier son hreflang sans outil payant ?
Un curl -sL avec un User-Agent navigateur, sans Accept-Language, plus un grep sur <link[^>]*hreflang. Ouvrez ensuite chaque cible et relevez son code HTTP, son URL finale, ses propres balises et sa canonique. Comptez une page par gabarit, pas une page par section : c'est le seul moyen de voir le défaut le plus fréquent.

Thibaut Legrand

Co-fondateur - Vydera

hreflang : sur 19 sites multilingues, le défaut n°1 est un gabarit oublié