Bien qu’il ait été introduit par Google il y a dix ans, de nombreux propriétaires de sites ont encore du mal à obtenir un hreflang correct. Souvent, cela est dû à des idées fausses courantes et aux vœux pieux des développeurs.

Dans 4 Reasons International SEO Fails, j’ai souligné les défis communs du contenu dupliqué des sites Web de l’ensemble du portefeuille et recommandé d’utiliser hreflang pour compléter les méthodes de ciblage géographique existantes.

Il peut également vous aider à lutter contre la cannibalisation du trafic par les sites dominants du marché.

Malgré le fait qu’il soit extrêmement efficace lorsqu’il est implémenté correctement, il semble toujours y avoir beaucoup de confusion autour de hreflang.

Les idées fausses peuvent entraîner la paralysie des sites quant à la manière de mettre en œuvre ; nous le voyons dans des recherches récentes qui montrent que 40% des principaux sites Web multinationaux n’utilisaient pas d’éléments hreflang et parmi ceux-ci, 58% l’utilisaient uniquement pour la page d’accueil.

Pire encore, beaucoup vont de l’avant et mettent en œuvre avec de graves erreurs.

Les propriétaires de sites sont confus par les déclarations implicites et littérales dans les conseils d’assistance quelque peu datés de Google et leurs interprétations par les blogueurs SEO populaires.

Donc, dans cet article, je vais tenter d’expliquer certaines de ces idées fausses qui doivent être clarifiées – et j’espère que cela ne confondra pas encore plus les choses.

Idée reçue 1 : Nous n’avons besoin que de Hreflang sur la page d’accueil du site

De plus en plus de sites n’ont implémenté hreflang que pour leurs pages d’accueil, dans de nombreux cas en raison de l’utilisation de plusieurs CMS pour gérer leurs sites. Cependant, cela rend le cross-tagging impossible.

Dans un cas, le professionnel du référencement l’implémentant uniquement sur la page d’accueil m’a dit que « Google est assez intelligent pour le comprendre – nous avons juste besoin de leur donner le modèle et ils comprendront ».

Malheureusement pour le client, Google ne l’a pas compris et affichait la mauvaise page sur les marchés locaux.

Clarification

L’élément hreflang doit être ajouté à toutes les pages qui ont une autre version linguistique ou qui sont inclus dans un sitemap XML et pas seulement des pages d’accueil.

Idée reçue 2 : nous n’avons besoin que d’Hreflang Point-Com Domaines

J’ai entendu cette excuse de la part d’équipes de développement qui ne peuvent pas développer de solution pour mapper des pages sur différents domaines de premier niveau.

Ils supposent qu’étant donné qu’ils utilisent des ccTLD comme .co.uk, le moteur de recherche devrait comprendre quel pays ils ciblent. (Consultez l’excellent article d’Eli Schwartz sur les ccTLD et leurs avantages pour en savoir plus.)

Malheureusement, l’interprétation des ccTLD par les moteurs de recherche n’est pas parfaite, et sur des marchés comme la Suisse et la Belgique qui ont plusieurs langues, Google peut afficher l’une des différentes variantes linguistiques.

Clarification

Je recommande de faire un test pour s’assurer qu’il est compris et qu’aucun autre site local n’est classé sur le marché.

S’il fonctionne très bien mais que d’autres pages du marché ne sont pas correctement classées, vous devez alors plaider en faveur de son implémentation sur tous les domaines.

Utilisez l’élément hreflang pour toute page qui a une alternative, quel que soit le domaine sur lequel elle se trouve. Bien que les ccTLD soient un signal de géolocalisation fort, ils n’indiquent pas la langue, ce qui fait de ccTLD et hreflang la combinaison parfaite pour lever l’ambiguïté.

C’est en fait l’une des meilleures raisons de gérer vos éléments hreflang avec des plans de site XML. Les outils Enterprise hreflang XML peuvent mapper les URL quel que soit le domaine sur lequel elles se trouvent.

Vous pouvez également héberger les plans de site XML pour tous les différents sites au même emplacement. Cela facilite grandement leur entretien.

Idée reçue 3 : Le X-Default ne peut être utilisé que sur la page d’accueil avec un sélecteur de pays

Quelques pros du référencement ont écrit que le x-default ne doit être utilisé que lorsque vous avez une page d’accueil qui a un sélecteur de pays et ne doit être utilisé que sur cette page. Ce n’est que partiellement vrai.

Il existe deux applications spécifiques de x-default.

Clarification

