Trois décisions règlent ça, dans cet ordre. D'abord, tu cibles une langue ou un pays. Ensuite, tu choisis ton architecture d'URL. Enfin seulement, tu poses le balisage hreflang. L'inverse ne marche pas : un hreflang impeccable posé sur une architecture bancale ne répare rien, il documente proprement le désordre.
Une précision honnête avant de commencer : hreflang ne fait pas monter tes positions, et ce n'est pas une canonique. Ça indique aux moteurs quelle version de ta page correspond à quel public — rien de plus, et c'est déjà beaucoup.
Langue ou pays : la question à trancher avant d'écrire une seule balise
C'est la question qui détermine tout le reste, et tu ne peux pas y répondre depuis ton code, seulement depuis ton offre.
Tu cibles une langue
Ton contenu français est le même pour un lecteur de Lyon, de Bruxelles, de Genève ou de Montréal : mêmes services, même discours, mêmes conditions. Tu n'as alors besoin que d'un jeu de pages françaises et d'un code langue seul : `fr`. Créer quatre versions quasi identiques pour quatre pays francophones, c'est fabriquer de la maintenance et de la concurrence interne pour rien.
Tu cibles un pays
Tes prix, ta devise, tes délais de livraison, tes mentions légales, ton catalogue : rien n'est identique d'un marché à l'autre. Là, tu as réellement besoin de versions distinctes, et donc d'un code langue-pays : `fr-FR`, `fr-BE`, `fr-CH`. Le critère n'est pas linguistique, il est commercial. Si un visiteur belge qui atterrit sur ta page française voit un prix qu'il ne peut pas payer, tu as ta réponse.
Tu n'as peut-être pas besoin de hreflang
Cas fréquent et rarement dit : si tes versions ne se ressemblent pas — contenus réellement différents, pas des traductions ni des adaptations — hreflang n'a rien à résoudre : pas d'ambiguïté à lever, rien à annoter.
Retiens le critère, il te servira à chaque arbitrage : hreflang sert quand deux URLs disent la même chose à deux publics différents. Sinon, c'est du contenu normal.
ccTLD, sous-domaine, sous-dossier : l'arbitrage réel
Trois options, trois URLs possibles pour la même page allemande :
ccTLD : `exemple.de`
Sous-domaine : `de.exemple.com`
Sous-dossier : `exemple.com/de/`
Google documente ces trois structures avec leurs avantages et leurs inconvénients, sans les classer (Gérer les sites multirégionaux et multilingues, Google Search Central, consulté le 6 août 2026).
Option | Signal de ciblage pays | Coût et maintenance | Historique et autorité | Réversibilité |
|---|---|---|---|---|
ccTLD `exemple.de` | Le plus explicite : Google parle de « ciblage géographique clair » | Le plus lourd : coût, infrastructure, exigences d'attribution parfois strictes | Repart sans historique : un domaine neuf n'hérite pas de l'ancienneté du tien | Faible : revenir en arrière, c'est migrer un domaine entier |
Sous-domaine `de.exemple.com` | Faible : Google note que l'URL seule ne le laisse pas deviner | Moyen : une entrée DNS, une stack potentiellement séparée | Débat non tranché : Google ne documente aucune différence avec le sous-dossier | Moyenne |
Sous-dossier `exemple.com/de/` | Faible : même remarque, c'est hreflang qui cible | « Peu de maintenance (même hébergeur) », écrit Google | Tout reste sur le même domaine | Élevée : une arborescence, pas une migration |
Le ccTLD
C'est le signal de ciblage pays le plus explicite, et le plus cher. Un domaine neuf repart sans historique : ton `exemple.com` vieux de dix ans ne transmet pas son ancienneté à ton `exemple.de` acheté hier. Il peut lui envoyer des liens, comme n'importe quel site externe — ce n'est pas grandir sur un socle existant. Ajoute le budget juridique, le dépôt de marque local, l'hébergement, la surveillance : tout ce que tu fais déjà une fois, multiplié. Réserve-le aux marchés où tu as une entité locale et un chiffre d'affaires qui justifie la ligne budgétaire.
Le sous-domaine
C'est le compromis : techniquement isolé — autre stack, autre CDN, une équipe locale qui gère sa boutique sans toucher au reste.
Sur la question qui revient toujours — est-ce qu'un sous-domaine profite de l'autorité du domaine principal ? — voilà ce qu'on peut dire sans se faire démentir : la documentation de Google sur les sites multirégionaux ne compare jamais les deux structures sur le classement ni sur la transmission d'autorité, elle liste des avantages et des inconvénients opérationnels. La profession observe tout et son contraire, sans que personne ait publié de démonstration qui tranche. Ne tranche pas non plus dans ton arbitrage. Ce qui est certain, c'est l'argument opérationnel — deux environnements à maintenir au lieu d'un. Choisis-le quand une contrainte technique ou organisationnelle l'impose, pas par défaut.
Le sous-dossier
C'est le choix par défaut pour la grande majorité des sites mid-market qu'on accompagne. Un seul domaine à faire grandir, une seule stack à maintenir, un seul historique de liens, et hreflang qui fait le travail de ciblage. Tu ajoutes un marché en ajoutant un dossier.
Les deux fausses bonnes idées
Le paramètre d'URL (`exemple.com/page?lang=de`) : Google le déconseille explicitement dans la même page. Tu fabriques des URLs fragiles, dupliquées et pénibles à canoniser, pour économiser une réécriture.
La redirection automatique selon l'IP : plus gênante encore, et là aussi c'est Google qui le dit. Sa documentation demande de ne pas rediriger automatiquement un internaute d'une version linguistique vers une autre, parce que ces redirections peuvent empêcher les internautes et les moteurs de voir toutes les versions du site. Elle précise aussi que Googlebot explore généralement depuis les États-Unis et que ses requêtes ne portent pas d'en-tête `Accept-Language` : un robot peut donc rester enfermé dans une seule version. Affiche plutôt un bandeau de suggestion (« Cette page existe aussi en allemand ») et laisse le choix. Suggérer, pas forcer.
Ma recommandation, et c'en est une, pas une loi : sous-dossier, sauf raison précise de faire autrement. Entité locale, contrainte réglementaire, infrastructure séparée : ce sont des raisons. « J'ai lu que c'était mieux » n'en est pas une. Si tu veux qu'on tranche ton cas avec toi, c'est ce qu'on fait quand on t'aide à structurer un site multilingue.
Écrire un cluster hreflang qui tient
La syntaxe d'abord, parce que c'est là qu'on voit le plus de clusters casser en audit.
Une valeur `hreflang` se compose d'un code langue ISO 639-1 (`fr`, `en`, `de`), éventuellement suivi d'un tiret et d'un code pays ISO 3166-1 alpha-2 (`fr-BE`, `en-US`). Deux conséquences immédiates : le code pays seul n'existe pas — il faut toujours une langue — et le Royaume-Uni s'écrit `GB`, pas `UK`. Google précise qu'employer `EU`, `UN` ou `UK` dans une annotation hreflang n'a aucun effet dans la recherche (Indiquer à Google les versions localisées de votre page, Google Search Central, consulté le 6 août 2026 — c'est la page de référence pour toute cette section).
Troisième cas, celui qu'on oublie, et il compte si tu ouvres un marché asiatique : Google documente aussi le code d'écriture ISO 15924. `zh-Hant` pour le chinois traditionnel, `zh-Hans` pour le simplifié, combinables en `zh-Hans-US`.
Ensuite, trois règles. Ce sont des règles, pas des conseils.
1. Chaque page se déclare elle-même. La page française contient une balise qui pointe vers la page française. C'est la balise auto-référente, et son absence casse le cluster. 2. La déclaration est réciproque. Si A déclare B, B doit déclarer A : Google indique que deux pages qui ne se pointent pas mutuellement voient leurs balises ignorées. Nuance utile, la même documentation ajoute que si un jeu bidirectionnel complet devient difficile à tenir, tu peux omettre certaines langues sur certaines pages, et que Google traitera quand même les paires qui se pointent l'une l'autre. Vise le jeu complet ; un échec partiel n'annule pas tout. 3. URLs absolues, protocole inclus, et strictement canoniques. Pas de chemin relatif, pas de version qui redirige, pas d'URL avec paramètre de suivi.
Avec trois versions et un `x-default`, voilà les quatre lignes à poser dans le `<head>` :
```html <!-- Ces quatre lignes sont identiques sur tes trois pages. Tu les copies telles quelles dans /fr/produit, /en/product ET /de/produkt. --> <link rel="alternate" hreflang="fr" href="https://exemple.com/fr/produit" /> <link rel="alternate" hreflang="en" href="https://exemple.com/en/product" /> <link rel="alternate" hreflang="de" href="https://exemple.com/de/produkt" /> <link rel="alternate" hreflang="x-default" href="https://exemple.com/" /> ```
Le point important est dans le commentaire : le bloc ne varie pas d'une page à l'autre. Si tu écris un bloc différent par langue, tu fabriques une non-réciprocité.
À quoi sert x-default
`x-default` désigne ta page de repli : Google la décrit comme la valeur employée quand aucune de tes langues ou régions ne correspond aux réglages du navigateur du visiteur. Précision utile de la même page : tu peux la poser sur n'importe quelle page, mais elle a été conçue pour les sélecteurs de langue et c'est avec eux qu'elle fonctionne le mieux.
Elle reste facultative : si tes versions couvrent exactement tes marchés, tu peux t'en passer sans rien casser.
Où poser les balises : head HTML, en-tête HTTP ou sitemap
Trois emplacements, et ce n'est pas un classement : Google écrit que les trois méthodes lui sont équivalentes et te laisse choisir la plus commode.
Dans le `<head>` HTML. Le plus lisible et le plus vérifiable : tu affiches le code source, tu vois le cluster. Le défaut arrive avec l'échelle — vingt marchés, c'est vingt balises sur chacune de tes pages.
Dans l'en-tête HTTP `Link`. Google la dit « utile pour les fichiers non-HTML (comme les PDF) » : un PDF publié en cinq langues n'a pas de `<head>` où poser quoi que ce soit. Utile, pas exclusive — les trois méthodes étant équivalentes, ce même PDF peut aussi porter ses annotations depuis ton sitemap.
Dans le sitemap XML. Le plus maintenable à grande échelle, surtout généré par ton CMS, et le plus facile à auditer : tout le mapping tient dans un fichier.
```xml <!-- Pense à déclarer xmlns:xhtml sur ton <urlset>. Chaque <url> reprend le jeu complet d'alternates, celui de la page comprise et x-default aussi : le même cluster que dans l'exemple <head> ci-dessus. --> <url> <loc>https://exemple.com/fr/produit</loc> <xhtml:link rel="alternate" hreflang="fr" href="https://exemple.com/fr/produit"/> <xhtml:link rel="alternate" hreflang="en" href="https://exemple.com/en/product"/> <xhtml:link rel="alternate" hreflang="de" href="https://exemple.com/de/produkt"/> <xhtml:link rel="alternate" hreflang="x-default" href="https://exemple.com/"/> </url> ```
La règle qui t'évite l'essentiel des incohérences tient en une ligne : choisis une méthode et tiens-t'y. Le scénario classique, c'est le head posé à la main il y a deux ans plus un sitemap généré par le CMS l'an dernier, deux mappings qui divergent sans que personne ne le voie.
Les cinq erreurs qui font ignorer ton cluster
1. Le hreflang pointe vers une URL cassée. Redirigée, en 404, ou en `noindex`. Symptôme : ton cluster est ignoré alors que les balises sont présentes. Correction : répare la cible, pas la balise. Et si ta page allemande a changé d'URL, c'est le bloc entier qu'il faut remettre à jour sur toutes les pages du cluster — y compris sur la page allemande elle-même, dont la balise auto-référente pointe encore vers l'ancienne adresse.
2. Le conflit avec la canonique. Ta page `/de/` déclare une canonique vers `/en/`. Tu viens d'annuler ton propre hreflang : tu dis en même temps « cette page est la version allemande » et « cette page n'en est pas une, c'est la version anglaise ». Canonical et hreflang doivent raconter la même histoire : Google demande, quand tu utilises hreflang, de désigner une canonique dans la même langue, ou dans la meilleure langue de substitution s'il n'en existe pas (Regrouper les URL en double, Google Search Central, consulté le 6 août 2026). En pratique, chaque page d'un cluster se canonicalise vers elle-même. C'est ce qu'on démêle en SEO technique, parce que le symptôme visible est souvent une désindexation, pas une erreur de balise.
3. La réciprocité manquante. C'est l'erreur qu'on retrouve le plus souvent dans les audits qu'on mène, presque toujours pour la même raison : quelqu'un a ajouté une langue sans repasser sur les clusters existants. La nouvelle page italienne déclare les quatre autres ; les quatre autres ne la déclarent pas. Correction : toute nouvelle langue est une mise à jour de toutes les pages, pas un ajout.
4. Les codes invalides. `en-UK` au lieu de `en-GB`, `fr_FR` avec un tiret bas, ou un code pays employé seul comme s'il désignait une langue. Un code invalide n'est pas interprété au mieux : il est sans effet.
5. La redirection automatique par IP. Déjà vue plus haut, mais son symptôme est trompeur : ton balisage est parfait et rien ne se passe, parce que le robot n'a jamais atteint les autres versions.
Une sixième chose : hreflang n'est pas une canonique. Mais méfie-toi de l'idée reçue inverse — « chaque URL reste forcément indexée séparément » est faux. Google précise que tes versions localisées ne sont des doublons que si le contenu principal reste non traduit, et que pour la canonicalisation il préfère les URLs appartenant à un cluster hreflang réciproque (les deux pages Google citées plus haut). Deux pages `en-US` et `en-GB` identiques au mot près peuvent donc être regroupées. Conclusion inchangée : une traduction bâclée ou une page quasi vide ne devient pas fréquentable parce qu'elle est bien annotée.
Vérifier que ça marche vraiment
Trois niveaux de contrôle.
À la main. Ouvre le code source d'une page dans chaque langue et compare les clusters : complets et identiques. Quelques minutes, zéro outil. Complète avec l'inspection d'URL de la Search Console, qui te montre la canonique retenue par Google — c'est là que tu attrapes les conflits canonical/hreflang.
Au crawl. Passé quelques dizaines de pages par langue — notre seuil de bascule en audit, pas une règle du métier — la vérification manuelle ne tient plus. Il te faut un crawler capable de remonter les hreflang manquants, non réciproques ou pointant vers des URLs non canoniques. À l'échelle de plusieurs centaines de pages, c'est le seul contrôle qu'on arrive à tenir dans la durée.
Dans la SERP. Vérifie quelle version ressort selon le pays, en gardant une réserve honnête : les résultats varient selon la langue du navigateur, la localisation et le contexte de la requête. Un test isolé n'est pas une preuve, une tendance en est une.
Dernier point : l'ancien rapport « Ciblage international » de la Search Console — l'onglet hreflang et le réglage de pays — a été supprimé. Google l'écrit dans son aide : le ciblage par pays depuis la Search Console a été jugé de peu de valeur pour l'écosystème et n'est plus pris en charge, alors que hreflang, lui, reste pris en compte (Le rapport sur le ciblage international est obsolète, aide Search Console, consultée le 6 août 2026). Ne le cherche plus.
Multilingue et moteurs IA : ce qu'on sait, ce qu'on ne sait pas
Commençons par ce qui est documenté. C'est maigre, mais ce n'est pas vide — et la réponse paresseuse, « aucun éditeur n'en parle », est fausse.
Un éditeur a publié une position, et c'est Microsoft. Dans un billet de son blog webmaster consacré au contenu dupliqué et à la visibilité en recherche IA, Bing recommande noir sur blanc d'« utiliser hreflang pour définir le ciblage linguistique et régional », et rappelle dans le même texte que beaucoup de LLM s'appuient sur des données ancrées dans l'index Bing ou dans d'autres index de recherche (Does Duplicate Content Hurt SEO and AI Search Visibility?, Bing Webmaster Blog, 19 décembre 2025). Sur au moins une des chaînes qui alimentent des réponses génératives, hreflang n'est donc pas un pari : c'est une recommandation officielle de l'éditeur.
Voilà pour ce qu'on sait. L'étage d'après reste opaque : comment une réponse générative choisit la version linguistique qu'elle cite. On n'a trouvé cette description chez aucun éditeur, et on ne l'a pas mesurée non plus — personne ne décrit ce mécanisme sans l'inventer, nous compris.
Ce qui est mesurable, en revanche, l'est très bien : quelle URL est citée, dans quelle langue, sur quel prompt. Un site systématiquement cité sur sa version anglaise en réponse à des questions posées en français a un problème observable, indépendamment de la cause. Le vocabulaire reste le même — Absent → Mentionné → Recommandé — mais il s'applique version par version, marché par marché.
Mesure avant de théoriser. Pour le cadre général de ce qui change entre référencement classique et moteurs génératifs, tout est dans GEO vs SEO.
Scanner ma visibilité IA — tu donnes ton domaine et ton secteur, on interroge jusqu'à quatre surfaces — ChatGPT, ChatGPT avec recherche web, Gemini, Perplexity — sur une banque de prompts sectoriels. Verdict surface par surface : Absent, Mentionné ou Recommandé, et la mention explicite d'un moteur qui n'a pas répondu. Le verdict est gratuit et sans compte, en moins de deux minutes.
Ta feuille de route en six étapes
1. Liste tes marchés et tranche langue ou pays pour chacun. Un tableau à deux colonnes suffit. Tant que cette ligne n'est pas décidée, ne code rien. 2. Fige ton architecture d'URL avant de traduire quoi que ce soit. Changer d'avis après cent pages traduites coûte une migration. 3. Cartographie tes paires d'URLs équivalentes. Une ligne par contenu, une colonne par langue. Ce tableau, c'est déjà ton cluster. 4. Génère le balisage depuis ce tableau, avec une seule méthode. Head, en-tête HTTP ou sitemap. Une seule. 5. Crawle et corrige les non-réciprocités. Chaque paire manquante est une version que tu as décidé de ne pas servir. 6. Surveille par pays, et refais le passage à chaque nouvelle langue. Un marché ajouté, c'est tous les clusters à mettre à jour.
Prends la première étape aujourd'hui : ouvre un tableau, liste tes marchés, écris en face de chacun « langue » ou « pays ». Tu verras vite si ton architecture tient. Si tu veux qu'on regarde la tienne avec toi, fais auditer ta structure internationale.
Questions fréquentes
hreflang, c'est quoi exactement — et est-ce obligatoire ?
C'est une annotation qui dit aux moteurs : cette page existe aussi en allemand ici, en espagnol là. Elle ne rend rien obligatoire. Elle n'est utile que si deux URLs disent la même chose à deux publics différents — contenu traduit, ou adapté à un autre pays. Si tes versions sont réellement différentes, tu n'en as pas besoin.
ccTLD, sous-domaine ou sous-dossier : lequel choisir ?
Le sous-dossier (`exemple.com/de/`) convient à la grande majorité des sites mid-market qu'on accompagne : un seul domaine à faire grandir, une seule stack à maintenir, et hreflang fait le ciblage. Le ccTLD (`exemple.de`) envoie le signal pays le plus explicite, mais un domaine neuf repart sans historique et coûte du budget juridique et technique — garde-le pour les marchés où tu as une entité locale. Le sous-domaine se réserve aux cas où une équipe ou une infrastructure locale impose l'isolement technique ; sur l'autorité, la doc de Google ne compare pas les deux structures et personne n'a tranché.
Est-ce que hreflang fait monter mes positions ?
Non. hreflang décide quelle version de ta page est servie à quel public, pas à quel rang elle sort. Ce que tu gagnes en le corrigeant, c'est de ne plus servir ta page anglaise à un lecteur français, et de ne plus voir deux de tes versions se concurrencer sur la même requête. C'est un gain de pertinence, pas un levier de classement.
Faut-il obligatoirement une balise x-default ?
Elle est facultative. Elle devient utile dès que tu as une page de repli : un sélecteur de langue, ou une version générique servie aux visiteurs dont aucune de tes langues ne correspond. Si tes versions couvrent exactement tes marchés, tu peux t'en passer.
Est-ce que les moteurs IA lisent hreflang ?
Un éditeur le recommande explicitement : Microsoft écrit sur le blog webmaster de Bing, en décembre 2025 et dans un billet consacré à la visibilité en recherche IA, qu'il faut utiliser hreflang pour définir le ciblage linguistique et régional. Ce qui n'est documenté nulle part, c'est l'étage suivant — comment une réponse générative choisit la version linguistique qu'elle cite. Là, personne ne peut te répondre. Ce qui reste mesurable, c'est le résultat : quelle URL est citée, dans quelle langue, sur une question donnée. Si tes pages anglaises ressortent systématiquement sur des questions posées en français, tu as un problème observable — mesure-le moteur par moteur avant de chercher la cause.
