Traduire son site paraît simple : on prend les textes, on les fait traduire, on ajoute un sélecteur de langue. En pratique, c’est l’un des chantiers où l’on accumule le plus d’erreurs structurelles et ces erreurs sont pénibles à corriger une fois le site en production. Quelques décisions prises au départ évitent l’essentiel des problèmes.
Choisir sa structure d’URL avant tout le reste
C’est la première décision, et la plus lourde de conséquences. Trois options existent.
Les domaines distincts (monsite.fr, monsite.it) envoient un signal géographique très fort mais imposent de construire l’autorité de chaque domaine séparément. Coûteux, réservé aux projets d’envergure.
Les sous-domaines (fr.monsite.com) offrent une séparation nette, avec une transmission d’autorité partielle entre les versions.
Les sous-répertoires (monsite.com/fr/) conservent toute la force du domaine principal sur chaque version. C’est le choix recommandé dans la grande majorité des cas.
Pour une agence proposant des biens à une clientèle internationale, le sous-répertoire est presque toujours la bonne réponse. C’est aussi l’option que privilégie www.jimenez-julien.com dans ses recommandations, pour une raison simple : le travail de notoriété fait sur une version profite à toutes les autres.
Cette structure ne se change pas facilement. Décidez-la avant la première ligne traduite.
Les balises hreflang
C’est l’élément technique central, et celui qu’on rate le plus souvent.
Ces balises indiquent à Google que plusieurs pages sont des versions linguistiques d’un même contenu, et laquelle servir selon la langue du visiteur. Sans elles, vos versions se retrouvent en concurrence les unes avec les autres.
Trois règles. Les déclarations doivent être réciproques : si la page française déclare la version italienne, l’italienne doit déclarer la française. Chaque page doit se déclarer elle-même. Et les codes doivent être corrects langue seule (fr), ou langue et pays (fr-be) quand la distinction a du sens.
Ajoutez une valeur x-default pour désigner la version servie aux visiteurs dont la langue ne correspond à aucune de vos versions.
Traduction automatique : ce qui est acceptable
La position de Google a évolué. Le contenu traduit automatiquement et publié sans relecture entre dans la catégorie du contenu de faible valeur ce n’est pas la génération automatique qui pose problème, c’est l’absence de contrôle humain.
En pratique : utiliser un outil de traduction comme point de départ est parfaitement admis. Publier le résultat brut ne l’est pas.
Prévoyez systématiquement une relecture par une personne maîtrisant la langue, en priorité sur vos pages commerciales. Sur un marché immobilier, une formulation maladroite sur une page de contact coûte bien plus qu’une position perdue.
Les erreurs les plus fréquentes
La redirection automatique selon la localisation. Elle empêche Google d’explorer les autres versions et frustre les visiteurs. Proposez une suggestion, jamais une redirection forcée.
Le contenu partiellement traduit. Une page mêlant deux langues brouille tous les signaux.
Le sélecteur de langue en JavaScript sans vrais liens. Les versions deviennent inaccessibles à l’exploration.
Les métadonnées oubliées. Balises title, descriptions, textes alternatifs des images : tout doit être traduit, pas seulement le corps du texte.
Un sitemap unique et confus. Prévoyez un sitemap par langue, réunis par un index.
Ne pas tout traduire
Dernier conseil, contre-intuitif mais décisif : la traduction intégrale n’est pas toujours la bonne stratégie.
Commencez par traduire vos pages à fort enjeu offres, services, contact et laissez votre blog dans sa langue d’origine dans un premier temps. Vous concentrez ainsi l’effort de relecture là où il compte, et vous évitez de vous retrouver avec deux cents pages traduites approximativement.
Vous étendrez ensuite, en fonction du trafic réellement observé sur chaque version.
