En France, « hreflang » pèse 390 recherches par mois pour une concurrence publicitaire quasi nulle et un coût par clic de 20,25 euros. Le déséquilibre est parlant : peu de monde cherche le terme, et ceux qui le cherchent valent cher.

La première page de résultats est propre, sérieuse et parfaitement obsolète. On y trouve la documentation de Google, Wikipédia, MDN, IONOS daté d'août 2024, Oncrawl daté de janvier 2024, Abondance daté d'octobre 2023. Neuf résultats organiques qui expliquent tous la même chose avec la même exactitude : la réciprocité, les codes ISO, le x-default, les erreurs fréquentes. J'ai découpé ces neuf pages en phrases. Sur 701 phrases de plus de quarante caractères, 357 parlent du sujet et zéro ne mentionne un moteur génératif autrement que dans un menu de navigation.

C'est un angle mort inconfortable, parce que le SEO international est précisément le terrain où le passage aux moteurs de réponse déplace le plus de choses. Une balise hreflang est une consigne adressée à un index, et elle lui demande de substituer une URL par une autre dans une liste de résultats. Un moteur qui récupère des pages pour rédiger une réponse n'a ni cette liste, ni cette substitution à opérer. Il a une question dans une langue, et un document dans une langue.

Reste à savoir lequel.

Ce que j'ai mesuré le 27 août 2026. J'ai téléchargé les six listes d'adresses IP que publient OpenAI, Perplexity et Anthropic pour leurs robots, soit 298 préfixes, et je les ai géolocalisées avec deux services indépendants. J'ai compté les occurrences du vocabulaire de la langue et du pays dans la documentation robots de ces trois éditeurs et dans les deux guides IA de Google. J'ai demandé la page d'accueil de vingt sites européens dotés d'une version française avec l'agent utilisateur de GPTBot, une fois sans en-tête Accept-Language, une fois avec fr-FR, une fois avec en-US, et j'ai comparé la langue servie. J'ai relevé le balisage hreflang de la documentation hreflang de Google elle-même. Et j'ai soumis la même question à ChatGPT en recherche web forcée, en français puis en anglais, pour comparer les sources citées.

Ce que hreflang demande, et à qui

Il faut relire la phrase d'ouverture de la documentation officielle, parce qu'elle contient tout le problème. Google écrit que si vous avez plusieurs versions d'une page pour différentes langues ou régions, vous devez l'en informer, et que cela aidera la recherche Google à « orienter les utilisateurs vers la version la plus appropriée de votre page selon la langue ou la région ».

Orienter les utilisateurs. Dans les résultats de recherche. La balise ne décrit pas la page sur laquelle elle se trouve : elle décrit les autres, et elle demande à un système d'aiguillage de choisir entre elles au moment de l'affichage. Trois conditions sont donc nécessaires pour qu'elle serve à quelque chose : un index qui a vu les deux versions, un groupe qui les relie, et un moment d'affichage où l'arbitrage se produit.

Le mécanisme est le cousin direct de celui de la balise canonical, que j'ai détaillé dans l'article sur le contenu dupliqué et les moteurs génératifs. Dans les deux cas, plusieurs URL portent un contenu proche, dans les deux cas un protocole d'index désigne laquelle doit apparaître, et dans les deux cas la récupération directe ne dispose d'aucune des trois conditions. Un moteur qui va chercher une page pour répondre cite l'URL qu'il a récupérée. Il n'y a pas d'élection.

La documentation prévoit d'ailleurs trois canaux de livraison équivalents pour les annotations : les balises HTML dans l'en-tête, les en-têtes HTTP, et le sitemap XML. Le troisième mérite qu'on s'y arrête. Un moteur en récupération directe ne lit pas votre sitemap : les documentations robots d'OpenAI, de Perplexity et d'Anthropic n'en font aucune mention, ce que j'avais déjà relevé en travaillant sur IndexNow et les moteurs IA. Une entreprise qui a choisi le sitemap pour déclarer ses versions linguistiques, ce que Google recommande explicitement pour les gros catalogues, a placé la totalité de son dispositif international dans le seul canal auquel ces moteurs n'accèdent jamais.

Passons maintenant à la question qui décide vraiment : quelle version votre serveur donne-t-il au robot qui frappe à la porte ?

Les robots qui construisent les corpus ne partent que des États-Unis

OpenAI, Perplexity et Anthropic publient les plages d'adresses IP de leurs robots, au format JSON, sans authentification. C'est fait pour que les administrateurs de serveurs puissent vérifier qu'un visiteur qui se dit GPTBot en est bien un. Ces fichiers disent aussi autre chose, que personne ne semble avoir regardé : d'où partent ces robots.

