Faut-il vraiment abandonner les balises hreflang dans les liens d'ancrage ?

Pourquoi cette clarification sur l'emplacement des balises hreflang ?

Google rappelle une règle qui n'a jamais changé depuis l'introduction du système hreflang en 2011. Les trois méthodes officielles d'implémentation sont fixées dans la spécification initiale : balises link rel="alternate" hreflang dans la section head, en-têtes HTTP X-Default, ou déclarations dans un sitemap XML dédié.

Cette mise au point vise probablement à corriger une confusion récurrente. Certains développeurs tentent d'ajouter des attributs hreflang directement sur les balises d'ancrage, sans doute par analogie avec d'autres attributs HTML comme lang ou rel. Le problème ? Cette syntaxe n'a jamais fait partie des standards reconnus par Google, et le moteur l'ignore purement et simplement lors du crawl.

Quelle différence entre balise link et attribut de lien ?

Une balise <link rel="alternate" hreflang="fr"> dans le head est un élément HTML autonome qui ne pointe vers rien visuellement. Elle existe uniquement pour communiquer aux moteurs de recherche les variantes linguistiques d'une page. Cette balise est parsée lors du crawl et intégrée dans le graphe de relation entre URLs.

Un attribut hreflang sur une balise d'ancrage <a href="/fr/" hreflang="fr"> serait théoriquement une instruction au niveau du lien lui-même. Mais Google ne reconnaît pas cette syntaxe, car elle n'a jamais été normalisée dans les spécifications HTML pour ce cas d'usage. Même si techniquement l'attribut existe dans le DOM, le crawler Google le traverse sans le traiter comme signal hreflang.

Comment Google détecte-t-il réellement les signaux hreflang ?

Le crawler parse trois sources distinctes lors du traitement d'une URL. D'abord, il analyse le code source HTML à la recherche de balises link dans le head. Ensuite, il examine les en-têtes de réponse HTTP pour détecter d'éventuelles directives Link. Enfin, il consulte les sitemaps XML déclarés dans robots.txt ou Search Console pour extraire les annotations hreflang groupées.

Chacune de ces méthodes présente des avantages techniques différents. Les en-têtes HTTP conviennent aux fichiers PDF ou autres ressources non-HTML. Les sitemaps centralisent la gestion pour les très gros sites multilingues. Les balises dans le head restent la méthode la plus courante, car elle permet un contrôle granulaire page par page sans dépendance serveur.

• Trois méthodes officielles exclusivement : balises link dans head, en-têtes HTTP, sitemap XML
• Aucun support des attributs hreflang sur les balises d'ancrage ou autres éléments HTML
• Le parseur Google ignore toute implémentation hors spécification documentée
• La réciprocité reste obligatoire : chaque URL doit déclarer toutes ses variantes, y compris elle-même
• Un seul type d'erreur courant : confondre la balise link autonome avec un attribut de lien cliquable

Cette déclaration reflète-t-elle vraiment les observations terrain ?

Absolument. Aucun cas documenté ne montre Google exploitant des attributs hreflang placés sur des balises d'ancrage. Les tests empiriques confirment que seules les trois méthodes officielles génèrent des signaux hreflang effectifs dans Search Console. Quand un site utilise une syntaxe invalide, les rapports de couverture internationale restent vides ou affichent des erreurs de réciprocité.

Ce qui est intéressant, c'est que cette confusion persiste malgré une documentation claire depuis plus de dix ans. Probablement parce que l'attribut hreflang existe bel et bien dans les spécifications HTML5 pour d'autres contextes, notamment pour indiquer la langue d'une ressource liée. Mais Google n'a jamais étendu son interprétation au-delà des trois canaux officiels.

Quelles nuances faut-il apporter à cette règle ?

La principale nuance concerne les sites JavaScript clients-side. Si une application SPA injecte dynamiquement des balises link hreflang dans le head après le rendu initial, Google peut théoriquement les détecter lors du second crawl (rendu JavaScript). Mais cette approche reste fragile : mieux vaut privilégier le rendu serveur ou les en-têtes HTTP pour garantir la détection.

