Pourquoi Google choisit-il une URL canonical dans la mauvaise langue pour vos contenus multilingues ?

Que signifie vraiment "content negotiation basée sur accept-language" ?

Certains serveurs analysent l'en-tête HTTP Accept-Language envoyé par le navigateur ou Googlebot pour décider quelle version linguistique servir. Si cette mécanique est mal configurée, Googlebot reçoit tantôt la version japonaise, tantôt la portugaise, sur la même URL. Le crawler enregistre alors des signaux contradictoires.

Le problème devient critique quand la balise canonical de la page japonaise pointe vers l'URL portugaise — ou inversement — parce que le serveur sert dynamiquement du contenu différent selon le contexte. Google indexe ce qu'il voit, et si ce qu'il voit change à chaque crawl, la canonical flotte entre les versions.

Pourquoi Google ne devrait-il pas confondre deux langues distinctes ?

Google traite les contenus traduits comme fondamentalement différents. Deux pages dans deux langues ne sont pas des duplicatas au sens classique : elles ciblent des audiences et des requêtes distinctes. En théorie, le moteur ne devrait jamais consolider une page japonaise et une page portugaise sous une seule canonical.

Si cela se produit malgré tout, c'est que les signaux techniques envoyés au crawler sont incohérents. Soit le serveur renvoie la même URL avec un contenu variable, soit les balises hreflang/canonical sont mal implémentées, soit les deux. Google ne devine pas : il suit ce que vous déclarez explicitement.

Quelles erreurs de configuration provoquent ce bug ?

Les cas les plus fréquents incluent des serveurs Apache ou Nginx configurés pour renvoyer du contenu dynamique selon Accept-Language sans redirection 302, ou des CMS qui génèrent des balises canonical pointant vers une "langue par défaut" indépendamment de la version affichée.

Un autre piège classique : les balises hreflang croisées mal définies. Si la page japonaise déclare une hreflang vers le portugais mais sans réciprocité correcte, ou si la canonical ne correspond pas à l'URL self-declared, Google reçoit des instructions contradictoires et choisit arbitrairement.

• Content negotiation mal configurée : le serveur renvoie des variants linguistiques sur une même URL selon l'en-tête HTTP Accept-Language, sans redirection claire.
• Balises canonical incohérentes : une page japonaise pointe sa canonical vers une URL portugaise, ou vice-versa.
• Hreflang asymétriques : les annotations hreflang ne sont pas bidirectionnelles, ou pointent vers des URLs qui ne se reconnaissent pas mutuellement.
• URLs sans marqueur linguistique clair : structures d'URL identiques entre versions (/page vs /page), rendant la distinction impossible sans inspection du contenu.
• Redirections conditionnelles non transparentes : redirections 302 basées sur Accept-Language qui cachent la vraie structure au crawler.

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, mais avec une nuance : Google ne confond effectivement pas deux langues quand les signaux techniques sont propres. En revanche, sur des sites mal configurés, on observe régulièrement des canonicals flottantes entre versions linguistiques. Mueller pointe du doigt le serveur et les balises — et il a raison dans 90 % des cas.

Le problème, c'est que beaucoup de CMS générent ces erreurs par défaut. WordPress multilingue avec WPML, Drupal avec i18n, ou des setups custom mal pensés créent des hreflang asymétriques ou des canonical qui pointent systématiquement vers la langue "principale". Le praticien SEO doit auditer manuellement.

Quelles nuances faut-il apporter à cette règle ?

Mueller ne mentionne pas un cas edge fréquent : les contenus quasi-identiques entre variantes régionales. Une page en portugais brésilien et une page en portugais européen avec 95 % de texte commun peuvent être traitées comme near-duplicates si les balises hreflang ne sont pas impeccables. Google choisit alors une canonical "dominante" selon d'autres signaux (liens, engagement, etc.).

Autre point : la déclaration suppose que le contenu est réellement distinct. Si vous servez du japonais machine-traduit de mauvaise qualité avec une structure HTML identique à la version portugaise, Google peut décider que l'une est une copie de l'autre, indépendamment de la langue affichée. [A vérifier] : aucune donnée publique ne précise le seuil de similarité où Google bascule d'une logique "variantes linguistiques" à "duplicata".

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si votre site utilise des sous-domaines ou domaines distincts par langue (ex: jp.example.com vs pt.example.com), le problème de content negotiation disparaît. Chaque sous-domaine sert un contenu unique, et les canonicals croisées deviennent impossibles par construction. C'est l'architecture la plus robuste pour éviter ce bug.

En revanche, si vous utilisez un seul domaine avec des paramètres d'URL pour switcher la langue (ex: example.com/page?lang=ja), vous êtes en terrain miné. Google recommande explicitement d'éviter cette approche, car elle rend les hreflang fragiles et les canonicals ambiguës. Dans ce cas, la déclaration de Mueller s'applique doublement.

Comment vérifier que votre configuration serveur ne crée pas ce bug ?

Testez manuellement avec curl en modifiant l'en-tête Accept-Language. Si curl -H "Accept-Language: ja" https://example.com/page renvoie du japonais et curl -H "Accept-Language: pt" renvoie du portugais sur la même URL, vous avez un problème. Google verra des contenus différents à chaque crawl.

Utilisez également la Google Search Console pour inspecter l'URL : vérifiez que la version crawlée correspond bien à la langue attendue. Si l'outil affiche tantôt du japonais, tantôt du portugais pour une même URL, votre serveur négocie le contenu de manière opaque.

Quelles erreurs éviter dans les balises hreflang et canonical ?

Chaque page doit pointer sa canonical vers elle-même (self-referencing canonical) et déclarer des hreflang bidirectionnels. Si /ja/page pointe vers /pt/page en canonical, c'est une erreur fatale. Si /ja/page déclare hreflang="pt" vers /pt/page, mais que /pt/page ne déclare pas hreflang="ja" vers /ja/page, Google ignore les annotations.

Évitez aussi les hreflang avec paramètres d'URL ou des URLs qui changent selon le contexte. Préférez des structures d'URL stables (/fr/, /en/, /ja/) ou des sous-domaines. Les canonicals doivent pointer vers des URLs absolues, jamais relatives, pour éviter toute ambiguïté.

Que faut-il faire concrètement pour corriger ce problème ?

Désactivez la content negotiation basée sur Accept-Language si elle est en place. Redirigez plutôt les utilisateurs selon leur langue via JavaScript côté client, ou servez toujours la même langue sur une URL donnée et laissez l'utilisateur switcher manuellement.

Auditez toutes vos balises canonical avec un crawler (Screaming Frog, OnCrawl) : chaque version linguistique doit pointer vers sa propre URL. Vérifiez que les hreflang sont symétriques : chaque page citée dans un hreflang doit citer en retour toutes les autres versions, y compris elle-même.

• Tester les URLs avec curl et différents en-têtes Accept-Language pour détecter du contenu variable sur une même URL.
• Vérifier que chaque page possède une canonical self-referencing pointant vers sa propre URL absolue.
• Auditer les balises hreflang pour s'assurer qu'elles sont bidirectionnelles et complètes (toutes les versions linguistiques citées mutuellement).
• Désactiver la content negotiation serveur si elle génère du contenu dynamique selon Accept-Language sans redirection explicite.
• Inspecter les URLs dans Google Search Console pour confirmer que la version crawlée correspond bien à la langue attendue.
• Privilégier une architecture d'URL claire (/fr/, /en/, /ja/) ou des sous-domaines distincts par langue.