Hreflang et recherche interne : pourquoi l'e-commerce multilingue ne trouve pas les produits

Un e-commerce multilingue peut avoir des hreflang parfaits et perdre quand même le client étranger. Hreflang décide quelle URL afficher dans la SERP ; il ne décide pas de ce que trouve l'utilisateur quand, arrivé sur la boutique française ou allemande, il tape sa recherche dans la barre du site avec ses propres mots.

Les audits SEO/AEO/GEO internationaux contrôlent les annotations, les canonical et les sitemaps par marché, et s'arrêtent à l'atterrissage. La recherche interne, qui interroge un index construit à partir du catalogue traduit, reste en dehors de tous les outils SEO.

Voyons comment fonctionne vraiment hreflang à la lumière de ce que Google a expliqué sur les « alternate names », pourquoi les IA traitent les pages traduites comme un seul et même contenu, et pourquoi ce même catalogue traduit mot à mot produit des recherches sans résultat sur les boutiques étrangères. Enfin, ce qu'il faut faire dans Meilisearch, Algolia et Elasticsearch.

Comment fonctionne hreflang : du routage, pas du classement

Hreflang n'est pas un signal de classement. C'est une table de correspondances : il indique à Google qu'une URL est l'équivalent italien d'une autre, qu'une troisième s'adresse aux anglophones du Royaume-Uni, une quatrième à l'Australie. Google utilise ces relations pour choisir quelle URL présenter à un utilisateur, pas pour décider à quelle position la classer.

Si la page américaine est déjà bien positionnée au Royaume-Uni, ajouter l'alternate britannique ne crée pas de nouveau score. Cela change seulement l'adresse affichée pour un classement déjà calculé.

Bill Hunt, consultant en stratégie digitale internationale, président de Bisan Digital et l'un des noms les plus connus du SEO international, l'explique très bien dans un article publié sur Search Engine Journal le 28 octobre 2026. Hunt raconte avoir suivi des dizaines de milliers d'implémentations de hreflang sans jamais voir une page monter dans le classement grâce à l'annotation elle-même. Sa formule : hreflang route, il ne classe pas.

Pour comprendre pourquoi, il faut séparer cinq étapes que l'on imagine d'habitude comme une seule séquence. Avec la découverte, Google trouve les URL grâce aux sitemaps, aux liens internes et aux annotations hreflang. Avec la canonicalisation, il décide s'il s'agit de ressources différentes ou de variantes quasi identiques du même contenu. Avec l'indexation, il ne mémorise comme document autonome que ce qui le mérite. Avec le scoring, il calcule le classement sur le membre retenu du groupe. Avec le serving, au moment de la réponse, il choisit quelle URL montrer à cet utilisateur, dans ce pays et dans cette langue. Hreflang intervient surtout dans cette dernière étape.

Alternate names : ce que Gary Illyes a expliqué sur les URL hreflang

En 2018, Glenn Gabe, consultant SEO américain, fondateur de GSQi et connu surtout pour ses analyses des mises à jour de l'algorithme de Google, a documenté un cas étrange. Un site canonicalisait ses versions britannique et indienne vers la version américaine, contrairement aux recommandations de Google. Pourtant, les URL « erronées » apparaissaient correctement dans les SERP locales, alors que la Search Console les indiquait comme non indexées.

Gabe a demandé des explications à John Mueller, à l'époque le porte-parole de Google le plus présent dans le dialogue avec les webmasters. Mueller a confirmé que le comportement était réel, sans en expliquer le mécanisme. Gabe l'a baptisé le « tour de magie » de hreflang.

En août 2026, le mécanisme a reçu un nom. Gary Illyes, analyste dans l'équipe Google Search et l'une des voix officielles de Google sur les sujets techniques, a répondu sur LinkedIn à une question portant précisément sur ce scénario. Quand Google canonicalise une URL, a-t-il expliqué, les autres URL du groupe de doublons dont elle a été choisie peuvent devenir des alternate names : elles ne sont pas indexées au sens propre, mais peuvent apparaître dans les résultats quand la recherche de l'utilisateur le justifie. Les alternates hreflang, a-t-il ajouté, entrent dans cette catégorie.