J'ai récupéré les six listes et géolocalisé le premier hôte de chaque préfixe, avec ip-api.com puis avec ipinfo.io. Les deux services renvoient exactement les mêmes pays sur les 298 préfixes.

Liste publiee                       Prefixes  Etats-Unis  Hors USA
----------------------------------  --------  ----------  --------
openai.com/gptbot.json              21        21          0
openai.com/searchbot.json           35        35          0
perplexity.ai/perplexitybot.json    8         8           0
perplexity.ai/perplexity-user.json  4         4           0
claude.com/crawling/bots.json       26        26          0
openai.com/chatgpt-user.json        204       102         102

Les cinq premières lignes se lisent d'un bloc : 94 préfixes publiés, 94 géolocalisés aux États-Unis. Aucune exception. Les adresses d'OpenAI sont toutes dans le système autonome 8075, celui de Microsoft, et sortent d'Atlanta, de Phoenix, de Des Moines et de Boydton. Celles de Perplexity sont toutes dans le système autonome 14618, celui d'Amazon, et sortent toutes d'Ashburn, en Virginie. Anthropic publie une liste unique pour l'ensemble de ses robots, avec cette formule dans sa documentation : si un robot a une adresse source figurant sur cette liste, cela indique qu'il vient d'Anthropic.

Ce relevé prolonge, sur l'axe des langues et des pays, ce que j'avais observé sur les requêtes géolocalisées dans l'article consacré au référencement local et aux moteurs IA : la géographie de l'utilisateur et celle du robot sont deux choses distinctes, et c'est la seconde qui décide de ce qui entre dans le corpus.

La dernière ligne est la seule qui échappe à la règle, et c'est logique. ChatGPT-User est le robot déclenché par une action d'utilisateur, celui qui va chercher une page parce que quelqu'un vient de poser une question. Il suit son utilisateur : 204 préfixes répartis sur 21 pays, dont l'Allemagne, le Japon, l'Inde, la Suisse, le Danemark, la Corée, l'Australie, le Brésil, la Belgique, Singapour. Exactement la moitié reste aux États-Unis. Et la France ne figure pas sur la liste, ce que les deux services de géolocalisation confirment séparément. Notons que le robot déclenché par l'utilisateur de Perplexity, lui, n'est pas géo-distribué : ses quatre préfixes sont américains comme les autres.

La séparation entre robot d'entraînement, robot de recherche et robot déclenché par l'utilisateur, que j'avais posée dans l'article sur les user-agents des crawlers IA, prend ici une dimension géographique qui n'avait pas été relevée. Le seul robot géo-distribué de tout ce relevé est celui qui arrive après la question, dans une session, pour une réponse ponctuelle. Ceux qui constituent le stock, GPTBot pour l'entraînement, OAI-SearchBot et PerplexityBot pour la recherche, partent tous du même pays. Or c'est le stock qui décide de ce que le modèle sait de vous entre deux requêtes, et c'est lui qu'on mesure dans les journaux du serveur.

Google documente le problème depuis des années, les autres n'en parlent pas

Ce constat n'a rien d'inédit dans l'histoire du référencement. Google l'a écrit noir sur blanc, et sa page tient toujours, mise à jour le 10 décembre 2025. Elle s'appelle « How Google crawls locale-adaptive pages » et elle explique pourquoi un site qui adapte son contenu au pays ou à la langue du visiteur risque de ne pas être exploré correctement :

This is because the default IP addresses of the Googlebot crawler appear to be based in the USA. In addition, the crawler sends HTTP requests without setting Accept-Language in the request header.

Deux variables, donc, et Google les nomme toutes les deux : l'adresse d'origine, américaine par défaut, et l'en-tête Accept-Language, absent. La même page décrit ensuite le correctif que Google a mis en place de son côté, l'exploration géo-distribuée : Googlebot explore aussi depuis des adresses situées hors des États-Unis, et le conseil aux éditeurs est de le traiter comme n'importe quel visiteur venu de ce pays. Et la page se termine par une recommandation sans ambiguïté : utiliser des URL distinctes par version linguistique et les annoter en rel="alternate" hreflang.

Voilà donc un problème identifié, documenté et corrigé par le moteur qui l'a rencontré le premier.

