En date du 7 octobre 2026, Shifter dispose du plus grand pool d'IP US actives, devant Oxylabs et Bright Data, pour une fraction du coût.Shifter a désormais le plus grand pool d'IP US actives

Voir les benchmarks

Base de connaissances

Cloaking SEO : définition et détection depuis plusieurs localisations

Ce qu'est le cloaking SEO, ce que Google considère ou non comme du cloaking, et comment le détecter sur votre site ou celui d'un concurrent en comparant les réponses selon le user agent, le référent et la localisation.

Daniel Okafor

18 octobre 2026 · 11 min de lecture

Le cloaking SEO consiste à montrer une version d’une page aux moteurs de recherche et une autre aux internautes. Le robot reçoit une page propre, riche en mots-clés, qui se positionne bien ; le visiteur qui clique obtient autre chose, souvent une redirection, une offre différente ou du spam pur et simple. Google cite le cloaking dans ses règles relatives au spam, et un site pris sur le fait peut perdre ses positions sur certaines pages ou sur l’ensemble du domaine.

La plupart des équipes découvrent le cloaking en position défensive : un site piraté qui se positionne sur des requêtes pharmaceutiques ou de casino que son propriétaire n’a jamais vues, ou un concurrent dont la page classée ne correspond pas à ce que promettait l’extrait. Dans les deux cas, le repérer relève du suivi SEO : vous devez voir la page telle que chaque type de visiteur la voit, puis comparer.

Ce qui constitue du cloaking

La définition de Google repose sur l’intention : présenter un contenu différent aux utilisateurs et aux moteurs de recherche afin de manipuler le classement et de tromper les utilisateurs. Parmi ses propres exemples figurent le fait de servir au robot une page sur des destinations de voyage alors que les visiteurs reçoivent une page sur des médicaments à prix cassés, ou encore l’insertion de texte ou de mots-clés uniquement lorsque le demandeur est un moteur de recherche.

Le mécanisme est toujours le même. Le serveur, ou un script sur la page, décide de ce qu’il envoie en fonction de l’identité apparente du demandeur. Les signaux utilisés sont les suivants :

  • User agent. La version grossière : tout ce qui se présente comme « Googlebot » reçoit la page propre.
  • Adresse IP. La version soignée : les requêtes provenant des plages publiées des robots de Google, vérifiées par DNS inverse, reçoivent la page propre, si bien qu’un user agent usurpé ne suffit pas à la débloquer.
  • Référent. Les visiteurs qui arrivent depuis une page de résultats Google sont redirigés ; ceux qui saisissent l’URL, y compris le propriétaire du site, voient un site normal.
  • Localisation et réseau. Les visiteurs du pays ciblé sur des connexions domestiques reçoivent la charge malveillante ; les plages de bureaux, de cloud et de datacenters reçoivent la version propre, car c’est de là que viennent les examinateurs et les scanners de sécurité.
  • Appareil. Certains dispositifs ne redirigent que les visiteurs mobiles, car c’est là qu’ils monétisent.

La plupart des cas réels combinent deux ou trois de ces signaux, ce qui explique pourquoi une simple vérification depuis votre bureau ne montre généralement rien.

Ce qui n’est pas du cloaking

De nombreuses configurations légitimes servent des réponses différentes selon les visiteurs. Google les accepte tant que le robot voit ce que verrait un utilisateur comparable :

  • Personnalisation géographique et linguistique. Afficher les prix en euros aux visiteurs situés en Allemagne n’est pas du cloaking. Traiter Googlebot différemment d’un utilisateur situé au même endroit en serait. Notre guide sur les résultats Google localisés explique comment la localisation modifie ce que voient les internautes.
  • Paywalls et contenu réservé. Google documente des données structurées pour le contenu payant précisément afin que les éditeurs puissent montrer l’article complet au robot sans que cela soit considéré comme du cloaking.
  • Mises en page propres à chaque appareil. Un balisage différent pour mobile et ordinateur ne pose pas de problème lorsque le contenu principal est équivalent.
  • Rendu pour les robots. Servir du HTML pré-rendu aux robots était autrefois recommandé pour contourner les problèmes liés au JavaScript lourd. Google parle désormais d’une solution de contournement plutôt que d’une solution durable, mais ce n’est pas du cloaking lorsque le contenu est identique.

Pour chacun de ces cas, le critère est le même : un utilisateur réel placé dans la position du robot obtiendrait-il le même contenu ?

Pourquoi une vérification depuis un seul endroit ne suffit pas