Conséquence pratique : l'URL britannique peut apparaître dans la SERP sans avoir jamais été indexée en tant que telle. Hreflang ne lui a pas donné un classement, il lui a donné une adresse. Et le statut « non indexée » dans la Search Console, pour une variante linguistique, n'est pas en soi une erreur à corriger.

Le cas que Hunt cite dans son article donne une idée de l'échelle. Une marque mondiale de chaussures comptait environ 98 sites marché, dont 38 en anglais et presque identiques, et 22 avec le même symbole du dollar. Pour l'entreprise, c'étaient 38 marchés. Pour Google, en grande partie, un seul groupe de pages équivalentes.

SEO international et IA : 20 pages traduites ne sont qu'une seule source

Avec le retrieval sémantique, l'étau se resserre encore. Hreflang est une relation déclarée : c'est nous qui affirmons que deux pages sont équivalentes. Les systèmes d'IA reconnaissent cette équivalence tout seuls, en lisant le contenu.

L'exemple le plus clair vient de Microsoft Web IQ, l'infrastructure de recherche et de grounding conçue pour les agents IA, présentée par Microsoft lors de la conférence Build le 2 juin 2026 et construite sur l'index de Bing. Web IQ ne renvoie pas des pages entières mais des passages de texte, utilisés comme preuves dans le raisonnement du modèle. Selon la lecture de Hunt, ses modèles multilingues sont conçus pour représenter aussi près que possible les informations équivalentes, même lorsqu'elles sont écrites dans des langues différentes.

Résultat : 20 pages marché avec les mêmes caractéristiques, les mêmes FAQ et les mêmes descriptions ne forment qu'une seule unité de connaissance avec 20 adresses. Les traduire à nouveau, ou ajouter un vingt-et-unième marché, n'apporte rien qu'une IA ait une raison de citer.

C'est la conclusion à laquelle arrive Hunt lui-même : hreflang ne rend pas un contenu local. La raison d'être d'une page marché doit se trouver dans son contenu, c'est-à-dire dans les prix, la réglementation, la disponibilité, les garanties, la livraison, les cas clients et la terminologie de ce pays.

Hunt est revenu sur le sujet en discutant de l'article (avec moi) sur LinkedIn (voir la conversation). Il a raconté avoir analysé récemment une entreprise dont les sites pour la France et l'Allemagne étaient en français et en allemand, mais où ni la page d'accueil ni les principales fiches produit ne mentionnaient le pays : en dehors du domaine national, rien n'indiquait qu'ils s'adressaient à ces marchés. Selon Hunt, ceux qui veulent une visibilité spécifique par marché dans les réponses des IA devront investir dans des adaptations pensées pour chaque pays, car il n'existe pas d'équivalent de hreflang pour les modèles.

La recherche interne, angle mort de l'audit SEO international

Un audit SEO multilingue classique vérifie que les annotations hreflang sont valides et réciproques, que les canonical sont cohérentes d'un marché à l'autre, que chaque marché a son sitemap. De plus en plus souvent, il contrôle aussi les citations de la marque dans les AI Overviews par pays. Tout ce travail sert à faire atterrir l'utilisateur sur la bonne version. Ce qui se passe après l'atterrissage, personne ne le mesure.

L'utilisateur français arrive sur la boutique FR et tape sa recherche. La requête part vers le moteur de recherche interne, qui interroge un index construit à partir du catalogue traduit. Cette étape est invisible pour toute la chaîne SEO. Aucun crawler SEO n'effectue de recherches internes. La Search Console ne voit pas les requêtes faites sur le site. GA4 les enregistre au mieux sous forme d'événement view_search_results, et seulement si le paramètre de recherche est correctement suivi.

C'est pourtant le moment où l'utilisateur a déjà choisi la boutique et s'apprête à choisir le produit. Chaque recherche sans réponse, à ce stade, c'est du trafic gagné grâce au SEO ou payé en publicité qui repart aussitôt.

Vocabulary mismatch : pourquoi le catalogue traduit génère des recherches sans résultat

Le catalogue traduit mot à mot coûte deux fois. Côté IA, c'est un contenu équivalent que le retrieval reconnaît déjà tout seul : il n'apporte aucune visibilité supplémentaire. Côté recherche interne, il produit du vocabulary mismatch : les mots de l'index ne sont pas ceux qu'utilisent les acheteurs.

