Le symptôme qui amène les entreprises à ce sujet est presque toujours le même : elles ont une section japonaise, elle est indexée, et pourtant les internautes au Japon continuent d’atterrir sur la page anglaise. Il arrive même que la page anglaise devance la page japonaise sur une requête en japonais.

Le hreflang fait généralement partie de l’explication. Ce n’est pas toujours toute l’explication (une page japonaise que personne ne recherche ne se positionnera pas, quelle que soit son annotation), mais c’est la partie que l’on peut corriger de manière déterministe, et il vaut la peine de la corriger avant de tirer d’autres conclusions.

Ce que fait réellement le hreflang

Le hreflang ne fait pas se positionner une page. Il indique à Google que plusieurs URL sont des versions linguistiques ou régionales alternatives d’un même contenu, afin que, lorsque l’une d’elles est retenue pour un résultat, Google puisse lui substituer la version correspondant à la langue et à la localisation de l’utilisateur.

Deux conséquences découlent de cette définition, et la plupart des erreurs de hreflang viennent de l’oubli de l’une d’elles.

Premièrement, c’est un mécanisme de substitution, pas un levier de classement. Si votre page japonaise n’a aucune visibilité propre et que la page anglaise n’en a pas non plus, un hreflang correct ne change rien.

Deuxièmement, il fonctionne par clusters d’URL, et non par site. Chaque page a son propre cluster. /services/technical-seo/ et /ja/services/technical-seo/ forment un cluster ; les deux pages d’accueil en forment un autre. Un bloc d’annotations unique à l’échelle du site, pointant vers la page d’accueil de chaque langue et répété sur chaque page, est l’une des manières les plus courantes d’avoir du hreflang sans en tirer le moindre bénéfice.

ja ou ja-JP ?

La sous-étiquette de langue est ja. Pas jp. jp est un code pays (c’est lui qui apparaît dans .co.jp et dans ja-JP) et ce n’est pas une valeur de langue valide à elle seule. hreflang="jp" est invalide et purement et simplement ignoré. C’est l’erreur de hreflang la plus fréquente que nous rencontrons sur les sections japonaises, et comme les annotations invalides échouent silencieusement, elle peut rester en place pendant des années.

Entre ja et ja-JP, la réponse honnête est que ja convient à la plupart des sites.

  • ja signifie « cette page est destinée aux japonophones », où qu’ils se trouvent dans le monde.
  • ja-JP signifie « cette page est destinée aux japonophones au Japon », et exclut les japonophones qui naviguent depuis un autre pays.

N’utilisez la sous-étiquette de région que si vous avez réellement plusieurs versions en japonais différenciées par pays, par exemple une page ja-JP avec des tarifs japonais et une page ja-SG pour l’entité singapourienne. Si vous n’avez qu’une seule page japonaise, ja couvre tous ceux qui doivent la voir, y compris les japonophones en voyage ou vivant à l’étranger. Restreindre à ja-JP sans raison revient simplement à supprimer une audience.

Si vous utilisez une sous-étiquette de région, elle doit être un code pays ISO 3166-1 alpha-2, et la casse conventionnelle est ja-JP (la valeur n’est pas sensible à la casse, mais la cohérence facilite les audits).

La réciprocité, la règle sur laquelle tout achoppe

Chaque URL d’un cluster doit lister toutes les URL de ce cluster, y compris elle-même. Si la page A déclare la page B comme son alternative japonaise mais que la page B ne déclare pas la page A en retour, Google peut ignorer complètement l’annotation.

L’auto-référence est réellement obligatoire, et elle manque réellement souvent. La page japonaise doit inclure une ligne hreflang="ja" pointant vers elle-même, et pas seulement la ligne pointant vers l’anglais.

Pour un site avec un original en anglais et une version japonaise, le bloc identique apparaît sur les deux pages :

<link rel="alternate" hreflang="en" href="https://example.com/services/pricing/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/services/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/services/pricing/" />

Le moyen le plus fiable d’assurer la réciprocité est de cesser de la maintenir à la main. Générez le cluster à partir d’une source de vérité unique (un registre de pages qui sait dans quelles langues chaque page existe) afin que chaque page du cluster émette la même liste par construction. Un hreflang maintenu manuellement se dégrade dès que quelqu’un ajoute une page.

x-default

x-default désigne la page à afficher lorsqu’aucune autre version ne correspond à l’utilisateur. Il est facultatif, et souvent mal compris.

Faites-le pointer vers la page qui constitue la solution de repli logique pour « quelqu’un pour qui nous n’avons pas de meilleure correspondance ». Il s’agit généralement de la version anglaise globale, ou d’une véritable page de sélection de langue si vous en avez une. Ne faites pas pointer x-default vers la page japonaise : elle serait servie à des utilisateurs auxquels vous ne la destiniez pas.

x-default participe lui aussi à la réciprocité : la même annotation doit figurer sur chaque page du cluster, y compris sur la page vers laquelle il pointe.

Une nuance à connaître : x-default n’est utile que lorsqu’il existe plus d’une version entre lesquelles choisir. Sur une page qui n’existe qu’en une seule langue, tout le bloc d’annotations n’est que du bruit.

Où le placer

Trois méthodes d’implémentation, toutes également valables aux yeux de Google :

  • Éléments <link> dans le <head> : la plus simple, et le bon choix par défaut pour la plupart des sites. Ils doivent figurer dans le <head> du HTML brut, et non être injectés par JavaScript dans le <body>.
  • En-têtes HTTP Link : la seule option pour les fichiers non HTML, comme les PDF.
  • Annotations dans le sitemap XML : souvent le choix le plus facile à maintenir pour un grand site, car toute la carte des clusters réside dans un seul fichier généré au lieu d’être répartie sur des milliers de gabarits.

