Quelles erreurs d'implémentation du hreflang coûtent le plus cher ?

Le hreflang est l'un des rares dispositifs techniques du référencement dont une mise en place approximative produit un résultat pire que l'absence totale. Il sert à indiquer au moteur quelles pages sont des variantes linguistiques ou régionales les unes des autres, afin qu'il serve la bonne version au bon public. Les erreurs d'implémentation du hreflang ne provoquent aucun message d'alerte visible sur le site, ne dégradent aucune page individuellement, et se traduisent seulement par des versions servies au mauvais public ou par des pages qui n'apparaissent jamais dans leur marché. Sur un site multilingue, cela peut représenter la moitié du potentiel, ce qui justifie de traiter le sujet avec une rigueur qu'on lui accorde rarement.

Ce que le dispositif fait et ne fait pas

La première source d'erreur est une attente mal calibrée. Le hreflang n'est pas un levier de positionnement, c'est un mécanisme de sélection entre pages déjà positionnées. Bien comprendre cette distinction évite d'en attendre des effets qu'il ne produira jamais, et rejoint les principes que nous exposons dans nos articles de la rubrique référencement naturel consacrés aux sites internationaux.

Un signal de substitution, pas de classement

Quand plusieurs pages d'un même ensemble sont éligibles pour une requête, le moteur choisit celle qui correspond à la langue et à la région de l'utilisateur, à partir des annotations fournies. Il ne fait pas mieux classer l'ensemble, et une page mal positionnée le restera. L'effet attendu porte donc sur la qualité de la correspondance, ce qui se traduit par un meilleur taux de clic et un moindre rebond, jamais par un gain de position sur une requête où le site n'apparaissait pas.

Une indication, pas une directive

La documentation officielle est explicite sur ce point : les annotations sont un signal, non une instruction impérative. Le moteur peut choisir une autre version s'il estime disposer de meilleurs éléments, notamment quand les signaux de langue de la page contredisent l'annotation. C'est une raison de plus pour que la cohérence interne du site soit irréprochable, l'annotation seule ne suffisant pas à imposer un choix.

Le cas des pages quasi identiques

L'un des usages les plus utiles concerne les variantes régionales d'une même langue, un contenu en français destiné à la France, à la Belgique et au Canada par exemple. Sans annotation, ces pages se concurrencent et l'une d'elles finit par absorber les autres. Avec annotation correcte, chacune est servie à son public. C'est le cas où le dispositif apporte le plus, et aussi celui où les erreurs sont les plus fréquentes, parce que les contenus étant proches, rien ne signale visuellement qu'une mauvaise version est affichée.

Ce qu'il ne règle pas du tout

Le hreflang ne remplace ni une traduction de qualité, ni une adaptation des contenus aux usages locaux, ni un travail de notoriété propre à chaque marché. Il ne corrige pas non plus un problème de contenu dupliqué entre langues différentes, qui n'en est pas un, ni entre pages de même langue et même région, qui relève de la canonique. L'attendre sur ces terrains conduit à des diagnostics erronés et à des chantiers inutiles.

Langue de la page et annotation doivent concorder

Le moteur détermine la langue d'une page à partir de son contenu visible, et non de ses balises. Une page annotée comme espagnole mais dont le texte est resté en français sera traitée comme française, l'annotation étant considérée comme une erreur plutôt que comme une instruction. Ce cas se produit très souvent sur les sites dont la traduction est partielle : la structure existe, les gabarits sont traduits, le contenu ne l'est pas encore. L'attribut de langue posé sur la balise racine du document, souvent oublié ou laissé à la valeur du gabarit d'origine, participe aussi de cette cohérence, tout comme la langue des éléments de navigation et du pied de page. Publier une version linguistique à moitié traduite est donc contre productif : mieux vaut la garder hors du dispositif jusqu'à ce qu'elle soit réellement dans sa langue.

Les erreurs qui reviennent le plus souvent

Sur les audits de sites multilingues, les mêmes défauts se retrouvent avec une régularité frappante. Ils ne demandent presque jamais un travail lourd pour être corrigés, et c'est ce qui rend leur persistance étonnante. La démarche de vérification est la même que pour les autres contrôles techniques, telle que décrite dans notre article sur la manière de détecter les chaînes de redirections sur un site de plusieurs milliers d'URL.

Les codes de langue et de pays inventés

