Référencement d’un site multilingue : la méthode, des URL aux balises hreflang

Pour qu’un site multilingue se positionne dans chaque langue, chaque version doit avoir sa propre adresse, être reliée à ses traductions par des balises hreflang réciproques, figurer dans un plan de site et reprendre les mots que l’on cherche sur son marché. Ce guide reprend ces étapes dans l’ordre où vous les mettrez en place.

Les règles techniques citées viennent de la documentation officielle de Google (Search Central et aide de Search Console), du blog officiel de Bing et du W3C, consultés le 7 octobre 2026. Quand un conseil relève de notre pratique, nous le signalons.

Multilingue ou multirégional : ce que vous ciblez

Google distingue deux cas. Un site multilingue propose son contenu en plusieurs langues, par exemple une version française et une version néerlandaise. Un site multirégional vise explicitement plusieurs pays, par exemple avec des prix différents pour la Belgique et pour la Suisse.

Un site belge en français et en néerlandais qui vend aussi en France est les deux à la fois. Notez dès le départ les langues et les pays que vous visez : ce choix décide de la structure des adresses et des codes hreflang.

Étape 1 : donner une adresse à chaque langue

Google recommande une URL différente pour chaque version linguistique d’une page, plutôt qu’un contenu qui change selon les cookies ou les réglages du navigateur. La raison est pratique : son robot explore le plus souvent depuis les États-Unis et n’envoie pas d’en-tête Accept-Language. Une page qui adapte sa langue au visiteur risque donc de n’être explorée que dans une seule version.

Quatre structures existent. Voici leurs points forts et leurs limites selon Google :

Structure Exemple Points forts Limites
Domaine national example.be ciblage géographique clair, emplacement du serveur sans importance, sites bien séparés coût, plus d’infrastructure, conditions d’attribution parfois strictes, un seul pays visé
Sous-domaine nl.example.com simple à mettre en place, serveurs séparés possibles, sites bien séparés « nl » peut se lire comme une langue ou comme un pays
Sous-répertoire example.com/nl/ simple à mettre en place, peu d’entretien avec un seul hébergement ciblage peu lisible dans l’adresse, un seul emplacement de serveur, sites moins séparés
Paramètre d’URL example.com?loc=nl déconseillé par Google segmentation par adresse difficile, ciblage peu lisible dans l’adresse

Pour une entreprise qui ajoute une ou deux langues à un site existant, nous conseillons en général le sous-répertoire : un seul domaine et un seul hébergement à entretenir, ce que Google range parmi ses points forts. C’est notre pratique : Google présente ces structures comme des options, sans en imposer une.

Deux précisions utiles. Google traite le .eu comme un domaine générique, au même titre que le .com : pour viser un pays avec ces domaines, passez par hreflang. Les mots de l’adresse peuvent être traduits, par exemple /nl/diensten/ plutôt que /nl/services/, à condition d’encoder les URL en UTF-8.

Étape 2 : relier les versions avec des balises hreflang

L’attribut hreflang signale à Google qu’une page existe dans d’autres langues, pour qu’il montre la bonne version au bon lecteur. Google accepte trois méthodes équivalentes : des balises link dans la section head du code HTML, un en-tête HTTP (pratique pour les PDF) ou le plan de site XML. Une seule suffit : selon Google, les combiner n’apporte rien dans la recherche et peut compliquer l’entretien.

Pour un site en français, en néerlandais et en anglais, chacune des trois versions, ainsi que la page de choix de langue indiquée en x-default, porte exactement le même bloc dans sa balise head :

<link rel="alternate" hreflang="fr" href="https://www.example.com/fr/services/" />
<link rel="alternate" hreflang="nl" href="https://www.example.com/nl/diensten/" />
<link rel="alternate" hreflang="en" href="https://www.example.com/en/services/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />

Les règles à respecter, toutes tirées de la documentation de Google sur les versions localisées :

  1. Chaque version se cite elle-même et cite toutes les autres.
  2. Les liens vont dans les deux sens. Si la page française cite la page néerlandaise sans que celle-ci cite la française, Google ignore ces annotations.
  3. Les URL sont complètes, avec https:// et le domaine. Un chemin comme /nl/diensten/ ne suffit pas.
  4. Le code commence par la langue (norme ISO 639-1), suivie si besoin du pays (norme ISO 3166-1 alpha-2). Pour viser la Belgique : fr-BE, nl-BE ou de-BE. Le code « be » seul désigne le biélorusse, et un code de pays seul n’est pas valide.
  5. Les codes réservés comme EU, UN ou UK n’ont aucun effet. Pour le Royaume-Uni, le code de pays est GB, par exemple en-GB.
  6. La valeur x-default désigne la page à montrer quand aucune version ne correspond à la langue du lecteur. Google l’a pensée pour les pages de choix de langue.
