Hreflang pour la zone DACH : pourquoi les plateformes d'IA exploitent à peine ces balises

Hreflang est considéré comme l'outil standard des sites multilingues et multirégionaux. Dans la zone DACH (Allemagne, Autriche, Suisse), il doit garantir que les utilisateurs autrichiens voient la version de-AT, les Allemands la version de-DE et les Suisses la version de-CH. Cette logique fonctionne dans la recherche Google classique, mais se heurte à une nouvelle limite : les plateformes d'IA comme ChatGPT, Perplexity, Copilot et Claude n'exploitent pratiquement pas les annotations hreflang. Cet article explique comment configurer correctement hreflang pour la zone DACH, pourquoi les crawlers d'IA ignorent ces signaux et comment tu peux malgré tout rendre un contenu de-AT visible dans les réponses d'IA et dans la recherche classique.

Pourquoi hreflang compte pour la zone DACH et où se situe la nouvelle limite

La zone DACH est un cas particulier : trois pays, une langue, mais des marchés distincts, avec leurs propres prix, cadres juridiques et parfois leurs propres termes. C'est précisément là qu'intervient hreflang. Il indique aux moteurs de recherche quelle URL est destinée à quelle combinaison langue-région, afin que Google affiche la page de-AT en Autriche et la page de-DE en Allemagne.

Le marché autrichien est presque entièrement connecté. Début 2025, 8,69 millions de personnes en Autriche utilisaient Internet, avec un taux de pénétration de 95,3 % (Autriche). Quiconque cible ce marché avec sa propre localisation de-AT a un intérêt légitime à ce que la bonne variante soit affichée, dans Google et, de plus en plus, dans les systèmes d'IA.

C'est justement là que la donne change. Hreflang ne fonctionne plus comme une contrainte stricte dès que les contenus sont restitués via la récupération d'informations par l'IA. La diffusion de cette recherche par IA est mesurable : en Allemagne, 50 % des internautes utilisent au moins occasionnellement des chats d'IA à la place des moteurs de recherche classiques (Allemagne), et 42 % de ces utilisateurs de la recherche par IA ont déjà reçu de l'IA des informations fausses ou inventées (Allemagne). Les mauvaises versions linguistiques font partie de ce problème : quand un système restitue des contenus de-DE pour une requête autrichienne, les prix, les taux de TVA ou les termes juridiques sont souvent faux.

Les bases de hreflang pour la zone DACH : annotation correcte et réciprocité obligatoire

Une implémentation propre de hreflang pour la zone DACH suit des règles claires. Les codes langue-région combinent ISO 639-1 (langue) et ISO 3166-1 Alpha-2 (région).

• Codes langue-région corrects : de-DE pour l'Allemagne, de-AT pour l'Autriche, de-CH pour la Suisse. Un simple de sans région cible tous les utilisateurs germanophones, quel que soit leur pays, et peut être utile comme variante générique supplémentaire.
• x-default comme solution de repli : La valeur x-default désigne la page affichée quand aucune autre variante ne correspond, par exemple pour des utilisateurs germanophones hors de la zone DACH ou pour une page de choix de la langue. x-default est l'élément qui manque le plus souvent.
• Autoréférence : Chaque page doit aussi se référencer elle-même via hreflang. La page de-AT liste donc de-DE et de-CH, ainsi qu'elle-même en tant que de-AT.
• Renvois réciproques (lien retour obligatoire) : Hreflang est bidirectionnel. Si la page de-DE renvoie vers la page de-AT, la page de-AT doit renvoyer vers la page de-DE. Si le lien retour manque, Google ignore l'annotation.

Un minimum pour la zone DACH comprend donc de-DE, de-AT, de-CH et x-default, chacun avec des balises complètes, réciproques et autoréférentes. Malgré ces règles claires, hreflang est source d'erreurs. Une analyse internationale de 374 756 domaines a montré que 67 % présentent au moins un problème d'implémentation hreflang (international). Les erreurs les plus fréquentes : x-default manque dans 56,3 % des cas, les balises autoréférentes manquent dans 18 % des cas et, dans 16,9 % des cas, les balises hreflang renvoient vers des pages redirigées ou cassées (international).

Pourquoi les crawlers d'IA ignorent largement hreflang

La différence décisive entre Google et les plateformes d'IA réside dans le traitement. Google effectue le rendu des pages, exécute le JavaScript et sélectionne la variante linguistique et régionale sur la base de hreflang, de la localisation et des paramètres de langue. Les crawlers d'IA ne le font pas.

