Un client m'appelle en panique. Sa version allemande a disparu de Google. Pas pénalisée, pas désindexée manuellement : disparue. Trois semaines plus tôt, son développeur avait « optimisé » les redirections de langue pour que ça aille plus vite. Résultat : Googlebot se faisait rediriger vers la version française depuis les IP américaines, et les pages allemandes avaient cessé d'être explorées. Le site n'avait pas de problème de traduction. Il avait un problème de crawl.
Voilà le vrai piège du site multilingue en référencement technique : tout le monde parle de contenu, de localisation, de mots-clés par marché. Très bien. Mais les dégâts que je répare chez mes clients viennent presque toujours d'ailleurs — d'une balise, d'un en-tête HTTP, d'un réglage de plugin qu'on a activé sans lire la doc.
Points clés à retenir
- Le hreflang doit être réciproque : une seule balise manquante et la paire est ignorée.
- Rediriger par géo-IP casse le crawl. Googlebot n'explore pas depuis le pays de vos visiteurs.
- Les balises canonical ne doivent jamais pointer d'une langue vers une autre.
- Un code langue seul (
fr) n'est pas équivalent à un code langue-région (fr-FR). - Chaque version linguistique doit être joignable en moins de trois clics depuis sa propre racine.
Les pièges du site multilingue en référencement technique : ce qui casse vraiment
Sur les dix dernières années, j'ai audité une cinquantaine de sites multilingues. Le constat est stable : environ un tiers d'entre eux ont au moins une version linguistique qui souffre d'un problème d'indexation non détecté par leur équipe. Personne ne le voit parce que personne ne regarde la bonne chose. On surveille les positions sur les mots-clés français, on oublie de vérifier si la page italienne est seulement dans l'index.
La réciprocité du hreflang, le piège le plus fréquent
Le mécanisme est impitoyable. Si la page A déclare « ma version allemande est là », mais que la page allemande ne déclare pas « ma version française est là », les deux annotations sont ignorées. Pas d'erreur, pas d'alerte. Juste un signal qui ne sert à rien.
Je l'ai encore vu le mois dernier sur un site de e-commerce : 14 langues, 3 800 pages, et une seule version (la polonaise) qui avait oublié le lien de retour vers le français. Cette paire était morte pour Google. Le trafic polonais existait, mais les clusters de versions ne se formaient pas correctement, et les pages se concurrençaient entre elles dans les résultats.
Autre subtilité que je vois régulièrement ratée : x-default. Cette valeur désigne la page de repli quand aucune version linguistique ne correspond à l'internaute. Elle n'est pas obligatoire, mais si vous l'utilisez, elle doit renvoyer vers une page réelle — souvent la version anglaise ou une page de sélection de langue. Beaucoup de sites la placent sur une URL qui redirige, ce qui l'invalide.
Codes langue et codes langue-région : la confusion coûteuse
fr et fr-FR ne veulent pas dire la même chose. Le premier cible tous les francophones, le second la France uniquement. Si vous servez une version belge distincte, vous devez déclarer fr-BE, et la version française générique doit rester fr ou fr-FR selon votre stratégie — mais surtout, vous ne pouvez pas déclarer deux fois la même valeur pour des URL différentes. J'ai déjà vu un site avec trois balises fr pointant vers trois pages : Google en choisit une au hasard et ignore les autres.
Et le format doit être strict : code langue en minuscules, code région en majuscules, séparateur tiret. Pas d'underscore. Une balise hreflang="fr_FR" est silencieusement rejetée.
Les pannes d'infrastructure que personne ne surveille
Le contenu est propre. Les balises sont là. Et pourtant rien ne se passe. C'est là qu'il faut regarder sous le capot.
La redirection par géo-IP, ce faux ami
Le principe semble évident : un visiteur japonais arrive, on le redirige vers la version japonaise. Sauf que Googlebot n'explore pas votre site depuis Tokyo. Il crawle majoritairement depuis des IP américaines. Résultat : vos pages japonaises sont redirigées vers le français, et Google conclut que le contenu japonais n'existe pas.
Ce n'est pas du cloaking volontaire, mais l'effet est le même. La parade est simple : ne jamais rediriger sur la base de l'IP, et laisser le choix de la langue à l'utilisateur (bannière, sélecteur) tout en gardant chaque version accessible directement par son URL. Si vous tenez absolument à la redirection, elle doit exclure les agents d'exploration — ce qui est fragile et que je déconseille.
Les chaînes de redirection lors du changement de langue
Un cas concret : le sélecteur de langue envoie vers /de/, qui redirige en 301 vers /allemand/, qui redirige vers /de-de/. Trois sauts. Google explore chacun d'eux. Le budget de crawl part en fumée sur des URL inutiles. Sur un site à 12 langues et 5 000 pages, j'ai mesuré une perte de près de 40 % du budget de crawl consommé par ces chaînes seules.
Règle simple : une redirection, un saut. Jamais de chaîne. Et évitez les 302 pour les changements de langue : si la nouvelle URL est définitive, c'est 301.
Les cookies de préférence qui cassent le crawl
Un site m'a occupé deux semaines. La version espagnole était bien indexée, mais le taux de clics s'effondrait. En cause : un cookie de préférence linguistique qui, une fois posé, forçait la redirection vers la version précédemment visitée. Googlebot, sans cookie, arrivait bien sur la page espagnole. Mais les utilisateurs qui avaient visité la version française étaient redirigés vers le français même en cliquant sur un lien espagnol. Google voyait un taux de rebond anormal et a fini par déclasser la page.
La préférence linguistique doit être un souvenir, pas une contrainte. Un utilisateur qui clique explicitement sur une URL espagnole doit rester sur cette URL.
Les canonical croisés entre langues, erreur classique et destructrice
Le raisonnement erroné est séduisant : « mes versions fr/de/it disent la même chose, donc je mets un canonical vers le français ». Non. Trois fois non. La balise canonical sert à désigner la version préférée d'un contenu dupliqué. Une traduction n'est pas un duplicata : c'est un contenu distinct pour un public distinct.
Si vous placez un canonical croisé, vous demandez à Google de ne pas indexer la version allemande. Elle disparaît. J'ai vu un site perdre 60 % de son trafic multilingue en un mois à cause d'un plugin de traduction qui posait automatiquement un canonical vers la langue source. Le développeur était convaincu de bien faire.
La bonne configuration : chaque page se canonise elle-même. Toujours.
| Pratique | Effet | Verdict |
|---|---|---|
| Canonical de soi vers soi | Indexation normale de chaque version | Correct |
| Canonical croisé vers la langue source | Désindexation des versions traduites | À proscrire |
| Redirection géo-IP pour tous | Googlebot bloqué hors version locale | À proscrire |
| Redirection 301 directe (un saut) | Signal clair, budget préservé | Correct |
| Hreflang non réciproque | Annotation ignorée, clusters cassés | À corriger |
Le cas des CMS et plugins de traduction
Sur WordPress, WPML et Polylang sont les deux options les plus répandues. Le piège n'est pas le plugin : c'est le réglage par défaut que personne ne vérifie.
- WPML crée par défaut des URL avec le paramètre
?lang=fr. Fonctionnel, mais le code langue n'apparaît pas dans le chemin, ce qui complique la lecture pour Google et pour tout audit rapide. - Polylang, en mode sous-répertoire, nécessite une vérification manuelle de la structure des slugs — un article français peut se retrouver avec un slug anglais si l'option de synchronisation est mal configurée.
- Les plugins ajoutent fréquemment leurs propres balises hreflang. Si vous en ajoutez aussi manuellement dans le
<head>, vous créez des doublons que Google ignore.
J'ai perdu une journée entière sur un site PrestaShop où deux modules concurrents posaient des hreflang contradictoires. Google ne s'y retrouvait pas. Le correctif a été de désactiver l'un des deux modules et de tout centraliser sur le <head>.
Une checklist de contrôle pour votre site multilingue
Quand j'audite un site multilingue, je passe systématiquement par ces vérifications. Elles prennent une heure et révèlent presque toujours un problème :
- Vérifier la réciprocité du hreflang : chaque page doit déclarer toutes ses sœurs, y compris elle-même.
- Tester chaque version dans la console de recherche du moteur avec l'outil d'inspection d'URL — la version est-elle bien indexée ?
- Contrôler les en-têtes HTTP : pas de redirection par IP, pas de chaînes.
- Chercher les canonical croisés entre langues.
- Vérifier les codes hreflang (format langue-région strict).
- Regarder le crawl : le budget est-il consommé par des URL de redirection ?
- Vérifier les cookies de préférence linguistique ne forcent pas la navigation.
Un dernier point, souvent négligé : les versions linguistiques doivent rester accessibles en profondeur de clic raisonnable depuis leur propre racine. Si la page allemande d'accueil renvoie à la page allemande « à propos » en trois clics parce qu'un menu a été mal traduit, le crawl s'en trouve affecté — et l'internaute aussi.
Un piège qui ne se voit pas dans les outils
Et puis il y a la panne invisible : celle qui n'apparaît dans aucun audit automatique. Un site parfait techniquement, dont la version italienne est vide parce que les traducteurs ont été payés à la page et que les pages ont été mises en ligne sans relecture. Google ne pénalise pas, il ignore simplement. Le contenu existe, il est indexable, mais il ne répond à aucune recherche réelle. Ce n'est plus du référencement technique, c'est du bon sens éditorial. Mais c'est dans le même audit.
La prochaine fois que vous lancez une version linguistique, ne demandez pas seulement « c'est traduit ? ». Demandez « c'est crawlable ? ». La différence entre un site multilingue qui fonctionne et un site qui cache sa moitié dans les limbes tient souvent à une balise. Une seule.
Ce que je vérifie en premier sur un site multilingue inconnu
La profondeur de crawl de chaque version depuis sa racine, puis la réciprocité hreflang. Ces deux points couvrent à eux seuls la majorité des cas où une version linguistique existe sans être réellement visible.
