Comment distinguer version mobile et cloaking aux yeux de Googlebot ?

Quelle différence entre adaptation mobile légitime et cloaking ?

Le cloaking consiste à servir un contenu différent au bot de crawl et aux visiteurs humains. Google pénalise cette pratique car elle fausse l'évaluation de pertinence. Mais l'adaptation mobile n'est pas du cloaking si elle respecte une règle simple : Googlebot desktop doit recevoir le même contenu qu'un utilisateur sur Chrome, Firefox ou Safari.

Si vous détectez un user agent mobile — Googlebot Smartphone, navigateur iOS, Android — vous pouvez légitimement afficher une version mobile allégée ou responsive. Le problème surgit quand le contenu desktop montré à Googlebot diffère de celui qu'un humain voit sur son PC. C'est là que Google bascule dans la sanction.

Pourquoi Googlebot desktop et Googlebot Mobile doivent-ils recevoir des versions cohérentes ?

Googlebot utilise deux bots distincts : un desktop, un mobile. Depuis le mobile-first indexing, c'est Googlebot Smartphone qui indexe en priorité. Mais Googlebot desktop continue de crawler. Si ces deux bots découvrent des contenus radicalement différents, Google suppose une tentative de manipulation.

Concretement, vous pouvez adapter la mise en page, réduire les images, simplifier la navigation pour mobile. Mais le contenu textuel principal, les titres, les liens internes doivent rester cohérents. Une page qui cache des paragraphes entiers à Googlebot mobile ou ajoute du texte invisible pour desktop déclenche l'alerte cloaking.

Quels sont les pièges techniques qui mènent au cloaking involontaire ?

Le cloaking involontaire arrive souvent par logique serveur mal calibrée. Exemple classique : un CMS qui détecte "Googlebot" dans le user agent et sert une version pré-rendue sans JavaScript, alors que les humains voient une SPA lourde. Résultat : Googlebot indexe un squelette vide ou incomplet.

Autre cas fréquent : les redirections conditionnelles. Si vous redirigez Googlebot vers une URL différente de celle affichée aux utilisateurs, c'est du cloaking pur. Google tolère les redirects vers versions mobiles (m.example.com) seulement si l'utilisateur mobile reçoit la même URL que le bot mobile.

• Googlebot desktop doit voir la version desktop complète, identique à celle d'un navigateur classique.
• Googlebot Smartphone peut recevoir une version mobile, à condition qu'elle soit aussi servie aux vrais utilisateurs mobiles.
• Les contenus cachés en CSS (display:none) ou JavaScript différé sont tolérés s'ils sont identiques pour bots et humains.
• Toute détection de user agent qui modifie le contenu textuel principal entre bot et humain est considérée comme cloaking.
• Les tests avec Mobile-Friendly Test et URL Inspection Tool permettent de vérifier ce que Googlebot voit réellement.

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Absolument. Les sites qui servent une version desktop complète à Googlebot et une version mobile distincte mais cohérente ne subissent aucune pénalité, tant que le contenu principal reste identique. J'ai audité des centaines de sites en responsive design et en configuration m.example.com : ceux qui respectent cette règle passent sans accroc.

Là où ça coince, c'est quand les développeurs implémentent des logiques de détection approximatives. J'ai vu des cas où un site affichait des blocs de texte entiers uniquement à Googlebot desktop pour "optimiser" l'indexation, pensant que le mobile-first indexing ignorait le desktop. Faux. Google croise les données des deux bots, et toute divergence suspecte déclenche un signal de cloaking.

Quelles nuances faut-il apporter à cette règle officielle ?

Google reste évasif sur les seuils de tolérance. Quelle proportion de contenu peut différer entre mobile et desktop sans basculer dans le cloaking ? Aucune métrique publique. [A verifier] : les retours terrain suggèrent qu'une réduction de 20-30 % du texte visible sur mobile (menus dépliables, sections masquées par défaut) est tolérée, mais rien d'officiel.

