SEO multilingue : hreflang, sous-dossier ou sous-domaine, ce qui compte vraiment

Vous avez traduit votre site en anglais, posé un joli petit drapeau en haut à droite, et vous attendez les visiteurs étrangers. Trois mois plus tard, la version anglaise ne reçoit presque personne. Google montre la page française à un internaute de Londres, ou ne montre rien du tout.

Le problème vient rarement de la traduction elle-même. Il vient de tout ce qui l’entoure : la structure des adresses, les balises hreflang, les redirections automatiques. Voici ce qui compte vraiment pour qu’un site multilingue se positionne dans chaque langue, et ce que vous pouvez oublier sans regret.

Le SEO multilingue, c’est quoi exactement ?

Le SEO multilingue consiste à faire comprendre aux moteurs de recherche que votre site existe en plusieurs langues, et quelle version servir à qui. Un internaute espagnol qui tape sa requête en espagnol doit tomber sur votre page espagnole. Pas sur l’originale en français.

Sachez qu’il y a deux problèmes différents sous le même mot. Le ciblage linguistique vise une langue : l’anglais, partout dans le monde. Le ciblage géographique vise un pays : les anglophones du Royaume-Uni, avec leurs prix en livres et leurs délais de livraison. Un blog n’a besoin que du premier. Une boutique qui livre au Canada et en Belgique a souvent besoin des deux.

Premier piège : Google ne lit pas la langue dans votre code. Sa documentation est claire, il ne se sert ni de l’attribut lang de la page, ni de l’adresse, pour savoir dans quelle langue elle est écrite. Il lit le contenu visible. Une page dont le menu est en français et le texte en anglais lui envoie donc un signal brouillé. Une page, une langue : c’est la règle de base.

Sous-dossier, sous-domaine ou domaine par pays : mon avis

Avant de traduire la moindre ligne, vous devez décider où vivront les versions traduites. C’est le choix le plus pénible à défaire ensuite, parce qu’il change toutes les URL du site. Quatre options existent :

Soyons clairs, pour neuf sites sur dix, je prends le sous-dossier. Un seul domaine, un seul hébergement, une seule Search Console, et les liens que vous gagnez sur la version française profitent au domaine entier, langues comprises. C’est la structure que je conseille à un blog, à une petite boutique ou à une entreprise qui ouvre sa première langue.

Le domaine par pays se justifie quand vous visez un marché précis et que vous avez les moyens d’y investir : une marque en .de inspire plus confiance à un acheteur allemand. Au passage, certaines extensions de nom de domaine nationales exigent une présence locale pour être achetées.

Le sous-domaine, lui, sert surtout quand chaque langue doit tourner sur un hébergement web distinct. Sinon, il complique le suivi sans rien apporter. Quant au paramètre ?lang=en, Google le déconseille noir sur blanc. Oubliez.

Hreflang : la balise qui dit à Google quelle version montrer

La balise hreflang est un petit bout de code qui relie entre elles les versions d’une même page. Elle dit en substance à Google : « cette page existe aussi en anglais à telle adresse, et en espagnol à telle autre ». Elle ne fait pas grimper une page dans les résultats. Elle aide Google à afficher la bonne version au bon internaute.

Concrètement, pour une page disponible en français, en anglais et en espagnol, chacune des trois versions porte ce bloc dans son en-tête :

<link rel="alternate" hreflang="fr" href="https://monsite.fr/tarifs/" />
<link rel="alternate" hreflang="en" href="https://monsite.fr/en/pricing/" />
<link rel="alternate" hreflang="es" href="https://monsite.fr/es/precios/" />
<link rel="alternate" hreflang="x-default" href="https://monsite.fr/tarifs/" />

La dernière ligne, x-default, désigne la version de repli : celle qu’on sert à un internaute dont la langue ne correspond à aucune des autres. En général la version d’origine, ou une page qui propose de choisir sa langue.