J'ai cherché le même vocabulaire dans les documentations des trois éditeurs de robots IA. Sur la page robots d'OpenAI, sur celle de Perplexity et sur l'article d'Anthropic, une fois les scripts, les styles et les balises retirés, les chaînes « hreflang », « Accept-Language », « locale », « geo » et « country » apparaissent zéro fois. Le mot « language » apparaît zéro fois chez OpenAI et Perplexity, et deux fois chez Anthropic, les deux dans le menu d'articles connexes du centre d'aide. Le HTML brut de la page de Perplexity contient bien quatorze « language » et un « locale », mais tous dans les données JSON embarquées qui alimentent le moteur de recherche interne du site de documentation, jamais dans le texte servi au lecteur.

Le geste vaut aussi dans l'autre sens. Sur les deux documents que Google consacre à ses propres surfaces génératives, le guide des fonctionnalités IA et le guide d'optimisation, les chaînes « hreflang » et « language » sont à zéro sur la page entière. Les mots « multilingual », « translation », « localized » et « international » y apparaissent bien, quatre, trois, une et trois fois, mais l'impression des contextes est sans appel : les onze occurrences sont dans le menu latéral de navigation, qui liste la rubrique « International and multilingual sites » du site de documentation. Corps à zéro sur les deux documents. C'est le même piège que celui rencontré sur ce guide en travaillant le contenu dupliqué, et il faut continuer à imprimer les contextes avant d'annoncer un zéro.

Symétriquement, la documentation hreflang de Google ne dit pas un mot des surfaces génératives : « AI Overview », « AI Mode », « Gemini », « chatbot » et « LLM » y sont à zéro, et les cinq occurrences de « generative » viennent du menu. Deux documentations du même éditeur, aucune des deux ne parle de l'autre.

Ces comptages ne prouvent pas que les moteurs génératifs ignorent la langue. Ils établissent qu'aucun des trois éditeurs ne prend d'engagement sur le sujet, et qu'aucune consigne officielle n'existe pour un site multilingue qui voudrait bien faire. En l'absence de consigne, il ne reste que la mesure.

Une URL française, deux langues, et c'est l'en-tête qui tranche

J'ai donc mesuré. Vingt sites d'éditeurs européens, dix-neuf français et un allemand, tous dotés d'une version française, demandés avec l'agent utilisateur de GPTBot, trois fois chacun : sans en-tête Accept-Language, avec fr-FR, avec en-US. La commande tient sur une ligne et se reproduit en dix secondes sur votre propre domaine :

curl -sIL -A "compatible; GPTBot/1.2" -H "Accept-Language;" \
     -o /dev/null -w "%{url_effective}\n" https://votre-site.fr/

Le point-virgule après Accept-Language est la syntaxe de curl pour envoyer la requête sans cet en-tête du tout, ce qui reproduit la situation que Google décrit pour son propre robot.

Cinq sites sur vingt servent une version différente selon l'en-tête. Dans les cinq cas, la requête sans Accept-Language aboutit à la version anglaise.

Domaine       Sans Accept-Language  Avec fr-FR
------------  --------------------  ---------------
qonto.com     /en   (lang=en)       /fr   (lang=fr)
dashlane.com  /     (lang=en)       /fr   (lang=fr)
deepl.com     /en   (lang=en)       /fr   (lang=fr)
payfit.com    /     (lang=en)       /fr/  (lang=fr)
spendesk.com  /     (lang=en)       /fr/  (lang=fr)

Le cas de DeepL a quelque chose de savoureux : une entreprise de traduction qui sert sa page anglaise à un robot sans préférence linguistique. Mais le cas le plus instructif est celui de PayFit, parce qu'il ne s'agit même pas d'une redirection. La même URL, https://www.payfit.com/fr/, rend deux pages différentes selon l'en-tête envoyé, avec le même agent utilisateur :

Sans Accept-Language  <html lang="en">
                      UK Payroll Software for Seamless
                      Automation | PayFit
Accept-Language fr-FR <html lang="fr">
                      Logiciel de paie et RH en ligne

Une URL qui contient /fr/, servie en anglais britannique, avec un attribut lang qui le confirme, à un robot qui n'envoie pas l'en-tête que Google documente comme absent de ses propres requêtes.

Et le balisage de cette page, lui, est correct. Elle émet quatre éléments <link rel="alternate">, en en, es, fr et x-default, tous pointant vers l'hôte sans www. Or ce jumeau sans www répond, lui, en français à la même requête sans en-tête : https://payfit.com/fr/ rend « Logiciel de paie et RH en ligne » avec lang="fr". Deux hôtes, un seul chemin, deux langues, et c'est celui que les annotations désignent qui fonctionne. Aucun outil d'audit hreflang classique ne signale quoi que ce soit, puisque l'outil, lui, envoie un Accept-Language. Détail supplémentaire relevé au passage : la balise canonical de cette page française pointe vers https://payfit.com/, c'est-à-dire vers la page d'accueil anglaise.

