Sur une boutique multilingue, la même fiche produit existe en cinq versions. Sans indication, un moteur de recherche voit cinq pages proches, en choisit une par requête, et peut très bien servir la version espagnole à un visiteur allemand. Les balises hreflang existent pour éviter cela.
Elles sont mal comprises, souvent mal posées, et PrestaShop ne les génère pas nativement de façon complète.
Ce que hreflang fait, et ne fait pas
Une précision utile avant tout paramétrage. Hreflang ne fait pas monter une page dans les résultats. C’est un signal de correspondance, pas de qualité.
Ce qu’il apporte concrètement : il indique quelle version servir selon la langue et la région du visiteur, et il regroupe les versions entre elles pour qu’elles ne se concurrencent pas. Une page allemande bien positionnée en Allemagne conserve son classement, et le visiteur français reçoit la version française plutôt que la même page en allemand.
Sur un site où toutes les versions sont dans la même langue, français de France et français de Belgique par exemple, hreflang est le seul moyen de faire comprendre à quel public chacune s’adresse.
Les trois règles absolues
Une implémentation hreflang est valide ou ne l’est pas. Il n’y a pas de demi-mesure, et trois règles conditionnent tout.
- La réciprocité. Si la page française pointe vers la page allemande, la page allemande doit pointer vers la page française. Un lien non réciproque est ignoré. C’est la première cause d’échec.
- L’auto-référence. Chaque page doit se déclarer elle-même dans la liste. Une page française qui ne liste que l’allemand et l’espagnol est incomplète.
- La cohérence avec la balise canonique. Chaque page doit avoir une canonique pointant vers elle-même. Une canonique qui pointe vers une autre version annule tout le dispositif, puisqu’elle dit au moteur que cette page n’est pas la bonne.
Ajoutons une contrainte de format : le code langue suit la norme ISO 639-1, le code pays facultatif la norme ISO 3166-1. « fr » est valide, « fr-FR » aussi, « fr-fr » est toléré, mais « fr-EU » ne l’est pas, l’Union européenne n’étant pas un pays.
Langue ou langue plus pays
Choix structurant qui dépend de votre modèle.
Si vous vendez le même catalogue aux mêmes conditions à tous les francophones, un simple « fr » suffit. Si vous avez une boutique française et une boutique belge avec des prix et des frais de port différents, il faut « fr-FR » et « fr-BE ».
Le second cas est plus puissant et plus fragile : il multiplie le nombre de relations à maintenir. Trois langues et quatre pays donnent douze versions, donc cent trente-deux relations réciproques à tenir correctes.
Module Hreflang PrestaShop 8 — Balises Alternate SEO Multilingue | DataFireflyBalises hreflang correctes sur toutes vos pages PrestaShop 8 : URLs natives traduites, x-default, groupes multishop et 70+ codes hreflang.€29.00
Où poser les balises
Trois emplacements possibles, un seul suffit et il ne faut pas les mélanger.
Dans l’en-tête HTML de la page. Le plus courant, le plus simple à contrôler, et le plus lourd si vous avez douze versions : douze lignes supplémentaires sur chaque page.
Dans le sitemap XML. Plus léger côté page, et pratique sur un grand nombre de versions. En contrepartie, une erreur est moins visible et le fichier devient volumineux.
Dans les en-têtes HTTP. Réservé aux fichiers non HTML, typiquement des PDF multilingues.
La balise x-default
Elle désigne la page à servir quand aucune version ne correspond à la langue du visiteur. Un visiteur japonais sur un site français, anglais et allemand doit atterrir quelque part.
Deux usages corrects : pointer vers la version anglaise, ou vers une page de sélection de pays. Un usage incorrect et fréquent : pointer vers la version française en la déclarant aussi comme « fr ». La page peut cumuler les deux rôles, mais la déclaration doit être explicite.
Les erreurs les plus fréquentes
- Hreflang vers une page non traduite. Une fiche existe dans le sélecteur de langue mais son contenu est resté en français. Le moteur constate que les deux pages sont identiques et cesse de faire confiance à l’ensemble des déclarations.
- Hreflang vers une redirection. L’URL déclarée renvoie un code 301. Le lien est ignoré.
- Hreflang vers une page bloquée. L’URL est interdite dans le fichier robots, ou porte une balise noindex. Contradiction directe.
- Déclaration partielle. Seules les pages d’accueil sont couvertes, et pas les fiches ni les catégories. C’est le cas le plus répandu, et il ne sert à peu près à rien.
- Produits désactivés dans une langue. Une référence vendue en France mais pas en Espagne casse la réciprocité si la déclaration continue de pointer vers une page inexistante.
Le cas PrestaShop
Deux architectures coexistent et n’appellent pas le même traitement.
En multilingue simple, une boutique, plusieurs langues, les URL se distinguent par un préfixe de langue. Les relations sont faciles à établir puisque chaque produit possède un identifiant unique commun à toutes ses traductions.
En multiboutique, une boutique par pays avec des domaines distincts, la correspondance n’est plus automatique. Un produit peut porter des identifiants différents selon les boutiques, ou exister dans l’une et pas dans l’autre. C’est là que la génération manuelle devient impraticable.
Contrôler
Trois vérifications, dans cet ordre. Le code source d’une fiche produit, pour voir les balises réellement présentes. Le rapport de ciblage international de la Search Console, qui remonte les erreurs de réciprocité et les codes invalides. Et un contrôle par échantillon sur une vingtaine de pages tirées au hasard, parce que les erreurs se concentrent rarement sur la page d’accueil.
Le module Hreflang pour PrestaShop génère ces balises automatiquement sur PrestaShop 8 et 9 : couverture de toutes les pages et pas seulement de l’accueil, gestion du multiboutique et des correspondances entre domaines, x-default paramétrable et exclusion des produits non disponibles dans une version.