Choisissez-en une. Deux méthodes en désaccord, c’est pire que l’une ou l’autre seule, et c’est une situation étonnamment fréquente lorsqu’un plugin et un gabarit écrit à la main sont actifs simultanément.

Balise canonique et hreflang doivent concorder

C’est ici que de nombreuses configurations par ailleurs correctes déraillent.

Chaque version linguistique doit être auto-canonique. La balise canonique de la page japonaise pointe vers elle-même. Si la page japonaise porte une balise <link rel="canonical"> pointant vers l’URL anglaise (ce qui arrive plus souvent qu’on ne le pense, généralement comme vestige d’une inquiétude liée au contenu dupliqué), vous avez indiqué à Google que la page japonaise ne doit pas être indexée du tout, et l’annotation hreflang qui pointe vers elle n’a plus de sens.

Règles connexes qui découlent du même principe :

  • Le hreflang doit pointer vers l’URL canonique et indexable : pas une redirection, pas une variante avec paramètres, pas une page en noindex.
  • Utilisez des URL absolues, avec le protocole. Les URL hreflang relatives ne sont pas prises en charge.
  • Respectez exactement vos conventions de slash final, de www et de https. https://example.com/ja/pricing et https://example.com/ja/pricing/ sont des URL différentes, et une incohérence casse la réciprocité même si le navigateur aboutit au même endroit.

Sous-répertoire, sous-domaine ou .co.jp

Le hreflang fonctionne de manière identique dans les trois cas. example.com/ja/, ja.example.com et example.co.jp peuvent tous être annotés comme alternatives les uns des autres, et Google gère sans problème les clusters hreflang inter-domaines.

Le choix de la structure d’URL n’est donc pas une décision hreflang : c’est une décision d’autorité, d’organisation et de crédibilité, que nous traitons séparément dans Faut-il un domaine .co.jp pour se positionner au Japon ?. Le seul point qui concerne le hreflang : un cluster inter-domaines est plus difficile à garder réciproque, car les deux côtés sont généralement maintenus par des équipes différentes, sur des cycles de mise en production différents. C’est un risque opérationnel, pas un risque de classement, mais il est bien réel.

Les erreurs à vérifier en priorité

Approximativement dans l’ordre où nous les rencontrons :

  1. hreflang="jp" au lieu de hreflang="ja".
  2. Absence d’annotation auto-référente d’un côté ou des deux.
  3. Clusters non réciproques, généralement parce que la section japonaise a été construite plus tard, par une autre équipe, à partir d’un autre gabarit.
  4. Annotation à l’échelle du site faisant pointer chaque page vers les deux pages d’accueil.
  5. Cibles hreflang qui redirigent, renvoient une 404 ou portent un noindex.
  6. Page japonaise dont la balise canonique pointe vers la page anglaise.
  7. Incohérences de protocole, de www ou de slash final entre l’annotation et l’URL réelle.
  8. Annotations injectées par JavaScript côté client.
  9. Redirections automatiques basées sur l’IP qui éloignent complètement Googlebot (qui explore majoritairement depuis des adresses IP américaines) des pages japonaises.

Ce dernier point mérite d’être souligné, car il annule tout le reste. Si les visiteurs avec une IP japonaise sont redirigés de force vers /ja/ et que tous les autres en sont redirigés de force, vos annotations décrivent un site que Google ne peut pas explorer. Suggérez un changement de langue au moyen d’une bannière que l’on peut fermer ; ne l’imposez pas.

Comment valider

Google a supprimé le rapport dédié au Ciblage international dans la Search Console : il n’existe donc plus de validateur hreflang officiel sur lequel s’appuyer. La validation vous incombe désormais, et elle n’est pas difficile :

  • Explorez les deux sections linguistiques avec un crawler qui extrait le hreflang, et vérifiez la réciprocité sur l’ensemble plutôt que de contrôler une page au hasard. Les erreurs de réciprocité sont systématiques : si une page en a une, des centaines en ont probablement aussi.
  • Vérifiez que chaque URL cible renvoie un code 200, est auto-canonique et indexable.
  • Contrôlez le HTML brut, et non le DOM rendu dans l’inspecteur de votre navigateur : les deux peuvent différer.
  • Utilisez l’outil d’inspection d’URL sur une page japonaise représentative pour confirmer que Google retient l’URL canonique que vous aviez prévue.
  • Surveillez le rapport Performances de la Search Console filtré sur le Japon, et regardez quelle URL reçoit les impressions pour les requêtes en japonais. Si c’est encore l’URL anglaise plusieurs semaines après la correction, soit l’annotation n’est pas prise en compte, soit la page japonaise n’est pas un résultat crédible pour cette requête.

C’est cette dernière distinction qu’il faut retenir. Le hreflang décide laquelle de vos pages est affichée. Il ne décide pas si l’une d’elles mérite de l’être. Si la page japonaise est une traduction directe d’une page anglaise, construite autour de la demande de recherche anglophone, des annotations correctes mettront en avant une page que personne ne cherchait, ce qui est l’argument développé en détail dans Pourquoi traduire votre site web, ce n’est pas faire du SEO au Japon.

Corrigez d’abord la couche technique, car elle est maîtrisable et reste corrigée. Ensuite, attaquez-vous à la moitié la plus difficile.

Si vous souhaitez faire vérifier sérieusement votre configuration, cela fait partie de nos missions de SEO international pour le Japon et de SEO technique : envoyez-nous les URL et nous vous dirons ce que nous trouvons.