Schéma : trois versions d'une même page, en français, en néerlandais et en anglais, reliées deux à deux par des flèches dans les deux sens. Les trois versions et la page de choix de langue marquée x-default sont aussi reliées dans les deux sens. Un encadré montre le bloc de quatre annotations hreflang, identique sur chaque page, x-default compris.
Schéma : chaque page cite les autres et elle-même, page de choix de langue en x-default comprise.

Étape 3 : déclarer les traductions dans le plan de site

Le plan de site XML permet de déclarer les mêmes relations sans toucher au code des pages. Chaque URL y a sa propre entrée, et chaque entrée liste toutes les versions de la page, y compris elle-même. Pour deux versions, le fichier ressemble à ceci :

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://www.example.com/fr/services/</loc>
    <xhtml:link rel="alternate" hreflang="fr" href="https://www.example.com/fr/services/"/>
    <xhtml:link rel="alternate" hreflang="nl" href="https://www.example.com/nl/diensten/"/>
  </url>
  <url>
    <loc>https://www.example.com/nl/diensten/</loc>
    <xhtml:link rel="alternate" hreflang="fr" href="https://www.example.com/fr/services/"/>
    <xhtml:link rel="alternate" hreflang="nl" href="https://www.example.com/nl/diensten/"/>
  </url>
</urlset>

Les limites habituelles s’appliquent : 50 000 URL ou 50 Mo non compressés par fichier, et les lignes xhtml:link ne comptent pas dans la limite d’URL. Sur un site de plusieurs centaines de pages, nous préférons souvent cette méthode, parce que toutes les annotations sont produites au même endroit.

Google indique aussi que soumettre plusieurs plans de site permet de suivre chacun dans Search Console. Un plan de site par langue vous permet ainsi de filtrer le rapport sur l’indexation des pages langue par langue. Notre guide complet des sitemaps détaille la création et la soumission.

Étape 4 : régler la canonique, la langue et les redirections

Trois autres réglages comptent autant que les balises hreflang.

La canonique reste dans la même langue

Quand vous utilisez hreflang, Google demande que la page canonique soit dans la même langue que la page. Dans le cas courant, chaque version se déclare elle-même canonique. Une balise canonique qui renvoie la version néerlandaise vers l’original français va à l’encontre de cette règle. Notre guide sur la canonicalisation explique le fonctionnement de cette balise.

Une seule langue par page

Google détermine la langue d’une page à partir de son contenu visible. Il n’utilise pour cela ni l’attribut lang, ni hreflang, ni l’URL. Écrivez donc le texte et la navigation de chaque page dans une seule langue, sans traduction côte à côte.

Traduire seulement le menu et le pied de page ne suffit pas : pour Google, des versions localisées ne sont des doublons que si leur contenu principal n’est pas traduit.

Bing a documenté d’autres signaux. Son blog officiel indiquait en mars 2011 que Bing lisait la balise meta content-language, puis l’attribut lang de la balise html, pour situer la langue et le pays d’une page. En décembre 2025, ce même blog a recommandé hreflang pour le ciblage par langue et par région.

Renseignez l’attribut lang de toute façon : c’est la technique de base du critère 3.1.1 des règles d’accessibilité WCAG (langue de la page), et il aide par exemple les lecteurs d’écran à choisir la bonne prononciation.

Aucune redirection automatique

Google déconseille de rediriger un visiteur vers la version que l’on suppose être la sienne, d’après la langue de son navigateur ou son adresse IP. Ces redirections peuvent empêcher les visiteurs et les moteurs de voir toutes les versions. Placez plutôt sur chaque page un lien vers ses autres versions linguistiques, comme le suggère Google.

Appliquez enfin les mêmes règles robots.txt et les mêmes balises meta robots dans toutes les langues.

Étape 5 : traduire avec les mots de chaque marché

