Le SEO multilingue en pratique — ce que nous avons appris en exploitant nous-mêmes des sites KO, EN et FR
L’essentiel du SEO multilingue n’est pas de « traduire un maximum de contenu », mais de structurer le site pour que chaque version linguistique pointe précisément les moteurs de recherche vers les autres. En pratique, trois décisions se posent : ① la structure de domaine (ccTLD, sous-domaine ou sous-répertoire), ② l’intégrité du hreflang (les URL de chaque langue se référencent-elles correctement entre elles ?), et ③ la stratégie de contenu (tout traduire, ou prioriser par marché ?). Plutôt qu’une théorie générale, cet article raconte les problèmes que nous avons rencontrés — et la façon dont nous les avons résolus — en exploitant nous-mêmes les sites coréen, anglais et français de growthmk.com sous forme de sous-répertoires (/en, /fr) d’un domaine unique. Nous avons pris le guide officiel de Google sur les sites multirégionaux comme référence, et noté où ces principes se sont heurtés à la réalité de l’exploitation, et comment nous les avons corrigés.
Qu’est-ce qui est réellement difficile dans le SEO multilingue ?
Quand la plupart des équipes construisent un site multilingue pour la première fois, elles considèrent la qualité de la traduction comme la variable la plus déterminante. Or, ce qui fait réellement s’effondrer la performance en recherche, ce n’est pas le naturel de la traduction, mais l’intégrité de la structure. Si la version coréenne et la version anglaise d’un même article sont perçues par les moteurs de recherche comme deux pages sans lien entre elles, ou si à l’inverse deux articles totalement différents sont associés à tort comme traductions l’un de l’autre, même la meilleure traduction du monde n’exposera pas la bonne langue au bon lecteur.
Ce problème n’est pas isolé — les chiffres confirment sa fréquence. Dans son analyse de 374 756 domaines, Ahrefs a constaté que 67 % des sites ayant implémenté le hreflang présentaient une erreur, sous une forme ou une autre (étude d’Ahrefs sur le hreflang). Le hreflang, ce signal central, est « facile à ajouter, difficile à ajouter correctement » — et nous n’avons pas fait exception. Les trois décisions ci-dessous visent toutes à préserver cette intégrité ; pour chacune, nous présentons côte à côte le principe officiel de Google (issu de sa documentation) et notre choix concret et sa raison d’être (issus de notre propre exploitation). Le SEO multilingue ne fonctionne cependant que sur la base des fondamentaux — crawl, indexation, rendu — donc si ce socle vous intéresse d’abord, nous vous recommandons notre guide complet du SEO technique.
Décision 1 — Structure de domaine : sous-répertoire, sous-domaine ou ccTLD
Le principe : Google autorise les trois options, mais en détaille les compromis
Le guide de Google sur les sites multirégionaux présente trois structures d’URL possibles par langue ou région : un domaine national (ccTLD, par exemple example.fr), un sous-domaine sous un gTLD (fr.example.com), ou un sous-répertoire sous un gTLD (example.com/fr). La documentation officielle ne tranche pas en faveur d’une seule bonne réponse : elle compare les avantages et les inconvénients de chacune. Le ccTLD envoie le signal de ciblage régional le plus net, mais exige une infrastructure distincte par domaine, ce qui en fait la solution la plus coûteuse. Le sous-domaine est simple à mettre en place et permet de séparer la localisation des serveurs, mais son ciblage régional est difficile à déduire de la seule URL. Google explique que le sous-répertoire est simple à configurer et allège la maintenance, puisqu’il partage le même hôte (Managing multi-regional and multilingual sites). Ce même document précise clairement que distinguer les langues par un paramètre d’URL (?lang=fr) n’est « pas recommandé ».
Notre choix : un domaine unique avec sous-répertoires, et le nettoyage de l’ancien sous-domaine
Nous avons décidé d’exploiter nos trois langues sous un domaine unique growthmk.com, via des sous-répertoires /en et /fr. Trois raisons ont motivé ce choix.
- La consolidation de l’autorité de domaine — Quand tout le contenu de toutes les langues s’accumule sur un seul domaine, la confiance acquise grâce au contenu coréen profite aussi, comme actif d’hébergement partagé, aux répertoires anglais et français. Si le domaine se scinde en trois, les backlinks et la confiance se dispersent également en trois.
- La simplicité opérationnelle — Nous fonctionnons en architecture headless (frontend et CMS séparés), et avec des sous-répertoires, la même application se contente de brancher la langue selon le chemin d’URL, sans multiplier domaines, certificats ou pipelines de déploiement par langue. C’est exactement l’avantage de « maintenance réduite (même hôte) » que décrit Google.
- La séparation entre langue et pays — Nos versions anglaise et française ne sont pas des sites régionaux ciblant un pays précis, mais du contenu organisé par langue. L’objectif est d’atteindre « des prospects qui lisent le français », et non « des résidents de France » — l’avantage d’un ccTLD en matière de ciblage pays ne justifiait donc pas son coût.
Un point pratique important mérite d’être ajouté. Nous avons autrefois exploité notre contenu anglais sur un sous-domaine, en.growthmk.com. En basculant vers des sous-répertoires, nous n’avons pas laissé l’ancien sous-domaine à l’abandon : nous avons nettoyé tous ses chemins via des redirections 301 permanentes vers growthmk.com/en/*. Il ne s’agissait pas d’un simple changement de domaine : nous avons supprimé le préfixe de catégorie de l’ancienne URL (par exemple /insight/{slug}) pour le faire correspondre à la nouvelle structure /en/{slug}, redirigé vers une page parente les pages de tags et d’auteurs que nous n’exploitons plus, et configuré le robots.txt de l’ancien sous-domaine pour bloquer toute indexation (Disallow: /). Le plus grand risque, lorsqu’on change de structure de domaine, est de laisser l’ancienne structure survivre à moitié. Si l’ancienne et la nouvelle URL répondent toutes deux en 200, les moteurs de recherche voient le même contenu à deux endroits, et leur jugement sur la version canonique s’en trouve fragilisé. Désigner un emplacement canonique et consolider le reste via des 301 est la toute première chose à faire lors d’un changement de structure.
| Structure | Signal de ciblage régional | Consolidation de l’autorité | Coût d’exploitation | Notre analyse |
|---|---|---|---|---|
| ccTLD (example.fr) | Le plus fort | Dispersée par domaine | Élevé (domaine et infrastructure séparés) | Pertinent si le ciblage pays est net. Excessif pour notre objectif, organisé par langue |
| Sous-domaine (fr.example.com) | Faible (difficile à percevoir depuis l’URL) | Partiellement dispersée par la séparation d’hôte | Moyen | Ancien en. → consolidé en sous-répertoire, nettoyé via 301 |
| Sous-répertoire (example.com/fr) | Faible (compensé par canonical et hreflang) | Entièrement consolidée sur un seul domaine | Faible (même hôte) | Notre choix — consolidation de l’autorité + simplicité pour notre architecture headless |
| Paramètre d’URL (?lang=fr) | — | — | — | Non recommandé par Google — écarté d’emblée |
Décision 2 — hreflang : réciprocité et intégrité des groupes
Le principe : le hreflang doit être bidirectionnel, sinon il est ignoré
Le hreflang est le signal qui indique aux moteurs de recherche « voici où se trouvent les autres versions linguistiques de cette page ». Google reconnaît trois méthodes équivalentes pour le déclarer : ① une balise <link rel="alternate" hreflang="..."> dans le <head> HTML, ② un en-tête HTTP Link:, ③ un élément <xhtml:link> dans un sitemap XML. La règle la plus importante est celle du lien retour (return link). La documentation officielle est catégorique : « Si deux pages ne se pointent pas mutuellement l’une vers l’autre, les balises seront ignorées. » Si une page coréenne pointe vers une page anglaise, la page anglaise doit impérativement pointer en retour vers la page coréenne. Chaque version linguistique doit lister toutes les variantes, y compris elle-même, et il est également recommandé d’ajouter un x-default pour les utilisateurs ne correspondant à aucune langue précise (Tell Google about localized versions).
Notre choix : résoudre le conflit « plusieurs URL pour une même langue » par la normalisation en groupes
En théorie, c’est simple : il suffit de faire pointer KO, EN et FR les uns vers les autres. En pratique, le problème rencontré était plus retors : une même langue se retrouvait associée à plusieurs URL. Certains articles ont hérité de deux slugs coréens au fil d’une migration, ou les données de lien de traduction n’avaient été saisies que d’un seul côté, créant deux candidats coréens au sein d’un même groupe. Dans ce cas, l’ensemble hreflang se retrouve avec une langue en double, et les moteurs de recherche ne peuvent plus déterminer quelle URL coréenne constitue la véritable correspondance. C’est un cas d’école de cette statistique des « 67 % de sites en erreur » évoquée plus haut.
Notre solution a consisté à cesser d’assembler le hreflang à la volée, page par page, pour plutôt regrouper les articles liés par traduction (normalisation en groupes) afin que tout le groupe partage un ensemble hreflang unique. Voici comment cela fonctionne.
- Construire les groupes à partir des relations de liaison — Suivre les données de lien de traduction de chaque article et fusionner en un seul ensemble les articles reliés entre eux. Si A est la traduction de B, et B la traduction de C, alors A, B et C forment un même groupe.
- Imposer une seule URL par langue au sein d’un groupe — Si un groupe compte deux URL ou plus pour la même langue, une seule est désignée comme canonique, les autres sont écartées, et le conflit est consigné. L’essentiel est de « consigner et nettoyer », et non d’« ignorer silencieusement » : il faut pouvoir retracer, plus tard, pourquoi le hreflang d’un article a disparu.
- Tout le groupe utilise le même ensemble d’alternates — Le mapping « langue → URL » finalisé est partagé par toutes les pages du groupe, si bien que les pages coréenne, anglaise et française se pointent automatiquement les unes vers les autres, et vers elles-mêmes. La règle de réciprocité est ainsi respectée de façon structurelle.
- Renseigner x-default de façon cohérente — Pour les utilisateurs ne correspondant à aucune langue précise, nous avons fixé le coréen comme valeur par défaut, avec un repli sur l’anglais pour les articles sans version coréenne, et figé cette règle.
Avec cette approche, le hreflang cesse d’être « quelque chose qu’une personne ajuste à la main page par page » pour devenir « un résultat calculé une fois à partir des données ». Que le site compte 200 ou 500 articles, la même règle s’applique uniformément à toutes les pages, ce qui élimine structurellement les situations où certaines pages sont correctes et d’autres non. Cet ensemble de groupe se répercute d’ailleurs directement dans le sitemap. Chaque URL du sitemap embarquant les alternates du même groupe, le hreflang du <head> de la page et celui du sitemap ne divergent jamais. S’ils se contredisent (le head pointe vers A, le sitemap vers B), les moteurs de recherche reçoivent un signal confus — mais en générant les deux depuis une source unique de vérité (l’ensemble de groupe), cette contradiction ne peut tout simplement pas apparaître.
Décision 3 — Stratégie de contenu : prioriser par marché plutôt que tout traduire
Le principe : régler le contenu dupliqué régional via canonical et hreflang
Lorsqu’un contenu identique ou similaire est proposé sur plusieurs URL de langue ou de région, Google recommande de « désigner une version préférée et d’utiliser rel="canonical" et le hreflang pour que la bonne URL de langue et de région s’affiche auprès des internautes » (Managing multi-regional and multilingual sites). Un peu de duplication est inévitable dans l’exploitation d’un site multilingue, et la bonne pratique n’est pas de la dissimuler ou de l’éviter, mais de désigner une version canonique et de tout relier par des signaux. Attention toutefois : pousser en masse de la traduction automatique sans révision humaine relève précisément du territoire que la politique anti-spam de Google surveille (nous y reviendrons dans la section suivante).
Notre choix : l’anglais comme sous-ensemble du coréen, complété d’un contenu exclusif par marché
L’une des décisions de contenu les plus importantes que nous ayons prises tôt a été de ne pas traduire chaque article coréen en anglais et en français, un à un. La raison est simple. Une grande partie de notre contenu coréen est fortement ancrée dans le contexte du marché coréen (environnement de recherche local, réglementation locale, écosystème médiatique local), et n’a que peu ou pas de demande de recherche auprès des lecteurs anglophones ou francophones. Traduire et indexer un article sans demande n’aide pas les lecteurs, et nuit à la réputation « contenu utile » de l’ensemble du site.
Notre version anglaise est donc un sous-ensemble du contenu coréen. Les sujets universels, indépendants de la langue (principes du SEO/GEO, méthodologie marketing B2B, cadres de mesure), sont proposés en anglais, tandis que les sujets propres au marché coréen restent réservés au coréen. À cela s’ajoute un contenu exclusif, qui n’a de sens que pour les marchés anglophone et francophone. C’est une structure à la fois sous-ensemble et extension au-delà de l’intersection.
Ce qui soutient cela sur le plan technique, ce sont les métadonnées de langue de contenu. Pour chaque article, nous précisons dans le CMS, via un champ meta, « quelle est la langue de cet article : ko, en ou fr ? », et le frontend filtre les listes, les archives et le sitemap par langue à partir de ce champ. Nous distinguions autrefois les langues par des tags, mais l’ambiguïté devenait trop importante — un article pouvait par erreur porter deux tags de langue — nous sommes donc passés à un champ dédié de langue de contenu. Ce champ remplit deux fonctions à la fois : ① filtrer l’affichage pour que « la liste coréenne n’affiche que des articles coréens », et ② déterminer, lors de la génération du sitemap par langue, dans quelle section linguistique placer chaque article.
Résultat, le sitemap est généré dynamiquement par langue. Les articles coréens résident sur growthmk.com/{slug}, les anglais sur growthmk.com/en/{slug}, les français sur growthmk.com/fr/{slug} — chacun sur son propre chemin — et grâce à la normalisation en groupes, chaque entrée pointe automatiquement vers les autres versions linguistiques de son groupe via le hreflang. Les pages statiques (accueil, à propos, services) et les pages de cluster thématique suivent le même principe, en n’assemblant que les versions linguistiques réellement existantes. Un article qui n’existe qu’en coréen figure seul dans le sitemap ; un article existant en coréen et en anglais y figure de façon liée.
| Type de contenu | KO | EN | FR | Critère de décision |
|---|---|---|---|---|
| Méthodologie universelle (principes SEO/GEO/B2B) | Oui | Oui | Partiel | Demande indépendante de la langue → offre multilingue |
| Sujets propres au marché coréen (recherche, réglementation locales) | Oui | Non | Non | Aucune demande de recherche à l’étranger → coréen uniquement |
| Contenu exclusif aux marchés anglophone et francophone | Selon les cas | Oui | Oui | Pertinent uniquement pour ce marché → production spécifique par marché |
| Informations sur les services et l’entreprise (pages statiques) | Oui | Oui | Oui | Commun à tous les marchés → les trois langues |
Le SEO multilingue n’est pas un « projet de traduction », mais une « décision de priorisation du contenu par marché ». Le critère que nous mettons toujours en avant — « pas le volume de trafic, mais le client unique qui devient chiffre d’affaires » — s’applique directement au-delà des langues. L’objectif de notre version anglaise n’est pas de reproduire à l’identique le nombre d’articles coréens, mais d’atteindre précisément les sujets que recherchent réellement les prospects anglophones susceptibles de devenir clients.
Trois pièges courants — ceux que nous avons réellement rencontrés ou évités
Piège 1 — indexer la traduction automatique telle quelle
Quand on cherche à développer rapidement un site multilingue, le choix le plus tentant est de générer toutes les pages par traduction automatique. Mais la politique anti-spam de Google désigne explicitement comme spam le fait de « transformer automatiquement du contenu scrapé (remplacement de synonymes, traduction, etc.) pour produire en masse des pages n’apportant que peu ou pas de valeur aux utilisateurs », et qualifie de scaled content abuse « tout contenu produit à grande échelle, quelle que soit la méthode, qui n’apporte que peu ou pas de valeur aux utilisateurs » (Google Search spam policies). La traduction automatique n’est pas interdite en soi, mais elle devient risquée dès qu’elle est diffusée en masse sans révision humaine, édition ou enrichissement du contexte de marché. C’est l’une des raisons pour lesquelles nous avons choisi de ne pas tout traduire : un article qu’on n’a pas les moyens de peaufiner correctement, il est plus prudent de ne pas le traduire du tout.
Piège 2 — l’absence de réciprocité du hreflang
C’est l’échec le plus fréquent, et le plus silencieux. Si la page coréenne inclut un hreflang pointant vers la version anglaise, mais que la page anglaise oublie le lien retour vers le coréen, Google ignore la paire tout entière. C’est d’autant plus dangereux que tout semble parfaitement normal à l’écran. Nous avons éliminé ce risque en abandonnant purement et simplement l’idée d’« ajouter le hreflang à la main, page par page ». Avec un ensemble de groupe partagé, ne renseigner qu’une seule direction devient structurellement impossible : puisque toutes les pages d’un groupe partagent le même ensemble, si A pointe vers B, B ne peut que pointer en retour vers A.
Piège 3 — le contenu dupliqué non résolu
Lorsqu’on change de structure de domaine (sous-domaine → sous-répertoire) ou qu’on réorganise les règles d’URL, laisser l’ancienne URL en vie tout en ajoutant la nouvelle fait que le même contenu répond en 200 à deux endroits. Les moteurs de recherche y voient une duplication et dispersent leur décision d’indexation entre les deux. La solution est simple, mais incontournable : désigner une seule version canonique, consolider le reste via des 301, et, lorsque des contenus similaires mais non fusionnables subsistent, indiquer la version préférée avec canonical. Le nettoyage par 301 de notre ancien sous-domaine en., associé au mapping des anciens préfixes de catégorie et de tags anglais que nous n’exploitons plus, est précisément le travail que nous avons mené pour éviter ce piège.
Une checklist d’audit SEO multilingue
Le tableau ci-dessous reprend les points que nous vérifions réellement. Nous suivons le même ordre à chaque ajout de langue, chaque changement de structure, et lors des audits réguliers.
| Domaine | Point de contrôle | Critère de réussite |
|---|---|---|
| Structure de domaine | Le format d’URL par langue est-il cohérent ? | Toutes les langues suivent la même règle (sous-répertoire, etc.). Aucun paramètre d’URL |
| L’ancienne structure (ancien domaine, anciens chemins) a-t-elle été nettoyée ? | Les anciennes URL sont consolidées en 301 vers la version canonique. Aucun doublon ne répond en 200 simultanément | |
| hreflang | La réciprocité est-elle bidirectionnelle ? | KO↔EN↔FR se pointent mutuellement, et vers elles-mêmes |
| Une même langue est-elle dupliquée dans l’ensemble ? | Une seule URL par langue et par groupe. Les conflits sont consignés et résolus | |
| Le x-default est-il présent ? | Une valeur par défaut (par exemple KO) est définie pour les utilisateurs sans correspondance | |
| Sitemap | Chaque langue figure-t-elle au bon chemin ? | KO=/slug, EN=/en/slug, FR=/fr/slug. Aucune omission ni chemin erroné |
| Le hreflang du sitemap correspond-il à celui du head ? | Générés depuis une source unique de vérité → les deux signaux ne se contredisent jamais | |
| Contenu | Chaque version linguistique correspond-elle à la demande du marché ? | Pas d’indexation en masse d’articles sans demande via traduction automatique. Révision humaine effectuée |
| Les métadonnées de langue sont-elles exactes ? | Un seul champ de langue défini par article. Base du filtrage des listes et du sitemap |
Le SEO multilingue ne consiste pas à valider ce tableau une seule fois, mais à construire la structure qui le fait continuer à passer à mesure que de nouveaux articles s’ajoutent. Fait à la main, l’écart se creuse à mesure que le volume d’articles augmente ; généré à partir des données comme une règle, il maintient sa cohérence quelle que soit la croissance du site. Pour consolider plus largement les fondamentaux de la recherche, nous vous recommandons de poursuivre avec notre guide complet du SEO technique et notre checklist de contenu pour l’optimisation SEO Google ; pour la perspective marché de l’internationalisation, voir le marketing du marché coréen pour les entreprises mondiales ; et pour se préparer à la recherche IA, notre guide complet du GEO (optimisation pour moteurs génératifs). Un site multilingue constitue un signal non seulement pour les moteurs de recherche, mais aussi pour les moteurs de réponse IA, qui départage « ce qu’il faut montrer à quel utilisateur linguistique » — et plus la structure est cohérente, plus les humains comme l’IA citent précisément la bonne version linguistique. En définitive, bien exploiter un site multilingue est une question de structure : faire parvenir le bon contenu au bon lecteur — en particulier celui qui deviendra du chiffre d’affaires.
Nous mettons à votre disposition l’expérience que nous avons acquise et validée en exploitant nous-mêmes notre structure SEO multilingue. Cela comprend le diagnostic de votre structure de domaine, l’audit de l’intégrité du hreflang, et la conception des priorités de contenu par marché. Découvrez notre approche sur notre page services SEO, et si vous souhaitez un examen concret des problèmes de votre site multilingue actuel, contactez-nous via notre formulaire de contact.
Vous trouverez la vue d’ensemble de ce sujet dans notre article « Le guide complet de l’internationalisation — du choix des marchés à la localisation et au SEO mondial ».
FAQ
Pour un site multilingue, sous-répertoire ou sous-domaine est-il préférable pour le SEO ?
Google ne fixe pas de réponse unique : il présente les compromis. Le ccTLD envoie le signal de ciblage régional le plus fort, mais coûte le plus cher ; le sous-domaine permet de séparer les serveurs, mais son signal régional depuis l’URL seule est plus faible ; le sous-répertoire partage le même hôte, ce qui facilite la maintenance et consolide l’autorité de domaine en un seul endroit. Le ccTLD est pertinent quand le ciblage pays est clair ; le sous-répertoire l’est quand on s’organise par langue et qu’on privilégie la consolidation de l’autorité et la simplicité opérationnelle. Nous avons choisi un domaine unique avec sous-répertoires (/en, /fr) pour cette seconde raison.
Quelle est l’erreur la plus courante concernant le hreflang ?
L’absence de lien retour (return link). Google précise que si deux pages ne se pointent pas mutuellement, le hreflang est entièrement ignoré. Ne renseigner qu’une seule direction laisse tout paraître normal à l’écran alors que le signal est intégralement perdu — et l’étude d’Ahrefs a montré que 67 % des sites ayant implémenté le hreflang présentaient une erreur. Plutôt que de l’ajouter à la main page par page, regroupez les articles liés par traduction pour qu’ils partagent le même ensemble : ne renseigner qu’une seule direction devient alors structurellement impossible.
Faut-il traduire tout le contenu dans toutes les langues ?
Non. Les sujets pertinents pour un seul marché (environnement de recherche ou réglementaire d’un pays donné, par exemple) doivent rester dans cette seule langue ; seuls les sujets véritablement universels gagnent à être proposés en plusieurs langues. Indexer en masse, via traduction automatique, des articles sans demande n’aide pas les lecteurs, et risque de relever du « contenu de masse sans valeur » que surveille la politique anti-spam de Google. Notre version anglaise est structurée comme un sous-ensemble du contenu coréen, complété d’un contenu exclusif conçu spécifiquement pour les lecteurs anglophones.
Le classement dans les moteurs de recherche baisse-t-il si l’on passe d’un sous-domaine à un sous-répertoire ?
Oui, si les anciennes URL ne sont pas nettoyées. L’essentiel est de désigner une seule version canonique et de fusionner l’ancienne URL vers la nouvelle via une redirection 301 permanente. Si les deux restent actives, l’indexation se disperse sur du contenu dupliqué. Nous avons redirigé en 301 tous les chemins de notre ancien en.growthmk.com vers growthmk.com/en/*, tout en nettoyant les anciens préfixes de catégorie, en mappant les pages retirées et en bloquant l’indexation du robots.txt de l’ancien domaine. Cette consolidation transfère le signal accumulé par l’ancienne URL vers la nouvelle, ce qui limite au maximum toute baisse de classement.
