Guide du ciblage linguistique et géographique

Quelle est la meilleure façon de configurer un site Web qui nécessite à la fois un ciblage par pays et par langue ? Eh bien, c'est une question très débattue parmi les experts SEO et malheureusement, il n'y a pas de réponse claire. Quelle que soit la manière dont vous choisissez de configurer votre site Web, il y aura des lacunes puisque chaque situation est différente et dépend de la nature unique de votre entreprise.

Cependant, en guise d'introduction au sujet, je vais explorer comment aborder la question du ciblage linguistique et national dans un environnement de commerce électronique.

Lors de l'examen initial de notre approche, de nombreux problèmes différents devaient être pris en compte, mais fondamentalement, il y avait deux facteurs importants à garder à l'esprit :

1. Optimisation des moteurs de recherche (SEO)
2. Optimisation du taux de conversion (CRO)

Deux aspects distincts devaient être pris en compte pour ces deux facteurs lorsque nous avons choisi la configuration de notre domaine : la manière dont nous ciblons les langues et la manière dont nous ciblons les pays. Un site multilingue est un site Web qui offre son contenu dans plus d'une langue, par exemple, une entreprise canadienne qui offre son contenu en anglais et en français.

Un site Web multirégional, en revanche, est un site Web qui cible spécifiquement les utilisateurs de différents pays. Ceci est fréquemment fait pour améliorer le CRO en personnalisant le contenu tel que le processus de commande, les détails d'expédition, la recherche d'adresse et tout autre contenu pour améliorer les conversions en fonction de l'emplacement géographique. En plus de ces deux configurations individuelles, il est important de garder à l'esprit qu'un site peut être à la fois multirégional et multilingue.

Les marques avec lesquelles nous travaillons sont populaires dans de nombreux pays différents, dont certains (comme le Canada), desservent des utilisateurs dans plusieurs pays, ce qui a ajouté un autre niveau de complexité à notre configuration. Comment devions-nous servir les utilisateurs dans la bonne langue tout en leur offrant une expérience utilisateur adaptée à leur emplacement géographique pour leur donner des attentes réalistes en matière d'expédition, de prix et de garanties ?

À QUOI RESSEMBLAIT NOTRE CONFIGURATION PRÉCÉDENTE ?

Auparavant, nous utilisions une configuration de sous-répertoire pour tous les sites du réseau MoreNiche, avec la version américaine sur https://brandwebsites.com/us/, la version française sur https://brandwebsites.com/fr/ et la version canadienne du site à https://brandwebsites.com/can/.

Par conséquent, les utilisateurs canadiens pourraient se retrouver sur /can/ ou /fr/ selon la langue dans laquelle ils ont effectué leur recherche, certains utilisateurs canadiens atterrissant même sur le site /us/ même si les paramètres régionaux étaient définis sur en-US. En fait, près de la moitié de tous les utilisateurs canadiens avaient atterri sur le site américain et avaient raté bon nombre des importantes améliorations de convivialité qui s'étaient avérées grandement bénéfiques pour le CRO.

Dans l'ensemble, lorsqu'il s'agissait de cibler correctement la langue et le pays, notre précision était d'environ 70 %, ce qui signifie qu'une bonne proportion des utilisateurs du site n'avaient pas une expérience optimale. Il s'agissait d'une performance nettement inférieure à celle du site CrazyBulk qui utilisait déjà une configuration multi-domaine et enregistrait une précision de 90 %.

Cela s'est reflété à la fois dans les taux de conversion et dans les classements des marques pays par pays. En général, Google semblait favoriser la configuration du site en langue, et les utilisateurs ont bénéficié de l'expérience de paiement personnalisée améliorée et de nos autres efforts de CRO.

A QUOI RESSEMBLE LA SOLUTION PARFAITE ?

Alors, quelle est la solution idéale pour une configuration qui nécessite un ciblage à la fois géographique et linguistique ? C'est une question délicate, sans réponse parfaite. En fait, les référenceurs débattent sans cesse de cette question controversée.

Notre vision à long terme est que tous les sites doivent être sur des domaines ou sous-domaines linguistiques (ccTLD) (sur un gTLD) où le ccTLD n'est pas disponible pour garantir que l'expérience est adaptée au pays spécifique. Les pays qui ont besoin de plus d'une langue devraient éventuellement avoir une configuration multilingue, par exemple, https://brandwebsites.ca desservirait le site principal en anglais canadien tandis que https://brandwebsites.ca/fr/ desservirait le site un peu moins important site de langue canadienne-française.

