En 2018, Glenn Gabe a publié l’une des études de cas SEO les plus déroutantes de la décennie. Un client canonisait les URL hreflang britanniques et indiennes vers une version américaine, techniquement erronée et contraire aux propres conseils de Google. Pourtant, les « mauvaises » URL continuaient à apparaître correctement dans les résultats de recherche spécifiques à un pays, même si la Search Console les indiquait comme non indexées. Lorsque Gabe a interrogé John Mueller à ce sujet lors d’un hangout pour les webmasters, Mueller a confirmé que le comportement était réel : Google pouvait échanger l’URL du pays/de la langue correcte au niveau SERP, même lorsqu’une seule page du cluster hreflang était réellement indexée. Cela a été traité comme une curiosité, un « tour de magie », comme l’appelait Gabe, parce que Google n’a jamais entièrement expliqué le mécanisme qui se cache derrière.
Huit ans plus tard, il a reçu un nom. En août 2026, Gary Illyes de Google a répondu à une question de LinkedIn sur ce scénario et a décrit ces URL comme des noms alternatifs. Son explication nous donne un modèle mental utile pour quelque chose que les référenceurs internationaux font de l’ingénierie inverse depuis des années : la découverte, la canonisation, l’indexation, la notation et la diffusion sont des parties distinctes du processus, et une URL ne doit pas nécessairement les traverser toutes indépendamment pour apparaître dans la recherche.
Cette distinction permet d’expliquer où s’inscrit réellement le hreflang dans le processus. Plus important encore, à mesure que la recherche évolue vers la récupération sémantique et les réponses générées par l’IA, elle soulève une question plus vaste pour les sites Web internationaux : si plusieurs pages de marché contiennent essentiellement les mêmes informations, qu’est-ce qui rend chacune d’entre elles particulièrement précieuse ?
Tout d’abord, Google doit découvrir les alternatives
Avant qu’il y ait un cluster à canoniser, un canonique à évaluer ou une autre URL à servir, Google doit découvrir les URL. C’est pourquoi les plans de site XML, les liens internes et les annotations hreflang deviennent particulièrement importants lors des migrations, des replateformes et des déploiements internationaux. Google doit découvrir les versions américaine, britannique, australienne, italienne et autres avant de pouvoir comprendre les relations entre ces ressources. Une fois découvertes et explorées, ces URL ne deviennent pas automatiquement des documents indexés indépendamment. Google doit encore déterminer s’ils représentent des ressources véritablement différentes ou des versions dupliquées ou quasi-dupliquées d’essentiellement le même contenu. Certains peuvent justifier une indexation et une notation indépendantes, tandis que d’autres peuvent être regroupés avec une autre URL.
Il s’agit d’une distinction importante, car nous traitons souvent les étapes « découverte », « explorée » et « indexée » comme des étapes par lesquelles une URL progresse simplement. L’explication des noms alternatifs démontre que Google peut conserver des connaissances sur une URL et ses relations avec d’autres URL même lorsque cette URL n’est pas représentée de manière indépendante dans l’index.
Hreflang est une référence croisée, pas un signal de classement
L’une des idées fausses les plus persistantes à propos du hreflang est qu’il crée d’une manière ou d’une autre une valeur de classement. J’ai toujours trouvé plus utile de considérer le hreflang comme une table de références croisées qui indique à Google que cette URL est l’équivalent italien d’une autre URL ; celui-ci est destiné aux anglophones d’Australie et un autre est destiné aux anglophones du Royaume-Uni.
Google peut utiliser ces relations pour déterminer quelle URL présenter à un chercheur particulier, mais cela ne signifie pas que hreflang a créé le classement en premier lieu. Sur des dizaines de milliers d’implémentations de hreflang, je n’ai jamais vu de cas où l’ajout de hreflang provoquait soudainement un classement plus élevé d’une page en raison de l’annotation elle-même.
Si une page en anglais américain est classée au Royaume-Uni avant la mise en œuvre du hreflang, l’ajout de l’alternative britannique correcte ne donne pas comme par magie à la page britannique un nouveau score de classement. Ce qui peut changer, c’est l’URL présentée par Google pour le classement qu’il a déjà déterminé.
C’est ce que je trouve particulièrement utile dans l’explication d’Illyes sur les « noms alternatifs ». L’indexation et la notation peuvent avoir lieu sur un membre d’un cluster en double pendant que la couche de diffusion sélectionne une URL alternative appropriée pour l’utilisateur. Hreflang aide Google à comprendre cette relation et à sélectionner la représentation appropriée. En ce sens, les itinéraires hreflang plutôt que les classements.
Le problème des 38 marchés
Une marque mondiale de chaussures avec laquelle j’ai travaillé illustre le problème à grande échelle. Il comptait environ 98 sites Web de marché, dont environ 38 étaient en anglais et presque identiques les uns aux autres. 22 partageaient même le même symbole monétaire en forme de dollar. Cela signifiait que des dizaines d’URL contenaient effectivement les mêmes informations sur les produits, la même langue et souvent la même présentation des prix, différenciées principalement par le domaine, l’annuaire ou une poignée de détails localisés.
Du point de vue de l’organisation, il s’agissait de 38 sites Web de marchés différents. Du point de vue d’une machine, cependant, bon nombre d’entre eux représentaient essentiellement la même ressource. Il y a peu de raisons pour que Google stocke, traite et note de manière indépendante 38 copies si elles ne fournissent pratiquement aucune information supplémentaire.
Au lieu de cela, il peut regrouper les quasi-doublons, choisir une représentation canonique et conserver suffisamment d’informations sur les alternatives pour présenter l’URL appropriée lorsque le pays ou la langue de l’utilisateur l’exige. Cela aide à expliquer le « tour de magie » documenté par Gabe. L’URL alternative n’avait pas nécessairement besoin de son propre score de classement indépendant pour apparaître, car Google comprenait déjà sa relation avec l’URL qui avait été indexée et notée.
La couche de service pourrait s’occuper du reste.
Tokenisation canonique et coût de la duplication
Cela devient plus facile à comprendre si l’on considère la canonisation comme un problème d’efficacité. Les moteurs de recherche fonctionnent à grande échelle, et il y a peu d’avantages à stocker et traiter de manière répétée des informations substantiellement identiques lorsque ces ressources peuvent être regroupées en toute confiance.
Un membre d’un cluster dupliqué ou quasi-dupliqué peut devenir la représentation principale tandis que Google conserve les relations avec les alternatives. Dans la recherche traditionnelle, ces relations peuvent ensuite être utilisées au moment de la diffusion pour présenter l’URL la plus appropriée.
L’IA rend cela plus intéressant car un système d’IA ne se limite pas à renvoyer un document sous forme de lien bleu. Il peut récupérer des informations, extraire des preuves de différentes sources et rassembler une réponse. En conséquence, l’unité sur laquelle nous devons nous concentrer passe de l’URL elle-même aux informations qu’elle contient.
Au lieu de nous demander uniquement quelle URL doit être classée, nous devons de plus en plus réfléchir aux informations utiles pour répondre à la question de l’utilisateur, où se trouvent les meilleures preuves de ces informations et si ces preuves sont réellement pertinentes pour le marché de l’utilisateur.
Motoko Hunt a exploré cette distinction récemment, affirmant que le hreflang peut aider à identifier la langue souhaitée ou la relation de marché, mais cela ne signifie pas qu’un système d’IA considérera le contenu lui-même comme la meilleure preuve pour un utilisateur sur ce marché.
Cette distinction devient particulièrement importante pour les sites Web internationaux comportant un grand nombre de pages de marché très similaires. Si les informations sous-jacentes sont sensiblement les mêmes, la présence d’URL distinctes et d’annotations hreflang correctes ne donne pas nécessairement à un système d’IA une raison de récupérer une version du marché plutôt qu’une autre. Cette raison doit de plus en plus venir du contenu lui-même.
Les systèmes d’IA reconnaissent mieux l’équivalence
Microsoft a fourni un aperçu intéressant de ce problème dans sa description de Web IQ, l’infrastructure de récupération et de mise à la terre prenant en charge ses expériences d’IA. Ses modèles multilingues sont conçus pour représenter des informations sémantiquement équivalentes aussi rapprochées que possible, même lorsque ces informations apparaissent dans des langues différentes.
C’est important car hreflang représente une relation explicitement déclarée. On indique au moteur de recherche que deux ressources sont équivalentes et destinées à des publics différents. Les systèmes de recherche sémantique sont de plus en plus capables d’identifier cette équivalence à partir du contenu lui-même. Deux passages peuvent être reconnus comme disant essentiellement la même chose même si l’administrateur Web ne déclare jamais explicitement la relation entre eux.
Microsoft décrit également la récupération comme étant axée sur les preuves au niveau du passage plutôt que de traiter l’URL entière comme la seule unité significative. Il s’agit d’un changement important dans la façon dont nous devrions considérer le contenu international. Si un système d’IA peut reconnaître des informations équivalentes sur plusieurs pages et langues et récupérer les preuves spécifiques dont il a besoin, la création d’URL supplémentaires contenant des informations sensiblement identiques ne crée pas nécessairement des connaissances utiles supplémentaires. Cela peut simplement créer davantage de copies des connaissances dont le système dispose déjà.
C’est là que ce qui ressemble initialement à une discussion technique sur le hreflang devient un problème de contenu international beaucoup plus vaste.
Hreflang ne peut pas rendre le contenu local
Hreflang peut indiquer à Google qu’une page est destinée au Royaume-Uni et une autre à l’Australie, mais il ne peut pas rendre l’une ou l’autre page plus pertinente pour ces marchés. Si 20 pages de marché contiennent essentiellement les mêmes descriptions de produits, allégations, spécifications, FAQ et informations complémentaires, l’ajout d’annotations hreflang parfaites ne rend pas soudainement ces pages significativement différentes.
L’organisation a peut-être créé 20 URL, mais du point de vue de la récupération, elle peut avoir créé un élément de connaissance avec 20 adresses différentes.
C’est pourquoi je pense que la localisation doit aller au-delà de la définition traditionnelle de la traduction de contenu et de l’échange de devises, de numéros de téléphone, d’orthographe ou de quelques références de marché. La question la plus utile est de savoir ce qu’une personne sur un marché particulier a besoin de savoir et qu’une personne sur un autre marché n’a pas besoin de savoir.
Les produits peuvent différer selon le marché. Les réglementations, certifications, disponibilités, garanties, options de livraison et modèles de tarification peuvent être différents. Les clients peuvent utiliser une terminologie différente, avoir des cas d’utilisation différents, évaluer différents concurrents, exiger différentes intégrations ou prendre des décisions d’achat basées sur des critères complètement différents. Les équipes locales peuvent également disposer de preuves, d’exemples de clients, d’une expertise réglementaire et d’une connaissance du marché qui ne figurent jamais sur le site Web.
Ces différences donnent à une page de marché une raison d’exister et donnent aux systèmes de recherche et d’IA quelque chose d’unique à récupérer.
Donnez à chaque page de marché une raison d’exister
Rien de tout cela ne rend le hreflang moins important. Au contraire, l’explication de Google sur les noms alternatifs rend son rôle plus clair. Hreflang établit la relation entre les langues alternatives et les URL du marché et aide Google à comprendre quelle version est destinée à quel public. Ce qu’il ne peut pas faire, c’est créer lui-même la différenciation du marché.
Le contenu doit faire cela.
Cela devient de plus en plus important à mesure que les systèmes de récupération comprennent mieux l’équivalence sémantique entre les URL et les langues. Si les pages américaines, britanniques, australiennes, singapouriennes et sud-africaines disent toutes essentiellement la même chose, les machines sont de plus en plus capables de le reconnaître, quel que soit le nombre d’URL, de dossiers, de domaines ou d’annotations hreflang qui entourent le contenu.
L’objectif ne devrait pas être de faire croire à ces systèmes que les pages sont différentes alors qu’elles ne le sont pas. Les équipes internationales devraient plutôt rechercher les endroits où les marchés diffèrent réellement et s’assurer que ces différences se reflètent dans le contenu.
Cela nécessite plus qu’une équipe de référencement ou de localisation travaillant de manière indépendante. Les équipes internationales de référencement, de localisation, de contenu, de produit, juridique, de marketing régional et de marché local peuvent toutes détenir différentes informations nécessaires pour rendre une expérience de marché véritablement utile.
La mise en œuvre technique établit la relation ; les connaissances locales établissent la différence.
C’est finalement ce que l’explication des « noms alternatifs » de Google permet de clarifier. Le mystère documenté par Gabe n’était pas un bug ou une faille. Il a exposé les différences entre l’indexation, la notation et la diffusion bien avant que Google ne nous donne la terminologie pour les désigner.
À mesure que la recherche évolue vers la récupération sémantique et les réponses générées par l’IA, la plus grande leçon n’est pas simplement de savoir comment Google peut proposer une URL alternative qui n’a pas été indexée de manière indépendante. C’est pourquoi nous devrions donner à cette page alternative une valeur locale suffisamment unique pour que les machines et les clients aient une raison de s’en soucier en premier lieu.
Plus de ressources :
