# SEO international : quand Google donne des résultats inattendus malgré un HREFLANG correct

> URL: https://4eck-media.de/fr/blog/12166/  
> Language: fr  
> Description: Les attributs HREFLANG sont corrects, mais Google désigne d’autres URL comme canoniques ? Voici une explication.

---

Pour les sites multilingues et le SEO international, l’[implémentation correcte de l’attribut hreflang](https://4eck-media.de/fr/https://4eck-media.de/fr/blog/12172/) représente souvent un défi. Cet attribut est censé aider les moteurs de recherche à sélectionner la bonne version linguistique et nationale d’une page pour les utilisateurs. Mais même avec une mise en œuvre correcte, des résultats inattendus peuvent apparaître lorsque l’on a créé différentes versions pays pour la même zone linguistique, comme c’est le cas pour l’Autriche, l’Allemagne et la Suisse, ou pour l’Angleterre, les États-Unis, l’Australie, etc. Ce **problème HREFLANG** se manifeste alors dans la Search Console.

Dans la Search Console, l’indication apparaît alors selon laquelle, à l’indexation, l’**URL canonique** indiquée par l’utilisateur n’a pas été utilisée, mais une autre URL a été choisie par Google comme canonique. Exemple — ici l’URL a été anonymisée via les DevTools :

Même une attribution du contenu via des ccTLD (.de et .at) n’est d’aucune aide. Le problème peut aussi apparaître avec des Top-Level-Domains. Pour poursuivre l’exemple fictif :

## Le mécanisme derrière le problème

Ce comportement inattendu de Google peut survenir lorsque le crawler indexe des pages de différents pays dont le contenu est très similaire. Un exemple : Google crawle d’abord la version allemande (DE) d’une page, calcule la valeur de hash et indexe la page avec l’URL DE comme version canonique. Quand Google crawle ensuite la version autrichienne (AT) de la page, il recalcule la valeur de hash et constate qu’elle est identique à celle de la version DE déjà indexée. Au lieu d’indexer séparément l’URL AT, Google l’ajoute au document existant.

Le hashing est une technique que Google utilise pour indexer plus efficacement le contenu des pages web et détecter les doublons. Une valeur de hash est une valeur unique et cryptographique (une sorte d’empreinte digitale), créée par une fonction de hash à partir du contenu d’une page. Si deux pages ont la même valeur de hash, cela indique que leur contenu est identique ou très similaire. On peut tenir pour acquis que Google utilise [**SimHash lors du crawling**](https://4eck-media.de/fr/https://static.googleusercontent.com/media/research.google.com/de//pubs/archive/33026.pdf).

### SimHash pour comparer les contenus et détecter les doublons

SimHash est une technique particulière que Google utilise pour analyser et comparer efficacement les contenus, en particulier pour détecter le **Duplicate Content**. SimHash permet de vérifier rapidement la similarité de grandes quantités de données, sans avoir à comparer en entier chaque contenu.

SimHash fonctionne en extrayant certaines **caractéristiques (features)** d’un texte, par exemple des mots, des phrases ou des structures fréquents. Ces caractéristiques sont **converties en un vecteur** qui représente les propriétés principales du texte. Après la vectorisation, le **hashing** intervient. À partir de ce vecteur, une fonction de hash produit une séquence de bits plus courte (le SimHash). L’astuce : des textes similaires conduisent à des valeurs SimHash similaires, ce qui permet d’identifier rapidement des contenus similaires ou quasi identiques.

Google utilise SimHash pour la Duplicate Content Detection, c’est-à-dire pour détecter rapidement et efficacement les contenus dupliqués ou très similaires sur différents sites. Si deux pages ont une valeur SimHash proche, Google peut s’en servir comme indicateur que les contenus sont très similaires et n’inclure éventuellement qu’une version de la page dans l’index de recherche.

Au lieu de mener une analyse textuelle complète à chaque crawl, Google peut, grâce à SimHash, vérifier rapidement si le contenu d’une page diffère significativement d’autres contenus. Cela économise des ressources et accélère le processus de crawl et d’indexation.

Un aspect important de SimHash est sa capacité à reconnaître des contenus similaires via la **distance de Hamming**. La distance de Hamming mesure le nombre de positions de bits où deux valeurs SimHash diffèrent. Une faible distance de Hamming entre deux valeurs SimHash signifie que les contenus correspondants sont très similaires. Contrairement aux méthodes de hash traditionnelles, où la moindre modification du contenu peut entraîner une valeur de hash totalement différente (résistance aux collisions), SimHash produit des valeurs de hash similaires pour des contenus similaires, ce qui le rend particulièrement utile pour la détection de contenu quasi identique.

Des pages ayant des valeurs SimHash similaires pourraient donc être pénalisées dans le classement, considérées comme du Duplicate Content ou comme moins originales, Google souhaitant afficher dans ses résultats des contenus uniques et de haute qualité.

Au passage : SimHash peut aussi être utilisé par les exploitants de très grands sites qui font beaucoup de spinning de texte ou de Programmatic SEO dans la création de contenu, pour comparer automatiquement les contenus et mesurer le degré de Duplicate Content.

## Pourquoi hreflang ne fonctionne parfois pas

Google utilise donc — vraisemblablement parmi d’autres procédés — SimHash pour analyser le contenu des pages et déterminer si elles sont des doublons. Si deux pages, comme les versions DE et AT, ont la même valeur SimHash, Google les considère comme identiques et choisit une URL canonique, indépendamment des balises hreflang. Les balises hreflang, tout comme les attributs html-lang ou les Canonical Tags, ne sont pas contraignantes pour Google, contrairement par exemple aux balises noindex ou aux instructions du robots.txt. Google fait donc ce qu’il estime juste, du point de vue de la meilleure expérience utilisateur. La désignation de l’URL canonique repose sur différents facteurs : nombre de liens entrants, signaux utilisateurs positifs et autres critères. Cette URL canonique est affichée comme telle dans la Google Search Console (GSC) et reçoit l’attribution de **tout le trafic**.

Cela ne signifie toutefois pas nécessairement que les utilisateurs voient toujours cette URL canonique dans les résultats. Google affiche en réalité l’URL la plus pertinente pour l’utilisateur — ce qui n’est pas toujours l’URL canonique. Oui, je sais, cela paraît complexe, voire contradictoire.

Si de petites différences existent entre les pages — comme un petit module présent sur une page et absent sur l’autre — cela peut conduire à une distinction suffisamment grande pour que les pages soient considérées comme du **contenu propre**. Mais même une différence minime dans les directives des moteurs de recherche, ou un changement de contenu ou de design, peut amener Google à traiter les pages différemment ou à les regrouper.

Parfois, le comportement de Google est vraiment remarquable. Je connais personnellement l’exemple d’une boutique en ligne de meubles disponible à la fois en .at pour les clients autrichiens et en .de pour les clients allemands. Selon la Search Console, Google a choisi l’URL .at comme URL canonique au lieu de la .de, alors même que la page allemande avait défini la .de comme URL canonique.

Le cas est devenu particulièrement étrange lorsque la boutique de meubles a mis le produit hors ligne sur le site .at et que la page renvoyait une 404.

L’URL est toujours dans l’index et conduit à une page 404, tandis que la page allemande propose encore le produit, mais n’est pas dans l’index.

La page .de affiche encore le contenu, même si l’article y est en rupture de stock. Il est néanmoins étonnant que Google ait la page 404 dans l’index et pas le pendant allemand avec un contenu disponible.

## Comment ce problème influence les données de la GSC

Le comportement décrit par Google, qui consiste à regrouper différentes versions pays d’une page et à choisir une URL canonique, a un impact direct sur la **lisibilité des données** dans la Google Search Console (GSC). Ce problème fait que les données de performance affichées dans la GSC ne reflètent pas toujours la réalité des résultats de recherche.

Quand Google reconnaît différentes versions pays d’une page comme doublons et en choisit une comme URL canonique, l’ensemble du trafic reçu par les différentes versions est attribué, dans la GSC, à l’URL canonique. Cela signifie que la GSC peut n’afficher que les données de trafic de la version DE d’une page, alors que des utilisateurs en Autriche ont en fait vu la version AT. Cela fausse les données et complique la mesure correcte du succès de chaque version pays.

Les données de classement peuvent aussi être affectées. Si Google désigne par exemple l’URL AT comme canonique, mais affiche tout de même aux utilisateurs en Allemagne la version DE, les données de ranking dans la GSC peuvent être tout aussi trompeuses. Cet écart vient du fait que les données GSC reposent sur l’URL canonique, tandis que les résultats de recherche réels peuvent afficher une autre URL.

Dans la GSC, on a l’impression qu’une seule URL performe, alors qu’en réalité plusieurs URL s’affichent dans différents pays. Cela complique l’analyse et la compréhension de la performance par pays, en particulier quand les entreprises appliquent des contenus ou des optimisations spécifiques à chaque marché.

Ce comportement de Google oblige les équipes SEO à adapter leurs approches d’analyse. Plutôt que de se fier exclusivement aux données affichées dans la GSC, on peut recourir à des outils externes pour vérifier quelle URL apparaît effectivement dans les résultats de recherche selon les pays. Il peut aussi être nécessaire d’examiner de plus près les filtres de la GSC, par exemple par une analyse par pays et par répertoire pays, pour obtenir une image plus claire de la performance réelle sur chaque marché. Les **requêtes regex dans la Search Console** peuvent aussi être utiles ici. Je publierai bientôt un article séparé à ce sujet.

## Stratégies de résolution

L’idéal serait que Google considère chaque variante langue-pays comme une URL canonique. Comme on le voit, ce n’est pas garanti pour des langues identiques. Une approche possible est de **questionner la nécessité des variantes pays** et de vérifier s’il est plus pertinent de ne créer qu’une version pour les marchés linguistiquement identiques. C’est particulièrement utile quand les différences entre pays sont minimes. S’il n’y a même pas de différence de monnaie — comme entre l’Allemagne (Euro) et la Suisse (Franc) — créer pour l’Autriche en Euro un répertoire supplémentaire /de-AT/ avec des contenus dupliqués a peu de sens.

On peut très facilement mesurer à quel point Google limite l’indexation via une requête inurl: dans Google. Exemple ci-dessous : la sitemap du site contient 644 pages pour /de-CH/ et 1 312 pour /de-DE/. Dans l’index, on en trouve nettement moins. De plus, ce site possède un autre répertoire /de-AT/. On peut supposer que beaucoup de pages ne sont pas dans l’index et que d’autres sont regroupées dans une URL canonique unique pour la langue allemande.

Certains outils SEO signalent également, après un crawl, du Duplicate Content. C’est pourquoi, là où il n’y a pas de différences de contenu, d’offre, de livraison ou d’autres particularités par pays, mieux vaut s’appuyer sur les répertoires linguistiques et regrouper Allemagne, Autriche et Suisse sur /de/.

Une autre stratégie — et probablement la meilleure — pour parvenir à la canonisation des URL souhaitées consiste à **différencier davantage les contenus**. Même si la langue est identique, des différences au niveau des métadonnées, du contenu principal ou du parcours utilisateur peuvent aider à convaincre l’algorithme Google qu’il s’agit de contenus propres, chacun rattaché à une région spécifique. On peut par exemple travailler avec des variables qui saluent les visiteurs de chaque pays : « Bienvenue depuis , ravis de vous accueillir ». La  est alors remplacée : Autriche pour de-at, Allemagne pour de-de, Suisse pour de-ch, etc. Idem avec « nos conditions de livraison pour  ». Plus le contenu est différencié, plus la valeur de hash est individuelle, plus Google a de chances de désigner chaque page comme une URL canonique propre.

Une troisième approche : utiliser les balises hreflang dans les sitemaps, ce qui conduit parfois à une attribution plus claire par Google. Nous-mêmes diffusons nos balises hreflang dans la sitemap et nous limitons à la variante linguistique pure, sans code pays.

Le moyen le plus efficace reste, à mon avis, de différencier autant que possible les contenus, afin d’envoyer à Google des signaux clairs indiquant qu’il s’agit de pages distinctes.