Deux façons d’indiquer la langue d’une page coexistent souvent sur un même site multilingue : l’en-tête HTTP Content-Language, hérité des débuts du web, et la balise link rel="alternate" hreflang, apparue avec la structuration moderne des sites internationaux. Beaucoup de configurations empilent les deux en pensant qu’elles se renforcent. Ce n’est pas tout à fait le cas : elles ne répondent pas à la même question, et l’une des deux a perdu, avec le temps, une bonne partie de son utilité pour le référencement.
Cette notion clarifie ce que chacun de ces deux signaux communique réellement à un moteur de recherche, et pourquoi il ne faut pas se fier à l’un pour compenser l’absence de l’autre.
Content-Language : un signal de métadonnée, pas de relation entre pages
L’en-tête Content-Language, qu’il soit envoyé en en-tête HTTP ou reproduit dans une balise meta http-equiv="content-language" dans le head du document, indique la langue du contenu de la page qui le porte. C’est une information ponctuelle sur une seule page, isolée : elle ne dit rien des autres versions linguistiques du même contenu, ni de leur existence, ni de leur URL. Un moteur de recherche qui lit cet en-tête sait dans quelle langue est rédigée cette page précise, un point c’est tout.
hreflang : un signal relationnel entre plusieurs URLs
La balise hreflang fonctionne à l’inverse comme un signal relationnel : chaque page d’un même contenu porte un jeu de balises listant l’intégralité de ses variantes linguistiques ou régionales, URL par URL. C’est cette structure en réseau, où chaque page référence toutes ses variantes et où chaque variante devrait référencer les autres en retour, qui permet à Google de comprendre qu’il s’agit d’un même contenu décliné, et d’éviter de faire concurrencer les versions entre elles dans les résultats de recherche.
<link rel="alternate" hreflang="fr" href="https://exemple.fr/produit/" />
<link rel="alternate" hreflang="en" href="https://exemple.fr/en/product/" />
<link rel="alternate" hreflang="x-default" href="https://exemple.fr/produit/" />Pourquoi Content-Language ne suffit plus comme signal SEO
La documentation de Google pour le référencement international recommande explicitement hreflang comme mécanisme de signalement des variantes linguistiques, sans faire de Content-Language un prérequis ni même un signal complémentaire pris en compte de la même façon. L’en-tête Content-Language garde une utilité réelle, mais ailleurs : pour l’accessibilité, pour certains lecteurs d’écran, et pour des usages de négociation de contenu côté serveur indépendants du référencement.
| Signal | Portée | Rôle pour l’indexation multilingue |
|---|---|---|
| Content-Language | Une seule page | Marginal, non documenté comme signal principal par Google |
| hreflang | Réseau de pages liées entre elles | Signal principal documenté pour les variantes de langue et de région |
| lang de la balise html | Une seule page | Utile pour l’accessibilité, pas pour la relation entre variantes |
L’erreur fréquente : croire que l’un remplace l’autre
Un site qui ne configure que Content-Language, en pensant avoir couvert le sujet du multilingue pour le SEO, laisse Google sans aucune information sur l’existence de ses variantes linguistiques : chaque page se retrouve indexée isolément, potentiellement perçue comme un doublon partiel des autres si le contenu structurel se ressemble. À l’inverse, un site qui configure hreflang correctement n’a nul besoin de dupliquer cette information via Content-Language pour que le signal fonctionne : les deux ne se substituent pas l’un à l’autre, mais seul hreflang porte la charge du signalement relationnel.
Ce que WordPress gère nativement
WordPress définit l’attribut lang de la balise html à partir de la locale du site via la fonction get_language_attributes(), utilisée par la plupart des thèmes dans leur fichier header.php. Cet attribut renseigne la langue de la page pour les technologies d’assistance, mais ne joue aucun rôle relationnel de type hreflang : c’est aux extensions de traduction, ou à du code maison comme décrit dans d’autres articles de cette catégorie, d’assumer la génération des balises hreflang proprement dites.
En résumé
Content-Language décrit une page seule ; hreflang décrit une relation entre plusieurs pages. Le premier a gardé une utilité pour l’accessibilité et la négociation de contenu, mais a perdu son rôle de signal principal pour l’indexation multilingue au profit du second. Un site bien configuré n’a pas besoin de choisir entre les deux : il doit simplement cesser de compter sur Content-Language pour faire le travail que seul hreflang accomplit réellement aux yeux des moteurs de recherche.