Les codes attendus suivent des normes précises, deux lettres pour la langue et deux lettres pour la région, et n'acceptent aucune improvisation. Les erreurs classiques sont l'usage d'un code de pays à la place d'un code de langue, la confusion entre le code du Royaume Uni et celui de la langue anglaise, et l'invention de codes qui semblent logiques mais n'existent pas. Une annotation dont le code est invalide est purement et simplement ignorée, sans qu'aucun signe ne l'indique sur la page. Le code de région, quand il est utilisé, doit désigner un pays et jamais une zone géographique ou linguistique plus large, ce qui écarte les tentatives de viser un continent ou un ensemble de marchés d'un seul code.

L'absence de réciprocité

Chaque page annotée doit désigner toutes les versions de l'ensemble, y compris elle même, et chacune de ces versions doit à son tour désigner les autres. Une relation non réciproque est ignorée. Cette exigence est simple à énoncer et difficile à tenir manuellement dès qu'il y a plus de trois langues, chaque ajout de version imposant une modification sur toutes les pages existantes. C'est la raison pour laquelle la génération automatique à partir d'une table de correspondances est la seule approche viable au delà d'un petit site.

La canonique qui contredit l'annotation

C'est l'erreur la plus destructrice et la plus fréquente. Une page qui déclare une adresse canonique pointant vers une autre version linguistique annule tout le dispositif : elle demande au moteur de ne pas l'indexer séparément, ce qui rend l'annotation sans objet. Chaque version doit être sa propre canonique, sans exception. Cette configuration se produit souvent par accident, quand une extension de traduction et une extension de référencement écrivent chacune leur balise sans se coordonner.

Les adresses relatives ou non finales

Les adresses déclarées doivent être absolues, complètes, servies en HTTPS et correspondre exactement à la page finale. Une adresse qui redirige, qui diffère par la présence d'une barre oblique ou qui pointe vers une version non indexable rompt la chaîne. Ce point recoupe directement le travail sur les redirections, et il constitue une des raisons pour lesquelles un changement de structure d'adresses doit s'accompagner d'une reprise complète des annotations.

L'annotation de repli mal comprise

Une valeur particulière permet de désigner la version à servir quand aucune autre ne correspond au visiteur. Elle est facultative, souvent utile, et régulièrement mal employée : elle ne désigne pas une langue par défaut du site mais une page de repli, qui doit elle même faire partie de l'ensemble et respecter la réciprocité. La déclarer sur plusieurs pages de l'ensemble, ou sur une page qui n'y appartient pas, produit un conflit qui invalide l'annotation. Elle n'a par ailleurs aucun rapport avec une quelconque langue universelle : elle désigne une page servie à tous les visiteurs dont la langue ne correspond à aucune version déclarée, ce qui est une situation, pas une langue.

La redirection automatique selon la langue du visiteur

Beaucoup de sites multilingues ajoutent une redirection automatique fondée sur la langue du navigateur ou sur la position géographique déduite de l'adresse réseau. C'est une source d'ennuis majeure et rarement identifiée. Le robot d'exploration se présente depuis une localisation qui n'est pas nécessairement celle du public visé, et une redirection systématique l'empêche purement et simplement de voir les autres versions, qui restent alors hors de l'index. La solution recommandée par la documentation officielle consiste à ne jamais rediriger d'autorité, mais à proposer un changement de version par un lien ou une bannière discrète, chaque version restant accessible à son adresse propre. Le visiteur garde le contrôle, et le moteur peut explorer l'ensemble.

Choisir sa méthode de déclaration

Trois emplacements sont possibles, et le choix a des conséquences pratiques importantes sur la maintenance et sur le poids des pages. Aucun n'est supérieur en soi, mais chacun convient à un contexte précis, ce qui rejoint les arbitrages techniques évoqués dans notre article sur les solutions de balise rel alternate hreflang pour WordPress.

Dans l'en tête du document

C'est la méthode la plus répandue et la plus simple à vérifier, puisqu'il suffit d'afficher le code source. Son défaut apparaît sur les sites comportant de nombreuses versions : avec quinze langues, chaque page porte quinze balises supplémentaires, sur des milliers de pages, ce qui alourdit inutilement chaque document. En dessous de cinq ou six versions, cet inconvénient reste négligeable et la lisibilité l'emporte. Ces balises doivent en outre figurer dans le document servi par le serveur, et non être ajoutées par script après chargement, faute de quoi elles dépendent de l'étape de rendu et perdent une grande partie de leur fiabilité.

Dans les en têtes de la réponse

La déclaration par en tête de réponse est la seule possible pour les documents qui ne sont pas du HTML, notamment les fichiers PDF, dont les versions linguistiques peuvent parfaitement être annotées. Elle a l'avantage de ne pas alourdir le document, et l'inconvénient d'être invisible pour qui regarde la page dans un navigateur, ce qui la rend plus difficile à contrôler et plus facile à oublier lors d'un changement de serveur. Elle suppose aussi que la configuration du serveur connaisse la correspondance entre les documents, information qui vit ailleurs que dans le contenu, ce qui la rend rapidement obsolète si rien ne la régénère.

