En 2021, j'ai hérité d'un site e-commerce de 14 000 pages d'un client dont l'agence précédente avait « fait le SEO international ». Trois semaines dans un audit, j'ai trouvé 31 000 erreurs hreflang dans Google Search Console. Trente et un mille. Le site avait sept variantes linguistiques et chaque page manquait sa balise d'auto-référencement. Les pages allemandes pointaient vers des URLs en français. Le x-default pointait vers une URL qui faisait un 301-redirect ailleurs complètement. Le trafic organique des marchés non-anglophiles avait stagné pendant huit mois et personne n'avait fait le lien.
Ce projet est probablement la plus grande raison pour laquelle je traite maintenant l'implémentation hreflang comme un problème d'ingénierie de première classe, pas un pis-aller qu'on ajoute lors d'un sprint de traduction.
Alors rentrons dans le vif du sujet correctement.
---
Ce que hreflang Fait Vraiment (et Ce Qu'il Ne Fait Pas)
Je vais rester bref car la plupart d'entre vous ont déjà une idée générale. hreflang est un attribut HTML (ou un en-tête HTTP, ou une entrée de sitemap XML) qui indique à Google quelle version d'une page correspond à quelle combinaison de langue et de région. Cela ne change pas directement les classements. Cela change l'URL que Google affiche à quel utilisateur dans quel pays.
C'est tout. C'est un signal, pas une directive. Google peut l'ignorer si l'implémentation est cassée ou contradictoire. Et c'est ce qu'il fait. Régulièrement.
Ce qu'il ne fait pas : il ne bloque pas les utilisateurs d'accéder à la mauvaise version régionale, il ne remplace pas votre stratégie de contenu, et il ne compense absolument pas les pages traduites minces qui ne sont que des copies générées par machine sans effort de localisation.
Avant tout, il vaut la peine de lire la documentation officielle de Google sur hreflang. C'est aussi sec qu'un biscuit rassis mais c'est exact.
---
Les Cinq Erreurs Que Je Vois Sur Presque Chaque Audit
Tags Auto-Référencés Manquants
C'est le gros problème. Chaque page d'un cluster hreflang doit inclure un tag pointant vers elle-même. Pas seulement les autres variantes. Elle-même.
Si votre page anglaise à example.com/en/product/ a des tags pointant vers /de/product/ et /fr/product/ mais oublie le hreflang="en" pointant vers /en/product/, tout le cluster est techniquement invalide. Google ne lèvera pas nécessairement une erreur critique mais il réduira sa confiance dans l'ensemble du signal.
J'ai vu cette erreur sur des sites développés par des développeurs qui ont lu un article de blog, vu un exemple avec deux variantes, et n'ont jamais remarqué le tag auto-référencé parce que l'exemple était mal écrit. Je ne nomme personne.
Les balises de retour sont manquantes ou cassées
hreflang est une relation bidirectionnelle. Si votre page en anglais pointe vers votre page en allemand, la page en allemand doit pointer en retour vers la page en anglais. Si vous manquez cette balise de retour, Google voit une poignée de main brisée.
Sur le projet de 2021 dont j'ai parlé, un développeur avait ajouté hreflang uniquement dans le modèle anglais. Les modèles allemand, français et espagnol n'avaient pas du tout de hreflang. Google recevait donc la moitié d'une conversation et sensément l'ignorait complètement.
Mauvais codes de langue
Utilisez les balises de langue BCP 47. Cela signifie en pour l'anglais de façon générique, en-GB pour l'anglais britannique, en-US pour l'anglais américain. Pas en_GB. Pas english. Pas ENG.
J'ai trouvé lang="english-uk" sur un site fintech que nous avons audité chez Seahawk l'année dernière. Le développeur avait clairement deviné le format. C'était en ligne depuis 14 mois.
x-default est soit manquant, soit incorrect
x-default doit pointer vers une page qui gère les utilisateurs dont la langue ou la région ne correspondent à aucune de vos autres variantes. Généralement votre page d'accueil ou une page de sélection de langue. Ce n'est pas simplement un synonyme de « version anglaise ». J'ai vu x-default pointer vers une URL qui renvoyait un 404, pointer vers une chaîne de redirection, et une fois, mémorабlement, pointer vers un environnement de staging.
Si vous n'avez pas de page de secours sensée, il est en réalité préférable d'omettre x-default que de l'utiliser incorrectement. Mais généralement vous devriez en avoir une.
Utiliser canonical et hreflang incorrectement ensemble
Votre balise canonical et vos balises hreflang ne doivent pas se contredire. Si /en-gb/page/ possède une canonical pointant vers /en/page/, mais déclare aussi une hreflang pour en-GB, vous avez créé un conflit de signaux. La canonical dit effectivement « je ne suis pas la version préférée de cette URL » tandis que hreflang dit « je suis la version préférée pour les utilisateurs d'anglais britannique ». Google doit choisir une interprétation et souvent il ne choisit ni l'une ni l'autre.
---
Comment l'implémenter sur de grands sites sans perdre la tête
Au niveau des modèles versus au niveau des pages
Sur un site de 50 pages, vous pourriez créer manuellement chaque balise hreflang. Sur un site de 5 000 pages, c'est impossible. Vous devez les générer programmatiquement.
L'approche la plus simple que j'ai trouvée consiste à stocker vos mappages d'URL dans une source de données structurée (une table de base de données ou même un fichier JSON plat pour les petits projets) et générer les balises au moment du rendu. Sur WordPress, Yoast SEO et Rank Math gèrent tous les deux cela correctement pour les configurations standard, mais tous les deux échouent quand vos structures d'URL diffèrent selon les langues au lieu de suivre un schéma prévisible du type /en/, /de/, /fr/.
Si vos URL ne sont pas uniformes (par exemple, des slugs traduits comme example.com/en/running-shoes/ et example.com/de/laufschuhe/), vous avez besoin d'une table de mappage explicite. Aucun plugin ne le déduira automatiquement. J'ai appris cela à mes dépens auprès d'un client du secteur du sportswear en 2022 dont les slugs traduits étaient complètement indépendants des anglais.
Méthode du sitemap XML
Pour les très grands sites, je préfère la méthode du sitemap XML aux balises HTML en ligne. Elle garde le <head> propre, c'est plus facile à vérifier programmatiquement, et vous pouvez mettre à jour le sitemap sans toucher aux modèles de page.
Le format ressemble à ceci (conceptuellement, sans bloc de code) : chaque bloc <url> contient plusieurs entrées <xhtml:link>, une par variante de langue y compris la référence à soi-même. La déclaration d'espace de noms xmlns:xhtml doit être présente dans l'élément <urlset> sinon le tout s'arrête silencieusement.
Un point important : la méthode du sitemap ne fonctionne que si Google a récemment crawlé et indexé vos sitemaps. Si vous avez des problèmes de budget de crawl sur un grand site, la méthode HTML est plus fiable car Googlebot lit les balises en ligne à mesure qu'il crawle chaque page.
En-têtes HTTP pour le contenu non-HTML
Vous avez des PDF ou d'autres fichiers non-HTML qui ont besoin de hreflang ? Utilisez les en-têtes HTTP. Votre serveur retourne un en-tête Link avec les attributs rel="alternate" et hreflang. C'est rare en pratique, mais j'ai vu des grands sites juridiques et financiers avec des milliers de documents PDF multilingues où cela compte vraiment.
---
Les outils qui aident vraiment
Écoutez, j'ai utilisé beaucoup d'outils au fil des années. Voici ceux sur lesquels je m'appuie vraiment :
- Screaming Frog SEO Spider : lancez un crawl, allez à l'onglet hreflang. Il signalera les balises de retour manquantes, les auto-références manquantes, les URL cassées et les codes de langue invalides tout en un seul endroit. C'est ma première étape pour chaque audit international. À £199/an, c'est le meilleur outil de SEO technique pour le rapport qualité-prix que je connaisse.
- Ahrefs Site Audit : une bonne vérification secondaire, surtout si vous voulez faire des recoupements avec les données de trafic organique dans la même plateforme.
- Outil de test des balises hreflang par Merkle : gratuit, sur https://technicalseo.com/tools/hreflang/. Collez une URL, il vérifie tout le cluster. Excellent pour vérifier rapidement des pages spécifiques en cours de correction.
- Google Search Console : le rapport Ciblage international sous Legacy Tools. Lent à se mettre à jour, mais c'est la source de vérité pour voir comment Google lit réellement votre implémentation.
- Sitebulb : si vous préférez un crawler visuel avec des rapports plus accessibles aux débutants, Sitebulb fait du bon travail pour visualiser les relations entre les clusters hreflang.
Ce que je n'utilise pas : les outils générateurs de hreflang qui produisent un bloc de balise statique à copier-coller. C'est correct pour apprendre la syntaxe. C'est inutile pour plus de 20 pages parce que vous revenez à la maintenance manuelle.
---
Auditing à l'échelle : un processus qui fonctionne
Voici le processus étape par étape que j'applique à chaque audit international, affiné après l'avoir fait sur 200+ sites multilingues :
- Crawlez le site avec Screaming Frog, en vous assurant que le rendu JavaScript est activé si le site utilise un framework JS.
- Exportez les données hreflang dans une feuille de calcul. Regroupez les URLs par cluster prévu.
- Vérifiez chaque cluster pour : la balise auto-référencée, les balises de retour de toutes les variantes, les codes BCP 47 valides, l'alignement canonique cohérent.
- Vérifiez les URLs x-default pour les codes de statut 200. Pas des 301. Des 200.
- Recoupez avec vos sitemaps XML si vous utilisez la méthode du sitemap. Chaque URL du sitemap doit retourner 200.
- Exécutez un échantillon de 20-30 pages via l'outil de test Merkle pour vérifier que Google lit vraiment ce que vous pensez qu'il lit.
- Extrayez le rapport Ciblage international de Search Console et recherchez spécifiquement les erreurs « Pas de balise de retour ». Ce sont presque toujours le symptôme de templates qui n'ont pas été mis à jour quand une nouvelle langue a été ajoutée.
- Corrigez, relancez un crawl dans 2 semaines, vérifiez que le nombre d'erreurs a baissé dans Search Console (cela peut prendre 4-6 semaines pour que les données GSC reflètent complètement les corrections).
Ce n'est pas un processus unique. Planifiez un crawl récurrent tous les trimestres dans votre calendrier. Les sites internationaux changent. De nouvelles pages sont ajoutées, les anciennes pages sont redirigées, et les clusters hreflang se cassent silencieusement quand personne ne regarde.
---
Quand ne pas utiliser hreflang
C'est oublié dans la plupart des guides et ça me rend fou.
Si vous avez une langue mais plusieurs régions (disons, UK et Australie tous deux en anglais), hreflang vaut le coup d'être utilisé mais seulement si le contenu est vraiment assez différent pour servir ces utilisateurs de façon distincte. Si vos pages UK et AU sont identiques à 95%, vous pourriez créer plus de confusion que de clarté. Google peut choisir de montrer une variante universellement et vos signaux hreflang seront largement ignorés de toute façon.
Si vous avez très peu de trafic provenant des marchés internationaux, passer une semaine à implémenter hreflang n'est peut-être pas le meilleur usage du temps. Une hiérarchie d'URL bien structurée avec des attributs <html lang=""> et les paramètres de ciblage géographique dans Search Console vous couvriront correctement jusqu'à ce que le volume de trafic justifie une implémentation complète.
Et si votre site est une application monopage avec chargement dynamique de contenu, commencez par corriger le rendu. J'ai vu hreflang implémenté parfaitement dans la coquille HTML statique tandis que le contenu réel de la page était rendu en JavaScript et Googlebot ne voyait qu'un spinner de chargement. Corrigez l'indexabilité avant de vous soucier des signaux d'internationalisation.
---
FAQ
Les balises hreflang affectent-elles directement les classements ?
Non. Les signaux hreflang indiquent à Google quelle URL servir à quel utilisateur, pas comment classer cette URL. Indirectement, afficher la bonne page au bon utilisateur réduit le pogo-sticking et améliore les métriques d'engagement, ce qui peut avoir un effet en aval sur les classements. Mais il n'y a pas d'amélioration directe du classement en ajoutant des balises hreflang.
Combien de temps faut-il à Google pour traiter les modifications hreflang ?
Généralement 4 à 8 semaines pour que les modifications se reflètent pleinement dans les données de Search Console. La fréquence d'exploration joue un rôle ici. Pour les grands sites avec des taux d'exploration lents, cela peut s'étirer jusqu'à 12 semaines. Ne modifiez pas et ne vérifiez pas les résultats le lendemain. Vous deviendrez fou.
Puis-je utiliser hreflang dans une boutique Shopify ?
Oui, mais l'internationalisation native de Shopify (via Markets) gère beaucoup de cela pour vous si vous utilisez des sous-dossiers ou des sous-domaines. Si vous utilisez des boutiques séparées pour différentes régions, vous devrez mettre en œuvre hreflang manuellement via une personnalisation de thème ou une application. J'ai utilisé les conseils SEO internationaux propres à Shopify comme point de départ ici. C'est raisonnablement complet.
Quelle est la différence entre le ciblage par langue et le ciblage par pays ?
Le ciblage par langue (par exemple, hreflang="es") dit : affiche ceci aux hispanophones quel que soit l'endroit où ils se trouvent. Le ciblage par pays (par exemple, hreflang="es-MX") dit : affiche ceci spécifiquement aux hispanophones au Mexique. Utilisez des balises langue uniquement quand votre contenu est le même pour tous les locuteurs de cette langue. Utilisez des balises langue-pays quand les prix, la devise ou le contenu important diffèrent selon la région.
Mes erreurs hreflang ont augmenté après les avoir corrigées. Pourquoi ?
Généralement parce que corriger certaines balises a poussé Google à crawler vos pages plus agressivement, et il trouve maintenant des erreurs qu'il ne rapportait pas auparavant. C'est un artefact de rapportage, pas un signe que les corrections ont empiré les choses. Continuez, relancez un crawl dans 4 semaines.
---
Hreflang est vraiment l'une de ces choses où obtenir 90% de juste est presque aussi mauvais qu'obtenir 0% de juste. Les signaux cassés créent du bruit auquel Google apprend à se méfier. Prenez le temps de faire correctement, auditez régulièrement, et traitez-le comme l'infrastructure qu'il est. Votre trafic organique international vous remerciera silencieusement, c'est la meilleure sorte de remerciement.