Le site montre à un utilisateur anglophone des États-Unis une page, tandis que Googlebot, qui se trouve physiquement dans le centre de données de Mountain View, en voit une toute autre. Formelement, c'est déjà du cloaking, même si vous vouliez simplement adapter le contenu à la région. Nous examinons 6 erreurs typiques de redirections géographiques qui font que les sites perdent des positions, reçoivent des sanctions manuelles et se font bannir des domaines entiers dans les réseaux partenaires.
Qu'est-ce qu'une redirection géographique et pourquoi est-elle nécessaire pour les entreprises
La redirection géographique est un mécanisme qui redirige automatiquement l'utilisateur vers la version du site adaptée à son pays : une autre langue, une autre monnaie, des prix, des offres. Les boutiques en ligne l'utilisent pour que l'acheteur d'Allemagne accède directement à la version allemande avec des prix en euros, plutôt que de parcourir un catalogue en dollars. Les arbitragistes utilisent des redirections géographiques dans des combinaisons pour montrer une offre différente en fonction du trafic géographique — par exemple, un landing page pour les utilisateurs des pays de Tier-1, et un autre produit ou une page d'attente pour les autres.
Le problème est que la même logique qui détermine le pays de l'utilisateur par IP s'applique également à Googlebot. Et les adresses IP des bots Google se trouvent physiquement aux États-Unis, peu importe s'ils indexent une page pour les résultats russes, kazakhs ou allemands. Si le système de redirection géographique ne distingue pas le crawler d'un être humain, le résultat est le même — Google voit une page différente de celle que voient les visiteurs réels. C'est une définition formelle du cloaking selon les recommandations de Google Search Central, et la sanction pour cela va de la baisse dans les résultats à l'exclusion totale du domaine de l'index.
Pourquoi Googlebot et un humain voient des pages différentes
L'écart se produit pour trois raisons simultanément, et elles se chevauchent généralement. Premièrement, Googlebot explore le site à partir d'adresses IP appartenant à Google, et ces adresses sont presque toujours identifiées par les services géographiques (MaxMind, IP2Location et similaires) comme américaines. Deuxièmement, Googlebot envoie son propre User-Agent, qui est souvent traité par une branche de code distincte — parfois intentionnellement, pour ne pas casser l'indexation, et parfois simplement par erreur du développeur. Troisièmement, le comportement de Googlebot lors du rendu JS diffère de celui du navigateur : le crawler peut ne pas exécuter la redirection qui dépend de JavaScript côté client, et alors il indexe une version de la page complètement différente de celle que voit une personne avec JS activé.
Ajoutez à cela le cache CDN, qui peut « se bloquer » sur la version d'un pays et la distribuer à tout le monde, et vous obtiendrez une situation où, même sans mauvaise intention de la part du propriétaire du site, le moteur de recherche indexe un contenu qui ne correspond pas à ce que voit l'audience. Ci-dessous, six scénarios spécifiques dans lesquels cela se produit le plus souvent.
Erreur 1 : redirection par IP sans vérification de l'User-Agent du bot
L'erreur la plus fréquente est que la logique de redirection est uniquement basée sur la détermination du pays par IP, sans aucune vérification de qui fait la demande : un humain ou un crawler. En conséquence, Googlebot, accédant avec une plage d'IP américaine, se retrouve automatiquement sur la version US du site, même si la page était initialement promue pour des requêtes en provenance de Russie ou du Kazakhstan. Après quelques semaines de scan, l'index de Google se retrouve saturé par la « mauvaise » version du contenu, et les positions dans les régions cibles commencent à chuter sans raison apparente.
La solution consiste à toujours exclure les User-Agent et plages d'IP connus des bots de recherche (Googlebot, Bingbot, YandexBot) de la redirection géographique, leur fournissant la version canonique de la page indépendamment du pays déterminé. La vérification de l'User-Agent est une barrière nécessaire, mais pas suffisante, car elle est facilement falsifiable, donc les projets sérieux vérifient également l'IP via une requête DNS inversée, comme le recommande la documentation de Google pour la vérification de Googlebot.
Erreur 2 : test avec des IP de centres de données au lieu de réelles utilisateurs
La deuxième erreur se produit déjà au stade de la vérification. Un développeur ou un marketeur teste la redirection géographique via un proxy ou un VPN de centre de données ordinaire, et la logique s'active comme si c'était un véritable utilisateur du pays requis. Mais les IP de centres de données sont facilement distinguables du trafic domestique — de nombreux CDN et systèmes anti-fraude les marquent avec un drapeau distinct, et une partie de la logique de ciblage géographique peut se comporter différemment pour ces adresses que pour une IP domestique ordinaire.
En fin de compte, le test « passe », la redirection sur le serveur de développement fonctionne parfaitement, mais en production, les utilisateurs réels du pays cible obtiennent la mauvaise version, car la base de géolocalisation du fournisseur ou la règle CDN interprète leur IP différemment de l'adresse de centre de données de test. Pour une vérification correcte, il est conseillé d'utiliser des proxies résidentiels — ils ont des IP de véritables fournisseurs domestiques dans le pays requis, et les services géographiques les identifient comme ils le feraient pour un utilisateur réel. Cela donne une image honnête de ce que verra un véritable visiteur du site, et non une version simplifiée pour une IP de centre de données « typique ».
Erreur 3 : cache et absence d'en-têtes Vary
Si le site est derrière un CDN (Cloudflare, Fastly, Akamai) et que la redirection géographique est mise en œuvre au niveau du serveur d'origine, et non du CDN lui-même, il est facile de se retrouver dans une situation où le CDN met en cache la première version de la page renvoyée et la distribue à tout le monde — indépendamment du pays du prochain visiteur. Cela se produit lorsque la réponse du serveur ne contient pas l'en-tête correct Vary: Accept-Language ou une clé de cache similaire basée sur des critères géographiques.
Dans ce cas, Googlebot peut rencontrer la « bonne » version lors de sa première visite, la mettre en cache dans ses propres systèmes d'indexation, puis recevoir la même version lors de visites ultérieures pendant des semaines, même si le contenu pour d'autres pays a longtemps changé. Pendant ce temps, les utilisateurs voient une version actuelle, mais différente — le désynchronisation augmente progressivement et il est difficile de le diagnostiquer sans comparaison directe des réponses du serveur pour différentes géos via des outils comme curl avec substitution des en-têtes ou via un proxy avec la géolocalisation requise.
Erreur 4 : redirection JS que le bot interprète différemment
Googlebot peut exécuter JavaScript, mais le fait avec un retard significatif (la deuxième vague de rendu peut prendre des jours) et pas toujours de manière identique au navigateur de l'utilisateur. Si la redirection géographique est mise en œuvre via JS côté client — par exemple, via window.location après une requête fetch vers l'API geo — il y a un risque que lors du premier passage, le crawler indexe la page avant que la redirection ne s'active, c'est-à-dire la version « incorrecte » pour la région spécifique.
Cela est particulièrement critique pour les pages de destination à une seule page (SPA), où toute la logique de personnalisation est maintenue côté client. L'approche correcte consiste à effectuer la détermination géographique et la redirection côté serveur (fonction edge du CDN, middleware sur Node.js, règle dans Nginx), afin que Googlebot et l'utilisateur reçoivent une redirection HTTP 302 avant que la page ne commence à se rendre dans le navigateur. Cela élimine la dépendance à la manière dont le crawler traitera le JS à un moment donné.
Erreur 5 : une URL sans hreflang pour différentes versions linguistiques
La cinquième erreur est d'essayer de servir plusieurs versions linguistiques sur la même URL sans balisage hreflang. Google recommande explicitement : si le contenu sur une URL diffère selon la locale de l'utilisateur, il faut soit donner des URL différentes pour chaque version (sous-domaines, sous-dossiers ou domaines distincts) avec un balisage hreflang croisé, soit montrer honnêtement la même version à tous, y compris aux bots, en ajoutant la possibilité de changer manuellement la langue.
Sans hreflang, Google ne peut physiquement pas comprendre que /product en russe et /product en anglais sont intentionnellement un contenu différent pour des audiences différentes, et non une tentative de cacher une version de l'index au profit d'une autre. En conséquence, une version aléatoire (généralement celle qui était accessible au bot lors du dernier crawl) entre dans l'index, et c'est celle-ci qui commence à être classée dans toutes les régions simultanément, ce qui nuit à la pertinence des résultats et à la conversion.
Erreur 6 : pas de fallback pour les utilisateurs avec VPN et proxies mobiles
La sixième erreur concerne non seulement Googlebot, mais aussi les utilisateurs réels — mais elle est directement liée au sujet des redirections géographiques, car souvent, c'est la tentative de « réparer » le comportement pour les bots qui le casse pour les personnes vivantes avec un VPN ou Internet mobile. Les utilisateurs des opérateurs mobiles se connectent souvent à Internet via CGNAT (Carrier-Grade NAT), lorsque des dizaines de milliers d'abonnés utilisent la même IP externe, et la base géographique peut identifier cette IP comme appartenant à un pays voisin ou complètement à tort.
Si le site n'a pas de commutateur manuel de pays/langue comme fallback, un utilisateur avec une IP « mal » déterminée se retrouve bloqué sur une version non pertinente sans possibilité de la changer — et part simplement. Pour tester ce scénario, il est utile de vérifier le comportement du site via des proxies mobiles, qui émuleraient les IP de véritables opérateurs de téléphonie mobile avec un comportement de géolocalisation typique pour CGNAT — cela aide à voir le problème à l'avance, avant que les utilisateurs réels ne le découvrent et n'écrivent au support.
Comment vérifier la redirection géographique aux yeux de Google depuis différents pays
L'outil principal pour le diagnostic initial est la fonction « Voir comme Googlebot » dans Google Search Console (outil de vérification d'URL), qui montre quel HTML le crawler Google reçoit réellement. Si la version affichée n'est pas celle que vous voyez dans votre navigateur depuis votre pays, le problème est confirmé. Mais la Search Console explore toujours depuis des IP américaines, donc pour comparer le comportement du site par région, un niveau de test distinct est nécessaire.
En pratique, les marketeurs et les spécialistes SEO créent plusieurs profils dans un navigateur anti-détection — Dolphin Anty, AdsPower, Multilogin ou GoLogin — et associent à chaque profil un proxy du pays requis, afin de passer manuellement par le parcours utilisateur : ouvrir le site, voir quelle version s'est chargée, quel en-tête Accept-Language a été envoyé, si la redirection a fonctionné et vers quelle URL. Pour ces vérifications, des proxies résidentiels avec un choix précis de ville ou d'opérateur sont pratiques — ils offrent la simulation la plus honnête d'un visiteur réel, contrairement aux adresses de centres de données, que certains services peuvent marquer comme suspectes avant même d'évaluer la géo.
| Type de proxy | Pour quel type de vérification il convient | Risque de faux résultat |
|---|---|---|
| Proxies résidentiels | Simulation d'un utilisateur domestique ordinaire dans le pays/ville requis | Faible |
| Proxies mobiles | Vérification du comportement en cas de CGNAT et de géolocalisation mobile | Faible |
| Proxies de centres de données | Vérification rapide du fait que la redirection par pays fonctionne | Plus élevé : une partie des bases géographiques marque les IP différemment des domestiques |
Pour vérifier le comportement de la logique serveur (et non le rendu visuel), il est également utile de regarder la réponse brute du serveur via curl en remplaçant l'User-Agent par Googlebot et l'en-tête X-Forwarded-For par l'IP du pays requis — cela montrera quel statut HTTP et quelle Location le serveur renvoie avant tout rendu JS, et permettra de capturer l'erreur 4 et l'erreur 1 de la liste ci-dessus en une seule commande.
Liste de contrôle pour une configuration sécurisée des redirections géographiques
- Googlebot, Bingbot et YandexBot exclus de la logique de redirection géographique par User-Agent et confirmés via DNS inversé
- La redirection est mise en œuvre côté serveur (302/307), et non seulement via JavaScript côté client
- En-tête
Varyconfiguré pour un cache CDN correct par géo/langue - Chaque version linguistique a une URL distincte avec un balisage hreflang croisé
- Un commutateur manuel de pays/langue visible comme fallback pour les IP mal déterminées
- Les tests sont effectués via des proxies résidentiels et mobiles des pays requis, et non uniquement via des adresses de centres de données
- Une fois par trimestre, vérifiez ce que montre Google Search Console — la version correspond à ce que voient les utilisateurs réels
Conclusion
L'écart entre ce que voit Googlebot et ce que voit un utilisateur est rarement une tromperie intentionnelle du moteur de recherche — c'est souvent une dette technique accumulée : redirection par IP sans vérification du bot, cache sans en-tête Vary, redirection JS que le crawler n'a pas le temps d'exécuter, et absence de hreflang pour les versions linguistiques. Chacune de ces erreurs semble insignifiante séparément, mais ensemble, elles créent un tableau classique de cloaking aux yeux de Google — avec les sanctions qui en découlent.
Le seul moyen fiable de s'assurer que le site se comporte de manière équitable tant pour les bots que pour les humains est de le vérifier régulièrement avec de véritables IP des pays requis. Pour ce diagnostic, nous recommandons d'utiliser des proxies résidentiels pour simuler un utilisateur domestique typique et des proxies mobiles pour vérifier les scénarios avec CGNAT — cela donne une image aussi honnête que possible de ce que voit réellement votre audience dans chaque région et aide à détecter le problème avant que l'algorithme de Google ne le trouve.