# Sitemap multilingue et Content-Language : deux signaux parfois contradictoires

> L'en-tête HTTP envoyé par le serveur ne correspond pas à la langue déclarée dans le sitemap XML, semant la confusion côté moteur de recherche.

- Auteur : WordPress Développement
- Publié le : 2025-02-15
- Mis à jour le : 2025-02-15
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/sitemap-multilingue-content-language-signaux-contradictoires/

## L’essentiel

- L'en-tête HTTP Content-Language est distinct de la déclaration du sitemap
- Un module serveur mal configuré peut réécrire cet en-tête sans que le CMS le sache
- Les deux signaux doivent converger vers la même langue par URL

« 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-FR
```

Ce 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.

> L'essentiel à retenir : L'en-tête HTTP Content-Language est distinct de la déclaration du sitemap ; Un module serveur mal configuré peut réécrire cet en-tête sans que le CMS le sache ; Les deux signaux doivent converger vers la même langue par URL

## 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-Language` avec `curl -I` sur 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.