Une analyse du trafic des crawlers sur le réseau Vercel le montre : aucun des grands crawlers d'IA n'effectue de rendu JavaScript (international). GPTBot, OAI-SearchBot, ClaudeBot et PerplexityBot chargent les contenus, mais ne les exécutent pas. À lui seul, GPTBot a généré en un mois 569 millions de requêtes sur le réseau (international). Certes, certains crawlers téléchargent des fichiers JavaScript : chez ChatGPT, les fichiers JS représentent 11,50 % des requêtes, chez Claude 23,84 % (international), mais il leur manque l'environnement de rendu pour les exécuter. Une étude plus large portant sur 23 grands crawlers d'IA aboutit au même résultat : 69 % des crawlers d'IA ne peuvent pas exécuter de JavaScript (international), dont explicitement GPTBot et ClaudeBot.

Il en découle trois conséquences pour hreflang :

• Pas de rendu JS : Les signaux hreflang qui n'arrivent dans le DOM que via du JavaScript côté client sont invisibles pour les crawlers d'IA. Ceux-ci ne voient que le HTML initial.
• Pas de sélection de locale : Les plateformes d'IA n'interprètent pas hreflang comme un mécanisme de sélection. Elles traitent l'URL qu'elles viennent de récupérer, sans chercher activement la variante de-AT d'une URL de-DE.
• Indication plutôt que contrainte : Ce qui, chez Google, n'est qu'une indication faible devient pratiquement sans effet dans la récupération d'informations par l'IA. La plateforme restitue la version qu'elle a indexée, pas forcément celle qui correspond à la région.

Le revers positif compte aussi : les contenus présents dans le HTML initial, y compris les données JSON intégrées ou les composants rendus côté serveur, peuvent être indexés, car les modèles d'IA interprètent aussi des contenus non HTML. Le levier ne se trouve donc pas dans hreflang, mais dans le fait d'écrire le bon signal linguistique directement dans le HTML livré.

content-language pour Bing et Copilot

Une erreur répandue consiste à croire que hreflang agit de la même manière sur tous les moteurs de recherche. Selon ses propres déclarations, Bing ne considère hreflang que comme un signal faible (international) et détecte la langue surtout via le signal content-language, les liens et la provenance des visiteurs. Dans la zone DACH, ce n'est pas un sujet secondaire : en Autriche, Bing occupe nettement la deuxième place avec 9,01 % de part de marché, derrière Google avec 81,87 % (Autriche, mai 2026). Comme Microsoft Copilot repose sur l'index de Bing, le signal content-language agit aussi sur ce système d'IA.

• Format ll-cc correct : Le signal content-language utilise lui aussi le schéma langue-région, par exemple de-AT. Plusieurs valeurs sont séparées par des virgules.
• Cohérence à tous les niveaux : Content-Language dans l'en-tête HTTP, l'attribut lang de l'élément html et les métadonnées complémentaires doivent porter la même valeur, afin que Bing ne reçoive pas de signal linguistique contradictoire.
• N'oublie pas l'attribut lang : L'attribut lang="de-AT" sur la balise html est le signal linguistique on-page le plus simple et le plus fiable. Il figure dans le HTML initial et reste donc visible pour les crawlers sans rendu JS.

En pratique : quiconque diffuse des variantes DACH devrait gérer ensemble hreflang pour Google, ainsi que content-language et un attribut lang correct pour Bing, Copilot et les crawlers d'IA.

Hreflang : une indication, pas une directive

Même chez Google, hreflang n'est pas un ordre. Google qualifie expressément les balises hreflang d'indications, et non de directives (international). John Müller, de Google, précise que hreflang ne garantit pas l'indexation et que, pour des variantes quasi identiques, Google en choisit souvent une comme canonique.

C'est particulièrement important pour la zone DACH. Les variantes de-DE, de-AT et de-CH sont souvent presque identiques sur le plan linguistique. Quand deux variantes ont le même contenu, Google choisit généralement, pour des versions de même langue, l'une d'elles comme canonique, parce que ses systèmes simplifient les choses (international). Résultat : la page de-AT peut sortir de l'index alors même que l'annotation hreflang est techniquement correcte.

Ce qui aide, c'est une vraie différenciation. Plus la variante de-AT se distingue par son contenu, plus Google aura tendance à la traiter comme une page à part entière :

