Dans un article publié sur le blog officiel des Webmasters de Google datant du 28 janvier 2015, il est précisé que que toutes les variantes de contenu des pages avec des paramètres régionaux ne soit pas indexé parce que je cite : “par défaut Googlebot accède à des pages sans définir d’en-tête de requête http Accept-language et utilise des adresses IP qui semblent se trouver aux Etats-Unis” (!). L’occasion pour nous de revenir sur le sujet multilingue puisque les balises hreflang sont parfois un réel problème pour WordPress. Peut-être avez-vous remarqué que cette balise paraît important dans le GWT de Google ? Pour un site bénéficiant d’un nom de domaine à l’extension .fr, Google déduit automatiquement que le contenu produit est français, c’est un petit avantage sur les noms de domaines génériques. Cela dit, si vous avez deux versions de langues, et plus a fortiori, vous aurez besoin de préciser les choses. Nous avons déjà vu via WPML qu’il existe des outils performants pour traduire et préciser cet aspect dans les sites multilingues de WordPress. Mais il existe des solutions alternatives pour la création de votre site Internet. Quand est-il vraiment ?
La balise hrflang dans le header de WordPress, mais comment ?
Avant tout, une petite vidéo de Google vous présente ce qu’il faut faire, ne pas faire et ce qui n’est pas optimisé en termes de référencement naturel mais accepté : Les paramètres régionaux sont à l’honneur. Plus simplement, il ne s’agit pas de traduire en anglais son site pour s’en satisfaire dans tous les pays anglophones. La langue anglaise a des distinctions sémantiques en fonction du pays dans lequel vous êtes et tous les pays anglophones n’ont pas la même monnaie non plus…
On peut placer les balises hreflang dans le balisage de page, dans le sitemap (notamment pur les sites de grande taille) ou dans les en-tête HTTP. La première des solutions pensées consiste à modifier votre <head> pour permettre d’afficher les fameux “rel” comme indiqué dans la page d’explications du support Webmaster de Google :
<link rel="alternate" href="http://monsite.com/fr-be" hreflang="fr-be" /> <link rel="alternate" href="http://monsite.com/fr-ca" hreflang="fr-ca" /> <link rel="alternate" href="http://monsite.com/fr-ch" hreflang="fr-ch” /> <link rel="alternate" href="http://monsite.com/fr" hreflang="fr" />
Les codes ci-dessus dans le cas où vous avez des contenus différents proposant une version française mais aussi une version suisse, belge, etc. Seulement voilà, par principe, les balises de ce type s’attachent à la page en question et il n’est pas question de proposer la même balise partout au risque de se voir expliqué par Google que vous n’avez “aucune balise de renvoi“. La solution passe donc par un usage similaire à celui des rel=canonical. D’ailleurs, dans les sites multilingues, on ne place les balises rel=canonical que si l’on place une balise hreflang. Où comment préciser que nous ne dupliquons pas le contenu, non jamais !
L’idéal consiste donc à utiliser un plugin spécifique pour proposer cela. Au rayon extensions de WordPress, plusieurs solutions s’offrent à vous. On peut retenir notamment Ceceppa Multilingua sur lequel on ne s’attarde pas et MCE Accessible Language Change, petite extension qui vous propose de mettre le lien concerné hreflang sur chacune de vos pages, à la main :
mais nous en avons retenu une qui permet cela plus facilement : WPML aux nombreuses fonctionnalités.
Pourquoi ? Parce qu‘il ne s’agit pas que de traduire les pages de votre site en plusieurs langues, il s’agit également de proposer du contenu différent en créant des pages spécifiques avec des liens traduits et un ensemble de chaînes de caractères également traduits. De plus vous pouvez avoir besoin de proposer un backoffice en langues différentes, WPML vous le propose. Et puis votre/vos balises Hreflang seront placées de manière automatique. De loin la solution la plus compatible avec tous les produits phares de WordPress, mais payant bien sûr.
Vous souhaitez utiliser cet outil pour votre site Woocommerce ? Un plugin existe également. Enfin, vous avez certainement besoin d’une solution compatible avec Yoast SEO, c’est également le cas.
Au final, nous avons un outil assez lourd et qu’il faut configurer de A à Z mais cela reste la solution la plus friendly Google.
Garder le même nom de domaine ou pas pour un meilleur référencement Google ?
Vous pouvez créer des sous-domaines de type en.monsite.com, un sous-répertoire comme monsite.com/en ou encore des solutions de type ccTLD (country-code top-level-domains) ou gTLD (generic top-level-domains). Clairement, Google préfère des versions du site dans des des langages locaux avec un même nom de domaine. Ceci peut poser de réels problèmes dans le cas de la création d’un multi site WordPress, fonctionnant avec sous-domaines et sous-répertoires. Dans le cas de domaines différents, tournez-vous au besoin vers la solution préconisée par WordPress Channel et le plugin Domain Mapping. Le tuto est très bien expliqué, comme toujours. C’est toutefois discutable sur le plan du référencement pour Google comme vous l’avez vu ci-dessus.
Ce qu’il faut retenir avec les balises hreflang
Il faut baliser l’ensemble des pages y compris l’accueil lorsque vous créez votre site Web pour permettre aux internautes de se retrouver aisément sur la page qui leur correspond, notamment lorsqu’ils vous trouvent dans les SERP de Google. On prendra soin d’affiner les contenus avec des éléments qui correspondent aux usages. L’exemple le plus parlant repris dans la vidéo est cette question des tarifs. Envisager un multilingue avec Woocommerce et proposer des prix en dollars en Grande Bretagne n’est pas concluant. Ce qui implique de paramétrer Woocommerce en fonction des pages.
Si vous utilisez une solution demandant à Google de prendre en compte les paramétrages locaux, n’oubliez pas d’indiquer la balise hreflang par défaut :
<pre><link rel=”alternate” hreflang=”x-default” href=”http://www.monsite.com/” /></pre>
Associez ensuite les autres balises régionales. Ces balises sont une demande pour Google, un signal qui n’est jamais une instruction, tout comme dans le cas de rel=canonical.
Pas de commentaire