Dans le plan de site

C'est la méthode la plus adaptée aux grands sites. Les relations sont décrites une seule fois, dans un fichier centralisé, ce qui supprime le poids sur les pages et facilite énormément la vérification de la réciprocité, puisque tout est au même endroit. Elle exige en contrepartie une génération fiable et à jour, et elle rend les erreurs plus difficiles à repérer à l'œil, le fichier pouvant compter des dizaines de milliers de lignes.

Ne jamais combiner deux méthodes

Déclarer les mêmes relations à deux endroits est la meilleure manière de créer des contradictions le jour où l'une des deux sources évolue et pas l'autre. Il faut choisir une méthode et une seule, la documenter, et vérifier lors de chaque intervention qu'aucune extension n'a ajouté une seconde source. Ce contrôle prend dix secondes et évite des diagnostics interminables sur des annotations qui semblent correctes à un endroit et fausses à un autre. La méthode retenue doit d'ailleurs figurer dans la documentation technique du site, au même titre que la structure des adresses.

Contrôler et maintenir dans la durée

Un dispositif correct au moment de sa mise en place se dégrade au premier ajout de contenu si rien ne le surveille. Le contrôle doit donc être automatisé, et il porte sur quatre points seulement.

Vérifier la validité et la réciprocité par script

Un contrôle complet consiste à parcourir toutes les pages annotées, à collecter les relations déclarées, puis à vérifier que chaque code est valide, que chaque page se désigne elle même, et que toute page citée cite en retour celle qui la cite. Ce traitement se scripte en une centaine de lignes, tourne en quelques minutes sur un site de taille moyenne, et détecte immédiatement les ruptures introduites par une publication récente. Le placer dans la chaîne d'intégration, avec un échec bloquant en cas de rupture, transforme un contrôle que personne ne pense à lancer en garantie permanente.

Croiser avec les directives d'indexation

Le second contrôle vérifie qu'aucune page citée dans un ensemble n'est bloquée à l'indexation, redirigée ou absente. Une version annotée mais interdite d'indexation est une contradiction qui affaiblit tout l'ensemble. Ce croisement se fait à partir des mêmes données que le contrôle précédent, en ajoutant une requête par adresse, ce qui reste raisonnable si le résultat est mis en cache entre deux exécutions. Il révèle presque toujours quelques pages retirées du site sans que leurs annotations aient été mises à jour ailleurs, cas typique d'une suppression faite dans une seule langue.

Lire les rapports du moteur

Les outils pour webmasters signalent les erreurs de langue détectées et donnent des exemples concrets, ce qui est précieux parce qu'ils reflètent ce que le moteur a réellement compris et non ce que le site déclare. Ces rapports mettent parfois plusieurs semaines à refléter une correction, ce qui décourage ; la bonne pratique consiste à corriger, à vérifier par script que la correction est effective, puis à attendre sans rien changer d'autre. Enchaîner les modifications avant d'avoir vu le résultat de la précédente est la meilleure manière de ne jamais savoir laquelle a produit l'effet observé.

Traiter les ajouts de contenu comme des ajouts d'ensemble

La règle d'organisation qui évite la plupart des régressions consiste à ne jamais publier une page dans une seule langue quand l'ensemble en compte plusieurs, ou alors à l'exclure explicitement du dispositif jusqu'à ce que ses variantes existent. Une page publiée seule et annotée vers des versions qui n'existent pas encore casse la réciprocité et introduit des adresses en erreur, ce qui dégrade la confiance accordée à l'ensemble du site plutôt qu'à cette seule page. Cette règle a une conséquence organisationnelle qu'il faut assumer dès le départ : le rythme de publication d'un site multilingue est celui de sa langue la plus lente, et vouloir s'en affranchir revient à sacrifier la cohérence du dispositif.

Documenter la table de correspondances

Le cœur du dispositif est une simple table qui, pour chaque contenu, indique l'adresse de chacune de ses versions. Cette table doit exister quelque part de manière explicite, dans la base ou dans un fichier, et non seulement dans la logique d'une extension. C'est elle qui permet de régénérer les annotations après un changement de structure, de repérer les contenus dont une version manque, et de reprendre le dispositif si l'extension utilisée disparaît. Sans cette table lisible, la relation entre les versions n'existe que sous forme d'une convention implicite sur les adresses, qui se brise à la première exception. Elle tient dans un simple tableau, une ligne par contenu et une colonne par langue, format que n'importe quel intervenant comprend sans explication et qui survit au changement d'extension comme au changement d'équipe.