Deux autres observations du même relevé. Trois sites sur vingt répondent HTTP 403 à l'agent GPTBot, malt.fr, algolia.com et leboncoin.fr, ce qui est un choix légitime mais rend le reste de la question sans objet pour eux. Et sur les dix-sept qui répondent 200, cinq n'émettent aucun attribut hreflang dans le HTML brut : qonto.com, deepl.com, swile.co, doctolib.fr et lemlist.com. Deux d'entre eux, Qonto et DeepL, sont aussi dans la liste des cinq qui aiguillent par en-tête. Leurs pages françaises existent, elles déclarent bien lang="fr", et rien dans le HTML servi ne permet à un robot arrivé sur la version anglaise de savoir qu'elles existent.

Google avait prévu le cas et le déconseille formellement, dans sa page sur les sites multi-régionaux : éviter de rediriger automatiquement les utilisateurs d'une version linguistique vers une autre, ne pas rediriger selon la langue qu'on suppose être la leur, parce que ces redirections peuvent empêcher les utilisateurs et les moteurs de recherche de voir toutes les versions du site. Le conseil a vingt ans. Il vient de changer d'enjeu.

La documentation hreflang de Google, parfaitement balisée, citée en anglais

Il reste une hypothèse à écarter. Peut-être qu'un balisage hreflang irréprochable, servi en HTML brut, suffit à orienter un moteur génératif vers la bonne version. Pour le savoir, il faut un site dont le balisage est au-dessus de tout soupçon.

La page de documentation hreflang de Google fait l'affaire. Son en-tête HTML, 6 998 caractères, contient vingt éléments <link rel="alternate"> portant chacun un attribut hreflang : en, x-default, ar, zh-Hans, zh-Hant, fr, de, hi, id, it, ja, ko, pl, pt-BR, ru, es, es-419, th, tr, vi. La variante française pointe vers la même URL suffixée de ?hl=fr. C'est la mise en oeuvre exemplaire, écrite par les auteurs de la spécification, sur la page qui explique la spécification.

J'ai posé à ChatGPT, en recherche web forcée, localisation France et langue française, la question « Comment mettre en place les balises hreflang sur un site multilingue ? ». La réponse cite trois pages, toutes sur developers.google.com. Deux des trois sont servies en anglais. Et l'une de ces deux est demandée par un chemin obsolète, /search/docs/advanced/crawling/localized-versions, qui renvoie aujourd'hui un HTTP 301 vers l'adresse actuelle, avec un paramètre de session visit_id collé à l'URL.

J'ai posé la même question en anglais, localisation États-Unis. Quatre pages citées, toutes sur developers.google.com également, et l'intersection avec le jeu français est vide : dépannage de la canonisation, définition de la canonisation, page des mises à jour de la documentation, guide de migration d'URL. Aucune n'est la documentation hreflang. Deux portent un paramètre authuser=2, c'est-à-dire l'identifiant de compte d'une session Google.

Trois enseignements se lisent dans ce relevé. Le balisage hreflang le mieux fait du web n'a pas suffi à faire citer la version française dans une réponse française. Les jeux d'URL retenus pour la même question dans deux langues n'ont aucun recouvrement, alors qu'ils viennent du même domaine, ce qui rappelle la dispersion mesurée sur le suivi des citations IA. Et le stock d'adresses de ces moteurs contient des URL périmées et des paramètres de session, ce qui prolonge le constat de Vercel et Merj sur le taux de 404 des robots IA, 34,82 % pour ChatGPT contre 8,22 % pour Googlebot, que j'avais utilisé à propos du maillage interne.

Ce qui remplace hreflang : un corpus par langue

Si la balise ne voyage pas, que reste-t-il du SEO multilingue ? Trois choses, et aucune n'est une annotation.

L'auto-description. Une balise hreflang parle des autres pages, l'attribut lang de la balise <html> parle de celle-ci. C'est la seule des deux informations qui reste attachée au texte quand un passage en est extrait. Le raisonnement est exactement celui que j'appliquais à l'E-E-A-T dans l'article sur l'attribution : sur les trois sources d'évaluation, seule celle qui est visible sur la page elle-même survit à l'extraction. Vérifier que chaque version déclare sa propre langue, et qu'elle la déclare correctement, coûte cinq minutes et corrige le défaut exact que porte la page française de PayFit dans mon relevé.

