Balises hreflang sur une landing page multilingue : à quoi ça sert, comment les poser

Publié le 23 août 2026 · 8 min de lecture

Une landing page qui fonctionne en français finit souvent par exister aussi en anglais, parfois en espagnol. Trois URLs, la même structure, la même offre — seule la langue change. Pour un moteur de recherche, ce sont des documents très proches dont il faut décider lequel indexer et, surtout, lequel afficher à quel internaute. Les balises hreflang servent à cela : déclarer que ces URLs sont des versions équivalentes d’un même contenu, destinées à des langues ou à des pays différents. Bien posées, elles évitent qu’un prospect belge tombe sur la version américaine avec des prix en dollars. Mal posées, elles sont ignorées.

Ce que hreflang dit à Google — et ce qu’il ne dit pas

Une annotation prend la forme <link rel="alternate" hreflang="en" href="https://exemple.com/en/offre"> : elle déclare une correspondance entre deux URLs et précise l’audience linguistique de la page pointée. Google s’en sert pour choisir quelle version afficher dans ses résultats, selon la langue et la localisation présumées de l’internaute. C’est un signal d’aiguillage, pas un levier de visibilité : il ne fait pas monter une page, il détermine seulement laquelle des versions déjà positionnées sera servie.

Ce n’est pas une redirection. Le visiteur qui arrive directement sur l’URL espagnole y reste. Rediriger selon l’adresse IP est une mécanique distincte, souvent contre-productive puisqu’elle peut empêcher le robot d’explorer les autres versions.
Ce n’est pas un signal de classement. Les fondamentaux du référencement d’une landing page restent à traiter, version par version.
Ce n’est pas un substitut à la balise canonical. La canonical dit « quelle URL indexer », hreflang dit « quelle version servir à qui ». Les deux cohabitent.
Ce n’est pas une garantie d’indexation. Le délai d’indexation s’applique à chaque version indépendamment.
Ce n’est pas une réponse au contenu dupliqué dans une même langue. Des pages déclinées ville par ville en français relèvent du SEO local multi-villes : la langue y est identique, l’intention de recherche différente.

La règle de réciprocité, celle qui fait tout échouer

C’est la règle la plus stricte, et la plus souvent négligée : les annotations doivent être réciproques. Si la page française déclare la version anglaise, la page anglaise doit déclarer en retour la version française. Chaque version doit aussi se déclarer elle-même : toutes listent exactement le même jeu d’URLs, y compris la leur. Une annotation non confirmée par la page cible est jugée peu fiable et ignorée, parfois pour tout le groupe. En pratique, cela condamne l’écriture manuelle page par page : la seule approche tenable consiste à décrire les correspondances dans une source unique et à générer les annotations à partir de là.

Codes de langue, codes de région et x-default

La valeur commence toujours par un code de langue sur deux lettres (ISO 639-1), éventuellement suivi d’un code de région sur deux lettres (ISO 3166-1 alpha-2). fr vise tous les francophones, fr-CA uniquement ceux situés au Canada. L’erreur classique consiste à écrire un code pays seul en pensant cibler un marché : hreflang="ca" ne désigne pas le Canada mais le catalan, hreflang="uk" désigne l’ukrainien — le code du Royaume-Uni est GB. Une valeur composée uniquement d’une région n’est jamais valide.

Ce que déclare réellement chaque valeur hreflang
Valeur	Audience ciblée	Piège à connaître
`fr`	Tous les francophones	Suffit tant qu’il n’existe qu’une version française
`fr-CA`	Francophones au Canada	N’a de sens que si une version `fr` existe aussi
`en-GB`	Anglophones au Royaume-Uni	Le code du pays est `GB`, pas `UK`
`ca`	Catalanophones	Confondu à tort avec le Canada, qui s’écrit `fr-CA`
`x-default`	Les cas non couverts	Doit viser une page générique, pas la version française

La valeur x-default désigne la page à servir quand aucune version ne correspond : un sélecteur de langue, ou la version internationale de référence. Elle n’est pas obligatoire, mais devient utile dès que le nombre de marchés atteints dépasse le nombre de versions publiées. Sans elle, un visiteur italien face à un site en français et en anglais est aiguillé selon la seule appréciation de Google.

Trois emplacements possibles, un seul raisonnable en statique

Les annotations peuvent être déclarées à trois endroits, et un seul suffit : les cumuler n’apporte rien et multiplie les risques d’incohérence.

Des balises <link> dans le <head>. L’option la plus lisible : les annotations sont visibles dans le code source de chaque page, faciles à vérifier. Le seul coût est le poids du HTML, marginal tant que le nombre de versions reste raisonnable. C’est le choix par défaut sur un site statique.
Des en-têtes HTTP Link. Le seul moyen d’annoter un document non HTML, un PDF par exemple. Sur une landing page classique, cette voie n’apporte rien de plus et impose de configurer le serveur.
Un sitemap XML. Il centralise les correspondances et allège le HTML, ce qui devient intéressant à partir de plusieurs dizaines de versions. En contrepartie, le signal n’est plus visible dans la page et dépend de l’exploration du sitemap.

