Comment rendre un site web multilingue en 2026

La première décision est de savoir quelles locales publier, et la réponse est rarement « toutes ». Chaque locale que vous ajoutez est un engagement : vous devrez maintenir son contenu, surveiller son SEO, réviser ses traductions et répondre à ses visiteurs. Ajouter 10 locales que vous ne pouvez pas maintenir est pire que d'en ajouter 2 que vous pouvez maintenir.

Commencez par les locales qui correspondent à votre audience réelle. Examinez votre trafic existant dans Google Analytics — quels pays et quelles langues vous visitent déjà ? Regardez vos clients — quelles langues parlent-ils ? Regardez vos concurrents — quelles locales servent-ils que vous ne servez pas ? L'intersection entre « où se trouve mon audience » et « où je peux offrir de la qualité » constitue votre liste restreinte de locales.

Pour la plupart des entreprises de services, la réponse est deux locales : votre langue commerciale principale plus une langue communautaire (par exemple, anglais + chinois pour un dentiste américain servant une communauté chinoise). Pour les entreprises transfrontalières, deux à quatre locales (par exemple, anglais + chinois + espagnol pour un consultant servant les États-Unis, la Chine et l'Amérique latine). Pour les sites logiciels et de contenu, quatre à dix locales peuvent se justifier une fois que l'économie unitaire justifie le coût de maintenance.

Trois structures d'URL viables pour les sites multilingues : (1) des sous-répertoires préfixés par la locale (example.com/zh-CN/, example.com/es/), (2) des sous-domaines préfixés par la locale (zh-cn.example.com, es.example.com), ou (3) des domaines distincts par locale (example.cn, example.es, example.com). Chacune présente des compromis.

Les sous-répertoires facilitent souvent la maintenance grâce au même hébergement et au même code. Google prend en charge sous-répertoires, sous-domaines et domaines nationaux, sans promettre de bonus de classement aux sous-répertoires. Privilégiez des URL propres et explorables pour chaque langue.

Les sous-domaines peuvent séparer équipes et infrastructures ; les domaines nationaux peuvent cibler clairement des régions mais demandent plus de gestion. Les liens et les performances de recherche dépendent de nombreux facteurs : un sous-domaine ne perd pas automatiquement toute valeur SEO.

Les domaines distincts se justifient pour des entreprises véritablement distinctes partageant une marque (par exemple, une chaîne de restauration rapide mondiale avec des menus et des tarifs propres à chaque pays). La complexité — SEO distinct, DNS distinct, hébergement distinct — en vaut rarement la peine pour les sites multilingues de petite ou moyenne taille.

Cogo Site ne génère pas encore de balises hreflang ni d'alternatives dans le sitemap pour les sites que vous publiez, et changer de langue ne modifie pas l'URL de la page.

La qualité de la traduction détermine si votre site multilingue se cumule ou se cannibalise. Trois approches, par ordre de coût et de qualité :

Méthode A — Traduction humaine avec relecture. Adaptée aux sujets juridiques, médicaux ou sensibles, mais tarifs et délais dépendent des langues, de la spécialité, du volume et de la qualité attendue. Demandez un devis adapté plutôt qu'un prix universel au mot.

Approche B — Traduction par IA avec relecture par un locuteur natif. L'IA traduit, un locuteur natif révise la page d'accueil et les pages critiques pour la conversion. Idéale pour la plupart des entreprises de services.

Méthode C — Traduction IA sans relecture humaine. Utile pour des brouillons peu sensibles, mais des nuances ou des faits peuvent être perdus. Google ne pénalise pas automatiquement la traduction automatique ; sa politique sur l'abus de contenu à grande échelle vise des volumes importants de pages peu utiles destinées principalement à manipuler le classement, quelle que soit leur création.

Une approche hybride peut utiliser des brouillons IA et une relecture native de l'accueil, des tarifs et des pages importantes pour la conversion. Qualité et coût varient selon la langue, le sujet et la profondeur de relecture ; des taux fixes de qualité ou d'économie ne sont pas étayés.

Hreflang indique à Google quelle version de locale montrer à quel internaute. Sans cela, Google peut servir la mauvaise locale au mauvais internaute, provoquant des rebonds et une perte de classement. Chaque page multilingue a besoin de trois éléments : une balise hreflang autoréférente, des balises alternatives pour chaque autre locale, et une balise x-default pointant vers la locale destinée aux internautes non appariés.

Au-delà du hreflang, chaque locale dispose de son propre titre, méta-description et slug d'URL — le tout dans la langue de la locale. Une erreur courante consiste à traduire le corps du contenu mais à laisser les métadonnées SEO en anglais ; Google interprète cela comme une « traduction de faible effort » et classe en conséquence. Traduisez tout.

Sitemaps : chaque locale doit figurer dans votre sitemap XML. La plupart des CMS modernes génèrent automatiquement des sitemaps multilingues avec les annotations hreflang correctes. Si vous gérez vos sitemaps manuellement, ajoutez des annotations hreflang à chaque entrée d'URL.

Données structurées : le JSON-LD de chaque page de locale doit être dans la langue de la locale lorsque cela s'applique (par exemple, les noms de Question de FAQ traduits, le titre d'Article traduit, le nom de Fil d'Ariane traduit). Consultez notre guide hreflang pour la spécification complète du hreflang.

La traduction représente la moitié du travail. L'autre moitié consiste en détails d'UX propres à chaque locale qui distinguent un véritable site multilingue d'un site simplement traduit.

Formats de date et d'heure : les États-Unis utilisent MM/JJ/AAAA, la majeure partie du monde utilise JJ/MM/AAAA, la norme ISO est AAAA-MM-JJ. Choisissez le format correspondant aux conventions de chaque locale ; n'utilisez pas un seul format à l'échelle mondiale.

Numéros de téléphone et adresses : format selon la convention postale de chaque locale. Les adresses américaines sont « 123 Main St, San Francisco, CA 94101 » ; les adresses chinoises sont en ordre inverse (pays, province, ville, district, rue, numéro).

Devise et unités : prix en USD pour en-US, en CNY pour zh-CN, en MXN pour es-MX. Ne convertissez pas automatiquement — affichez la devise réelle de la locale.

Preuve sociale : affichez des témoignages WeChat / Weibo / QQ sur zh-CN, des témoignages Facebook / Twitter / Yelp sur en-US. N'affichez pas de preuve sociale en anglais sur les pages chinoises — cela signale un « opérateur étranger ».

Libellés de formulaire et validation : les règles de validation des numéros de téléphone diffèrent (10 chiffres aux États-Unis, 11 chiffres en Chine continentale), les codes postaux diffèrent (5 chiffres aux États-Unis, 6 chiffres en Chine), les champs de nom diffèrent (prénom/nom occidental vs nom de famille/prénom chinois dans cet ordre). Validez selon la locale.

Piles de polices : le chinois nécessite des polices compatibles CJK (Noto Sans CJK, PingFang, Microsoft YaHei) ; l'anglais nécessite des polices latines (Inter, system-ui). La typographie à scripts mixtes nécessite des piles de secours.

Après le lancement, suivez le rapport sur les performances et l’inspection d’URL de Search Console pour chaque langue, analysez le trafic et les conversions, et vérifiez hreflang par un crawl ou un audit. L’ancien rapport « Ciblage international » a été abandonné ; Google prend toujours en charge hreflang.

Problèmes courants après le lancement : erreurs hreflang (à corriger immédiatement), pages d'une locale non indexées (vérifiez l'inspection d'URL), mauvaise locale classée dans la mauvaise région (vérifiez que le hreflang est correct), faible engagement sur une locale (révisez la qualité de la traduction et les détails d'UX).

