Pourquoi hreflang ne fonctionne-t-il que sur les pages canoniques ?

Qu'est-ce que Google entend réellement par versions canoniques ?

Google parle ici des URLs désignées comme canoniques via la balise rel="canonical" ou sélectionnées automatiquement par ses algorithmes. Quand plusieurs versions d'une même page existent (paramètres, sessions, variations mineures), Google en choisit une comme référence.

La déclaration de Mueller précise que hreflang doit pointer vers ces URLs canoniques, pas vers des variantes. Si vous placez hreflang sur une page A qui canonicalise vers B, ou si vos annotations hreflang ciblent des URLs que Google considère comme dupliquées, le signal sera perdu.

Pourquoi cette exigence technique n'est-elle pas anodine ?

Sur des sites multilingues complexes, les canonicales sont souvent définies en cascade : paramètres de tri, filtres, versions mobiles séparées. Si votre CMS génère automatiquement des canoniques vers des versions "propres" mais que vos hreflang restent sur les URLs avec paramètres, vous créez une incohérence.

Google traite alors les annotations comme non fiables et peut les ignorer complètement. Résultat : vos pages françaises s'affichent en Belgique, vos pages UK en Australie, sans logique apparente.

Quel est le piège le plus fréquent sur les sites multilingues ?

Le scénario classique : un site .com/fr/, .com/en/, .com/de/ avec des canoniques auto-référencées (chaque page pointe vers elle-même), mais des hreflang qui ciblent des URLs avec /index.php ou ?lang=fr. Google voit des incohérences entre les canoniques et les cibles hreflang.

Autre cas courant : des variantes régionales multiples (fr-FR, fr-BE, fr-CA) où certaines versions canonicalisent vers fr-FR par défaut. Si vos hreflang pointent vers fr-BE mais que cette page canonicalise vers fr-FR, le signal est court-circuité.

• hreflang doit toujours cibler l'URL canonique, jamais une variante ou un duplicate
• Les annotations doivent être réciproques : si A pointe vers B, B doit pointer vers A
• Google ignore les hreflang placés sur des pages non-canoniques
• La cohérence entre canonical et hreflang est vérifiable en crawl
• Une erreur sur une langue peut contaminer tout le cluster hreflang

Cette règle est-elle appliquée strictement par Google dans les faits ?

Terrain : oui, et c'est mesurable. Les tests montrent que Google ignore effectivement les annotations hreflang quand elles ne pointent pas vers les canoniques détectées. Search Console le signale d'ailleurs explicitement dans les rapports d'erreurs hreflang.

La nuance : Google peut tolérer temporairement des incohérences mineures si le reste du cluster est cohérent. Mais dès qu'il y a ambiguïté (hreflang vers A, canonical vers B), il tranche en faveur de la canonical et abandonne l'annotation.

Quelles zones d'ombre subsistent dans cette déclaration ?

Mueller reste volontairement évasif sur ce qui se passe quand hreflang et canonical entrent en conflit. [A vérifier] : quelle annotation prévaut exactement ? Les observations suggèrent que canonical l'emporte toujours, mais Google n'a jamais documenté l'ordre de priorité complet.

Autre flou : que faire quand Google choisit une canonical différente de celle déclarée ? Si vous indiquez A comme canonique mais que Google préfère B, vos hreflang vers A deviennent-ils invalides ? La réponse pratique : oui, et c'est détectable dans les logs.

Dans quels cas cette règle devient-elle un vrai casse-tête ?

Les sites avec facettes ou filtres : si /produits/chaussures?couleur=rouge canonicalise vers /produits/chaussures, mais que vous voulez des hreflang spécifiques par couleur entre langues, vous êtes coincé. Google ne suivra que la canonique sans filtre.

Les architectures avec CDN ou domaines multiples : si votre .fr canonicalise vers .com mais que vos hreflang pointent entre .fr, .de, .it, il y a conflit structurel. Solution : soit unifier les canoniques sur un domaine unique, soit abandonner hreflang au profit du ciblage géographique Search Console.

Comment auditer la cohérence canonical/hreflang sur un site existant ?

Premier réflexe : crawler le site avec Screaming Frog ou Oncrawl en extrayant simultanément les canonical et les cibles hreflang de chaque page. Exporte vers Excel et croise les données : chaque URL ciblée par hreflang doit matcher exactement la canonical déclarée sur cette page.

Vérifie ensuite dans Search Console, rapport Couverture internationale : Google liste explicitement les conflits détectés. Cherche "hreflang vers URL non-canonique" ou "canonical introuvable". Ces erreurs bloquent l'indexation multilingue.

Quelle architecture privilégier pour éviter ces conflits ?

La solution la plus robuste : structure en sous-répertoires avec auto-référencement strict. Chaque /fr/page/ pointe canonical vers elle-même, et les hreflang ciblent /en/page/, /de/page/ qui font de même. Pas de cascade, pas d'ambiguïté.

Si vous utilisez des paramètres ou sessions, force les canoniques vers les URLs propres et n'ajoute hreflang que sur ces versions propres. Ne déploie jamais hreflang sur les URLs paramétrées elles-mêmes.

Comment corriger un site déjà en production avec des erreurs massives ?

Priorise les pages stratégiques : homepage, catégories principales, top produits. Corrige d'abord leurs canonical et hreflang, pousse une revalidation Search Console. Google réévaluera le cluster en quelques jours.

Pour les URLs générées automatiquement (facettes, filtres), ajoute une règle serveur : si canonical ≠ URL courante, ne génère pas de hreflang sur cette page. Simple mais efficace pour éviter les incohérences en masse.

• Crawler le site et extraire canonical + hreflang de chaque page
• Vérifier que chaque cible hreflang correspond exactement à sa canonical
• Corriger les auto-références : chaque page doit canonicaliser vers elle-même ou vers une URL stable
• Implémenter hreflang uniquement sur les URLs canoniques, jamais sur les variantes
• Contrôler les rapports Search Console (Couverture internationale) chaque semaine
• Tester avec des user-agents géolocalisés pour valider l'affichage des bonnes versions