Quand les balises canoniques pointent vers d’autres langues, Hreflang échoue

Une page peut porter 2 balises dans le même <head> qui s’adressent au même crawler à propos de la même URL et disent des choses opposées. Sur https://example.com/fr/pricing, cela indique que la page est le membre français d’un cluster :

<link rel="alternate" hreflang="fr" href="https://example.com/fr/pricing" />

Et ceci, 1 ligne en dessous, indique que la page est une variante qui doit être intégrée à l’original anglais :

<link rel="canonical" href="https://example.com/pricing" />

Les sites réels livrent les deux, à partir du même modèle, sur chaque route localisée qu’ils possèdent. C’est l’échec qui reste après celui que nous avons documenté en juillet — la référence self‑hreflang manquante, toujours en échec 58 % sur 88 évaluations hreflang dans nos données actuelles. Un site peut fermer cette boucle, obtenir chaque référence self‑référence correcte, et tout de même que chaque page localisée demande à être remplacée par son homologue anglais.

Une balise canonique interlangue demande à Google de fusionner la page localisée URL dans l’original

Une balise canonique est une demande de consolidation : traiter cette URL comme une variante de celle-là, et indexer celle-là. Une annotation hreflang est une revendication de routage : cette URL est la version pour cette langue. Les orienter vers des URLs différentes et le site a émis une requête qui annule sa propre revendication — le créneau français dans le cluster est rempli par une page qui se déclare elle‑même.

Google a été explicite sur le fait que hreflang est un indice plutôt qu’une directive, et la canonisation fonctionne de la même manière : le site fournit des signaux, Google les résout. Cette résolution est tout le problème. Avec une page localisée auto‑canonique, l’éditeur décide quelle URL sert les chercheurs français. Avec une canonique interlangue, l’éditeur a délégué la décision tout en croyant que le cluster est configuré — et le résultat rapporté plus tard est une page localisée qui ne se classe nulle part sur son propre marché alors que la page anglaise apparaît à sa place.

Les générateurs qui produisent cela sont ordinaires. Un helper canonique construit à partir d’une définition de route plutôt que du chemin de requête émet l’URL non préfixé pour chaque locale. Un CMS dont le réglage hreflang est par locale mais dont le réglage canonique est global fait la même chose. Donc, une migration qui a ajouté des préfixes de locale aux URL et laissé le canonique pointer vers l'endroit où le contenu était à l'origine. Dans chaque cas, la page se rend parfaitement, les annotations semblent complètes dans view-source, et la contradiction est 2 des attributs.

Le jeu de données

Méthodologie : instantané d'audit le plus récent par domaine à partir de notre jeu de vérification actuel, approximativement mai 23 – August 31, 2026, anonymisé. Les dénominateurs diffèrent selon la vérification — sites 34 à 49 — parce qu'une vérification ne s'exécute que lorsque ses entrées existent : la vérification de référence propre ne donne aucun verdict sur une page d'accueil sans annotations hreflang du tout, ce qui explique pourquoi son nombre de sites est le plus petit. Les taux au niveau de l'évaluation et au niveau du site diffèrent parce que certains domaines ont été audités plus d'une fois dans la fenêtre. L'échantillon est auto-sélectionné — propriétaires qui ont effectué un audit — et penche vers les petites à moyennes tailles, donc considérez les taux comme directionnels pour ce segment.

La deuxième ligne est le risque le plus discret. Une page sans canonique n'a pas contredit son annotation hreflang, mais elle n'a pas non plus défendu l'annotation : rien dans la page ne précise quel URL elle considère comme autoritaire, donc une variante de locale accessible à plus de 1 adresse est résolue entièrement par inférence. Atteindre un cluster correct passe d'abord par l'hygiène canonique, c'est pourquoi notre guide canonique est le prérequis pour le guide d'implémentation hreflang, et non un compagnon.

La contradiction n'est visible que depuis les deux extrémités du cluster

Une seule page ne peut pas signaler cet échec à elle-même. /fr/pricing semble cohérent en interne — un ensemble hreflang, un canonique, tous deux bien formés. Le défaut apparaît lorsque vous placez l'annotation et la page annotée côte à côte, c'est pourquoi la vérifier implique de récupérer le cluster plutôt que de lire 1 seul document.

Suivez chaque annotation hreflang jusqu'à sa cible et notez ce qui revient : le code d'état, si la requête a été redirigée, si une directive noindex est présente, et si la balise canonique propre de la cible désigne l'URL vers laquelle pointait l'annotation. Une cible dont la balise canonique désigne une autre URL est précisément le canonique inter-langues dont traite cet article.

L'attribut lang est un second témoin. Une page dont le html lang désigne une autre langue que la locale revendiquée par sa propre entrée hreflang se contredit de la même manière, et c'est souvent le premier signe visible qu'une route localisée sert le contenu de l'original.

