75 % des sites multilingues ont une implémentation hreflang cassée. Ce chiffre vient d'une analyse SEMrush de 2018, et franchement, quand je vois les backlinks que je reçois encore aujourd'hui de sites qui se plantent sur des erreurs basiques, je pense que rien n'a vraiment changé.
J'ai migré mon propre blog vers une structure à trois langues il y a quatre ans. Je pensais avoir tout bon. Résultat : Google m'a servi du contenu espagnol à des visiteurs québécois pendant six semaines avant que je comprenne ce qui clochait. Six semaines.
Donc voilà. Cet article, c'est la procédure que j'aurais aimé lire à l'époque.
Points clés à retenir
- Le hreflang doit être réciproque : chaque version pointe vers toutes les autres, y compris elle-même.
- Trois méthodes d'implémentation existent (balises HTML, sitemap XML, en-têtes HTTP), et elles ne se valent pas selon votre contexte technique.
- L'auto-référence est obligatoire. L'oublier, c'est la première cause de dysfonctionnement.
- Un code de langue seul (ex.
fr) cible tous les francophones ; un code combiné (ex.fr-CA) cible une région précise. - La balise
x-defaultsert de page de repli quand aucune version ne correspond à la langue de l'internaute. - Tester avec l'inspection d'URL de la Search Console reste le seul moyen fiable de valider, parce qu'aucune erreur ne s'affiche côté navigateur.
Ce que fait vraiment le hreflang (et ce qu'il ne fait pas)
Le hreflang n'est pas une balise magique qui redirige automatiquement vos visiteurs. C'est une indication. Google s'en sert pour choisir la version à afficher dans les résultats de recherche, pas pour l'internaute qui tape l'URL à la main.
Beaucoup de développeurs confondent avec la détection navigateur. Non. Si quelqu'un arrive directement sur /es/ depuis un lien, le hreflang ne le renverra pas vers /fr/. C'est un signal destiné aux moteurs, point.
Un rôle purement SEO, pas UX
Concrètement, il résout trois problèmes distincts :
- Il évite que Google considère vos versions traduites comme du duplic content. Deux pages en langue différente, ce n'est pas la même page.
- Il empêche la mauvaise version de s'afficher pour un utilisateur d'un pays donné (un Allemand qui tombe sur votre page anglaise alors qu'une version allemande existe).
- Il consolide les signaux : chaque version se classe sur son marché local plutôt que de se cannibaliser.
Le revers de la médaille, c'est qu'un hreflang mal posé fait l'inverse de ce qu'on veut. J'ai vu un site se faire désindexer sa version néerlandaise sur Google.be pendant deux mois. La cause ? Un href pointant vers une URL en 404.
La règle que tout le monde oublie : l'auto-référence
Chaque bloc hreflang sur une page doit lister la page elle-même parmi les alternatives. Oui, celle où vous vous trouvez.
Si votre page française liste seulement les versions en et es mais jamais fr, Google comprend que la page française ne fait pas partie du groupe. Et là, tout s'effondre.
Je l'ai fait cette erreur. Sur 200 pages. Le correctif m'a pris un script Python et un après-midi entier, mais j'aurais préféré le savoir avant.
Les trois méthodes d'implémentation, comparées
Il existe trois façons de déclarer vos alternances linguistiques. Vous pouvez les combiner, mais c'est rarement utile.
1. Balises HTML dans le <head>
C'est la méthode la plus répandue, et pour un site de moins de 50 pages, c'est aussi la plus simple à maintenir à la main :
<link rel="alternate" hreflang="fr-FR" href="https://exemple.fr/page" />
<link rel="alternate" hreflang="en-US" href="https://exemple.com/page" />
<link rel="alternate" hreflang="es-ES" href="https://exemple.es/pagina" />
<link rel="alternate" hreflang="x-default" href="https://exemple.com/page" />Avantage : visible directement dans le code source, facile à auditer. Inconvénient : sur un catalogue e-commerce de 10 000 produits multiplié par 5 langues, vous devenez fou.
2. Sitemap XML
Ici, les balises vivent dans le sitemap, pas dans le HTML :
<url>
<loc>https://exemple.fr/page</loc>
<xhtml:link rel="alternate" hreflang="fr-FR" href="https://exemple.fr/page" />
<xhtml:link rel="alternate" hreflang="en-US" href="https://exemple.com/page" />
<xhtml:link rel="alternate" hreflang="es-ES" href="https://exemple.es/pagina" />
</url>Pour du volume, c'est la voie royale. Un seul fichier regroupe tout, et vous le régénérez automatiquement à chaque déploiement. C'est ce que j'utilise aujourd'hui sur mon site, quatorze langues, environ 900 URL uniques. Le sitemap pèse 340 Ko et se met à jour via un cron nocturne.
3. En-têtes HTTP Link
Réservé aux fichiers non-HTML : PDF, vidéos, ressources binaires. La syntaxe ressemble à ceci :
Link: <https://exemple.fr/fichier.pdf>; rel="alternate"; hreflang="fr-FR"
Honnêtement, je ne l'ai jamais déployé en production. Le cas d'usage est trop niche pour la plupart des sites.
Quelle méthode choisir ?
| Méthode | Idéal pour | Difficulté de maintenance | Fonctionne sur PDF ? |
|---|---|---|---|
| Balises HTML | Petits sites, moins de 50 pages | Faible | Non |
| Sitemap XML | Gros volumes, e-commerce | Moyenne (automatisable) | Non |
| En-têtes HTTP | Ressources non-HTML | Élevée | Oui |
Mon conseil : si vous dépassez 100 URL multilingues, passez au sitemap. Ne cherchez pas à bricoler du HTML sur 3 000 pages.
Les erreurs qui plombent réellement votre setup
Voici celles que je rencontre le plus souvent lors d'audits, par ordre de fréquence.
Le manque de réciprocité
Si la page A pointe vers B, la page B doit pointer vers A. Google appelle ça la confirmation bidirectionnelle. Dans les faits, une relation non réciproque est ignorée purement et simplement.
J'ai audité un site de tourisme l'an dernier : la version française listait cinq langues, la version italienne en listait trois, la version anglaise aucune. Résultat, seuls les couples réciproques fonctionnaient. Trois langues sur cinq étaient invisibles sur Google.
Confondre code langue et code pays
Le format standard suit la norme ISO 639-1 pour la langue, couplée à ISO 3166-1 Alpha 2 pour la région.
fr→ tout contenu francophone, peu importe le paysfr-FR→ version destinée à la France uniquementfr-CA→ version québécoisefr-BE→ version belge
Piège classique : utiliser fr-FR alors que vous ciblez aussi la Belgique, la Suisse et le Québec. Vous excluez mécaniquement tout ce beau monde.
Oublier la balise x-default
Cette balise définit la version de repli quand aucune autre ne correspond à la langue de l'internaute. Sans elle, Google choisit lui-même. Et il choisit souvent mal.
Sur mon blog, l'x-default pointe vers la version anglaise. Pas parce qu'elle est supérieure, mais parce que c'est la langue la plus largement comprise par défaut. C'est un choix subjectif, mais il tient la route.
Comment vérifier que tout fonctionne
Il n'existe pas d'outil qui vous dit "bravo, ton hreflang est parfait". Désolé, la réalité est plus laborieuse.
Ce qui marche réellement, dans l'ordre :
- L'inspection d'URL dans la Search Console sur une page de chaque langue. Elle affiche les erreurs de type "valeur hreflang incorrecte" ou "aucun renvoi" quand un lien est manquant.
- Un crawler type Screaming Frog en version gratuite pour scraper les balises et détecter les codes invalides.
- Un test manuel : modifiez votre en-tête Accept-Language dans Chrome via une extension, rechargez la SERP depuis un VPN, et observez quelle version remonte.
- Le rapport "Pages" de la Search Console, onglet "Autres", qui signale parfois les cas de mauvaise sélection canonique liés à un hreflang défaillant.
Mes deux dernières années m'ont appris une chose : ne jamais faire confiance au hreflang avant de l'avoir vu dans une SERP. Les outils vous mentent, ou plus exactement, ils vous confirment que le code est présent. Pas qu'il est correct.
Le vrai problème n'est pas technique
La plupart des erreurs hreflang que je vois ne viennent pas d'une mauvaise compréhension du code. Elles viennent de la gouvernance.
Quand l'équipe française met à jour sa page et oublie de prévenir l'équipe allemande, la réciprocité se casse. Quand un nouveau marché s'ouvre et qu'on ajoute le Brésil sans toucher aux autres versions, l'auto-référence saute. Ce n'est pas un bug, c'est un process.
Sur mon propre site, j'ai fini par bloquer les modifications de balises hreflang dans un fichier de configuration centralisé. Plus personne ne les touche directement dans le template. Une décision chiante à mettre en place, mais qui a éliminé 90 % de mes erreurs en six mois.
Si vous ne devez retenir qu'une chose : le hreflang est un système. Chaque page dépend des autres. Le jour où une seule se désynchronise, c'est l'ensemble du groupe qui perd sa cohérence aux yeux de Google.