La grande majorité du trafic provenant d'affiliés, nous avons estimé qu'il était plus important de considérer d'abord le CRO pour s'assurer que la plupart des utilisateurs ont une expérience adaptée à leur emplacement géographique.

Afin de prendre en charge cette configuration et de nous assurer que nous ne rencontrions pas de problèmes de contenu dupliqué, nous devions être certains que nous utilisions correctement hreflang pour expliquer aux moteurs de recherche exactement ce que nous ciblions. De plus, nous devions être conscients du contenu dupliqué sur plusieurs domaines et examiner attentivement si nous devions utiliser la canonisation ou s'il était, en fait, acceptable d'avoir du contenu dupliqué puisque nous ciblions différents utilisateurs dans différents pays. Vous trouverez ci-dessous un extrait des conseils de Google sur le contenu dupliqué dans le cas de sites Web spécifiques à une langue et à un pays.

Souvent, surtout lorsque vous portez votre chapeau SEO, il est beaucoup trop facile d'avoir trop peur d'avoir du contenu en double sur votre site Web. Une grande partie de cette peur a été causée par la nature trop zélée de la mise à jour initiale de Google Panda en février 2011. Bien que le contenu dupliqué ait toujours été quelque chose à garder à l'esprit, son importance a décuplé avec l'introduction de Panda.

Du jour au lendemain, de nombreux sites qui étaient auparavant bien classés ont tout simplement disparu en raison de problèmes de qualité du contenu et de duplication qui ont soulevé un drapeau contre le site et ont effectivement marqué l'ensemble du domaine comme étant de mauvaise qualité. En fait, je vous conseillerais tout de même de lire cet ancien article sur Moz qui fournit des conseils détaillés sur le contenu dupliqué dans un monde post-Panda.

Une chose qu'il convient de noter maintenant est que depuis janvier 2016, Panda n'est en fait qu'une autre partie de l'algorithme de base de Google et qu'il est de nature beaucoup plus granulaire. Cela signifie que même dans le pire des cas, vous ne devriez pas trouver l'ensemble de votre domaine pénalisé. Mais si c'est le cas, vous devriez pouvoir récupérer beaucoup plus rapidement car vous n'avez pas à attendre plusieurs mois pour le prochain rafraîchissement de l'algorithme.

De plus, Google a appris assez rapidement que certains contenus dupliqués étaient acceptables, en particulier lorsqu'ils s'adressaient à différents utilisateurs dans différents pays. Dans cet esprit, en décembre 2011, il a introduit l'attribut hreflang afin que vous puissiez indiquer à Google qui devrait voir quelle version de votre contenu provient de la recherche Google.

NOTRE PREMIÈRE ÉTAPE EST MAINTENANT TERMINÉE

Nous ne pouvions donc pas passer directement de notre configuration précédente à la configuration de nos rêves pour diverses raisons techniques et liées aux ressources. Au lieu de cela, nous avons fait quelques pas de bébé en cours de route. À l'heure actuelle, pour la majorité des marques avec lesquelles nous travaillons, nous avons mis en place les domaines suivants :

https://brandwebsites.com
https://uk.brandwebsites.com
https://au.brandwebsites.com
https://ca.brandwebsites.com
https://fr.brandwebsites.com
https://de.brandwebsites.com
https://brandwebsites.es
https://brandwebsites.gr

Comme vous pouvez le constater, il existe un mélange de sous-domaines sur le domaine gTLD .com et les ccTLD. Au fur et à mesure que nous acquerrons des ccTLD, nous passerons du sous-domaine au ccTLD pour standardiser notre configuration sur les ccTLD, avec d'autres avantages potentiels à l'esprit que nous aborderons plus tard.

Depuis la fin de cette migration au début de 2017, nous avons mis à jour nos plans de site et nous nous sommes assurés que les nouveaux domaines sont correctement configurés dans les outils Google et Bing pour les webmasters. Nous avons également mis en place des redirections permanentes (301) afin que le trafic qui atterrit dans les anciens emplacements ne soit pas simplement perdu et que nous conservions une partie de la valeur des autres sites Web renvoyant aux pages de l'ancienne configuration.

Depuis le 6 février 2017, nous avons également publié des modifications de serveur concernant la manière dont nous gérons la redirection depuis « www. ». à 'non-www.' domaines, ainsi que des changements dans la manière dont nous nous assurons que tout le trafic est sécurisé et redirige vers https://.

Parallèlement à ces modifications, nous mettrons également à jour le fichier robots.txt de chaque site afin d'indiquer clairement le nouvel emplacement du sitemap et d'éviter les problèmes courants tels que l'indexation des pages de résultats de recherche sur certains sites Web de marques.

QUELLES AUTRES OPTIONS AVONS-NOUS ENVISAGEES ?

