C’est l’un des rares dispositifs techniques où une erreur ne produit aucun message d’alerte, aucune page cassée, aucun symptôme visible. Tout semble fonctionner, et pourtant rien n’est pris en compte. Les balises hreflang échouent silencieusement c’est ce qui les rend si souvent défaillantes sur des sites par ailleurs bien construits.
À quoi servent ces balises
Quand un même contenu existe en plusieurs versions, un moteur se trouve devant deux problèmes.
Le premier est un problème de duplication. Votre page française et votre page belge francophone disent à peu près la même chose. Sans indication, elles se font concurrence, et le moteur en choisit une au détriment de l’autre.
Le second est un problème de ciblage. Un visiteur belge doit recevoir la version belge, avec ses tarifs, ses conditions et sa devise. Un visiteur canadien francophone doit recevoir la sienne.
Les balises hreflang répondent aux deux simultanément. Elles déclarent : ces pages sont des versions alternatives les unes des autres, et voici à quel public linguistique ou géographique chacune s’adresse. Le moteur cesse alors de les traiter comme des doublons et sert la bonne version selon le profil de l’internaute.
Point important : ces balises ne modifient pas votre classement. Une page mal positionnée ne remontera pas grâce à elles. Elles déterminent quelle version est affichée, pas à quelle place. C’est la première clarification qu’apporte Julien Jimenez sur le sujet, et elle évite d’attendre du dispositif un effet qu’il n’aura jamais.
Choisir sa structure internationale
Cette décision précède tout le reste et se change difficilement.
Les domaines par pays monsite.fr, monsite.be, monsite.ca envoient le signal géographique le plus fort et permettent une gestion juridique séparée, ce qui compte sur les activités réglementées. Contrepartie lourde : chaque domaine construit sa notoriété séparément, à partir de zéro. Réservé aux organisations disposant de moyens réels par marché.
Les sous-domaines fr.monsite.com offrent une séparation technique nette, avec une transmission partielle de l’autorité entre versions. Solution intermédiaire, parfois retenue pour des raisons d’infrastructure.
Les sous-répertoires monsite.com/fr/ conservent l’intégralité de la force du domaine sur chaque version. C’est le choix recommandé dans la grande majorité des cas, et particulièrement pour une structure qui démarre à l’international : le travail de notoriété fait sur une version profite à toutes les autres.
Écartez les paramètres d’URL pour distinguer les langues : le signal est faible et la gestion, fragile.
Les règles à respecter
Trois règles non négociables, à vérifier avant toute mise en production, parce qu’une seule d’entre elles enfreinte annule l’ensemble du dispositif.
La réciprocité. Si la page française déclare la version espagnole, la page espagnole doit déclarer la version française. Le lien doit exister dans les deux sens, sans exception. Une déclaration unilatérale est purement et simplement ignorée c’est la protection du moteur contre les sites qui se déclareraient version alternative d’un site tiers.
L’auto-référencement. Chaque page doit se déclarer elle-même dans sa propre liste. Une page française listant l’espagnol et l’italien mais pas le français est invalide. Cette règle paraît redondante ; elle est strictement appliquée.
Les codes corrects. La langue suit une norme à deux lettres, le pays une autre norme à deux lettres, et l’ordre est toujours langue-tiret-pays. fr-be désigne le français de Belgique. be-fr n’existe pas. Le pays seul n’est jamais valide : be seul sera interprété comme la langue biélorusse, pas comme la Belgique.
Ajoutez-y une quatrième règle, techniquement facultative mais fortement recommandée : déclarez une version par défaut avec la valeur x-default. Elle indique quelle page servir aux visiteurs dont la langue ou le pays ne correspond à aucune de vos versions. Sans elle, le moteur choisit seul, et rarement bien.
Où déclarer les balises
Trois emplacements, avec des propriétés différentes.
Dans l’en-tête HTML de chaque page. C’est la méthode la plus courante et la plus lisible. Chaque page porte la liste complète de ses versions. L’inconvénient apparaît sur les gros volumes : avec dix versions linguistiques, chaque page transporte dix lignes supplémentaires, et toute modification impose de régénérer l’ensemble.
Dans les en-têtes HTTP. Seule solution pour les fichiers non HTML des documents PDF déclinés en plusieurs langues, par exemple. Plus difficile à contrôler visuellement.
Dans le sitemap XML. C’est l’option la plus maintenable sur les grandes structures : toutes les correspondances sont centralisées dans un fichier unique, ce qui facilite la génération automatique et la vérification. Elle exige en revanche une génération rigoureuse et un sitemap parfaitement à jour.
Choisissez une seule méthode. En combiner deux crée des risques de contradiction, et rien n’oblige à la redondance.
Les erreurs qui annulent le dispositif
Six écueils, tous silencieux.
La réciprocité manquante. De loin le plus fréquent, souvent parce qu’une nouvelle version a été ajoutée sans mettre à jour les précédentes.
Les URL relatives. Les adresses déclarées doivent être absolues, avec le protocole complet. Une URL relative rend la déclaration inexploitable.
Les codes inventés. en-uk au lieu de en-gb, fr-fra, ou des codes régionaux qui n’existent pas dans les normes. Le moteur ignore la ligne concernée.
Le mélange avec les balises canoniques. Erreur classique et destructrice : une page espagnole portant une canonique vers la version française. Vous déclarez d’un côté que ce sont deux versions alternatives, de l’autre que l’une est un doublon de l’autre. Les canoniques doivent être auto-référentes sur chaque version.
Les pages déclarées non indexables. Une version portant une directive noindex tout en figurant dans les déclarations casse la cohérence de l’ensemble.
Les URL déclarées qui redirigent. Chaque adresse listée doit renvoyer un code 200, directement.
Les cas particuliers
Trois situations reviennent régulièrement et méritent une réponse claire.
Une même langue pour plusieurs pays. Français pour la France, la Belgique et le Canada. C’est un usage parfaitement légitime des balises, à condition que les contenus diffèrent réellement prix, disponibilité, mentions légales, exemples locaux. Si les trois versions sont strictement identiques, vous créez de la duplication sans bénéfice : mieux vaut une version unique.
Le contenu partiellement traduit. Si seule une partie de votre site existe dans une langue, déclarez les correspondances uniquement pour les pages effectivement traduites. Ne pointez pas une page anglaise vers l’accueil français faute d’équivalent : c’est traité comme une erreur.
La redirection automatique par géolocalisation. À éviter fermement. Elle empêche l’exploration des autres versions le robot, localisé dans un pays donné, ne verra jamais les autres et frustre les visiteurs qui souhaitent consulter une autre version. Proposez une suggestion, avec un bandeau discret, jamais une redirection forcée.
Vérifier et surveiller
Le caractère silencieux des erreurs impose un contrôle actif.
Utilisez un outil de vérification dédié qui teste la réciprocité sur l’ensemble de vos URL. C’est le seul moyen fiable de détecter une déclaration unilatérale sur un site de taille conséquente.
Consultez les rapports de ciblage international de vos outils pour webmasters lorsqu’ils sont disponibles : ils remontent les balises sans retour et les codes non reconnus.
Procédez à un contrôle par échantillon après chaque publication d’une nouvelle version linguistique. C’est le moment où la réciprocité se casse : on ajoute la nouvelle page en déclarant les anciennes, et l’on oublie de mettre à jour les anciennes en retour.
Enfin, inscrivez cette vérification dans votre procédure de mise en production, au même titre que les redirections. Un dispositif hreflang se dégrade à chaque évolution du site, et personne ne s’en aperçoit avant plusieurs mois.