Autre zone grise : les SPAs et le rendu JavaScript. Si Googlebot desktop exécute le JS et indexe le contenu dynamique, mais que l'utilisateur sur navigateur classique voit la même chose après chargement, c'est OK. Mais si le serveur détecte "Googlebot" et sert un DOM pré-rendu différent de celui généré côté client pour les humains, c'est du cloaking. La nuance tient à qui génère le contenu (serveur vs client) et non au résultat final, ce que Google ne clarifie jamais assez.

Dans quels cas cette règle ne protège-t-elle pas contre les faux positifs ?

Les sites avec geo-targeting agressif prennent des risques. Si vous redirigez les visiteurs européens vers example.fr et Googlebot (crawlé depuis les USA) vers example.com, Google peut interpréter ça comme du cloaking, même si le contenu est identique. Solution : utiliser hreflang et servir le même contenu principal, en adaptant seulement langue et devises.

Les paywalls et inscriptions obligatoires sont un autre cas limite. Si vous affichez le contenu complet à Googlebot mais forcez les humains à s'inscrire, Google tolère sous conditions strictes (balisage FirstClick Free ou Flexible Sampling). Mais si vous changez le contenu lui-même — résumés pour humains, version intégrale pour bots — c'est du cloaking. Cette distinction reste floue dans la documentation officielle, et les erreurs sont fréquentes.

Que faut-il faire concrètement pour éviter le cloaking entre desktop et mobile ?

D'abord, unifier la logique de détection. Votre serveur doit traiter Googlebot desktop exactement comme Chrome ou Firefox : même contenu, même DOM, même ressources chargées. Si vous utilisez un responsive design, c'est simple : tout le monde reçoit le même HTML, seul le CSS adapte l'affichage selon la largeur d'écran.

Pour les configurations avec URLs mobiles séparées (m.example.com), assurez-vous que les redirects 302 vers la version mobile ne s'appliquent qu'aux vrais user agents mobiles ET à Googlebot Smartphone. Googlebot desktop doit rester sur la version desktop. Utilisez les balises <link rel="alternate"> et <link rel="canonical"> pour signaler à Google la relation entre les deux versions.

Quelles erreurs éviter absolument dans la détection de user agent ?

Ne jamais coder une règle du type "si user agent contient 'Googlebot', alors servir version X". Les deux crawlers de Google — desktop et mobile — contiennent la chaîne "Googlebot", mais leurs comportements doivent être différenciés. Vérifiez la chaîne complète du user agent : "Googlebot/2.1" pour desktop, "Googlebot-Mobile" ou "Googlebot Smartphone" pour mobile.

Autre erreur classique : masquer du contenu en display:none uniquement pour Googlebot, pensant améliorer la "lisibilité" pour le bot. Google détecte ces manipulations via des crawls aléatoires avec user agents non-Googlebot et croise les données. Si le contenu caché n'est jamais visible pour un humain, c'est du cloaking. La seule exception tolérée : les éléments UI non essentiels (boutons de partage, publicités) qui n'affectent pas le contenu principal.

Comment vérifier que mon site respecte cette règle Google ?

Utilisez Google Search Console, outil "Inspection d'URL". Testez une page en mode desktop et mobile. Comparez les captures d'écran et le HTML rendu. Si des sections entières disparaissent entre les deux versions sans raison UX légitime, vous êtes en zone de risque.

Complétez avec des tests manuels : simulez Googlebot desktop avec curl -A "Mozilla/5.0 (compatible; Googlebot/2.1)" et Googlebot mobile avec curl -A "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X) AppleWebKit/537.36 Googlebot/2.1". Comparez les réponses HTTP et le contenu HTML. Toute divergence suspecte doit être corrigée avant que Google ne la détecte.

• Servir la version desktop complète à Googlebot desktop et aux navigateurs classiques, sans distinction de traitement.
• Autoriser l'affichage de la version mobile uniquement si un user agent mobile (bot ou humain) est détecté.
• Vérifier que le contenu textuel principal (titres, paragraphes, liens) reste identique entre desktop et mobile, même si la mise en page diffère.
• Utiliser les balises rel="alternate" et rel="canonical" pour les configurations avec URLs mobiles séparées.
• Tester régulièrement avec Google Search Console (Inspection d'URL) et des simulations de user agent en ligne de commande.
• Éviter toute règle serveur qui détecte "Googlebot" de manière générique sans différencier desktop et mobile.