Un moteur lexical compare des mots. Si l'utilisateur français tape « k-way » et que l'index contient « veste imperméable », le résultat est nul, même si le produit existe. Aucun hreflang ne règle ce problème : la question n'est pas quelle URL on sert, mais quels mots se trouvent dans l'index.

Les causes reviennent toujours. Les marques devenues noms communs, comme k-way ou Sopalin en France, n'apparaissent dans aucune traduction professionnelle. Le registre trahit la traduction : le traducteur choisit le terme correct, le client celui qu'il emploie. Les variantes régionales touchent les boutiques qui servent le Royaume-Uni, les États-Unis et l'Australie avec un seul vocabulaire anglais. La morphologie pèse surtout en allemand, où les mots composés ne sont pas trouvés si l'analyseur ne les décompose pas.

Le problème existe déjà dans la langue d'origine. Sur les e-commerces italiens que nous mesurons dans notre classement, les recherches en langage naturel obtiennent en moyenne 3,7 réponses pertinentes sur 10, et 21 % des recherches aboutissent à une page sans résultat. Sur les boutiques étrangères, où le catalogue est une traduction, il faut s'attendre à pire.

Comment localiser le catalogue pour la recherche interne

Localiser un catalogue ne consiste pas à traduire des chaînes de caractères. Cela consiste à mettre dans l'index les mots de ceux qui achètent sur ce marché. C'est la seule intervention qui agit en même temps sur la SERP, sur le retrieval des IA et sur la recherche interne.

Un index par marché, avec la bonne analyse linguistique

Chaque langue a besoin de sa propre tokenisation, de ses pluriels, de ses mots vides et, pour l'allemand et les langues nordiques, de la décomposition des mots composés. Un index unique aux réglages génériques pénalise toutes les langues sauf celle d'origine.

Dans Meilisearch, la langue se déclare par attribut avec le paramètre d'index localizedAttributes, et dans la requête avec le paramètre locales, qui prime sur le réglage de l'index. Le tokeniseur décompose les mots composés allemands, mais la documentation elle-même conseille de placer dans un index séparé les langues à mots composés comme l'allemand. Pour les jeux de données multilingues, elle suggère d'associer à la recherche par mots une recherche hybride avec un modèle d'embedding multilingue.

Dans Algolia, la langue se règle avec indexLanguages pour l'indexation et queryLanguages pour les recherches, avec ignorePlurals et removeStopWords. La décomposition des mots composés s'active avec decompoundedAttributes sur les attributs et decompoundQuery sur les requêtes ; elle est disponible pour l'allemand, le néerlandais, le finnois, le danois, le suédois et le norvégien.

Dans Elasticsearch, on utilise les analyseurs de langue (french, german, etc.) et, pour les mots composés, les filtres dictionary_decompounder ou hyphenation_decompounder. Les synonymes se gèrent avec le filtre synonym_graph appliqué au moment de la recherche, ce qui permet de les mettre à jour sans réindexer.

Dans les trois moteurs, les synonymes doivent être gérés par index, donc par marché : « k-way » est un synonyme utile en France et du bruit en Allemagne.

Collecter le vocabulaire local dans les données, pas dans le glossaire

Les bons mots, ce n'est pas le traducteur qui les connaît : ce sont les clients qui les tapent. La source la plus fiable, ce sont les logs de recherche interne par marché, en particulier les recherches sans résultat et celles suivies d'une sortie du site. Viennent ensuite les requêtes de la Search Console filtrées par pays, qui montrent avec quels mots les utilisateurs arrivent depuis le moteur de recherche. Les marketplaces et les concurrents locaux révèlent les termes employés dans les titres produits d'Amazon.fr ou de Zalando.de. Le service client et les avis dans la langue du marché complètent le tableau.

Enrichir la donnée, pas seulement le moteur

Les synonymes dans le moteur sont un pansement : ils fonctionnent, mais ils vivent en dehors du catalogue. L'intervention durable consiste à ajouter les termes locaux aux données produit, par exemple dans un attribut recherchable dédié aux termes de recherche de chaque marché, dans le système qui détient la source de la donnée, qu'il s'agisse de la plateforme e-commerce ou du PIM. Ainsi, les mêmes termes alimentent aussi les flux, les marketplaces et les pages que lisent Google et les IA.