Autre point : la méthode par sitemap XML souffre d'un défaut rarement mentionné. Google traite les sitemaps de manière asynchrone et avec délai. Une modification dans le sitemap peut mettre plusieurs semaines à se propager, alors qu'une balise dans le head est détectée au prochain crawl de la page. Pour les sites à forte vélocité éditoriale, cette latence pose problème. [A vérifier] : Google n'a jamais publié de SLA sur la vitesse de traitement des annotations hreflang via sitemap.

Dans quels cas cette règle pose-t-elle des difficultés pratiques ?

Les sites e-commerce avec filtres rencontrent un vrai casse-tête. Chaque combinaison de filtres génère potentiellement une URL unique, et maintenir les annotations hreflang sur des milliers de variantes filtrées devient ingérable. La tentation d'utiliser un attribut d'ancrage dynamique serait compréhensible, mais elle ne fonctionne pas.

Les plateformes headless ou découplées posent aussi question. Quand le front-end ne contrôle pas directement le head HTML (généré par le CMS back-end), injecter les balises hreflang requiert une coordination technique entre équipes. Les en-têtes HTTP deviennent alors la solution de repli, mais elles nécessitent une configuration serveur que tous les hébergements mutualisés ne permettent pas.

Que faut-il vérifier immédiatement sur un site multilingue ?

Première action : ouvrir la Search Console et consulter le rapport « Ciblage international ». Si aucune donnée n'apparaît alors que le site déclare plusieurs versions linguistiques, c'est le symptôme d'une implémentation hreflang défaillante. Ensuite, inspecter manuellement le code source de quelques pages clés : les balises link doivent être présentes dans le head, pas ailleurs.

Pour les sites utilisant des en-têtes HTTP, un simple curl -I ou l'onglet Network des DevTools Chrome révèle immédiatement si les directives Link sont envoyées. Si la méthode sitemap est choisie, télécharger le fichier XML et vérifier la syntaxe : chaque URL doit lister toutes ses variantes, y compris elle-même, sinon Google rejette l'annotation comme incomplète.

Comment corriger une implémentation incorrecte ?

Si des attributs hreflang traînent sur des balises d'ancrage, les supprimer est sans risque puisqu'ils n'ont aucun effet. L'effort doit se concentrer sur l'ajout des vraies balises link dans le head. Pour un site WordPress, des plugins comme WPML ou Polylang gèrent ça automatiquement. Pour un site custom, le template doit boucler sur les traductions disponibles et générer dynamiquement les balises.

La réciprocité est le piège le plus fréquent. Chaque page fr-FR doit pointer vers en-GB, es-ES, de-DE, etc., mais aussi vers elle-même avec hreflang="fr". Et chaque page en-GB doit faire de même dans l'autre sens. Une seule balise manquante dans la chaîne casse la réciprocité, et Google ignore alors tout le cluster. Des outils comme Screaming Frog ou Oncrawl détectent ces incohérences lors d'un crawl.

Quelles erreurs éviter absolument lors de la migration ?

Ne jamais mélanger les trois méthodes sur le même site. Google privilégie les balises dans le head, puis les en-têtes HTTP, puis le sitemap. Si des annotations contradictoires existent, le comportement devient imprévisible. Choisir une méthode et s'y tenir. De même, ne jamais pointer vers des URLs non-canoniques : hreflang doit toujours référencer la version canonical de chaque variante.

Autre erreur classique : oublier la balise x-default. Elle indique à Google quelle version servir aux utilisateurs dont la langue ne correspond à aucune variante déclarée. Sans x-default, Google fait un choix arbitraire, souvent basé sur la géolocalisation IP, ce qui génère une expérience utilisateur incohérente. Enfin, attention aux codes langue : utiliser fr-FR pour le français France, pas juste « fr », sauf si la variante couvre tous les francophones indifféremment.

• Auditer le code source : les balises link doivent être dans le <head>, pas dans le body ni sur les ancres
• Vérifier la réciprocité : chaque URL doit lister toutes ses variantes, y compris elle-même
• Contrôler les codes langue : ISO 639-1 pour la langue, ISO 3166-1 Alpha 2 pour le pays
• Tester avec Search Console : le rapport Ciblage international doit afficher toutes les variantes détectées
• Éviter de mélanger balises head, en-têtes HTTP et sitemap sur le même domaine
• Implémenter x-default pour gérer les langues non couvertes proprement