« Google Search Console signale une incohérence de langue sur 340 URL de la version espagnole du site. » Ce message, découvert dans les alertes hebdomadaires de la console, ne pointait vers aucune erreur de contenu visible : les pages concernées affichaient bien du texte espagnol, correctement structuré, avec les bonnes balises hreflang dans le head. Le problème se cachait ailleurs, à un niveau que peu d’outils de diagnostic SEO vérifient par défaut.
L’écart concernait l’en-tête HTTP Content-Language, envoyé par le serveur avant même que le navigateur ne commence à lire le HTML, et qui contredisait silencieusement la langue déclarée par ailleurs dans le sitemap XML du site.
Symptôme : deux sources de vérité qui divergent
Le sitemap XML, généré par l’extension SEO du site, déclarait correctement chaque URL espagnole avec ses attributs hreflang associés. Mais l’en-tête HTTP Content-Language, envoyé sur les mêmes URL, indiquait systématiquement fr-FR — la langue par défaut du serveur, jamais mise à jour selon la langue réelle de la page servie.
curl -sI https://exemple.fr/es/productos/ | grep -i content-language
Content-Language: fr-FRCe genre de décalage passe totalement inaperçu à l’œil nu : un visiteur humain ne consulte jamais les en-têtes HTTP, et la page elle-même s’affiche parfaitement dans la bonne langue. Seuls les outils qui analysent le trafic à un niveau protocolaire — dont certains robots d’indexation — remarquent la contradiction.
Diagnostic : remonter à la source de l’en-tête
La première hypothèse, la plus fréquente, consiste à vérifier si WordPress lui-même émet cet en-tête. Ce n’est pas le cas par défaut : WordPress ne définit pas Content-Language nativement, cette responsabilité revient généralement au serveur web ou à une configuration explicite. Un tour du côté de la configuration Apache a révélé la cause exacte :
# Dans un fichier .htaccess hérité d'une configuration ancienne
Header set Content-Language "fr-FR"Cette directive, ajoutée des années plus tôt pour un site qui n’existait alors qu’en français, forçait l’en-tête sur toutes les réponses du serveur, sans distinction de langue — une configuration devenue invisible avec le temps, jusqu’à ce que le site devienne multilingue sans que personne ne revienne sur ce détail de configuration serveur.
Correctif : générer l’en-tête dynamiquement selon la langue de la page
La directive statique a été retirée du fichier de configuration serveur, remplacée par une génération dynamique côté WordPress, alignée sur la locale réellement active pour chaque requête :
add_action( 'send_headers', function () {
$locale = determine_locale();
$lang = substr( str_replace( '_', '-', $locale ), 0, 5 );
header( 'Content-Language: ' . $lang );
} );Cette fonction s’appuie sur determine_locale(), la fonction native de WordPress qui résout la locale active pour la requête courante, en tenant compte du préfixe d’URL ou du domaine selon la configuration multilingue en place.
Vérification après correctif
Un contrôle systématique sur un échantillon d’URL de chaque langue a permis de confirmer la cohérence retrouvée entre les deux signaux :
| URL | Content-Language | hreflang du sitemap |
|---|---|---|
| /es/productos/ | es-ES | es-ES |
| /en/products/ | en-US | en-US |
| /productos-fr/ | fr-FR | fr-FR |
Pourquoi ce signal compte malgré son discrétion
L’en-tête Content-Language a un poids bien moindre que les balises hreflang dans les critères de classement des moteurs de recherche, mais une contradiction persistante entre les deux signaux introduit une incertitude qui peut ralentir l’indexation correcte d’une nouvelle langue, en particulier lors d’un lancement récent où le moteur cherche activement à confirmer la structure linguistique du site.
- Vérifier l’en-tête
Content-Languageaveccurl -Isur un échantillon d’URL par langue - Auditer toute règle de configuration serveur héritée d’une version antérieure du site, avant qu’il ne devienne multilingue
- Ne jamais fixer cet en-tête de façon statique sur un site qui sert plusieurs langues depuis la même infrastructure
Un en-tête HTTP configuré une fois, à une époque où le site n’existait qu’en une seule langue, devient un bug silencieux le jour où ce site s’internationalise sans que personne ne revienne sur ce détail de configuration.
En résumé
La cohérence multilingue d’un site ne se joue pas uniquement dans le contenu HTML : elle se joue aussi dans les en-têtes HTTP envoyés avant même que la page ne commence à se charger. Un audit régulier de Content-Language aux côtés du sitemap XML évite ce genre de contradiction silencieuse, dont l’origine remonte souvent à une configuration serveur oubliée depuis longtemps.