Une page avec cloaking est conçue pour paraître propre précisément aux personnes les plus susceptibles de la vérifier. Cela vous laisse trois angles morts :

  1. Vous faites partie du public exclu. Si vous vérifiez votre propre site en étant connecté, depuis le bureau ou en saisissant l’URL, un piratage basé sur le référent ne se manifestera jamais. Les propriétaires de sites l’apprennent souvent par Search Console ou par leurs clients.
  2. Vous ne pouvez pas être Googlebot. Envoyer un user agent Googlebot ne détecte que le cloaking grossier. Tout dispositif qui vérifie l’IP du robot vous traitera comme un utilisateur.
  3. Vous n’êtes pas sur le bon marché ni sur le bon réseau. Un dispositif qui ne se déclenche que pour les visiteurs mobiles d’un pays donné sur des connexions domestiques reste invisible depuis un serveur cloud situé ailleurs.

La détection est donc une comparaison, menée depuis suffisamment de points d’observation pour couvrir les conditions que filtre le cloaking.

Une méthode de détection

Étape 1 : obtenir d’abord la vue de Google. Dans Search Console, le test en direct de l’outil URL Inspection récupère la page en tant que Googlebot depuis l’infrastructure de Google et affiche le HTML rendu ainsi qu’une capture d’écran. Le Rich Results Test fait de même pour les pages qui ne vous appartiennent pas. C’est le seul moyen fiable de voir la version destinée au robot, car elle provient d’une véritable IP de Googlebot.

Étape 2 : collecter les vues utilisateur. Récupérez la même URL comme le ferait un visiteur ordinaire, en ne modifiant qu’une condition à la fois :

VarianteUser agentRéférentRéseau
RéférenceNavigateur de bureauaucunvotre bureau
Depuis la rechercheNavigateur de bureaupage de résultats google.comvotre bureau
Mobile depuis la rechercheNavigateur mobilepage de résultats google.comIP domestique dans le pays ciblé
Bureau depuis la recherche, marchéNavigateur de bureaupage de résultats google.comIP domestique dans le pays ciblé
Test robot grossierChaîne Googlebotaucunvotre bureau

Les lignes avec IP domestique sont celles où un proxy résidentiel intervient : une connexion de particulier dans le pays testé, pour que la requête ressemble aux visiteurs qu’attend le dispositif. Gardez des paramètres régionaux, un fuseau horaire et une langue cohérents avec le pays de sortie, comme l’explique notre guide sur l’alignement de la géolocalisation, du fuseau horaire et des paramètres régionaux du proxy, sinon un dispositif bien conçu vous traitera comme une anomalie.

Étape 3 : comparer ce qui compte. Le HTML brut diffère entre deux requêtes quelconques à cause des jetons et des horodatages. Comparez les éléments qui influencent le classement ou l’expérience du visiteur :

  • l’URL finale après redirections, et chaque étape de la chaîne ;
  • le titre, la meta description, la balise canonical et les directives robots ;
  • le texte principal, normalisé et haché ;
  • les liens sortants, en particulier vers des domaines inconnus.

Étape 4 : répéter. Les piratages et les dispositifs des concurrents ne se déclenchent souvent que pour une partie des visites, ou seulement à certaines heures. Un seul résultat propre est une preuve faible. Exécutez la matrice plusieurs fois, avec différentes sorties et à différents moments de la journée, avant de conclure qu’une page est saine.

Voici un script de comparaison minimal. Définissez PROXY_URL sur une passerelle résidentielle avec ciblage par pays, et ajoutez des variantes pour chaque marché qui vous intéresse :

import hashlib, os, re
import requests

URL = "https://example.com/some-page"
DESKTOP = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0 Safari/537.36"
MOBILE = "Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Mobile/15E148 Safari/604.1"
GOOGLEBOT = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
SERP = "https://www.google.com/"
RESI = {"http": os.environ["PROXY_URL"], "https": os.environ["PROXY_URL"]}

VARIANTS = {
    "baseline": dict(ua=DESKTOP, ref=None, proxies=None),
    "from_search": dict(ua=DESKTOP, ref=SERP, proxies=None),
    "mobile_market": dict(ua=MOBILE, ref=SERP, proxies=RESI),
    "desktop_market": dict(ua=DESKTOP, ref=SERP, proxies=RESI),
    "googlebot_ua": dict(ua=GOOGLEBOT, ref=None, proxies=None),
}

def tag(html, pattern):
    m = re.search(pattern, html, re.I | re.S)
    return m.group(1).strip() if m else ""

def fingerprint(ua, ref, proxies):
    headers = {"User-Agent": ua, "Accept-Language": "en-US,en;q=0.9"}
    if ref:
        headers["Referer"] = ref
    r = requests.get(URL, headers=headers, proxies=proxies, timeout=30)
    html = r.text
    text = re.sub(r"<script.*?</script>|<style.*?</style>|<[^>]+>", " ", html, flags=re.S)
    text = re.sub(r"\s+", " ", text).strip().lower()
    return {
        "final_url": r.url,
        "hops": [h.headers.get("Location", "") for h in r.history],
        "title": tag(html, r"<title[^>]*>(.*?)</title>"),
        "canonical": tag(html, r'<link[^>]+rel=["\']canonical["\'][^>]+href=["\']([^"\']+)'),
        "robots": tag(html, r'<meta[^>]+name=["\']robots["\'][^>]+content=["\']([^"\']+)'),
        "text_hash": hashlib.sha256(text.encode()).hexdigest()[:12],
    }