Un alternatif qui ne peut pas être récupéré est un manque de preuve, pas la preuve d'un défaut. Notez-le comme non vérifié et réessayez avant de déclarer le cluster défaillant.

graph TD
    FR["/fr/pricing — html lang=fr"]
    EN["/pricing — original anglais"]
    FR -->|"hreflang=fr, self-referencing"| CLAIM["Réclamation : servir ce URL aux chercheurs français"]
    FR -->|"rel=canonical"| EN
    EN -->|"hreflang=fr"| FR
    CLAIM --> Q{"Quel URL répond à une requête française ?"}
    EN --> Q
    Q -->|"le site a cessé de décider"| OUT["Google sélectionne — généralement le URL anglais"]

Nos propres préfixes de locale servaient l’anglais jusqu’à August 17, 2026

Nous avons nous-mêmes échoué à ce type de défaut sur seoreport.dev. Ahrefs Site Audit a signalé un hreflang et un désaccord de langue HTML sur 184 URL de notre propre site. L’attribut lang était le symptôme ; le contenu était également en anglais, sur chacun des 9 préfixes de locale, ce qui rendait chaque URL localisé un duplicata de son jumeau anglais — le même résultat qu’un canonique inter‑langue produit, atteint depuis l’autre direction.

La cause était 1 fonction de frontière. Le shell du document prenait sa langue d’un helper qui renvoie la langue par défaut chaque fois que window est indéfini. Sur le serveur, /fr/pricing rendait donc lang="en" et semait le bundle de traduction anglais, tandis que le composant qui émet les liens d’en-tête — qui lit le chemin, pas l’exécution — émettait un fr self‑hreflang correct directement à côté. Un effet client changeait la langue après l’hydratation, donc chaque vérification basée sur le navigateur passait et aucun humain ne l’a vu. Les crawlers n’exécutent pas cet effet.

Corrigé sur August 17, 2026 : le shell tire sa langue du chemin, la mise en page localisée résout le bundle de locale dans un loader afin que le rendu serveur et l’hydratation le partagent, et une locale prise en charge sans bundle lance une erreur plutôt que de servir silencieusement l’anglais sous son préfixe. La direction du texte était également incorrecte — l’arabe servait ltr.

Le test de régression est une exécution en HTML brut sans JavaScript, car une vérification par navigateur est aveugle à toute cette classe d'échec. Exécuté en rouge d'abord contre la production, il a signalé 440 échecs sur 128 URLs localisées, chaque page à 100% anglais en surplus. Contre la version corrigée : 0 échecs sur 144 URLs. Une comparaison de lang avec hreflang aurait fait échouer notre propre site en premier.

x-default hérite de ce que la page de secours déclare

Notre échantillon de sites déclarant x-default est trop petit pour publier un taux d'échec. Le HTML prouve aussi moins qu'il n'y paraît : il montre qu'une annotation x-default est déclarée, pas quel public l'éditeur voulait qu'elle serve. Les faits vérifiables sont les faits voisins — forme de l'URL, santé de la cible, annotations réciproques et alignement canonique.

Ce que le mécanisme implique vaut la peine d'être déclaré de toute façon. x-default est le secours pour les chercheurs dont la langue le site ne sert pas, donc il pointe généralement vers la page du marché principal. Si cette page porte un canonique inter-langue, le secours pour chaque chercheur non apparié sur la planète hérite de la contradiction, et celle-ci apparaît dans la santé de la cible plutôt que dans la ligne x-default elle-même.

Vérifiez-le en brut HTML, par locale, dans les deux sens

Récupérez la page comme le fait un crawler et lisez 3 choses :

curl -s -A "Googlebot" https://example.com/fr/pricing | grep -iE '<html|rel="canonical"|hreflang'

L'attribut lang, l'entrée hreflang auto-référencée, et le canonique doivent être d'accord sur 1 locale et 1 URL :

<!-- On https://example.com/fr/pricing -->
<html lang="fr">
<link rel="canonical" href="https://example.com/fr/pricing" />
<link rel="alternate" hreflang="en" href="https://example.com/pricing" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />

Puis répétez sur 1 page par locale, et récupérez chaque URL que le nom des annotations confirme que chacun canonique à lui-même. La règle est assez courte pour être remise à un développeur : chaque membre d'un cluster hreflang canonique à lui-même. Un canonique inter-langue est correct dans exactement 1 situation — lorsque le URL localisé n'est pas localisé du tout et sert la même langue que l'original — et dans cette situation le URL n'appartient pas non plus au cluster.

L'Inspection URL de Search Console donne la seconde opinion autoritaire sur quel canonique Google a réellement été sélectionné, par URL. Un diagnostic SEOReport payant exécute la boucle sur le cluster et liste chaque paire contradictoire avec la page où elle a été trouvée. Les 9 préfixes de locale sur seoreport.dev passent maintenant, et ils passent parce que nous avons expédié le défaut d'abord, sur un site dont tout le produit le trouve.