Dans un projet Next.js, ces alternatives se déclarent au niveau des métadonnées de chaque route : l’objet metadata expose un champ alternates.languages qui associe un code de langue à l’URL correspondante, et le framework génère les balises dans le <head>. Comme pour la canonical, mieux vaut construire ces URLs absolues à partir de la variable d’environnement du site plutôt que de les écrire en dur.

hreflang et canonical : deux signaux qui doivent rester cohérents

La règle tient en une phrase : chaque version porte une canonical auto-référente, pointant vers sa propre URL, jamais vers celle d’une autre langue. Une canonical inter-langues dit à Google « n’indexe pas cette page, indexe celle-là à la place » : la version concernée sort de l’index et l’ensemble hreflang s’effondre. Corollaire : les URLs listées doivent être les URLs canoniques, pas des variantes avec paramètres de tracking ni des adresses qui redirigent. Un point à vérifier après une refonte qui modifie les URLs.

Le cas des landing pages publicitaires déclinées par pays

Cas très fréquent en acquisition payante : une même page, dans une même langue, dupliquée par pays parce que la devise, la TVA ou les mentions légales diffèrent. Une page fr-FR, une fr-BE, une fr-CH dont l’essentiel du texte est identique. C’est le scénario pour lequel les codes de région ont été prévus : hreflang garde les trois pages indexables et sert la bonne selon la localisation, là où la canonical seule obligerait à en sacrifier deux. Deux réflexes l’accompagnent : vérifier que la différence justifie des URLs séparées — l’affichage du prix dans la devise locale se gère parfois sur une seule page — et veiller à ce que le maillage interne reste cohérent d’une version à l’autre.

Reste que l’aiguillage technique ne dit rien de la qualité de la version servie. Dans une étude publiée en 2003 dans Electronic Commerce Research and Applications, Mathew Hillier s’appuie sur les travaux en anthropologie et en conception de systèmes pour montrer qu’il existe une relation entre langue, contexte culturel et utilisabilité d’un site marchand multilingue : la façon dont un visiteur perçoit et aborde une interface dépend de son contexte culturel, pas seulement des mots traduits (Hillier, 2003). Servir la bonne version à la bonne personne n’a donc de valeur que si cette version a été réellement adaptée — arguments, preuves, format des prix — et pas seulement traduite.

Les erreurs qui annulent tout le dispositif

Des annotations non réciproques. La cause numéro un : une version oubliée dans le jeu d’URLs, ou une page ajoutée sans mise à jour des autres.
Une URL déclarée qui ne répond pas en 200. Une adresse en 404, en redirection ou en noindex rend le groupe incohérent — le signal est abandonné.
Des URLs relatives. Les annotations attendent des URLs absolues, protocole et nom de domaine compris.
Un mélange langue / pays approximatif. Un code pays employé seul, un uk à la place de en-GB, ou une région déclarée sans version générique pour la langue.
Une version traduite automatiquement sans relecture. Le sujet de la traduction d’une landing page pour l’international se traite avant la couche technique, pas après.
Un jeu figé dans le temps. Ajouter une langue ou changer un chemin d’URL oblige à reprendre toutes les versions du groupe.

Les balises hreflang sont une couche de plomberie : peu visible, sans effet sur les positions, mais qui évite qu’un prospect atterrisse sur la mauvaise version d’une page trouvée en cherchant dans sa langue. Les 10 templates LanderKit (89 € l’unité, 229 € le pack complet) sont des projets Next.js standards : les alternates de langue se règlent dans les métadonnées de chaque route, au même endroit que la canonical.

FAQ

Questions fréquentes

Faut-il des balises hreflang si mon site n’existe qu’en une seule langue ?

Non, elles n’ont aucune utilité dans ce cas. Les annotations hreflang ne servent qu’à décrire une correspondance entre plusieurs versions d’un même contenu. Sur un site monolingue, une balise canonical auto-référente sur chaque page suffit.

Faut-il déclarer hreflang si les versions sont sur des domaines différents ?

Oui, et c’est même un cas prévu : les annotations fonctionnent entre sous-domaines, sous-répertoires ou domaines nationaux distincts. La contrainte reste la même — la réciprocité doit être respectée d’un domaine à l’autre, chaque version déclarant l’ensemble complet des URLs, la sienne comprise.

Que se passe-t-il si j’oublie x-default ?

Rien de bloquant : les annotations restent valides et Google continue d’aiguiller les visiteurs des langues déclarées. En revanche, pour un internaute dont la langue ne figure dans aucune version, le moteur choisit seul la page à afficher. Déclarer x-default permet de reprendre la main sur ce cas.

Comment vérifier que mes annotations sont bien prises en compte ?

Le rapport dédié aux versions internationales dans la Search Console signale les annotations sans retour réciproque et les codes de langue invalides ; c’est le point de départ le plus fiable. En complément, inspecter le code source de chaque version permet de confirmer que le jeu d’URLs déclaré est identique d’une page à l’autre. La documentation officielle en vigueur reste la référence sur les valeurs acceptées.

À lire ensuite