Redirection uniquement sur mobile : pourquoi vous ne la voyez pas
Le script vous reconnaît comme desktop ou administrateur. C’est pour ça que la redirection mobile ne s’affiche pas chez vous. Reproduisez depuis un téléphone, en navigation privée, via un lien Google — pas en tapant l’URL dans la barre du bureau. Ensuite seulement, cherchez le test `mobile` dans htaccess, JS ou PHP.
Le script vous reconnaît comme desktop ou administrateur. Reproduisez depuis un téléphone, en navigation privée, via un lien Google, pas en tapant l'URL.
Pourquoi vous ne la voyez pas (ce n’est pas « ça s’est arrangé »)
Redirection uniquement sur mobile : le payload est écrit pour monétiser le trafic téléphone (pubs, jeux, faux support) sans alerter le webmaster derrière son 27 pouces. Vous rechargez, « tout va bien », vous rassurez le gérant. Trois clients iPhone plus tard, le téléphone sonne encore. Le décalage n’est pas une rémission. C’est le cahier des charges de l’attaque.
Les campagnes « hack redirection smartphone » sont industrielles. Les mêmes domaines cibles, les mêmes tests UA. Votre site n’est pas spécial. Votre écran desktop, si.
Donc le diagnostic commence par une reproduction mobile, pas par un scan Wordfence sur votre session admin. Le scan peut même être vert : rien sur la home desktop, tout dans un `if (mobile)`.
- Ne pas conclure sur un desktop connecté.
- Croire la capture iPhone avec l’URL.
- Traiter comme site qui redirige, canal mobile.
Reproduire : iPhone, 4G, privée, SERP
Téléphone réel, données mobiles (pas le Wi-Fi bureau, parfois whitelisté), Safari ou Chrome iOS, navigation privée, clic depuis un résultat Google plutôt que l’URL tapée. Les quatre, pas un au hasard. Taper l’URL omet le referer ; le Wi-Fi du bureau peut être l’IP « safe » du script ; privée évite vos cookies admin synchronisés (rare mais réel si vous vous êtes connecté sur le téléphone).
Sans iPhone : les outils dev (user-agent iPhone, device mode) marchent souvent, pas toujours (ils ratent un vrai `touch` ou une taille). Un collègue loin, capture. curl `-A "Mozilla/5.0 (iPhone; …)"`.
Notez si Android saute aussi. Parfois le test est `iPhone|Android`, parfois `iPhone` seul. Ça oriente la regexp à grepper.
User-agent : le filtre le plus bête et le plus fréquent
`.htaccess` : `RewriteCond %{HTTP_USER_AGENT} (iPhone|Mobile|Android)`. PHP : preg_match sur la variable HTTP_USER_AGENT. JS : `/iPhone|Android/i.test(navigator.userAgent)` puis `location`. Grep ces chaînes. C’est sale, c’est efficace, c’est partout.
Les UA « Googlebot-Mobile » parfois inclus : là, l’index pourrit. Parfois exclus : Google voit le site normal, les humains mobile non. Les deux existent. Inspection GSC + un vrai téléphone.
Un WAF légitime (Cloudflare bot fight) n’envoie pas vers un site de jeux. Ne blâmez pas le WAF pour une cible `.xyz`.
Où chercher le test `mobile`
Les trois pistes de l’article parent : htaccess, JS (thème / options / GTM), PHP prepend. Grep `mobile`, `iphone`, `android`, `user-agent`, `HTTP_USER_AGENT`, `referrer`. Dates de fichiers 3 h du matin.
AMP / versions `m.` / thème mobile dédié : un dossier `mobile/` oublié, un plugin « mobile redirect » légitime détourné, un `m.exemple.fr` addon sale. Testez le hostname mobile s’il existe. Sous-domaine.
Ne cherchez pas seulement dans `wp-content/plugins`. Le prepend est avant.
Couper et vérifier sur le vrai téléphone
Isoler, flush cache / CDN, retester sur l’iPhone qui échouait, privée, SERP. Votre device mode vert ne clôture pas. Demandez une nouvelle capture au client. Cinq minutes.
Si ça saute encore : deuxième piste (vous avez retiré htaccess, le JS reste). Checklist des trois, encore.
Secrets et entrée : comme toute redirect. Le mobile-only n’est pas « moins grave ». C’est plus rentable pour eux, donc plus fréquent.
Ce que Google indexe quand même
Si Googlebot-Mobile est dans le test, `site:` montre déjà la cible ou des titres louches. Si Googlebot est exclu, l’index a l’air propre, les humains non — et Safe Browsing peut quand même finir par voir un signalement utilisateur. Les deux horloges. Inspection en « smartphone » dans GSC.
Après coupure : réindex des URLs importantes, pas un nouveau domaine. Blacklist si interstitiel.
Les pubs mobiles (Ads) : parfois coupées avant le desktop. Guichet Ads, pas seulement le CMS.
Quand ce n’est pas un piratage
Un plugin de redirect mobile légitime mal réglé (vers un AMP mort, vers l’ancien site). Un thème qui `location` vers une URL de démo. Un lien `tel:` / appli store mal compris par le client (« ça ouvre un autre truc »). La cible (casino, support US) tranche. En doute, les trois pistes quand même : un plugin légitime peut avoir été édité.
Un AASA / universal link iOS vers une appli : rare sur une vitrine. Le client décrit « ça ouvre l’app ». Ce n’est pas un 302 casino. Capture.
Si les trois pistes sont propres, UA mobile propre en curl, et un seul iPhone : le téléphone (Safari corrupt, profil MDM, DNS de l’opérateur). Ne formatez pas le serveur pour un device. Demandez un second mobile.