Site multilingue : hreflang, slugs locaux, traduction
Comment hreflang, des URLs traduites et un processus de traduction continu font qu'un site multilingue inspire confiance dans les deux marchés.
Équipe rabbitclipPublié: 6 min de lecture
En bref
Hreflang est une balise HTML qui indique aux moteurs de recherche pour quelle langue et quelle région une page est écrite; mal réglée, Google peut confondre différentes versions linguistiques d'un même contenu avec des doublons et montrer une page dans la mauvaise langue à un utilisateur du mauvais pays. Construire un site multilingue ne se limite pas à traduire le texte; cela veut dire planifier ensemble la structure d'URL, les balises hreflang et le processus de traduction dans la durée.
Pour une agence travaillant entre Istanbul et Londres, ce n'est pas un sujet abstrait; le site d'un fabricant avec une version anglaise et une version turque peut, sans hreflang, montrer une page en turc à un acheteur à Londres et une page en anglais à un client à Istanbul.
Cet article explique ce que fait hreflang, comment construire la structure d'URL, et comment gérer le processus de traduction.
Ce que fait vraiment hreflang
Hreflang est une balise dans le code source d'une page qui indique pour quelle langue, et éventuellement quelle région, cette page est écrite, et qui pointe dans les deux sens vers les autres versions linguistiques du même contenu.
Quand Google voit la version turque pointer vers la version anglaise et la version anglaise pointer en retour vers la turque, il comprend que les deux sont des versions linguistiques différentes du même contenu, pas du contenu dupliqué.
Si cette balise manque, ou ne fonctionne que dans un sens (la page turque pointe vers l'anglaise mais pas l'inverse), Google se retrouve désorienté; la page dans la mauvaise langue peut se retrouver montrée au mauvais visiteur, ou les deux pages traitées comme des copies l'une de l'autre.
Comment construire la structure d'URL
Trois structures courantes existent pour un site multilingue: des domaines séparés (site.com.tr, site.co.uk), des sous-domaines (tr.site.com, en.site.com), ou des sous-dossiers (site.com/tr/, site.com/en/). Selon les propres recommandations de Google, les trois fonctionnent techniquement; le choix dépend de la préférence de marque et de marketing de l'entreprise.
Une structure en sous-dossiers demande en général le moins d'entretien, puisque toutes les versions linguistiques bénéficient de l'autorité d'un seul domaine. Les domaines séparés conviennent à une entreprise voulant une image de marque distincte par marché, mais chaque domaine doit alors gagner sa propre autorité SEO séparément.
Si le site anglais d'une chaîne de spas vit sur un domaine séparé pendant que son site turc vit dans un sous-dossier, cette structure incohérente crée de la confusion pour les moteurs de recherche; la structure mérite d'être fixée sur un seul modèle dès le début du projet.
Cette décision gagne aussi à être pensée en tenant compte d'une éventuelle troisième langue plus tard; une structure conçue pour seulement deux langues peut nécessiter d'être entièrement revue le jour où une troisième s'ajoute.
Ce que veut dire un slug local, et pourquoi ça compte
Un slug local signifie que les mots dans l'URL d'une page sont eux aussi traduits dans cette langue; la version anglaise d'une page 'services' devrait par exemple se trouver sur '/services', pas sur le turc '/hizmetlerimiz'.
Laisser l'URL non traduite affaiblit à la fois l'expérience utilisateur et le SEO; un visiteur britannique voyant un mot turc dans la barre d'adresse a l'impression que le site n'a jamais été pensé pour lui.
Mettre en place des slugs locaux ajoute une étape au processus de traduction: non seulement le texte de la page, mais aussi l'URL, le titre de page et la meta description doivent se penser séparément dans chaque langue.
Comment construire le processus de mise à jour des traductions
Le problème le plus courant sur un site multilingue est que la langue source (généralement le turc ici) se met à jour pendant que l'autre langue (l'anglais) prend du retard. Si le prix d'un produit ou une description de service change côté turc et reste figé côté anglais, un client britannique lit une information périmée.
La solution ici est procédurale, pas technique: une checklist qui signale l'autre langue à chaque changement de contenu, ou le module de contenu multilingue d'un CMS headless, fonctionnent tous les deux.
- Chaque mise à jour de contenu déclenche une vérification de l'autre langue, comme un processus permanent
- La traduction suit le contexte plutôt que le mot à mot; une traduction littérale peut sonner bizarrement
- Les particularités locales (un mode de paiement, une référence légale) s'adaptent au marché cible plutôt que d'être traduites littéralement
Quelle entreprise a vraiment besoin d'un site multilingue
Un site multilingue se justifie pour une entreprise qui vend à des clients dans plusieurs pays, reçoit des demandes de l'étranger, ou travaille avec des partenaires à l'international. Pour une entreprise servant uniquement son marché local, une deuxième langue devient en général un entretien superflu.
La question qui tranche: y a-t-il une demande réelle depuis l'étranger, ou la deuxième langue n'est-elle là que pour 'paraître plus professionnelle'? Dans le premier cas, l'investissement se rentabilise; dans le second, l'entretien continu devient un fardeau pour l'entreprise.
Pourquoi la qualité de traduction n'est pas qu'une question de grammaire
Une bonne traduction va au-delà de la correction grammaticale; elle doit se rapprocher de la façon dont le lecteur cible parle réellement au quotidien. Une phrase qui sonne naturelle en turc peut sembler raide ou étrange traduite mot à mot en anglais; c'est un problème d'approche de traduction, pas une erreur du traducteur.
L'expression turque pour une commande en gros d'un fabricant de vêtements de travail se traduit directement par 'wholesale order', mais ajouter à côté un terme plus recherché sur le marché britannique, 'bulk order' ou 'trade account', colle mieux au comportement de recherche réel.
C'est pourquoi le processus de traduction a besoin de quelqu'un qui connaît le marché cible, pas seulement d'un traducteur; les deux rôles n'ont pas à se retrouver dans la même personne, mais l'un devrait vérifier le travail de l'autre.
Une fois ce genre d'ajustements réfléchis une fois pour toutes et couchés dans un guide de style dès le début du processus, il n'y a plus besoin de les rediscuter pour chaque nouvelle page ensuite.
Un site multilingue, construit avec un hreflang correct, des URLs traduites et un processus de mise à jour de traduction régulier, se lit comme digne de confiance dans les deux marchés; construit à moitié, il désoriente à la fois le moteur de recherche et le visiteur. Lors d'un premier échange avec rabbitclip, la structure multilingue existante, quand il y en a une, se revoit ensemble. Une fois la structure bien posée, ajouter du contenu neuf ne demande plus qu'un effort de traduction, pas une reconstruction technique.
Questions fréquentes
Que se passe-t-il si hreflang manque?
Google peut montrer la page dans la mauvaise langue au mauvais visiteur, ou traiter les deux versions linguistiques comme du contenu dupliqué.
Les sous-dossiers valent-ils mieux que des domaines séparés?
Les deux fonctionnent techniquement; les sous-dossiers demandent en général moins d'entretien, les domaines séparés conviennent quand une image de marque distincte par marché est recherchée.
Les URLs doivent-elles être traduites dans chaque langue?
Oui, des slugs traduits renforcent à la fois la confiance des visiteurs et le SEO.
À quelle fréquence les traductions doivent-elles être mises à jour?
Idéalement à chaque changement du contenu dans la langue source; c'est un processus continu, pas une tâche ponctuelle.
Les outils de traduction automatique comme Google Translate suffisent-ils?
Non, la traduction automatique peut donner un point de départ rapide mais rate le contexte et le comportement de recherche local; au minimum, une personne doit la relire.