• Contenus spécifiques : Prix autrichiens en euros avec le bon taux de TVA, interlocuteurs locaux, termes juridiques autrichiens et références issues du marché autrichien.
• Termes et graphies locaux : Là où l'allemand d'Autriche diffère, le texte doit le refléter. Cela renforce à la fois la pertinence et la distinction.
• Une URL propre par variante : Une URL clairement distincte pour chaque variante est la condition pour qu'une variante puisse être indexée et référencée dans les systèmes d'IA.

Les méthodes d'implémentation comparées et leur visibilité pour l'IA

Hreflang peut être implémenté de trois façons. Pour les crawlers d'IA, l'essentiel est de savoir si le signal figure dans le HTML initial.

• Éléments link HTML dans le head : Les annotations hreflang figurent sous forme de balises link dans la section head. Si elles sont rendues côté serveur, elles sont incluses dans le HTML initial et donc visibles pour tous les crawlers. Pour la zone DACH, c'est la méthode la plus transparente.
• En-tête HTTP : Hreflang peut être transmis via l'en-tête HTTP Link, surtout pour des documents non HTML comme les PDF. L'en-tête est visible quel que soit le crawler, mais il est plus difficile à maintenir en pratique.
• Sitemap XML : Hreflang peut être entièrement déclaré dans le sitemap XML. Cela allège le code HTML, mais présente un inconvénient pour la récupération d'informations par l'IA : le signal ne figure pas dans la page elle-même. Un crawler d'IA qui récupère directement une URL sans exploiter le sitemap ne voit pas l'annotation.

Pour la recherche Google classique, les trois méthodes se valent. Tu peux les combiner, mais selon Google cela n'apporte aucun avantage dans la recherche et complique la maintenance, car chaque modification doit être répercutée sans contradiction à plusieurs endroits. Mieux vaut une seule méthode, appliquée de façon cohérente. Pour la visibilité dans l'IA, la variante dans le head rendue côté serveur est la plus fiable, car elle lie le signal linguistique directement au document livré. L'attribut lang et des signaux linguistiques on-page clairs restent toutefois déterminants, car ils fonctionnent même sans interprétation de hreflang.

Hreflang dans Next.js et les architectures headless

Dans les configurations Next.js et headless modernes, la stratégie de rendu détermine si les signaux linguistiques arrivent bel et bien jusqu'aux crawlers d'IA.

• Server-Side Rendering plutôt que Client-Side : Les signaux de locale doivent figurer dans le HTML initial, et non être générés après l'hydratation par du JavaScript côté client. Comme les crawlers d'IA n'effectuent pas de rendu JS, tout signal ajouté uniquement côté client est perdu.
• alternates.languages dans les métadonnées : Next.js permet de générer hreflang côté serveur via l'objet Metadata avec alternates.languages. Les annotations arrivent ainsi de façon fiable dans le head du HTML initial.
• Définir l'attribut lang côté serveur : Le lang="de-AT" de l'élément html doit être défini par le serveur pour chaque locale. C'est le signal linguistique le plus stable pour les crawlers sans rendu.
• Structure du head propre : Les métadonnées importantes doivent figurer en haut du head. Une étude internationale a montré que 10,1 % des pages sur desktop contiennent des éléments invalides dans le head (international). Si hreflang, canonical ou meta robots se trouvent sous un élément invalide, ils sont déplacés dans le body et deviennent inopérants.

Conséquences GEO et AEO pour les contenus de-AT

Si les plateformes d'IA n'exploitent pas hreflang comme mécanisme de sélection, la tâche passe du pilotage des locales à la simple visibilité. L'objectif : que les contenus de-AT soient reconnaissables comme contenus autrichiens dans ChatGPT, Perplexity et Copilot, sans que hreflang fasse office de filtre.

• Rendu côté serveur obligatoire : Seul ce qui figure dans le HTML initial est traité par les crawlers d'IA. Les contenus de-AT doivent être entièrement livrés côté serveur.
• Signaux linguistiques on-page explicites : Plutôt que de s'en remettre à hreflang, mieux vaut placer la référence à l'Autriche dans le texte lui-même : Autriche, implantations en Autriche, prix en euros avec le taux de TVA autrichien, termes juridiques et techniques autrichiens. La localisation devient ainsi directement lisible pour les modèles de langage.
• Des URL propres et stables : Chaque variante a besoin d'une URL unique et accessible durablement pour pouvoir être citée et recevoir des liens.
• Des contenus structurés et sourcés : Des définitions claires, des listes et des affirmations étayées par des sources augmentent la probabilité d'être cité comme source dans les réponses génératives.