results = {name: fingerprint(**v) for name, v in VARIANTS.items()}
base = results["baseline"]
for name, res in results.items():
    diffs = [k for k in res if res[k] != base[k]]
    print(f"{name:15} {'SAME' if not diffs else 'DIFFERS: ' + ', '.join(diffs)}")

Une différence portant uniquement sur text_hash peut relever d’une personnalisation inoffensive. Une final_url différente, une nouvelle étape de redirection ou un titre qui n’apparaît que pour les visiteurs venant de la recherche, voilà ce qui mérite une enquête. Comparez ensuite les vues utilisateur avec le HTML issu du test en direct de URL Inspection.

Que faire en cas de découverte

Sur votre propre site, traitez d’abord la situation comme un incident de sécurité. Un cloaking basé sur le référent ou l’IP sur un site que vous n’avez pas conçu ainsi signifie presque toujours une compromission : règles serveur injectées, plugin ou thème modifié, ou script ajouté au gabarit. Supprimez le code, colmatez la faille qui l’a laissé entrer, puis demandez un réexamen dans Search Console si Google a appliqué une action manuelle. Relancez ensuite la matrice de comparaison, depuis les mêmes marchés, pour confirmer sa disparition.

Sur le site d’un concurrent, documentez avant de signaler. Capturez la version du robot via le Rich Results Test, les versions utilisateur avec horodatage, pays de sortie et appareil, ainsi que la chaîne de redirection complète. Google accepte les signalements de spam via son formulaire de signalement sur la qualité de la recherche. Pour la version de ce comportement dans la recherche payante, notre guide sur la détection des annonces avec cloaking et ciblage géographique couvre le volet publicitaire.

Continuez la surveillance. Les piratages reviennent lorsque le point d’entrée n’est pas corrigé, et ils réapparaissent généralement sur les pages les mieux classées. Une exécution hebdomadaire de la matrice sur vos principales pages d’atterrissage, depuis les pays qui vous envoient du trafic organique, constitue une alerte précoce peu coûteuse.

FAQ

Le cloaking SEO est-il illégal ?

Ce n’est généralement pas une question juridique, mais une violation des règles d’un moteur de recherche. Google le mentionne dans ses règles relatives au spam et peut rétrograder ou supprimer les pages qui y recourent. Lorsque le cloaking dissimule des arnaques ou des logiciels malveillants, d’autres lois peuvent s’appliquer au contenu lui-même.

Afficher un contenu différent selon le pays, est-ce du cloaking ?

Pas en soi. Adapter les prix, la langue ou les offres selon le pays est normal. Cela devient du cloaking lorsque le robot est traité différemment d’un utilisateur dans la même situation.

Puis-je détecter le cloaking en changeant mon user agent pour Googlebot ?

Uniquement pour le cloaking grossier. Les dispositifs soignés vérifient l’IP du robot, de sorte qu’un user agent usurpé est traité comme un visiteur ordinaire. Utilisez le test en direct de URL Inspection dans Search Console ou le Rich Results Test pour voir la vue réelle de Google.

Pourquoi ai-je besoin d’IP résidentielles pour détecter le cloaking ?

De nombreux dispositifs ne montrent leur charge malveillante qu’aux visiteurs ordinaires d’un marché ciblé et affichent une page propre aux adresses de bureaux, de cloud et de datacenters. Vérifier depuis des connexions domestiques sur ce marché permet de voir ce que reçoivent ces visiteurs.

En résumé

Le cloaking se cache de ceux qui sont les plus susceptibles de vérifier, si bien qu’un simple coup d’œil depuis votre bureau ne prouve pas grand-chose. Obtenez la vue de Google via ses propres outils, collectez les vues utilisateur selon les référents, les appareils et les connexions domestiques sur les marchés qui comptent, comparez les URL finales, les titres et le contenu principal, et répétez l’opération avant de déclarer une page saine. S’il s’agit de votre site, traitez toute découverte comme une compromission et corrigez le point d’entrée. Pour suivre l’affichage de vos pages depuis de nombreuses localisations dans le temps, consultez notre guide sur le suivi de positionnement en grille géographique.

Prêt à commencer ?

Essayez les proxies résidentiels de Shifter, 205M+ IPs, 195+ pays, à partir de 0,75 $/GB.

Commencer