Recherche sémantique : utile, mais pas suffisante

Une recherche hybride avec des modèles d'embedding multilingues réduit le vocabulary mismatch, parce qu'elle compare des significations et non des mots. Mais une marque devenue nom commun ou un terme très familier peut rester en dehors de l'espace sémantique du modèle. La partie lexicale, avec des synonymes par marché et des données enrichies, reste nécessaire.

Mesurer par marché

Chaque marché doit être mesuré séparément : part de recherches sans résultat, clics sur les résultats, sorties après la recherche. Une valeur moyenne sur toutes les boutiques cache justement le marché qui va le plus mal.

Audit SEO/AEO/GEO international pour l'e-commerce : quoi contrôler avant et après l'atterrissage

La partie classique de l'audit reste nécessaire ; il faut simplement la compléter par ce qui se passe une fois l'utilisateur arrivé sur la boutique.

Avant l'atterrissage, on vérifie que les hreflang sont valides, réciproques et cohérents avec les canonical, que chaque marché a son sitemap et que les pages marché ont un contenu réellement local : le pays cité dans les textes, les prix, la TVA, la livraison, les retours, les moyens de paiement et la réglementation. On mesure aussi la façon dont les réponses des IA citent la marque, pays par pays et langue par langue.

Après l'atterrissage, on contrôle que chaque marché a son propre index, avec l'analyseur de la bonne langue et la décomposition des mots composés là où c'est nécessaire. On vérifie que le suivi des recherches internes est actif sur chaque boutique et on mesure la part de recherches sans résultat par marché, jamais en moyenne. On met le moteur à l'épreuve avec une vingtaine de recherches rédigées par un locuteur natif, et non tirées du catalogue. Enfin, on collecte les termes locaux dans les logs et dans la Search Console, et on les ajoute aux données produit dans le système qui détient la source de la donnée.

Le dernier contrôle se joue dans la durée : le vocabulaire des clients évolue, le catalogue traduit non. Un audit de la recherche interne par marché doit être répété, pas réalisé une seule fois.

Questions fréquentes

Hreflang améliore-t-il le classement ?

Non. Hreflang indique à Google quelle version d'une page afficher en fonction du pays et de la langue de l'utilisateur. Le classement est calculé sur un membre du groupe de pages équivalentes ; hreflang intervient au moment où Google choisit quelle URL servir.

Que sont les alternate names de Google ?

C'est le terme employé par Gary Illyes, de Google, pour désigner les URL d'un groupe de doublons qui ne sont pas indexées de façon autonome, mais qui peuvent apparaître dans les résultats quand la recherche de l'utilisateur le justifie. Les URL alternatives déclarées avec hreflang entrent dans cette catégorie.

Pourquoi la Search Console indique-t-elle les versions dans d'autres langues comme non indexées ?

Parce que, d'après les explications de Gary Illyes, les variantes hreflang ne sont pas indexées au sens propre : Google les conserve comme noms alternatifs de la page canonique. Elles peuvent tout de même être présentées aux utilisateurs du bon pays.

Les IA citent-elles les versions traduites d'un site comme des sources distinctes ?

En général, non. Les modèles multilingues reconnaissent comme équivalents les contenus qui disent la même chose dans des langues différentes. Une page traduite sans informations locales propres ne donne au système aucune raison supplémentaire de la citer.

Pourquoi la recherche interne d'une boutique étrangère ne trouve-t-elle pas des produits qui existent ?

Parce que l'index contient les mots de la traduction, alors que les clients cherchent avec les leurs : termes familiers, marques devenues noms communs, variantes régionales, mots composés. Le moteur compare les mots et ne trouve pas de correspondance.

La recherche sémantique résout-elle le problème des langues ?

En partie. Elle réduit l'écart entre des mots différents qui ont le même sens, mais elle ne couvre pas tous les termes familiers ou de marque. Elle fonctionne mieux associée à des synonymes par marché et à des données produit enrichies avec les termes locaux.