L’annotation de langue alternative indique aux moteurs qu’une même page existe en plusieurs versions linguistiques et laquelle servir à qui. Elle est simple dans son principe et redoutablement facile à casser : une erreur sur un seul élément invalide souvent tout le groupe.
Voici dix erreurs, vérifiables en une vingtaine de minutes sur votre site.
1. Le lien retour manquant
L’erreur la plus fréquente et la plus destructrice.
La déclaration doit être réciproque. Si votre page française déclare une version allemande, la page allemande doit déclarer la page française en retour. Sans cette réciprocité, la déclaration est ignorée.
Le cas typique : une traduction ajoutée sans que le modèle de page ne soit régénéré, ou une page dépubliée d’un côté seulement.
Vérification : ouvrez une page allemande, regardez ses annotations, et vérifiez qu’elle pointe bien vers la française.
2. L’auto-référence absente
Chaque page doit se déclarer elle-même dans la liste, en plus de ses alternatives.
Une page française qui déclare l’allemand, l’espagnol et l’italien mais pas le français est incomplète. L’auto-référence fait partie du groupe.
Vérification : comptez les annotations sur une page. Si vous avez cinq langues, vous devez en voir cinq, pas quatre.
3. La confusion avec la balise canonique
Erreur la plus dommageable pour le trafic international.
Les versions linguistiques ne sont pas des doublons. Chaque page doit porter une canonique vers elle-même, pas vers la version d’origine.
Faire pointer les traductions vers la page française revient à demander leur désindexation. Le site paraît correctement traduit et il ne reçoit aucun trafic étranger.
Vérification : sur une page allemande, la canonique doit être l’adresse allemande.
4. Les codes de langue et de région mélangés
Le code peut désigner une langue seule, ou une langue dans un pays. Les deux sont valides et ils ne veulent pas dire la même chose.
Un code de langue seul cible tous les locuteurs de cette langue. Un code de langue et de région cible cette langue dans ce pays précis.
Trois erreurs classiques : utiliser un code de pays seul, qui n’est pas valide ; inventer un code de région inexistant ; ou mélanger les deux formes de façon incohérente dans un même groupe.
Point important : le premier élément est toujours la langue, le second la région. L’inverse est invalide.
Vérification : relevez tous vos codes et comparez-les aux normes correspondantes.
5. Le ciblage par pays sans contenu différencié
Erreur de conception plutôt que de syntaxe.
Déclarer une version pour la France et une pour la Belgique francophone n’a de sens que si les contenus diffèrent réellement : prix, devise, conditions de livraison, mentions légales.
Si les deux pages sont identiques, vous créez de la duplication sans bénéfice, et les moteurs choisiront eux-mêmes laquelle servir.
Vérification : pour chaque paire de versions d’une même langue, identifiez au moins une différence substantielle. Sinon, fusionnez.
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
6. Les annotations sur des pages non traduites
Situation fréquente sur les catalogues partiellement traduits.
Déclarer une version allemande d’une fiche produit dont la description est restée en français produit deux problèmes : le visiteur allemand arrive sur du contenu qu’il ne comprend pas, et le moteur constate que la page annoncée comme allemande ne l’est pas.
La règle : ne déclarez que les versions réellement traduites. Un groupe à trois langues sur un produit et à cinq sur un autre est parfaitement valide.
Vérification : prenez trois produits au hasard et lisez leurs versions étrangères. Si vous y trouvez du français, corrigez.
7. La valeur générique mal employée
Une valeur particulière permet de désigner une version par défaut, servie aux visiteurs dont la langue ne correspond à aucune version déclarée.
Deux erreurs. La traiter comme une langue, en croyant qu’elle cible l’anglais : elle ne cible aucune langue en particulier. Et l’oublier : sans elle, un visiteur japonais sur un site à cinq langues européennes n’a pas de version désignée.
Cette valeur est facultative. Si vous l’utilisez, elle doit désigner une seule page, et cette page doit exister dans le groupe comme les autres.
8. Les adresses relatives ou incohérentes
Quatre problèmes d’adresse qui invalident les déclarations.
Les adresses relatives. Elles doivent être absolues, avec le protocole et le domaine.
Le mélange de protocoles, une version déclarée en sécurisé et l’autre non.
Les adresses redirigées. Une déclaration pointant vers une adresse qui redirige ajoute une étape et brouille le signal.
L’incohérence avec la canonique. Si la déclaration pointe vers une adresse et la canonique de la page cible vers une autre, le groupe est cassé.
Vérification : un contrôle automatisé sur un échantillon de pages repère ces quatre cas en quelques minutes.
9. Les pages en erreur ou non indexables
Une déclaration pointant vers une page qui n’existe plus, qui redirige, ou qui porte une directive de non-indexation est inutilisable.
Le cas se produit typiquement après une refonte ou une suppression de produit dans une seule langue.
Conséquence pratique : quand vous retirez une page dans une langue, vous devez mettre à jour les annotations de toutes les autres versions du groupe. C’est ce qui est le plus souvent oublié.
Vérification : un crawl du site avec relevé des codes de réponse sur les adresses déclarées.
10. Le plan de site et les en-têtes oubliés
Les annotations peuvent être posées de trois façons : dans l’en-tête de la page, dans les en-têtes de réponse, ou dans le plan de site.
Deux erreurs opposées.
Les déclarer à plusieurs endroits avec des valeurs différentes, ce qui produit un conflit.
Ne pas les déclarer du tout pour les documents non HTML, comme les PDF, pour lesquels seule la voie des en-têtes de réponse est possible.
Sur un catalogue important, la déclaration dans le plan de site présente un avantage : elle centralise l’information et elle allège les pages. Elle demande en revanche un plan de site correctement généré et à jour.
La méthode de vérification en vingt minutes
Cinq étapes.
1. Ouvrez une page dans chaque langue et comparez leurs annotations. Elles doivent lister exactement les mêmes adresses.
2. Vérifiez la canonique de chacune : elle doit pointer vers elle-même.
3. Relevez les codes utilisés et validez leur format.
4. Lisez le contenu de deux ou trois pages étrangères pour confirmer qu’elles sont réellement traduites.
5. Consultez le rapport international de la Search Console, qui remonte les liens retour manquants et les codes invalides à l’échelle du site.
Ce dernier point est le plus efficace pour le suivi continu : il détecte les régressions après une mise en production sans que vous ayez à recontrôler manuellement.
Ce que ces annotations ne font pas
Trois clarifications utiles.
Elles ne modifient pas le classement. Elles indiquent quelle version servir, pas laquelle mieux positionner.
Elles ne remplacent pas la traduction. Une page mal traduite reste une mauvaise page, correctement annotée.
Elles ne redirigent personne. Un visiteur qui arrive sur la mauvaise version doit pouvoir en changer, ce qui suppose un sélecteur de langue visible.
Sur ce dernier point, une pratique à éviter : la redirection automatique selon la langue du navigateur. Elle empêche un visiteur de consulter une autre version, et elle gêne l’exploration des moteurs. Proposez, ne forcez pas.
Le module Hreflang pour PrestaShop gère ces annotations sur PrestaShop 8 et 9 : génération automatique avec réciprocité et auto-référence, exclusion des pages non traduites du groupe, cohérence avec les canoniques auto-référentes et contrôle des adresses déclarées en erreur ou redirigées.
