Le ciblage linguistique : il n'y a pas que le hreflang
Ecrit par Peak Ace
le
Le ciblage linguistique
Récemment nous revenions sur les bonnes pratiques pour géolocaliser son nom de domaine. Nous avions consciemment fait le choix de ne pas confondre une stratégie basée sur la géolocalisation et le ciblage linguistique.
En effet, contrairement à ce que tout le monde peut penser, développer son site à l’international pour augmenter sa visibilité, ne veut pas dire simplement traduire son site dans les langues souhaitées et rajouter des balises hreflang.
Dans cet article, nous allons revenir sur les fondamentaux d’une stratégie d’internationalisation
Compréhension du pays cible et de la langue cible
Une bonne stratégie d’internationalisation doit passer par une compréhension de la langue et du pays ciblé.
Dans cette étape, il faut comprendre qu’une langue n’est pas toujours synonyme d’un pays distinct. Concrètement, l’anglais est par exemple parlé dans 59 pays différents, l’espagnol dans 21 pays différents.
Ce qui veut dire qu’en fonction de la stratégie que l’on aura, on ne ciblera pas le même nombre d’internaute.
Par exemple : une entreprise française qui veut cibler les français vivant en France et une autre entreprise qui cible les français vivant en Russie ne viseront pas le même nombre d’internaute.
Il est donc primordial de distinguer une stratégie de site multilingue d’un site multirégional et d’un site disons hybride.
Comment gérer un site multilingue
Le ciblage linguistique nécessite une adaptation linguistique pour chaque langue visée.
Traduction du contenu :
Il est vivement recommandé de faire traduire son contenu par un natif et surtout d’éviter tout type de traduction automatique (google translate par exemple) qui fournissent généralement une traduction approximative qui vient nuire à l’expérience utilisateur.
Dans le cas où un site fait de la traduction automatique de son contenu original, il est recommandé de bloquer les pages générées dans le robots.txt car ce type de stratégie est synonyme de spam auprès de google.
Bénéfices d’une traduction par un natif : meilleure image du site et potentiel de conversion plus fort.
Figure 1: Exemple de traduction automatique à éviter
Les problèmes liés aux pages composites :
Il est fréquent de voir des pages rédigées en plusieurs langues (avec un contenu en anglais et en français par exemple).
Ce type de page est très mal supporté par les moteurs, malgré l’existence de l’attribut “language”.
C’est pourquoi, il faut garder en tête qu’un page équivaut à une langue.
Balisage :
On arrive aux fameux hreflang (Google) et meta language (Bing). ces deux balises ont pour objectif de permettre aux moteurs de recherche de déterminer les versions internationales d’une page, mais aussi ils permettent de positionner la version locale de la page en fonction de l’interface linguistique de l’utilisateur et de sa requête.
Les balises doivent aussi être réciproques entre chaque version de langue, sans quoi ils seront ignorés.
Les codes doivent être au format ISO 639-1(langue), ainsi qu’au format ISO 3166-1 Alpha 2(région).
Et pour la culture générale le nombre de hreflang par page ne doit pas dépasser le nombre de 100, tout simplement qu’au-delà la page est considéré comme un spam.
Il existe un nombre conséquent d’article sur l’implémentation de ces balises :
Voici les ressources de Google et de Bing.
Petite astuce : à l’heure de la course à la performance, nous vous recommandons d’implémenter ces balises dans le sitemap XML et non dans le head de votre code html.
Dans le cas où une page qui ne cible pas une langue ou un pays particulier. Par exemple une page de sélection de langue/pays, il est recommandé d’ajouter une balise un attribut hreflang » « x-default.
Vérification :
Une fois les balisages mises en place, vous pouvez via la search console la bonne ou la mauvaise implémentation de vos balises “hreflang”. Et ainsi identifier les points qui bloquent.
Le choix de l’URL
Le choix de l’URL dépend des moyens de chacun mais globalement on évitera le ccTLD qui permettent principalement de cibler un pays.
Par conséquent il nous reste 3 choix :
● Le répertoire permet facilement de cibler la langue de la page, notamment en respectant les nomenclatures officielles d’identification de pays et de langue (vues plus haut avec le hreflang)
Par exemple :
www.domaine.com/uk-en/ est reconnu comme un répertoire destiné aux habitants du royaume uni avec des pages en anglais.
www.domaine.com/es-ca/ est reconnu comme un répertoire destiné aux habitants de l’Espagne parlant catalan (et non des pages en espagnol pour des canadiens).
La notation /es/ca/ est également reconnue.
● Les paramètres sont une option à éviter car souvent mal compris par les moteurs et peuvent accidentellement biaiser l’utilisation des balises canoniques.
● Pour un ciblage purement linguistique on évitera le ccTLD qui est destiné aux régions
La détection de langue :
Il convient d’éviter absolument de créer un écran d’accueil pour choisir la langue. Cette pratique est fortement déconseillée pour des raisons d’ergonomie et cela nuit au référencement.
Nous préconisons plutôt de détecter le pays d’origine de l’internaute, et la langue par défaut du navigateur et de :
Définir une version pays et une langue par défaut, qui sera présentée en cas d’échec de la détection
D’orienter automatiquement l’internaute vers les pages qui lui sont destinées (détection de la langue du navigateur)
De lui permettre de choisir un autre réglage par défaut, si la redirection automatique ne lui convient pas.
Détecter le pays d’origine du visiteur
La détection du pays d’origine du visiteur peut s’effectuer par détection de la géolocalisation de l’IP du visiteur en utilisant une solution en Js qui ne viendra pas modifier le comportement des robots.
Il existe différents services payants ou gratuits offrant sous forme de service SaaS la résolution de la géolocalisation IP.