Le premier s’applique aux sites avec des sélecteurs de langue/emplacement forcés comme FedEx ou Ikea. Ces sites présentent une page d’accueil avec un sélecteur de langue et/ou de pays demandant au visiteur de choisir l’emplacement et/ou la version linguistique du site qu’il souhaite visiter.

Étant donné que cette page ne cible pas de langue ou de pays spécifique, x-default indique aux moteurs de recherche de présenter cette page sur n’importe quel marché qui n’a pas de page assignée.

Là où les pros du référencement se trompent, c’est sur la façon de gérer les plus anciennes et les grandes multinationales, en particulier celles des États-Unis, qui utilisent souvent le site dot-com principal à la fois comme site mondial et comme site américain.

Dans cette situation, ils doivent également utiliser x-default.

Un bon exemple est Cisco, qui n’a pas de version américaine dédiée de son site. Étant donné que ces pages ont une double fonction, pour en faire à la fois les URL préférées pour le reste du monde et les définir pour les États-Unis, elles doivent ajouter une double entrée à leur hreflang pour définir la même page en x-default et en anglais américain. , similaire à l’exemple ci-dessous.

Idée reçue 4 : EU, LA et ME ne sont pas des codes ISO régionaux valides pour les éléments hreflang

Certains sites ont défini leur site régional LatAm sur « es-la » en espérant que Google interpréterait « la » comme l’Amérique latine alors qu’il s’agit en fait du code de pays du Laos.

De même, le code de pays « moi » de la Macédoine est utilisé à tort pour les sites régionaux du Moyen-Orient.

Votre entrée indique que les sites sont destinés à ces régions linguistiques spécifiques.

Clarification

Malheureusement, il n’y a pas d’options où vous pouvez utiliser un code de pays pour représenter une région, ou le code d’une « région économique » représente le groupe de pays et de langues représentés par leur appartenance.

Votre seule option est d’utiliser la recommandation ci-dessous pour la gestion des sites régionaux.

Idée reçue 5 : les sites régionaux ne peuvent pas utiliser un élément Hreflang

Les sites régionaux sont l’approche à budget limité pour cibler plusieurs pays dans une région à l’aide d’un site en une seule langue.

Les plus courantes de ces régions sont APAC pour les pays d’Asie-Pacifique, LatAM pour les pays d’Amérique du Sud et centrale ou MENA couvrant les pays arabophones du Moyen-Orient et l’Afrique du Nord.

Clarification

Le hreflang peut être utilisé sur un site régional de plusieurs manières.

La première consiste à définir le site régional sur une langue commune dans la région.

Cela se fait généralement avec un site en langue arabe ciblant la région MENA. Dans l’exemple ci-dessous, ils définissent le site régional comme site préféré pour les marchés de langue arabe.

Une autre façon pour les entreprises d’utiliser l’élément hreflang consiste à baliser la même page pour plusieurs pays.

Les sites le font souvent lorsqu’ils ont déjà un site dans la langue désignée, plusieurs sites locaux dans la même langue et souhaitent que cette version apparaisse sur des marchés spécifiques plutôt que la version x-default ou la version linguistique.

Dans cette approche, l’élément serait répertorié pour chacun des marchés linguistiques que vous ciblez. Google a indiqué qu’il est acceptable de référencer le même site plusieurs fois pour différents marchés linguistiques, mais ne devenez pas fou avec cela.

Idée reçue 6 : Pour enregistrer des lignes de code, ajoutez plusieurs codes à la syntaxe Hreflang=

J’ai vu cela plusieurs fois, en particulier dans les balises hreflang ajoutées aux pages.

Le propriétaire du site m’a dit que le professionnel du référencement qui l’avait mis en œuvre avait été informé par Google qu’il pouvait réduire le nombre d’entrées de plan de site XML ou de lignes de code en ajoutant plusieurs codes de pays et de langue à la syntaxe.

<xhtml:link rel=”alternate” hreflang=”es-ES;fr;fr-BE;fr-CH;pt;it;it-CH;de-CH;de-AT;de;en-GB;en; fr-BE”

Clarification

Non, cela ne fonctionne pas.

La documentation de Google indique très clairement que vous devez créer un élément hreflang distinct pour chaque URL. Si hreflang n’est pas déployé correctement, il sera simplement ignoré.

Idée reçue 7 : vous devez définir votre Rel=Canonical sur le site global

Il s’agit d’un énorme malentendu et cela supprimera vos pages en langue locale presque aussi rapidement que de les bloquer avec une entrée robots.txt.

C’est l’une des plus grosses erreurs que les entreprises commettent en matière de hreflang, à l’exception des codes de pays et de langue incorrects.