Google accepte trois façons de déclarer ces liens, qu’il juge équivalentes : dans l’en-tête HTML de la page, dans l’en-tête HTTP (pratique pour les PDF), ou dans le sitemap XML. Choisissez-en une seule. Mélanger les trois, c’est s’assurer des contradictions le jour où une adresse change.

Les quatre erreurs que je vois tout le temps

• Le lien à sens unique. La page française pointe vers l’anglaise, mais l’anglaise ne pointe pas vers la française. Google ignore alors les deux annotations : le lien doit être réciproque.
• L’oubli de soi-même. Chaque version doit se citer elle-même dans la liste, en plus des autres.
• Le code pays inventé. en-UK ne vaut rien, le code du Royaume-Uni est en-GB. Et un pays seul (hreflang= »be ») n’est pas valide : la langue vient toujours en premier, au format ISO 639-1, le pays ensuite.
• La canonique qui tue les traductions. Si la page anglaise déclare la page française comme canonique, vous dites à Google qu’elle n’est qu’un doublon à ignorer. Chaque version garde sa propre balise canonique, qui pointe sur elle-même.

Et le pire, c’est que ces erreurs restent silencieuses. Google a retiré en septembre 2022 le rapport « Ciblage international » de la Search Console, celui qui les signalait. Depuis, plus personne ne vous prévient. Un crawler (robot d’exploration) SEO ou un contrôle à la main de temps en temps reste la seule façon de les repérer.

Un site traduit, c’est du contenu dupliqué ?

Non. C’est la question qu’on me pose le plus, et la réponse tient en une ligne : une page traduite n’est pas un doublon de l’original, puisque le texte est différent. Google ne vous pénalisera pas pour avoir la même page en français et en allemand.

Le vrai doublon apparaît quand vous déclinez une même langue par pays. Une version pour la France, une pour la Belgique, une pour la Suisse, avec exactement le même texte : là, Google voit trois pages identiques. La parade, c’est le hreflang avec région (fr-FR, fr-BE, fr-CH) et une vraie différence entre les pages, comme les prix, la livraison ou les mentions légales.

Si rien ne change d’un pays à l’autre, une seule version française suffit. Petit conseil : ne créez pas de variantes régionales pour faire joli, vous multipliez le travail sans gagner un visiteur.

Traduction automatique : ce que Google tolère, et ce qu’il sanctionne

Google n’interdit pas la traduction automatique. Il interdit d’en faire une usine. Ses règles contre le spam visent l’abus de contenu à grande échelle (scaled content abuse), et citent parmi les exemples les pages générées en masse par des « transformations automatisées » comme la traduction, quand elles n’apportent presque rien au lecteur.

Traduire mille pages d’un clic et les publier sans un regard, c’est exactement le profil que visent les mises à jour anti-spam. Et la remontée prend des mois. À l’inverse, une traduction automatique de bonne qualité, relue sur les pages qui comptent, avec un vocabulaire cohérent d’une page à l’autre, ne pose aucun problème. La différence se joue sur la relecture, pas sur l’outil.

Pour traduire un site internet sans y passer vos week-ends, j’aime bien l’approche de Tinidy : pas d’extension à installer, pas de code à toucher. Le service se branche sur votre domaine, traduit les pages à la volée et les sert sous vos propres adresses, en sous-dossier, en sous-domaine ou sur un domaine dédié. Il est conçu pour WordPress, WooCommerce, Shopify et PrestaShop, et vos données restent hébergées en Europe.

Ce qui m’intéresse surtout côté référencement, c’est qu’il génère tout seul les balises hreflang et traduit les métadonnées, deux points où les bricolages maison finissent mal. Il ne vous laisse pas non plus seul face à la machine : un éditeur côte à côte sert à relire et corriger chaque phrase, un terme corrigé une fois l’est sur tout le site, et vous pouvez protéger les mots à ne jamais traduire, comme votre nom de marque. L’offre gratuite (2 000 mots, une langue) suffit pour tester sur quelques pages avant de vous engager. Les formules payantes sont affichées à partir de 15 € HT par mois.

Ce que la traduction ne fait pas à votre place

Un texte traduit ne fait pas une page traduite. Voici ce qui passe le plus souvent à la trappe :