Pour cela, l'approche par sous-répertoires avec example.com/at/ est généralement supérieure à l'approche par ccTLD distincts, car elle consolide l'autorité du domaine tout en fournissant une URL claire et indexable par région. La localisation est ainsi préservée, sans répartir la visibilité sur plusieurs domaines faibles.

L'interaction de hreflang avec canonical, redirections et sitemaps

Hreflang n'agit jamais seul. Les conflits avec les balises canonical, les redirections et les sitemaps comptent parmi les sources d'erreurs les plus fréquentes.

• Ne pas définir canonical et hreflang de façon contradictoire : Chaque variante doit être canonique vers elle-même. Une balise canonical qui pointe de la page de-AT vers la page de-DE annule la logique hreflang et entraîne une consolidation.
• Pas de renvois vers des redirections : Hreflang doit pointer vers l'URL finale, accessible avec un statut 200, et non vers une adresse redirigée en 301. Les renvois vers des redirections ou des pages cassées sont une erreur majeure documentée.
• Cohérence avec le sitemap XML : Les URL du sitemap, de la balise canonical et des annotations hreflang doivent être identiques, y compris le protocole, la barre oblique et la casse.

L'ampleur de ces problèmes est considérable. Une étude internationale portant sur 18 786 sites web avec du code hreflang a relevé des directives hreflang contradictoires dans 31,02 % des cas et l'absence de x-default dans 47,95 % des cas (international). Ce type de conflit conduit Google à ignorer les signaux et à décider lui-même.

Suivi, validation et mesure

Hreflang nécessite un contrôle continu, justement parce que les erreurs restent souvent invisibles. Une combinaison d'outils et d'analyse des logs couvre les problèmes les plus importants.

• Google Search Console : On n'y trouve plus de rapport d'erreurs hreflang : Google a supprimé le rapport « Ciblage international ». Le rapport « Indexation des pages » montre quelles URL ont été écartées comme doublons, et l'outil d'inspection d'URL indique pour chaque variante DACH le statut d'indexation et l'URL canonique choisie par Google. Les erreurs hreflang elles-mêmes, tu les trouves avec un crawler.
• Crawlers comme Screaming Frog : Un crawl technique repère les autoréférences manquantes, l'absence de x-default, les renvois non réciproques et les balises hreflang qui pointent vers des redirections ou des pages non canoniques.
• Analyse des logs des accès des bots d'IA : Les logs serveur montrent si et comment GPTBot, ClaudeBot et PerplexityBot récupèrent les différentes variantes. Cela permet de vérifier si le HTML initial est livré avec les bons signaux linguistiques.
• Contrôle du rendu : Une récupération du HTML brut sans exécution de JavaScript montre si l'attribut lang, hreflang dans le head et la référence locale figurent réellement dans le document initial.

Pour situer l'adoption : selon l'étude internationale Web Almanac 2022, 9,6 % des pages utilisaient des balises hreflang sur desktop, et la valeur de figurait parmi les quatre valeurs de langue les plus fréquentes (international). Hreflang est donc très répandu, mais, comme le montrent les taux d'erreur, rarement exempt de fautes.

Pour aller plus loin et conclusion

Hreflang reste utile pour la recherche Google classique dans la zone DACH, à condition d'être bien mis en œuvre : de-DE, de-AT, de-CH et x-default avec des balises complètes, réciproques et autoréférentes. L'essentiel est de comprendre que hreflang n'est déjà qu'une indication chez Google et qu'il devient pratiquement sans effet dans la récupération d'informations par l'IA, parce que les crawlers d'IA ne sélectionnent pas de variante linguistique et régionale et ne voient même pas les signaux ajoutés côté client.

La conséquence pour les entreprises présentes sur le marché autrichien est claire : les signaux linguistiques doivent figurer dans le HTML rendu côté serveur, la référence à l'Autriche dans le texte visible, et chaque variante a besoin d'une URL propre et stable. En complément, il faut gérer content-language et l'attribut lang pour Bing et Copilot. Les prochaines étapes utiles sont un contrôle du rendu du HTML initial, un audit hreflang avec un crawler et une analyse des logs des accès des bots d'IA, pour vérifier si la bonne variante parvient réellement aux systèmes d'IA.