Un corpus, pas une traduction. La langue de la requête explique environ 32 % de la variance des réponses d'un modèle, d'après la décomposition de Dmitrij Żatuchin sur 12 933 réponses, que j'avais détaillée dans l'article sur le suivi des citations. Dans la même décomposition, l'identité de la marque en explique 1,6 %, soit vingt fois moins. Une langue n'est donc pas un habillage de votre contenu : c'est un espace de récupération séparé, avec ses propres sources dominantes, ses propres formulations de question et ses propres concurrents. Le corollaire pratique est désagréable pour les budgets : une traduction littérale de vos pages françaises ne vous fait pas exister dans l'espace anglophone, parce qu'elle répond à des questions posées en français avec des exemples français. Chaque langue veut ses chiffres, ses cas et ses sources locales, faute de quoi elle n'a pas de passage qui tienne debout tout seul dans cette langue.

Une joignabilité qui ne dépend d'aucun en-tête. C'est le geste le plus rentable, et le plus simple. Chaque version linguistique doit avoir son URL propre, répondre 200 à une requête sans Accept-Language, et être atteignable par un lien HTML en dur depuis les autres versions. Pas un sélecteur de langue en JavaScript, qui tombe sous le même couperet que dans l'article sur le rendu JavaScript et les crawlers IA, mais une balise <a href> présente dans le HTML brut. Le conseil que Google donne pour ses propres surfaces IA se réduit d'ailleurs à cela : rendre le contenu facilement trouvable par les liens internes du site.

Ces trois gestes ne remplacent pas hreflang au sens où ils feraient la même chose. Ils traitent le problème que hreflang laisse ouvert quand il n'y a plus d'index pour l'arbitrer.

Ce que cet article n'établit pas

Mon relevé d'adresses IP porte sur les plages que ces éditeurs publient volontairement, à une date donnée. Il ne prouve pas qu'aucune requête ne part d'ailleurs : il établit que sur les 94 préfixes déclarés hors de la liste de ChatGPT-User, aucun n'est géolocalisé hors des États-Unis, et que la géolocalisation d'adresses de fournisseurs de cloud reste une donnée déclarative, dérivée des fichiers publiés par Microsoft, Amazon et Google.

Je n'ai pas pu tester la seconde variable que Google nomme, l'adresse d'origine. Mes requêtes partent d'une adresse française, donc les sites qui aiguillent par géolocalisation IP m'ont servi du français, et deux d'entre eux, backmarket.fr et ovhcloud.com, ont bien envoyé leur version française quel que soit l'en-tête. Ce que je n'ai pas mesuré, c'est ce qu'ils servent depuis Phoenix ou Ashburn. Le sens de l'effet est déductible, sa mesure ne l'est pas.

Je n'ai testé aucune intervention. Rien ici ne démontre qu'ajouter un balisage hreflang, en retirer un, ou supprimer une négociation de contenu changerait le taux de citation d'un site. Pour l'affirmer, il faudrait le dispositif décrit dans l'article sur le test A/B en GEO, avec un groupe témoin, et l'unité randomisable manque pour un réglage qui s'applique à tout un domaine.

Enfin, mes deux relevés ChatGPT sont deux exécutions, pas une campagne. Une réponse isolée porte beaucoup de bruit, et la répétition est la seule façon d'en tirer une part de voix défendable.

Ce qu'il faut retenir

La documentation française de hreflang est excellente et elle n'a pas changé de monde. Elle explique très bien comment demander à un index d'aiguiller un utilisateur vers la bonne traduction, et cette demande reste utile pour Google, y compris pour ses surfaces IA qui s'appuient sur son index, comme je l'expliquais à propos du Mode IA.

Ce qu'elle ne peut pas faire, c'est décider quelle version de votre page un robot va recevoir quand il frappe à votre porte depuis Phoenix, sans dire dans quelle langue il lit. Sur les 94 plages IP publiées hors de la liste de ChatGPT-User, 94 sont aux États-Unis. Sur vingt sites européens testés, cinq répondent en anglais à un robot sans préférence linguistique, et l'un d'eux le fait sur une URL qui contient /fr/.

Le SEO international en régime génératif se joue donc ailleurs que dans les balises. Il se joue dans la négociation de contenu, dans la langue déclarée sur la page, et dans le corpus réellement écrit pour chaque langue visée. Votre balisage peut être parfait : si votre serveur donne l'anglais au robot, c'est l'anglais qui sera cité.

Vérifier ce que votre serveur sert réellement aux robots IA, version par version et langue par langue, fait partie de chaque audit GEO que nous menons, et le vocabulaire de ces sujets est détaillé dans notre glossaire. La question de départ tient en une commande : demandez votre page d'accueil sans Accept-Language, et regardez dans quelle langue elle vous répond.