Voilà un sujet qui n’est pas passionnant mais qu’il convient de maîtriser si on intervient sur des sites qui ciblent plus qu’un pays ou qu’une langue, les HREFLANG.
En théorie, c’est simple, en pratique ça l’est aussi. Alors pourquoi tant de littérature et de crispation sur le sujet ? Car c’est une histoire de rigueur, de discipline et parfois de coopération entre une équipe de développeurs et un expert SEO qui ne se comprennent pas nécessairement. Tout ça mis bout-à-bout, augmente forcément le potentiel d’erreurs.
Plus récemment, j’ai aussi été consulté pour une entreprise de logiciels qui possède un site internet traduit dans 30 langues, et sur lequel j’ai remarqué quelques erreurs basiques et d’autres plus techniques qui étaient particulièrement dommageables puisqu’elles étaient responsables de contenus dupliqués et donc de positions perdues sur Google .
Alors, pour bien faire, je me suis dit que je rédigerai ce guide pour que les choses soient claires et vous offrir aussi une sorte de “checklist” quand vous réalisez un audit de référencement naturel d’un site multilingue ou multi-localisation (que j’appellerai multi-régionaux pour rester dans la sémantique employée par Google).
Je vais essayer de faire un guide exhaustif mais utile, sans nécessaire verbosité, et qui comprend la définition des balises HREFLANG et leur utilité réelle, les méthodes d’implémentation, les erreurs les plus courantes et la fameuse checklist .
Quand utiliser les balises hreflang ? Commençons par le commencement car on lit un peu tout et n’importe quoi.
Du fait de mon expérience, et pour éviter d’ajouter de la complexité sur des projets internationaux, je me base sur l’expérience que je souhaite offrir à l’audience . C'est-à-dire que si mon site n'offre qu’une unique expérience à l’entièreté du monde, je ne me pose pas la question. C’est le cas d’un blogueur qui ne veut pas proposer de version traduite de son site, ou encore d’une startup qui a développé un SaaS dans une seule langue et ne se repose pas sur le SEO pour gagner ses clients.
En revanche, je recommanderai l’utilisation de hreflang si vous devez (ou souhaitez) offrir plusieurs expériences pour les raisons suivantes :
Besoin de traduire dans la langue de l’audience pour améliorer l’engagement ; Nécessité d’adapter des contenus à des spécificités régionales ; Obligation d’adapter des éléments légaux selon l’audience et le pays ciblé. Dans l’exemple ci-dessus, j’indique que le document “/fr/ma-page-francophone” est à servir à tous les pays francophones à l’exception de la Belgique qui a sa propre page “/fr-be/ma-page-belge-francophone”. Cela permet aussi d’indiquer aux moteurs de recherche que bien que ces deux pages aient probablement un contenu quasi-identique, elles ne sont pas dupliquées puisqu’elles ne s’adressent pas à la même audience .
3 exemples pour comprendre :
Exemple 1 : Je suis un e-commerce Français qui souhaite me lancer en Italie, et je sais qu’une stratégie SEO pourra me ramener des clients. Je me décide donc à traduire mon site du Français vers l’Italien. J’aurais ainsi un meilleur positionnement SEO mais aussi un meilleur engagement de mon audience si mes pages sont en Italien. Nous sommes ici dans une situation multilingue et multi-régionale.
Exemple 2 : Je suis un e-commerce anglophone, mais je ne suis pas autorisé à utiliser certains arguments de vente au Canada comparé aux États-Unis. Nous sommes ici dans une situation monolingue et multi-régionale.
Exemple 3 : Par contre, je vends sur mon site anglophone un logiciel à destination de clients en France, en Allemagne, au Canada, bref partout dans le monde, je n’offre qu’une expérience unique à tous ces clients, dans ce cas je ne me contraint pas avec de l’implémentation de balises hreflang.
À noter que l’Europe possède de nombreuses lois notamment sur la protection des données et du consommateur qui font qu’il convient de plus en plus de faire des versions européennes puis une version “Rest Of the World ” (ROW) que l’on peut traduire en “reste du monde”.
Définition des balises hreflang en SEO Créé en 2011 par Google afin d’aider les webmasters à indiquer clairement aux moteurs de recherche quelles versions (pages) servir selon la langue et le pays, l’attribut hreflang s’est progressivement généralisé y compris à d’autres moteurs de recherche tels que Baidu, Yandex, Bing ou encore Yahoo.
Ainsi, la structure standard d’une balise hreflang est la suivante :
< link rel = ”alternate” hreflang = ”fr” href = ”https://www.domaine.com/fr/ma-page-francophone” />
< link rel = “alternate” hreflang = ”fr-be” href = ”https://www.domaine.com/fr-be/ma-page-belge-francophone” />
< link rel = ”alternate” hreflang = ”fr-ca” href = ”https://www.domaine-canadien.ca/ma-page-canadienne-francophone” /> Ce que vous retrouvez dans l’attribut hreflang est d’abord le paramètre de “langue” (“fr” pour français) puis le paramètre de “pays” (“be” pour Belgique ou “ca” pour Canada”).
À noter toutefois qu’une balise hreflang est un signal et non une directive et j’insiste là-dessus.
Un signal signifie que vous informez un user agent mais que celui-ci peut négliger votre information. Une directive (telle qu’une balise noindex) donne un ordre à un user agent .
Nota Bene : Je parle parfois de balise hreflang ou d’attributs hreflang. En réalité, hreflang est un attribut d’une balise link comme on peut le voir dans l’impression d’écran ci-dessous. Néanmoins, l'utilisation du terme “balise hreflang” étant prédominante, je me conformerai à l’usage et parlerai le plus souvent de balise hreflang.
Quatre concepts clés des balises hreflang Taxonomie des hreflang Comme vu dans l’exemple partagé plus haut, le paramètre de langue est toujours indiqué en premier pour des questions de logique et de facilité .
Quel est le plus simple pour cibler tous les pays francophones ? simplement indiquer l’attribut “fr”. Si le code pays devait toujours être indiqué en premier, vous devriez alors créer une version pour chaque pays francophone.
Second élément important dans la taxonomie, les URLs doivent être absolues et non relatives . C’est-à-dire que l’URL doit être complète et inclure le protocole, le sous-domaine, et le domaine.
Cela s’explique par le fait que les différentes versions d’une page n’ont pas besoin d’être sur le même domaine. Dans mon exemple ci-dessous de la version québécoise, le domaine est différent. En effet, l’attribut hreflang n’est pas limité à un seul domaine et peut effectivement inclure des liens vers d’autres domaines ou sous-domaines.
< link rel = ”alternate” href = ”https://www.domaine.com/fr/ma-page-francophone” hreflang = ”fr” />
< link rel = “alternate” href = ”https://www.domaine.com/fr-be/ma-page-belge-francophone” hreflang = ”fr-be” />
< link rel = ”alternate” href = ”https://www.domaine-canadien.ca/ma-page-canadienne-francophone” hreflang = ”fr-ca” /> Une simple erreur dans la taxonomie de vos hreflang peut en annuler les bénéfices.
Principe d’auto-déclaration La page francophone du produit A doit s’auto-déclaré dans les hreflang . C’est-à-dire être présente dans la balise hreflang.
Principe de réciprocité Les différentes versions de langue et/ou de région d’un même document (ou d’une même page si vous préférez) doivent chacune pointer les autres. C’est ce qu’on appelle des liens de renvoi .
Dans l’exemple ci-dessus, tout est correct. Ce qui signifie :
la page francophone du produit A inclut une balise hreflang vers la page germanophone du même produit A ainsi que la page italophone du produit A ; la page germanophone du produit A inclut une balise hreflang vers la page italophone du même produit A ainsi que la page francophone du produit A ; la page italophone du produit A inclut une balise hreflang vers la page francophone du même produit A ainsi que la page germanophone du produit A. Ainsi, si nous avions accès au code HTML de chacune de ces trois pages, il est probable que l’on retrouverait le code suivant :
< link rel = ”alternate” href = ”https://www.domaine.com/fr/produit-A-francophone” hreflang = ”fr” />
< link rel = “alternate” href = ”https://www.domaine.com/it/produit-A-italophone” hreflang = ”it” />
< link rel = ”alternate” href = ”https://www.domaine-allemand.de/produit-A-germanophone” hreflang = ”de” /> Maintenant, si je reprends l’exemple ci-dessus mais que nous sommes dans la situation suivante :
Vous constatez que la page germanophone inclut bien le lien vers la page francophone, mais la page francophone n’inclut pas celui vers la page germanophone. Ainsi, le principe de réciprocité n’est pas respecté à l’échelle du groupe (ensemble des différentes versions d’une page) ce qui remontera des erreurs et annulera aussi les bénéfices des hreflang…
Tout cela nous amène d’ailleurs au principe de parité.
Principe de parité Cela signifie qu’entre la page francophone de votre produit A et la page germanophone du même produit A, le core content est le même mais traduit en Allemand .
Bien évidemment, certains éléments peuvent être adaptés au contexte local tels que : la devise, les délais de livraison, les conditions de retour, et quelques arguments. Mais l’essentiel du contenu (la description du produit, les photos, les caractéristiques détaillées) doivent être les mêmes.
En revanche, si vous offrez un produit B en Allemagne que vous n’offrez pas en France, vous ne devrez pas inclure de lien vers une page produit B francophone puisque ce serait une erreur 404, et vous ne devrez pas inclure de lien vers la page produit A francophone car cela ne respecte pas le principe de parité.
Un autre exemple concerne notamment les retailers. La page qui liste vos boutiques en France, ne doit pas inclure de liens hreflang vers la page qui liste vos boutiques en Espagne. Il faut bien comprendre que les hreflang ne sont pas systématiques et reposent vraiment sur ce principe de parité .
Vous voyez venir la contrainte technique supplémentaire pour l’implémentation de hreflang ? Nous y venons juste après.
Comment implémenter les balises hreflang 1. Vérifier la pertinence d’implémentation des hreflang Je vous conseille d’implémenter les hreflang si :
Vous souhaitez offrir une expérience unique adaptée à la langue et/ou au pays ciblé ; Vous devez adapter, à la marge, votre contenu pour être en conformité avec des législations spécifiques à la région ciblée ; Vous avez la parité entre vos pages. Si vous avez déjà internationalisé vos sites et que vous avez des problèmes, comme la page anglophone des États-Unis qui récupère du trafic du Royaume-Uni à la place de votre page dédiée au Royaume-Uni, alors l’implémentation des hreflang est tout à fait indiquée.
2. Identifier vos cas d’usages en backoffice Si vous reprenez le principe de parité que j’expliquais plus haut dans cet article, vous comprenez qu’au-delà de l’implémentation des hreflang, il faut aussi gérer la logique de création et de gestion de ces hreflang.
Je vous mets quelques questions en-dessous qu’il est important de se poser pour être sûr que vous intégrez une solution avec la bonne logique :
Est-ce que toutes mes versions sont en 1-pour-1 ? En d’autres termes, une page dans une version de langue A aura-t-elle systématiquement son équivalent dans mes autres versions ? Comment gérer programmatiquement la création d’une page dans une langue qui n’aura pas son équivalent dans une ou plusieurs langues ? Quand je crée une page qui n’a pas d’équivalent ailleurs, dois-je inclure toutes les traductions avant la publication ? Comment gérer dynamiquement les hreflang avec les autres versions qui ne seraient pas publiées ? Quid de cette gestion si certaines de mes versions du groupe sont sur d’autres sous-domaines voire domaines ? Si je supprime une page sur une version, comment mettre à jour programmatiquement les hreflang des X autres versions ? Comment gérer programmatiquement la suppression des hreflang si je passe une page en noindex ? Si vous êtes dans une structure avec une équipe tech, je vous conseille d’avoir cette discussion avec eux afin de ne pas vous retrouver avec une version qui ne répond pas à vos besoins et annulent les bénéfices de la mise en place de hreflang.
Et si vous n’avez pas d’équipe tech et que vous optez pour une solution “sur-étagère” comme un plugin , pensez à bien vérifier ses fonctionnalités.
Une fois que vous avez bien identifié vos cas d’usage en back , parlons de l’implémentation des hreflang en front .
3. Choisir la bonne méthode d’implémentation Choisir la méthode d’implémentation va dépendre de deux facteurs :
Vos cas d’usage ; Votre stack technologique ; Vos compétences techniques ou celles de votre équipe. Sachez que si vous utilisez des CMS tels que Wordpress ou Webflow, vous pouvez normalement trouver des plugins qui pourront faire l’implémentation de manière systématique et automatique avec les avantages et inconvénients que cela procure (manque de flexibilité).
Méthode #1 : attributs hreflang dans la section <head> C’est la méthode la plus répandue et la plus accessible aux professionnels du SEO car nous avons souvent accès au code HTML de la section <head> de nos sites. En effet, c’est déjà dans cette section que vous retrouvez vos balises canonical par exemple ou encore vos balises title .
C’est aussi la méthode la plus simple pour pouvoir ensuite vérifier l’implémentation puisqu’il suffit d’inspecter le code depuis n’importe quel navigateur.
Ca commence à en faire des lignes de code pour les balises hreflang en plus dans la section head. C’est cette méthode que l’on retrouve la plupart du temps, y compris sur des sites qui fonctionnent avec des CMS type Wordpress.
Méthode #2 : sitemaps C’est une méthode qui a ses avantages notamment d’un point de vue technique. Elle est parfois plus simple à implémenter que la méthode du <head> et surtout cela permet de tout centraliser dans un seul emplacement, votre sitemap (ou vos sitemaps si vous êtes sur plusieurs domaines).
C'est ma méthode préférée quand celle-ci est réalisable techniquement car elle permet de :
Réduire la taille du fichier HTML d'une page puisque les balises ne sont pas incluses ; De rendre la gestion des hreflang indépendante des pages web elles-mêmes comme la logique peut être construite sur un micro-service à part ; Google crawl plus souvent les sitemaps que les pages, vous pouvez donc avoir une mise à jour de vos hreflang plus fréquentes ; Si votre site est construit en Javascript, vous éviterez le risque d'injecté un js qui soit cassé dans la section <head> de votre page web . Le choix de l'implémentation des balises hreflang dans le sitemap est avant tout un choix rationnel influencé par la technique. D'un point de vue purement SEO, la méthode sera aussi efficace que les autres.
La méthode du sitemap partage les mêmes principes de base à savoir la réciprocité et la parité comme vous le voyez ci-dessous :
Implémentation des balises hreflang en utilisant le sitemap (exemple fourni par Google) Méthode #3 : en-tête HTTP C’est une méthode à réserver exclusivement à vos ressources qui ne sont pas des documents HTML. Je pense notamment à des PDFs indexés par exemple.
En résumé Si cela est possible, essayez de vous cantonner à une seule méthode pour l’ensemble de vos pages. Google n’en recommande aucune particulière et saura s’adapter, mais rappelez-vous ce que j’ai dit au début de cet article : c’est une histoire de rigueur et de discipline. Ainsi, je vous recommande de vous faciliter la vie et de choisir une seule et unique méthode.
Cela dit, sachez que vous pouvez décider d’utiliser différentes méthodes selon différentes pages. Par exemple, vous pourriez utiliser la méthode <head> sur toutes les pages produits, et la méthode du sitemaps pour toutes les pages du blog. Si vous aimez faire les choses de manière compliquée ou si vous avez des contraintes techniques, c’est possible et pas dommageable.
En revanche, utiliser plus d’une méthode pour un même document en plusieurs versions est inutile.
4. Définir la taxonomie de vos balises Je rappelle les éléments clés de la taxonomie des hreflang :
Les pages correspondantes aux différentes versions d’un même document doivent être toutes reliées ensemble (principes de parité et de réciprocité) ; Chaque version doit s’auto-déclarer ; Vous devez obligatoirement spécifier le code langue ; Et si vous souhaitez ajouter le pays, celui-ci doit nécessairement être précédé du code langue ; Les URLs des versions doivent forcément être en format absolu et non relatif. Au sujet des codes, ceux-ci sont normés et très bien définis. Ils suivent la norme ISO 639-1 (ou ISO 3166-1) et vous les retrouverez dans ce document à jour intitulé : Liste des codes langue et codes pays pour les hreflang .
Concernant les codes pays, ceux-ci doivent se conformer à la liste de la norme ISO 3166-1 alpha-2 , que vous trouverez dans ce même document .
Je vous conseille de ne pas bâcler ce travail car il y a rapidement de petites subtilités. Par exemple, celui qui veut cibler le Royaume-Uni serait enclin à utiliser “uk”. Néanmoins, “uk” est le code langue pour l’Ukrainien. Le ciblage du Royaume-Uni se ferait via le code pays “GB” (oui je sais, la Grande-Bretagne et le Royaume-Uni sont deux entités géographiques différentes mais ce n’est pas moi qui décide des normes ISO).
Celui qui voudrait cibler l’audience francophone de Belgique et utiliserait “be-fr” ciblerait en fait les locuteurs du Biélorusse de France.
Le code “eu” n’est pas un code géographique qui permet de cibler l’Europe. Mais c’est un code langue qui permet de cibler les locuteurs Basques, et “br” est le code langue des Bretons mais aussi le code géographique pour le Brésil.
Enfin, un dernier conseil pendant que vous réfléchissez à l’architecture de vos hreflang et leur taxonomie, c’est d’y incorporer une langue “par défaut” . Ce qui signifie que si un internaute a un idiome qui n’est pas considéré dans votre liste de hreflang, vous lui affichez une version par défaut.
< link rel = ”alternate” hreflang = ”x-default” href = ”https://www.domaine.com/fr/ma-page-francophone” />
< link rel = “alternate” hreflang = ”fr-be” href = ”https://www.domaine.com/fr-be/ma-page-belge-francophone” />
< link rel = ”alternate” hreflang = ”fr-ca” href = ”https://www.domaine-canadien.ca/ma-page-canadienne-francophone” /> Si je reprends l’exemple ci-dessus, un internaute qui ne serait ni francophone Belge, ni francophone Canadien, serait renvoyé par défaut - d’où la notation "x-default” sur l’URL https://www.domaine.com/fr/ma-page-francophone.
5. “Recetter” l’implémentation C’est mon côté tech et product qui ressort. Mais si vous pouvez bénéficier d’un environnement de test dans lequel vous pouvez tester votre implémentation, faites-le. Vous pouvez utiliser n’importe quel crawler (OnCrawl, ScreamingFrog, etc.), pour vérifier la présence des hreflang et s’il n’y a aucune erreur.
Si vos différentes versions sont sur plusieurs domaines, vous pouvez aussi le faire. Vous devrez néanmoins sûrement faire un peu de data crunching , quelques vlookup, etc. Mais c’est faisable.
6. Déployer et surveiller Une fois que vous avez bien testé que l’implémentation en front était correcte, que côté back la solution choisie répondait bien à vos différents cas d’usage, vous pouvez alors déployer en production (et pas le vendredi soir avant le week-end bien entendu).
Après le déploiement, lancez de nouveau vos outils de crawl pour vous assurer que tout est resté correct entre l’environnement de recette et celui de production. Pensez notamment à relancer quelques crawls et à surveiller vos rapports depuis la Google Search Console pour être certains que vous n’avez implémenté de potentiels bugs avec votre déploiement.
Checklist : audit des hreflang Si vous souhaitez vérifier une page rapidement, je vous invite à télécharger mon extension chrome gratuite dédiée qui, en un clic, vérifie l’ensemble des éléments ci-dessous. Vous pouvez également utiliser d’autres solutions comme l’outil de test de Merkle .
Alors, quels éléments vérifiez quand on audite des hreflang ?
Au niveau page :
La page en question a une réponse 200 ; Elle est indexable ; Et possède une self-canonical . Au niveau du balisage hreflang de cette page :
La page s’auto-référence ; Les URLs sont absolues et non relatives ; Les codes langues et géographiques sont corrects ; Une version “par défaut” est implémentée avec la balise “x-default”. Au niveau d’un groupe de pages (plusieurs versions d’un même document) :
Le principe de réciprocité est respecté (la page A mentionne la page B, et la page B mentionne la page A) ; Le principe de parité est aussi respecté ; Les pages d'un même groupe sont bien indexable et en auto-canonicals . Trois erreurs peu courantes mais existantes Pour ne pas faire une répétition de ce qui est déjà présent dans la checklist , je me permets de partager trois erreurs que j’ai pu rencontrer dans ma carrière et qui sont plus rares.
Les problèmes causés par les redirections et les balises canonical dans l'implémentation des hreflang :
Si vos URLs hreflang redirigent vers une autre page ou si elles pointent vers des pages qui ont une balise canonical différente, cela peut créer de la confusion pour les moteurs de recherche et annuler les bénéfices des balises hreflang. Il est donc essentiel de s'assurer que les URLs spécifiées dans les balises hreflang sont directes (sans redirection) et que les pages ciblées possèdent une balise canonical qui pointe vers elles-mêmes.
La mise à jour des hreflang est d'ailleurs une composante à ne pas occulter lorsque vous préparez un plan de redirection avant une migration de site.
Redirections automatiques basées sur l'IP :
Une fausse bonne idée que je vois de plus en plus est la redirection automatique d'utilisateur basée sur l'IP et donc la localisation supposée de l'internaute.
Bien que cela puisse s'entendre du point de vue de l'expérience utilisateur, cela peut fortement nuire à l'expérience et à votre SEO. Les redirections forcées peuvent en effet empêcher les utilisateurs d'accéder à la version du site qu'ils souhaitent consulter et peuvent également poser des problèmes pour l'indexation par les moteurs de recherche.
Par exemple, le googlebot opère souvent depuis les États-Unis, y compris lorsqu'il souhaite explorer vos pages en France. Alors si vous redirigez automatiquement le bot vers vos pages anglophones il pourrait conclure que vos pages francophones ne sont en fait que des redirections et donc désindexés vos versions françaises.
Donc évitez la redirection automatique et offrez aux internautes une option pour changer de version du site plutôt que de les rediriger automatiquement si vous repérez une incohérence entre la langue demandée et la localisation.
Contenus dupliqués et expérience utilisateur :
Je souhaite également mettre en avant une autre erreur courante que j'ai rencontrée : si vos contenus sont strictement les mêmes dans une même langue mais ciblent différentes zones géographiques, il n’est pas nécessaire de mettre en place des hreflang .
Je rappelle un des aspects que j’ai expliqué au début de l’article, mais la création de différentes versions et leur “hreflang-isation ” n’a de sens que si les contenus doivent offrir des expériences différentes. Je vous invite à consulter cette vidéo de John Mueller élaborer sur cette problématique.
Partagez votre avis, vos questions, vos recommandations ci-dessous