Au cours du processus de prise de décision pour notre nouvelle configuration, nous avons eu plusieurs options à considérer :
Domaines spécifiques à un pays, par exemple https://brandwebsites.es
Sous-domaines sur un gTLD, par exemple https://fr.brandwebsites.com
Sous-répertoires sur un gTLD, par exemple https://brandwebsites.com/el/
Notre configuration actuelle, par exemple comme exemple 3 mais sans site au niveau racine, par exemple https://brandwebsites.com/us/
Paramètres d'URL, par exemple https://brandwebsites.com?lang=de

Pourquoi n'avons-nous pas conservé la configuration actuelle ?

Nous avons tout de suite abandonné notre configuration actuelle, car ne pas avoir de site au niveau racine a causé une variété de problèmes :

• Les utilisateurs étaient fréquemment redirigés du domaine de niveau racine vers un sous-répertoire de langue, ce qui ralentissait leur temps de chargement. Cela a été causé par un mélange d'anciens liens internes, de liens externes sans dossiers de langue ou d'utilisateurs visitant directement le domaine via le navigateur.
• Google s'attend à ce qu'un site Web existe au niveau racine. En fait, les classements de marque du site s'affichaient dans Google sous la forme https://brandwebsites.com même si aucune page n'existait ici. Nous ne lui facilitions pas la tâche et cela se reflétait dans les classements de marque pour le site américain de plusieurs de nos marques.
• La vérification d'un domaine nécessite souvent qu'un tag apparaisse sur la page d'accueil ; cela peut être en utilisant la configuration des outils sociaux ou de webmaster. Alors que nous pouvions contourner certains en validant en utilisant une autre méthode telle que les entrées DNS, avec d'autres nous ne le pouvions pas et cela nous a causé des problèmes d'intégration sociale.
• Nous confondions le ciblage par langue et par pays et rendions les choses plus difficiles que nécessaire pour les utilisateurs. Par exemple, notre répertoire espagnol a été défini sur les paramètres régionaux es_ES alors qu'une grande partie du trafic provenait en fait d'utilisateurs espagnols au Mexique (es_MX). Il s'agissait de définir hreflang="es_ES", alors que hreflang="es" pour couvrir tous les pays hispanophones aurait peut-être été plus efficace pour le référencement. Mais cela créerait ses propres problèmes avec la personnalisation du panier en termes de drapeaux locaux et de fournisseurs d'expédition.

En termes simples, nous devions pouvoir personnaliser le site en fonction de l'emplacement de l'utilisateur, nous devions donc séparer le ciblage par langue et par pays.

Avec ces quatre points à l'esprit, nous avons pu instantanément abandonner notre configuration actuelle et rechercher des alternatives qui nous apporteraient le niveau de flexibilité dont nous avions besoin.

Paramètres d'URL - pourquoi sont-ils une mauvaise idée ?

La prochaine option évidente que nous ne voulions même pas envisager était la configuration des langues en tant que paramètres d'URL. La raison évidente en est que vous ne pouvez tout simplement pas cibler géographiquement les langues distinctes dans les outils pour les webmasters.

De plus, il est extrêmement difficile pour les utilisateurs de reconnaître le site Web et d'atterrir manuellement sur le bon domaine, et nous avions également des inquiétudes quant à la maintenance du site linguistique sur lequel se trouvait un utilisateur et à la gestion efficace des liens internes.

Il existe certaines situations où les paramètres d'URL peuvent fonctionner, mais cela a tendance à être lorsque vous êtes moins préoccupé par le référencement et que vous filtrez manuellement le trafic de la page de destination. Par exemple, les sites Web entièrement alimentés par le trafic des affiliés qui n'attendent pas grand-chose pour prendre en charge le trafic SEO peuvent prospérer avec une configuration de langage de paramètre d'URL.

Pesant les options restantes - quels étaient les avantages et les inconvénients ?

Il nous restait donc trois options disponibles à considérer :

1. Domaines spécifiques à un pays
2. Sous-domaines sur un gTLD
3. Sous-répertoires sur un gTLD

Chacune de ces options a ses propres avantages et inconvénients, et je tiens à préciser qu'il n'existe pas de solution parfaite. Alors que les référenceurs du monde entier seront très probablement les partisans de l'une de ces options par rapport à toutes les autres, il s'agit d'un choix complètement situationnel qui nécessite la prise en compte de plusieurs facteurs :

• L'impact sur les ressources de votre équipe de marketing numérique
• Le coût de mise en place et de maintenance de la solution
• Comment l'expérience utilisateur est impactée
• L'impact potentiel sur les moteurs de recherche