• Le title et la meta description, que Google affiche dans ses résultats. Une page anglaise présentée avec un extrait en français ne sera jamais cliquée.
• L’adresse de la page : /en/pricing/ parle plus à un anglophone que /en/tarifs/.
• Les textes alternatifs des images, et le texte incrusté dans les images elles-mêmes.
• Les prix, les unités et les formats de date : le 10/12 n’est pas le même jour à Paris et à New York.
• Les recherches réelles : un Anglais ne tape pas forcément la traduction littérale de votre mot-clé français.

Ce dernier point est le plus négligé, et c’est celui qui coûte le plus de trafic. Vous pouvez avoir une traduction parfaite d’une page qui vise un mot que personne ne cherche dans l’autre langue. Vérifier la requête réellement tapée dans chaque pays fait partie du b.a.-ba du référencement, et ça vaut dans toutes les langues.

Redirection automatique et sélecteur de langue : laissez le choix

Rediriger d’office un visiteur vers « sa » langue, c’est tentant. C’est aussi une mauvaise idée, et Google la déconseille explicitement pour une raison très concrète : son robot explore le web depuis les États-Unis la plupart du temps, sans indiquer de langue préférée. Si votre site renvoie tout visiteur américain vers l’anglais, Googlebot ne verra jamais vos pages françaises.

Et la localisation par adresse IP se trompe souvent. Un Français en vacances à Barcelone, un expatrié ou un utilisateur de VPN se retrouvent avec une langue qu’ils n’ont pas demandée. Proposer la bonne langue dans un bandeau discret, oui. La forcer, non.

La bonne pratique tient en une phrase : un sélecteur de langue visible en haut de page, avec le nom de chaque langue écrit dans cette langue (« English », « Español »), sous forme de liens HTML classiques que Google peut suivre. Les drapeaux, je les évite. Un drapeau désigne un pays, pas une langue : britannique ou américain pour l’anglais ? Bref, un détail d’expérience utilisateur qui en dit long sur le soin apporté au site.

Et Bing dans tout ça ?

On l’oublie souvent, mais Bing, et les moteurs qui s’appuient en partie sur son index comme DuckDuckGo, Qwant ou Ecosia, ne lit pas les langues tout à fait comme Google. Il a historiquement mis en avant d’autres signaux que le hreflang : l’attribut lang de la balise html et la balise meta content-language. Les deux ne coûtent rien à renseigner. Faites-le sur chaque version, et déclarez votre sitemap dans Bing Webmaster Tools en plus de la Search Console.

Ma méthode pour lancer une première langue

1. Vérifiez la demande. Dans la Search Console, filtrez le rapport Performances par pays : si vous recevez déjà des impressions de l’étranger, c’est bon signe.
2. Choisissez le sous-dossier, sauf raison sérieuse d’en décider autrement.
3. Traduisez d’abord les pages qui rapportent : accueil, pages produits ou services, articles les plus lus. Relisez-les.
4. Déclarez le hreflang et le x-default avec des liens réciproques, et ajoutez les nouvelles adresses au sitemap.
5. Contrôlez au bout de quelques semaines : pages traduites indexées, impressions dans les pays visés, aucune canonique qui pointe vers la version française.

Si votre site tourne sous WordPress, les fondations restent celles de la version française : elles sont détaillées dans ce guide pour améliorer le SEO de votre site WordPress. Une version traduite bâtie sur un site lent ou mal structuré hérite de tous ses défauts.

Ce que je ferais à votre place

Trois gestes, dans cet ordre. Choisissez une structure d’adresses et n’en changez plus. Déclarez des hreflang réciproques sur chaque page, x-default compris. Relisez les traductions des pages qui comptent avant de les publier. Le reste se règle ensuite.

Si je ne devais garder qu’un conseil : commencez par une seule langue, bien faite. Une version anglaise propre sur vingt pages rapporte plus que cinq langues traduites à la chaîne sur tout le site. En vrai, le SEO multilingue récompense la patience bien plus que la vitesse.