Une entreprise qui passe d'un site unique à plusieurs langues commence généralement par traduire les pages existantes et considère que le travail est fait. Il ne l'est pas. Sans la bonne structure technique en dessous, un site traduit peut activement embrouiller Google sur quelle version montrer à qui — parfois en positionnant la mauvaise langue dans le mauvais pays, ou pire, en traitant les pages traduites comme du contenu dupliqué et en supprimant la plupart des résultats de recherche.
Le SEO international est la couche qui garantit que chaque version linguistique atteint le public pour lequel elle a été conçue. Voici comment cela fonctionne réellement.
Hreflang : Ce que ça Fait Vraiment
La balise hreflang indique à Google (et à Bing) pour quelle langue, et éventuellement quel pays, une page spécifique est destinée, et quelles autres URLs de votre site sont des versions alternatives de ce même contenu dans d'autres langues. Bien fait, un internaute qui cherche en allemand reçoit votre page /de/ dans les résultats de recherche même si votre page d'accueil en anglais a techniquement plus d'autorité brute — parce que hreflang indique à Google que c'est la version la plus pertinente pour ce chercheur.
Les trois erreurs qui cassent le plus souvent ce système :
Réciprocité manquante — Chaque page d'un ensemble hreflang doit référencer toutes les autres pages de l'ensemble, y compris elle-même. Si votre page anglaise pointe vers la version allemande mais que la page allemande ne pointe pas vers l'anglaise, Google ignore souvent tout le groupe.
x-default absent ou incorrect — La valeur x-default indique à Google quelle version montrer à un internaute dont la langue ne correspond à aucune de vos alternatives. Sans cela, ce trafic est acheminé de façon imprévisible.
Hreflang sans balises canonical correspondantes — Chaque version linguistique a besoin de sa propre balise canonical auto-référente, et non d'une canonical pointant vers une seule version « principale ». Faire pointer la canonical de chaque page traduite vers l'original anglais indique à Google que les traductions sont des doublons plutôt que des pages distinctes — sapant exactement ce que le hreflang est censé résoudre.
Sous-Répertoires, Sous-Domaines ou ccTLD
Il existe trois façons courantes de structurer un site multilingue, et ce choix affecte à la fois le SEO et le coût de maintenance à long terme.
Sous-répertoires (exemple.com/de/) — Le choix le plus courant pour les petites et moyennes entreprises. Toutes les versions linguistiques partagent l'autorité du même domaine, ce qui signifie qu'un nouveau lancement de langue bénéficie de la confiance déjà construite par le domaine principal, plutôt que de partir de zéro.
Sous-domaines (de.exemple.com) — Techniquement plus simples à héberger séparément, mais Google a historiquement traité les sous-domaines comme des entités au moins partiellement distinctes en matière d'autorité, ce qui signifie qu'un nouveau sous-domaine met souvent plus de temps à se positionner qu'un sous-répertoire.
Domaines nationaux — ccTLD (exemple.de) — Le signal de confiance le plus fort pour le marché local, aussi bien pour les utilisateurs que pour Google, mais le plus coûteux à maintenir sur le long terme : enregistrements de domaine séparés, travail technique SEO séparé, et aucune autorité partagée entre les marchés.
Pour la plupart des entreprises qui s'étendent sur deux à cinq marchés, les sous-répertoires sont le choix pragmatique — c'est aussi la structure que nous utilisons sur notre propre site, décrite plus loin.
Contenu Localisé, pas Seulement Traduit
Traduction directe et localisation ne sont pas le même travail, et les traiter comme identiques est l'une des raisons les plus courantes pour lesquelles une expansion multilingue sous-performe.
Les prix doivent être convertis dans la devise locale avec des chiffres ronds et sensés, pas un calcul littéral de taux de change produisant un chiffre étrange à plusieurs décimales qu'aucun client ne verrait jamais sur une vraie grille tarifaire. Les expressions idiomatiques, la terminologie sectorielle et même le ciblage de mots-clés doivent être adaptés à la façon dont ce marché recherche réellement — une traduction littérale d'une expression clé n'est souvent pas ce qu'un locuteur natif taperait sur Google. Et les références spécifiques au marché d'origine (dates, réglementations locales) doivent être généralisées ou remplacées par des équivalents adaptés à chaque marché, et non reportées telles quelles dans chaque traduction.
Checklist Technique pour les Sites Internationaux
Entrées de sitemap par langue — Votre sitemap XML doit lister chaque version linguistique de chaque URL, idéalement avec des annotations hreflang alternate incluses à la fois dans le sitemap et sur la page elle-même.
Données structurées adaptées à la langue — Le schema JSON-LD doit inclure une propriété inLanguage correspondant à la langue réelle de la page, et non une copie unique de schema réutilisée telle quelle sur chaque locale.
Maillage interne cohérent — Les liens dans le contenu traduit doivent pointer vers la page traduite équivalente lorsqu'elle existe, sans revenir par défaut à la version anglaise. Une page allemande qui renvoie sans raison vers une page anglaise fait silencieusement sortir ce visiteur de l'expérience allemande.
Détection de langue qui respecte le choix manuel — Détecter automatiquement la langue d'un visiteur à partir des paramètres du navigateur est une bonne pratique, mais cela ne devrait jamais outrepasser une URL vers laquelle un utilisateur a explicitement navigué, ni une langue qu'il a explicitement choisie — rien ne frustre plus un visiteur international que d'être redirigé vers une langue qu'il n'a pas choisie.
Erreurs Courantes qui Plombent le Classement International
Contenu traduit automatiquement sans relecture — Les systèmes de Google comme les internautes humains reconnaissent la traduction automatique non relue, et elle convertit mal même quand elle se positionne techniquement.
Une seule stratégie de title et meta description pour toutes les langues — La recherche de mots-clés doit être refaite par marché, pas traduite mot à mot depuis la version anglaise, car le volume de recherche et la formulation diffèrent réellement d'une langue à l'autre, même pour la même intention sous-jacente.
Contenu dupliqué entre marchés quasi identiques — Deux sites dans la même langue pour des marchés différents avec un contenu identique et aucune différenciation de marché peuvent déclencher des problèmes de contenu dupliqué aussi facilement que des échecs de traduction littérale.
Comment Dricomm Aborde le Sujet
Notre propre site fonctionne en cinq langues — anglais, espagnol, français, allemand et russe — en utilisant la structure en sous-répertoires et la configuration hreflang décrites ci-dessus, avec chaque page portant une canonical adaptée à la langue, des balises alternate et des données structurées. Il est construit sur Next.js avec next-intl, la même stack et la même approche que nous apportons aux projets clients devant servir plusieurs marchés. Nous ne traduisons pas automatiquement pour publier tel quel ; chaque version linguistique est adaptée à la façon dont ce marché recherche réellement, pas simplement convertie mot à mot.
Si vous prévoyez une expansion vers de nouveaux marchés et souhaitez un avis technique sur ce dont votre site actuel aurait besoin avant le lancement, obtenez un audit gratuit ou découvrez notre gamme complète de services, y compris les tarifs pour les projets multilingues.
Prêt à développer votre activité en ligne ? Obtenez votre audit gratuit →