Itérez en fonction des données. Si zh-CN génère 10 fois le trafic de en-US, votre audience est chinoise — priorisez cette locale. Si es-MX a un trafic élevé mais une faible conversion, la traduction est peut-être maladroite ou les prix erronés — corrigez-le. Les sites multilingues sont des systèmes vivants ; le lancement est le début, pas la fin.

Réauditez le hreflang chaque trimestre. Les modifications de sitemap, les migrations de contenu et les mises à jour de CMS peuvent casser le hreflang silencieusement. Un crawl trimestriel avec Ahrefs ou Sitebulb détecte les problèmes avant qu'ils ne coûtent des classements.

Erreur 1 — Publier trop de locales à la fois. Chaque locale est un engagement de maintenance ; 10 locales que vous ne pouvez pas maintenir, c'est pire que 2 que vous pouvez maintenir. Commencez par vos locales à plus forte valeur, prouvez le modèle, développez plus tard.

Erreur 2 — Choisir une structure d'URL pour un bénéfice de classement supposé. Sous-répertoires, sous-domaines et domaines nationaux ont chacun leurs usages. Choisissez des URL distinctes et explorables en fonction du public, des équipes, de l'infrastructure et de la maintenance.

Erreur 3 — Traduire le texte sans localiser les métadonnées. Adaptez titres, descriptions, textes alternatifs et données structurées lorsque c'est pertinent. Cela clarifie le contenu mais ne garantit pas une meilleure position.

Erreur 4 — Traduction automatique sans relecture par un natif. La traduction par IA est bonne mais pas parfaite. Faites toujours réviser la page d'accueil et les pages critiques pour la conversion par un locuteur natif. Le coût est faible ; le gain de qualité est important.

Erreur 5 — Détails d'UX identiques d'une locale à l'autre. Formats de date, formats de téléphone, devises, preuve sociale, validation de formulaire — tout nécessite un traitement propre à la locale. Une UX « taille unique » signale que « nous ne connaissons pas réellement votre locale ».

Erreur 6 — Oublier Baidu et Bing. Google est le moteur de recherche dominant en Occident, mais Baidu domine la Chine continentale et Bing compte encore dans certains segments d'entreprise/éducation. Assurez-vous que votre hreflang et votre sitemap fonctionnent pour les trois.