La plupart font cette suggestion dans le contexte de la suppression du contenu en double. L’élément hreflang le fait essentiellement pour vous.

Si vous avez un site de commerce électronique pour le Royaume-Uni avec des prix en livres sterling qui est un doublon de contenu du site américain en dollars américains, vous devez utiliser le hreflang pour les séparer.

Ne bloquez pas le site britannique car cela pourrait avoir un impact significatif sur les ventes sur le marché local.

Clarification

Le rel=canonical doit pointer vers la page en langue locale sur laquelle il se trouve et ne pointer jamais vers une autre page à moins que vous ne vouliez que la page soit bloquée.

Si tel est l’objectif, il n’est pas nécessaire qu’une balise hreflang soit sur la page.

Par exemple,

Idée fausse 8 : Vous pouvez combiner des balises hreflang et canoniques

C’est une autre erreur que je vois fréquemment, où les développeurs essaient de combiner l’élément hreflang canonique et l’élément hreflang auto-référencé en une seule balise.

Dans ce cas, il s’agissait de la page pour l’Irlande en anglais.

Clarification

Le rel=canonical doit être sa propre entité, tout comme l’élément hreflang de la page.

Vous ne pouvez en aucun cas les combiner. Une entrée correcte ressemblerait au code ci-dessous.

Idée fausse 9 : Le Rel=Canonical peut servir d’entrée d’auto-référence

Je n’ai pas réussi à trouver la source de ce petit bijou d’information, mais c’est complètement faux. Même ainsi, de nombreux professionnels du référencement l’utilisent encore.

Si votre site contient un grand nombre d’erreurs de non-auto-référencement dans Google Search Console, cela est généralement causé par les propriétaires de sites qui tentent de faire en sorte que l’élément canonique fasse double fonction en tant qu’élément d’auto-référencement.

Voici un exemple de cette erreur lors du référencement de la page espagnole de l’Argentine.

Site Argentine – https://www.mysite.com/ar/

Site irlandais – https://www.mysite.com/ie/

Clarification

Ceci est incorrect et vous devez utiliser un élément hreflang pour l’élément auto-référençant.

Par exemple, si les balises hreflang se trouvent sur les pages locales, elles devraient ressembler à ceci.

Site Argentine – https://www.mysite.com/ar/

Site irlandais – https://www.mysite.com/ie/

Idée fausse 10 : Vous ne pouvez pas utiliser HREFLang avec les domaines ccTLD et Dot-Com

Il s’agit d’une idée fausse relativement nouvelle qui se produit avec les sites de commerce électronique multinationaux à croissance rapide.

On leur a dit que la mise en œuvre de hreflang n’était pas possible en raison de l’utilisation de plusieurs configurations de domaine, notamment des ccTLD, des domaines Dot-Com et des dossiers ou sous-domaines de langue pour représenter des sites de marché ou de langue spécifiques.

Clarification:

S’il est vrai que votre CMS ou votre plate-forme de commerce électronique peut ne pas être en mesure d’ajouter des balises hreflang aux pages en dehors de la configuration principale, cela ne signifie pas que hreflang n’est pas possible.

Les entreprises ont résolu ce défi en utilisant des sitemaps XML hreflang générés indépendamment du système et hébergés sur un emplacement central, puis ont utilisé la méthode de validation XML intersite via Google Search Console pour authentifier la propriété.

Conclusion

John Mueller de Google a déclaré que le hreflang est l’un des problèmes techniques les plus complexes auxquels les professionnels du référencement doivent faire face. Les éléments abordés dans cet article aident à soutenir l’affirmation selon laquelle hreflang est complexe, mais ce n’est pas obligatoire.

Malheureusement, une grande partie de la complexité perçue de hreflang provient d’interprétations incorrectes du fonctionnement réel de hreflang et d’infrastructures de sites Web mondiales trop complexes.

Avant de vous attaquer à votre implémentation hreflang, prenez un moment pour réfléchir aux problèmes que vous essayez de résoudre et si l’une de ces modifications entraînera de nouveaux problèmes.

Commencez par de petites sections de votre site, en particulier celles qui utilisent la même langue, et travaillez à partir de là. Même une mise en œuvre partielle de hreflang peut réduire la cannibalisation du trafic, l’abandon de panier et augmenter les revenus du marché local.

Davantage de ressources:

  • Une introduction au référencement international
  • Un guide rapide pour démarrer dans le référencement international
  • Sous-domaine vs sous-répertoire vs ccTLD : quel est le meilleur en 2018

Image en vedette : Shutterstock/Studio Minerva

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici