Votre site multilingue n’est probablement indexé que dans une seule langue

Un schéma que nous voyons souvent : une entreprise traduit son site en six langues, publie un sélecteur de langue, et ne voit aucun trafic venant des nouveaux marchés. Les traductions sont bonnes. Personne ne les trouve.

La cause est presque toujours la même, et elle relève de l’architecture, pas de l’édition.

Les moteurs indexent des URL, pas un état applicatif

Si votre sélecteur de langue remplace le texte de la page et mémorise le choix dans localStorage ou un cookie, alors toutes les langues partagent une seule URL.

Le robot demande cette URL, reçoit la langue intégrée dans le HTML, et indexe celle-là. Vos six autres traductions n’existent pas pour la recherche. Aucune seconde URL à positionner, aucun titre ni description propres.

Ce n’est pas une limite de robot à contourner. L’URL est l’unité d’indexation. Une URL signifie un document indexé.

Le test est simple : pouvez-vous envoyer à quelqu’un un lien qui ouvre votre page en japonais ? Sinon, Google ne peut pas non plus indexer une version japonaise.

Quand le changement côté client convient

Soyons justes envers ce motif, il n’est pas toujours mauvais. Le changement côté client est parfaitement raisonnable quand la page n’est pas quelque chose que l’on trouve par son texte :

• Interfaces applicatives derrière une authentification
• Tableaux de bord et outils internes
• Un petit site vitrine dont le trafic vient de la publicité, de recommandations ou du bouche-à-oreille

Cela devient un problème dès que vous voulez du trafic organique dans ces langues. Le marketing de contenu, la documentation et les blogs sont exactement ce cas.

Donnez à chaque langue une vraie URL

Trois structures courantes, toutes acceptables pour les moteurs :

Pour la plupart des équipes : les sous-répertoires. Un seul domaine accumule l’autorité et aucun travail d’infrastructure supplémentaire.

Ensuite, dites aux moteurs que ces pages sont liées

Séparer les URL crée un risque nouveau : sept pages qui disent la même chose peuvent ressembler à du contenu dupliqué. hreflang est la façon de dire « ce sont les mêmes pages dans des langues différentes, montrez la bonne ».

Sur chaque version, listez toutes les versions, y compris elle-même :

<link rel="alternate" hreflang="en" href="https://example.com/en/page">
<link rel="alternate" hreflang="vi" href="https://example.com/vi/page">
<link rel="alternate" hreflang="ja" href="https://example.com/ja/page">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/page">

Plus un canonical autoréférent sur chacune :

<link rel="canonical" href="https://example.com/ja/page">

Les cinq erreurs qui cassent tout

1. Liens retour manquants. hreflang doit être réciproque. Si la page anglaise pointe vers la japonaise mais que la japonaise ne pointe pas en retour, l’appariement est ignoré. C’est de loin l’échec le plus courant.
2. Canonical pointant vers une autre langue. Une page japonaise dont le canonical vise l’URL anglaise ordonne aux moteurs de l’écarter. Le canonical doit pointer vers elle-même.
3. Confondre langue et région. hreflang="ja" désigne la langue japonaise. hreflang="ja-JP" désigne le japonais spécifiquement pour le Japon. Utilisez le code de langue seul, sauf si vous avez vraiment des variantes régionales ; restreindre sans raison vous coûte des lecteurs ailleurs.
4. Mauvais codes. Le sous-tag de région est un code pays, pas un code langue. L’anglais britannique est en-GB, pas en-UK. Pour le chinois, l’écriture compte plus que le pays : zh-Hans et zh-Hant.
5. URL relatives. hreflang et canonical exigent des URL absolues avec protocole et domaine.

Traduisez aussi les slugs

Un gain facile souvent sauté : les mots de l’URL sont un signal de pertinence dans cette langue. Si votre page vietnamienne vit à /vi/how-to-look-up-a-character, l’URL n’apporte rien en vietnamien.

Traduisez le slug et gardez un identifiant interne stable pour apparier les versions. C’est exactement ainsi que ce blog est structuré : chaque article a un id qui ne change jamais et un slug par langue qui, lui, change.

Ne redirigez pas automatiquement selon l’IP

C’est tentant et cela cause de vrais dégâts. Si vous détectez le pays du visiteur et forcez une redirection :

• Les robots demandent surtout depuis un pays et peuvent ne voir qu’une seule version.
• Vous écrasez le choix délibéré des gens. Beaucoup de personnes au Japon veulent lire en anglais.

Suggérez, n’imposez pas. Proposez un bandeau, gardez le sélecteur visible, et laissez l’URL décider du contenu.

Les sites statiques rendent cela facile

Rien de tout cela ne demande de CMS ni de serveur. Générez un fichier HTML par langue et par page au moment de la construction, avec les bonnes balises intégrées, puis téléversez le dossier. La sortie est constituée de fichiers statiques ; l’intelligence est dans le générateur exécuté avant le déploiement.

C’est ce que nous faisons pour ce blog : le contenu vit dans un fichier par article et par langue, un petit script produit le HTML avec hreflang, canonical, JSON-LD et entrées de sitemap par langue, et le site reste un dossier de fichiers statiques, sans aucun backend.

Une liste de contrôle

• Chaque langue a sa propre URL, que vous pouvez envoyer à quelqu’un
• Chaque page liste toutes les langues dans hreflang, y compris elle-même, de façon réciproque
• Un x-default existe pour les visiteurs sans correspondance
• Le canonical de chaque page pointe vers elle-même
• Les slugs sont traduits, avec un id stable qui les apparie en interne
• Le sitemap liste chaque URL de langue avec ses alternatives
• html lang correspond au contenu réel
• Aucune redirection forcée basée sur l’IP