Une traduction fidèle ne donne pas toujours la requête que tapent vos clients. Avant de traduire une page importante, cherchez dans chaque langue le terme qui revient dans les suggestions du moteur et dans les pages déjà classées. Placez-le ensuite dans le titre, la meta description, le premier paragraphe et l’adresse. Cette vérification rejoint ce que nous décrivons sur l’intention de recherche.

Adaptez aussi ce qui change d’un pays à l’autre : devise, unités, format des dates, adresse et téléphone de contact, mentions légales. Google cite la langue locale, la devise, les adresses et les numéros de téléphone locaux parmi les signaux qui l’aident à comprendre à qui s’adresse une page.

Reste la traduction automatique. La politique de Google contre le spam vise ce qu’il appelle l’utilisation abusive de contenu à grande échelle : de nombreuses pages créées surtout pour manipuler le classement, avec peu ou pas de valeur pour les lecteurs, quelle que soit la façon dont elles ont été produites. Parmi ses exemples figure la récupération de contenus pour générer de nombreuses pages, y compris par des transformations automatiques comme la traduction, quand elles apportent peu de valeur aux utilisateurs. Un autre exemple vise l’usage d’outils d’IA générative pour produire de nombreuses pages sans valeur ajoutée pour les utilisateurs.

Si vos traductions passent par l’IA, le guide de Google sur le contenu généré par IA s’applique aussi. Il demande de vérifier et de relire ce contenu avant publication, y compris les balises title, les meta descriptions et les textes alternatifs des images. Prévoyez donc un contrôle de qualité dans chaque langue, et une relecture par une personne qui maîtrise la langue pour les pages qui comptent le plus dans votre activité.

Étape 6 : construire un maillage interne dans chaque langue

Google se sert des liens pour découvrir de nouvelles pages à explorer. Dans chaque langue, traduisez le menu, le fil d’Ariane et les blocs d’articles liés, et faites pointer chaque lien vers la page de la même langue.

Le sélecteur de langue mène à la même page dans l’autre langue. Utilisez pour cela de vrais liens HTML, avec une balise a et un attribut href, que les moteurs savent suivre. Les principes généraux sont dans notre guide du maillage interne.

Étape 7 : suivre chaque langue séparément

Dans Search Console, le rapport sur les performances se lit par onglet : Requêtes, Pages, Pays. Ajoutez un filtre « URL contenant » /nl/ pour isoler la version néerlandaise, puis comparez les clics, les impressions et la position langue par langue.

Commencez par vérifier que les pages traduites sont indexées et reçoivent des impressions, avant de juger leur trafic. Une langue sans aucune impression pointe souvent vers un problème de structure ou de hreflang plutôt que vers la qualité de la traduction. Ce dernier point vient de notre pratique.

Les erreurs les plus fréquentes

Google cite lui-même les liens de retour manquants et les codes de langue ou de pays incorrects comme les erreurs hreflang les plus courantes. Les autres pièges de cette liste contredisent une règle vue plus haut :

  • des URL relatives dans les annotations hreflang ;
  • une canonique qui renvoie toutes les langues vers l’original ;
  • une redirection automatique selon l’adresse IP ou la langue du navigateur ;
  • des pages traduites à moitié, où seuls le menu et le pied de page changent ;
  • des règles robots différentes d’une langue à l’autre ;
  • un sélecteur de langue qui renvoie vers la page d’accueil de chaque version.

Ce que donne la méthode sur notre site principal

Nous appliquons ces étapes sur notre site principal, marcwiner.com, un site de cuisine écrit en français et traduit en 23 langues avec nos propres systèmes, développés en interne. Il appartient à Marc Winer, gérant de MACCUS.

Ses traductions apportent plus de 460 000 sessions par mois en 23 langues (septembre 2026). Dans ces langues, le trafic a été multiplié par plus de huit en un an, et elles pèsent près de 40 % du trafic du site.

Ces chiffres sont ceux de notre site. Le résultat d’un autre site dépend de son marché, de ses contenus et de son point de départ.

Faire le travail vous-même ou le confier

Sur un site de quelques langues et de quelques dizaines de pages, vous pouvez mener ces sept étapes vous-même, avec votre CMS et Search Console pour le suivi.

Si vous préférez confier la structure, les traductions et le suivi par langue à une équipe qui les applique sur son propre site, découvrez notre offre de SEO multilingue.

Laisser un commentaire