Avoir une présence web multilingue et/ou multi pays est important pour développer votre entreprise et atteindre un public international. Mais cela requiert une connaissance approfondie de vos marchés cibles, ainsi qu’une connaissance du SEO à l’international pour que celui-ci reflète la structure de votre site web, la segmentation souhaitée ainsi que la configuration technique, le développement du contenu, l’optimisation et les efforts de d’activation.
Beaucoup manquent d’expérience sur ces sujets, et il n’est pas rare de voir les processus de positionnement SEO internationaux touchés par des problèmes, dont beaucoup peuvent entraîner une mauvaise expérience pour l’utilisateur.
Une solide connaissance du SEO technique est obligatoire lorsque l’on travaille sur des campagnes internationales. Voici donc quelques problèmes fréquents qui génèrent des erreurs dans les processus de SEO à l’international... mais aussi comment les éviter ou les résoudre !
1. Ne pas utiliser d’URLs différents pour chaque version internationale de votre page web
Il est essentiel que chacune des pages de langues différentes ou de pays différents soient affichée avec leur propre URL accessible, afin qu’elles puissent être suivies, indexées et positionnées par Google.
Cette option est préférable au suivi local adaptatif, qui tente d’identifier la langue et/ou le pays à partir duquel se connecte l’utilisateur pour vous montrer une version du contenu avec la même URL.
Google le mentionne dans sa propre documentation officielle :
« Google ne peut pas suivre, indexer ou positionner tout votre contenu à différents endroits. En effet, les adresses IP par défaut du suivi de Googlebot sont situées aux États-Unis. De plus, le traqueur envoi des demandes HTTP non configurées à l’aide de la fonction Accept-Language dans l’en-tête de la demande. »
C’est pourquoi vous devez établir une structure web individuelle pour chacune de vos versions internationales, en utilisant :
- des ccTLDs, des sous-répertoires et des sous-domaines si vous segmentez par pays
- des sous-répertoires et des sous-domaines si la segmentation se fait par langue.
Toutes ces options ont des avantages et des inconvénients, et les options devraient être basées sur la meilleure structure web internationale en fonction de vos propres caractéristiques, objectifs et restrictions.
Ce qui est également important, c’est de montrer constamment aux visiteurs la version de l’URL réelle de la page pertinente pour une langue ou un pays lorsqu’ils arrivent ou choisissent d’accéder à cette version.
C’est une stratégie plus appropriée plutôt que de faire comme certaines pages web comme l’Entrepreneur, qui, comme vous pouvez le voir dans l’exemple ci-dessous, préfère afficher la version espagnole de la page d’accueil via la même URL anglaise ( https://www.entrepreneur.com/) quand ils identifient que l’utilisateur utilise un navigateur en espagnol.
Ceci est peu inutile, étant donné que l’Entrepreneur dispose d’une version espagnole de la page « home » qui s’affiche à partir de sa propre URL ( https://www.entrepreneur.com/es).
Il s’agit de l’URL pertinente à afficher dans ce cas, afin d’éviter une expérience confuse, et permettant aux utilisateurs hispanophones de la relier ou de la partager.
2. Réorienter automatiquement les utilisateurs internationaux à une version web internationale sans leur donner la possibilité de la sélectionner
Bien que vous souhaitiez montrer à vos utilisateurs le contenu web pertinent pour leur pays ou leur langue, il n’est pas conseillé de le faire automatiquement en utilisant les redirections.
Ces redirections peuvent constituer une expérience déroutante et intrusive pour les utilisateurs qui souhaitent afficher le contenu dans une langue ou depuis un emplacement spécifique.
Un point rapide sur Google
À l’heure actuelle, la plupart des adresses IP de Googlebots se trouvent toujours aux États-Unis. Par conséquent, Google ne traque toujours pas tous les pays (les traqueurs proviennent des États-Unis et de certains autres pays).
Par conséquent, si nous redirigeons en fonction de l’IP, Googlebot ne pourrait être redirigé que vers quelques versions de notre site et ne pourrait pas accéder à toutes les versions existantes, car vous ne redirigeriez plus seulement les utilisateurs... mais aussi les bots.
Il est donc préférable d’autoriser non seulement les utilisateurs mais aussi Google, à parcourir n’importe quelle version internationale de notre site web, de sorte que Google puisse traquer ces versions au lieu de rediriger en fonction de l’IP.
Exemples
Une expérience encore pire que celle mentionnée se produit lorsque la redirection est effectuée sans permettre aux utilisateurs de passer à la version internationale de leur choix via une option visible ; ce que nous pouvons voir sur certains blogs ou sites d’informations, comme Gizmodo, que vous pouvez voir ci-dessous.
Au lieu de rediriger, il est recommandé d’autoriser l’accès aux utilisateurs de la version internationale initiale du site web, tout en leur indiquant qu’il existe une version plus pertinente en fonction de la langue ou du pays selon les informations fournies par leur navigateur ou l’adresse IP de leur pays.
Vous pouvez le faire de façon non intrusive et très visible, en offrant aux utilisateurs la possibilité de rester dans la version actuelle ou de passer à la version suggérée, comme le fait Autodesk.
3. Ne pas personnaliser le contenu dans la langue locale selon les différentes versions de chaque région
Même si vous segmentez en différents pays partageant la même langue, veuillez à ne pas réutiliser le contenu de différentes versions de votre site web.
Il est extrêmement important que votre contenu soit personnalisé pour chaque emplacement, et axé sur le comportement spécifique du public cible dans chaque pays.
Même lorsque la même langue est parlée, le contenu peut être différent.
Les différences peuvent être des termes particuliers pour décrire le même concept ou pour nommer des produits ou des services.
Malgré la langue commune, les préférences peuvent changer d’un pays à un autre.
Par exemple, vous pouvez voir comment, dans la version américaine du site web Adidas, il existe une catégorie appelée « Soccer cleats » et appelée « Football boots » dans la version anglaise, afin de s’adapter aux termes locaux employés par les utilisateurs de chaque pays, qui dans ce cas sont différents, bien qu’ils partagent la même langue.
C’est pourquoi il est essentiel de mener une étude de mots-clés pour chacun de vos marchés cibles, même si la langue est commune.
Cette étude, qui inclut le processus de sélection, d’assistance et de validation des conditions, devrait idéalement être réalisée par une personne native de ce marché spécifique, capable d’identifier et de valider le comportement de recherche du public cible.
Par la suite, vous pourrez optimiser votre contenu web, votre architecture, votre design, et vos actions promotionnelles en fonction des préférences trouvées.
4. Utiliser un seul ccTLD pour atteindre plusieurs pays
Ces sites qui commencent à se concentrer sur un seul pays, généralement où l’entreprise initiale est située et qui utilisent leurs ccTLD spécifiques (acronymes de “country code top-level domains” tels que .fr, .uk, .mx, .es, .de géolocalisés à chaque pays par défaut) peuvent faire face à un défi de taille au moment de se développer à l’international.
Le problème est qu’ils n’ont pas la possibilité d’utiliser le ccTDL initial pour atteindre d’autres pays, contrairement aux gTDL (acronyme de “generic top-level domains comme par exemple .com, .org, .net) car ils ne sont pas associés à un pays spécifique.
Un domaine gTLD peut être utilisé pour atteindre différents pays en activant des sous-répertoires ou des sous-domaines pour chacun pouvant être géo-localisé via la Google Search Console.
Malheureusement certaines entreprises ne connaissent pas ces options et tentent de se concentrer sur d’autres pays en activant des sous-répertoires pour différents pays avec un ccTLD déjà géo-localisé dans un autre.
Nous pouvons le voir ci-dessous, avec un exemple pour les États-Unis dans un sous-domaine sous un fichier .co.uk (ccTLD déjà géo-localisé par défaut au Royaume-Uni).
Pour cette raison, lorsqu’elles se développent sur de nouveaux marchés internationaux, les entreprises qui possèdent déjà un ccTLD (au lieu d’un gTLD) doivent choisir entre différentes options, généralement entre :
- la géolocalisation pour de nouveaux marchés utilisant de ccTLD
- la création d’un nouveau gTLD qui permet de créer de nouvelles options de pays dans des sous-domaines ou sous-répertoires pouvant être géo-localisés, en le réutilisant.
La première option demande plus de travail pour accroître la popularité individuelle de chaque ccTLD centré sur chaque pays.
La deuxième option sera – si vous souhaitez consolider la version de pays existante avec les nouvelles dans un seul domaine – d’effectuer une migration. D’autre part, les gTLD peuvent être activés en plus, uniquement pour une utilisation sur de nouveaux marchés, en évitant une migration de la version initiale. L’utilisation d’un seul gTDL avec des sous-répertoires géo-localisés pour plusieurs marchés aidera à géo-localiser vers plusieurs pays de manière plus efficace et plus simple à gérer.
5. Supposer que Google autorise la segmentation par continent avec des domaines tels que .asia ou .eu ou « eu » dans la balise hreflang
Google ne permet pas (du moins pour l’instant) la segmentation régionale au niveau du continent, que vous utilisiez des domaines de haut niveau tel que .eu ou .asia traités comme des gTDL ou utilisant des valeurs telles que « eu » pour l’Europe dans le tag car Google utilise le code ISO 3166-1 alpha-2 pour différencier les régions.
Il est important de garder cela à l’esprit lorsque vous décidez de créer un domaine .eu destiné aux utilisateurs européens, car il serait peut-être plus optimal d’utiliser un gTDL avec des sous-répertoires spécifiques pouvant être géo-localisés via la Google Search Console et marquer avec des annotations hreflang pour s’adresser individuellement à chaque pays européen.
6. Canonicaliser toutes les versions internationales de votre site web en un pour éviter les problèmes de contenu en double
Parfois, même lorsque des processus d’adaptation ont été mis en œuvre, en raison de la nature de votre entreprise, vous pouvez vous retrouver avec un contenu très similaire dans des versions différentes de pays partageant la même langue (comme l’anglais aux États-Unis, au Royaume-Uni ou en Australie).
Toutefois, si les versions de ces pays sont correctement géo-localisées sur leurs marchés respectifs, le contenu de ces pages ne doit pas être considéré comme dupliqué, car il est destiné à différents publics et doit être indexé individuellement pour être correctement positionné pour chaque pays.
Par conséquent, vous ne devez pas canonicaliser les URL centrées sur différents pays vers un seul, car chacune d’entre elles est originale et est la seule centrée sur chaque pays.
Souvent, une confusion peut être générée en raison de la canonicalisation croisée qui peut être vue sur des sites connus, comme dans l’exemple d’Airbnb que vous pouvez voir ci-dessous, où on voit comment est canonicalisé la page d’accueil de la version mexicaine vers la page d’accueil espagnole dans le domaine .com.
Cependant, nous ne connaissons pas le contexte dans lequel la décision de cette configuration a été prise et, d’autre part, nous pouvons constater que sur les marchés où ils ont une présence active et un volume important de trafic organique, tels que le Royaume-Uni, la France ou l’Espagne, ils sont autocanonicalisés.
Dans ces cas-là, pour géolocaliser et positionner les pages de chaque version de pays sur votre marché cible, il est recommandé de géolocaliser à l’aide de ccTLD ou de sous-répertoires ou sous-domaines qui enregistrent et géolocalisent chaque pays dans la Google Search Console, et utilisent des annotations hreflang qui spécifient la langue et le pays cible de chaque page, ainsi que ses versions alternatives.
7. Constituer des annotations de hreflang sans suivre un processus qui requiert une validation
Nous pourrions écrire un article entier sur les erreurs généralement commises avec les annotations hreflang.
De l’utilisation de valeurs non prises en charge à la spécification du pays sans définir la langue ou même oublier d’inclure des balises de retour ou le faire dans des URLs non indexables, entre autres.
En général, ces erreurs se produisent lorsqu’un processus de mise en œuvre hreflang qui requiert une validation correcte n’est pas suivie, tel que :
-
Évaluer la portée de la mise en œuvre par langue et/ou pays.
Identifier les versions des langues et/ou pays qui doivent utiliser hreflang, en particulier celles avec des résultats de recherche internationaux, qui ne sont pas alignés et qui pourraient être prioritaires.
-
Choisir une méthode de mise en œuvre
Évaluer la méthode de mise en œuvre de hreflang qui vous convient le mieux (balises dans l’en-tête HTML, l’en-tête HTTP ou le plan du site XML) selon les exigences du site et du projet, ainsi que les restrictions existantes.
-
Spécifier le modèle de code hreflang
Définir le libellé hreflang qui sera utilisé dans la mise en œuvre des différentes pages de langue/pays.
Vous avez pour référence les spécifications officielles de Google, ainsi que les formats et valeurs de pays et de langue pris en charge, afin d’éviter de les inclure dans des emplacements erronés ou avec des libellés, des attributs ou des valeurs non prises en charge.
-
Valider la mise en œuvre de hreflang dans un environnement de test
Les pages marquées doivent faire l’objet d‘un suivi dans un environnement de test avant le lancement afin d’identifier les erreurs de marquage possible.
-
Surveiller et résoudre les problèmes de mise en œuvre hreflang après le lancement.
Après le lancement, les pages balisées doivent être suivies de nouveau et surveillées à l’aide du rapport de recommandations internationales de la Google Search Console pour identifier les problèmes restants.
Vous devez également lancer une surveillance continue pour identifier tout problème généré lors de la publication de nouvelles pages, ainsi que lors de la modification ou suppression de celles déjà existantes.
En outre, vous pouvez identifier les problèmes de désalignement de nouvelles langues et de nouveaux pays dans les résultats de la recherche grâce au rapport de performance de la Google Search Console.
-
Établir un guide avec les meilleures pratiques de mise en œuvre de hreflang, guide qui doit toujours être suivi
Documenter la portée et les règles de mise en œuvre hreflang que vous avez définies et qui doivent être suivies et prises en compte chaque fois que les pages sont publiées dans les langues et/ou pays concernés ou lorsque les URL sont modifiées ou supprimées.
Ces documents sont nécessaires pour garantir que les annotations hreflang puissent être mises à jour efficacement.
Avec ce processus de mise en œuvre hreflang, les erreurs devraient être minimisées, et si elles venaient à surgir, elles seraient rapidement identifiées et résolues.
J’espère que cet article vous aidera à éviter ces erreurs courantes dans les processus internationaux de référencement. Si vous faites déjà face à ces erreurs, cela vous permettra de les résoudre plus rapidement.
Vous avez encore des doutes sur les erreurs les plus courantes dans les processus de SEO internationaux ? Nous ouvrons le fil de discussion dans les commentaires.