Site multilingue : checklist technique

Un site multilingue n'est pas un bouton « traduire », c'est une tâche d'ingénierie à part entière, avec ses pièges techniques. Traduire les textes est la partie facile ; faire en sorte que chaque moteur de recherche serve la bonne langue à la bonne personne est le vrai travail, et c'est là que la plupart des projets échouent silencieusement.

Ce n'est pas un bouton traduire

Sous la surface, l'internationalisation touche au routage, aux balises, à l'indexation et à la gestion de contenu. Une erreur dans n'importe quel maillon, et Google montre la version anglaise à un public français, ou pire, dilue votre autorité entre dix pages quasi identiques. Le coût est invisible mais réel : du trafic perdu et des positions qui ne décollent jamais.

hreflang : la base non négociable

L'attribut hreflang indique aux moteurs quelles pages sont équivalentes dans quelles langues et quelles régions. Sans lui, le moteur devine, et il devine mal. Chaque page doit pointer vers sa version dans chaque langue, y compris vers elle-même, et les références doivent être réciproques : si la page A pointe vers B, B doit pointer vers A.

• Une balise hreflang par combinaison langue-région
• Réciprocité stricte entre les versions liées
• Une page par langue, jamais de contenu mixte
• Une page par défaut explicite (x-default)

Structure d'URL propre

Deux écoles dominent : un sous-domaine (fr.site.com), un sous-dossier (site.com/fr), ou un domaine national (site.fr). Le sous-dossier est le plus simple à faire ranker et à maintenir pour la plupart des PME. Évitez surtout de passer la langue en paramètre (site.com?lang=fr) : les moteurs le traitent mal et les utilisateurs ne le partagent pas.

• Préférer /fr/, /en/, /de/ en sous-dossiers
• Garder la même structure d'URL entre langues
• Éviter les paramètres de langue dans l'URL
• Rediriger proprement selon la locale du navigateur

Traduction complète, pas partielle

Traduire le menu et l'accueil tandis que les pages produits restent en source crée une expérience cassée et un signal de faible qualité pour Google. Chaque page, chaque bouton, chaque message d'erreur doit exister dans la langue cible. La traduction doit aussi être locale, pas littérale : « panier » devient « cart » en anglais mais les tours de phrase changent profondément.

Canonical et sitemap par version

Chaque version linguistique a besoin de sa propre balise canonique pointant vers elle-même, et d'un sitemap qui liste l'ensemble des langues via les balises xhtml:link. Cela évite la pénalité pour contenu dupliqué et aide le moteur à comprendre la cartographie précise de votre site international.

• Canonical vers la version de même langue
• Un sitemap regroupant tous les hreflang
• Soumission séparée par propriété Search Console
• Pas de canonical croisé entre langues

Polices et mise en page

Le français s'étend, l'allemand est long, le russe est dense, l'arabe se lit à droite. Une maquette pensée pour l'anglais éclate au contact d'autres langues : débordements, coupures de mots, alignements cassés. Le design system doit intégrer des jeux de polices et des conteneurs flexibles pour chaque script cible, y compris la direction RTL.

Le piège du contenu dupliqué

Traduire mot à mot génère souvent des pages trop similaires entre elles, surtout dans des langues proches. Le moteur peut alors ne pas comprendre laquelle indexer, et votre effort de traduction ne paie pas. La rédaction doit adapter le fond, pas seulement la forme : des exemples localisés, des références culturelles pertinentes, une intention réelle par marché.

SEO international et ciblage

La Search Console permet de cibler une région par version, ce qui renforce le signal géographique. Combinez cela avec un hébergement proche de la cible ou un CDN régional, et des liens entrants depuis des sites locaux, pour que chaque version gagne en pertinence sur son propre marché.

• Ciblage géographique par version dans Search Console
• CDN régional pour la vitesse locale
• Netlinking depuis des sites du pays cible
• Contenu éditorial adapté à la culture locale

Gestion des contenus et CMS

Le CMS doit gérer proprement les champs par langue, pas juste dupliquer des pages. Préférez une structure où chaque bloc de contenu existe en N langues, avec des permissions de traduction séparées, et une synchronisation des médias. Cela évite qu'une langue oubliée affiche du contenu obsolète ou vide.

Exemple de structure saine

Imaginons un site produit : /fr/produit, /en/product, /de/produkt, chacun avec hreflang vers les deux autres et x-default vers l'anglais, un sitemap unique listant les trois, et des traductions complètes des fiches. Le visiteur allemand tombe sur la version allemande, le moteur comprend la relation, et chaque version acquiert son propre capital de classement.

Traduire le texte est facile. Faire en sorte que le moteur serve la bonne langue, c'est la vraie tâche.

En résumé

Un site multilingue réussi repose sur une ingénierie rigoureuse : hreflang réciproques, URL propres, canonical et sitemap par version, traduction complète et localisée, et une maquette qui supporte chaque script. Négligez un seul de ces points et l'internationalisation devient un trou noir à trafic. Faites-le bien, et chaque marché devient une source de croissance indépendante.