Ces facteurs peuvent être décomposés en plusieurs éléments qui doivent être pris en compte pour chaque option et le tableau ci-dessous les résume. Cependant, gardez à l'esprit que la valeur de ces éléments pour votre site Web ou votre organisation est quelque chose de complètement personnel à votre situation.

L'importance de ces douze éléments varie considérablement selon votre situation. C'est pourquoi, en fin de compte, il n'existe pas de solution unique pour le ciblage par langue et par pays. Il s'agit plutôt d'une question de jugement qui nécessite une réflexion approfondie, car votre décision aura un impact sur votre site Web et sur la capacité de le modifier pour les années à venir.

NOS CONCLUSIONS

D'un point de vue purement SEO, il existe des risques associés à la séparation d'un site en plusieurs domaines, et le plus grand d'entre eux est l'effet inconnu de plusieurs domaines sur les backlinks. Cependant, Google est devenu beaucoup plus granulaire dans la façon dont il traite les liens, il serait donc sage de conclure qu'il accorde une plus grande attention aux liens locaux spécifiques à une niche lors de la détermination des classements dans un pays spécifique.

Mais les avantages CRO du changement l'emportent sur les risques liés à tout travail de référencement supplémentaire requis pour assurer les classements. L'utilisation de domaines pour cibler un pays et la séparation du ciblage linguistique et géographique permettent une approche beaucoup plus précise du ciblage des utilisateurs du site.

De plus, la séparation présente certains avantages en termes de référencement, car elle permet d'éviter certains des problèmes que nous avons rencontrés avec le mauvais classement des sites de pays dans un emplacement spécifique. Par exemple, nous avons assez fréquemment vu le site principal en anglais américain se classer à la place de la version localisée, par exemple, le dossier /can/ au Canada. Cela nous aidera également à l'avenir à accélérer le site dans des pays spécifiques, où la demande est jugée suffisamment importante, en hébergeant des domaines sur des serveurs distincts et spécifiques à l'emplacement.

De nombreuses organisations ont mis en place des domaines distincts spécifiques à un pays de la même manière que nous, y compris Google, Amazon et Wikipedia (sous-domaines). Étant donné que nos sites Web sont des sites de commerce électronique, cela en fait des candidats idéaux pour ce niveau de séparation nécessitant à la fois des variations de pays et de langue à adapter à l'utilisateur. De plus, le problème du contenu dupliqué peut être évité grâce à un balisage hreflang approprié et en tenant compte des conseils de Google sur le contenu dupliqué sur les sites internationaux.

QUE CE PASSE T-IL APRÈS?

Nous avons terminé la première phase de nos modifications des sites Web et nous cherchons maintenant à améliorer :

1. Balisage hreflang : à certains endroits, le plugin que nous utilisons semble causer des problèmes sans balises de retour. Cela signifie effectivement que tous les sites de variantes linguistiques et nationales ne se renvoient pas les uns les autres. Cela doit inclure une auto-référence avec la page liée à elle-même avec le balisage hreflang.
2. Développez les variations de langue une fois que nous avons un meilleur contrôle hreflang. Un exemple parfait de cela serait de créer une version canadienne-française du site, qui serait un sous-répertoire sur le domaine canadien. Nous pouvons également chercher à déplacer les variations de langue non spécifiées par défaut vers brandwebsites.com et avoir plusieurs langues sur le domaine, par exemple :
   1. <link rel=”alternate” href=”https:// uk.brandwebsites.com/ ” hreflang=”en-GB” />

   <link rel=”alternate” href=”https:// ca.brandwebsites.com/ ” hreflang=”en-ca” />

   <link rel=”alternate” href=”https:// au.brandwebsites.com/ ” hreflang=”en-au” />

   <link rel=”alternate” href=”https:// brandwebsites.com/ ” hreflang=”en-US” />

   <link rel=”alternate” href=”https:// brandwebsites.com/” hreflang=”en” />

   <link rel=”alternate” href=”https://brandwebsites.es/ ” hreflang=”es-ES” />

   <link rel=”alternate” href=”https://brandwebsites.com/es/” hreflang=”es” />

3. Plus de sites linguistiques avec des processus de paiement adaptés au pays, y compris des facteurs de confiance tels que les fournisseurs de livraison locaux et les drapeaux. Commencez également à examiner les tests fractionnés spécifiques à chaque pays, le cas échéant, car le comportement des acheteurs et les attentes UX varient à l'échelle mondiale.

Bien que ces informations n'aident pas directement nos affiliés dans le référencement international, elles devraient vous donner matière à réflexion lorsqu'il s'agit de créer votre propre site Web multilingue.