Tests à faire avant de déclarer qu'un site est propre
Un administrateur qui « voit normal » n'est pas un feu vert. Mobile, navigation privée, clic depuis Google, `site:domaine`, Search Console, un scan distant, dates de fichiers 48 h plus tard : voilà ce qui autorise à parler d'un site propre. Pas une home depuis le bureau.
Mobile, navigation privée, clic Google, site:domaine, Search Console, un scan distant, dates de fichiers 48 h plus tard. Un admin qui « voit normal » n'est pas un feu vert.
Pourquoi l'admin n'est pas un visiteur
Vous êtes connecté, souvent en desktop, parfois avec un cache d'administrateur, souvent depuis l'IP du bureau. Les infections conditionnelles filtrent précisément ça : elles épargnent l'admin, le réseau d'entreprise, parfois la France, et servent la redirection au mobile, au clic Google, à un pays. « Chez moi ça marche » est le premier mensonge involontaire du dossier.
Le site marche chez moi, pas chez les visiteurs : ce n'est pas un bug de cache personnel seulement. C'est le fonctionnement normal d'un cloaking. Figer une capture client (barre d'adresse visible) vaut plus qu'une heure à rafraîchir la home connecté.
Avant de déclarer victoire, sortez de ce contexte. Les tests ci-dessous tiennent en trente minutes. Les sauter pour envoyer « c'est nettoyé » à OVH ou pour déposer un réexamen Safe Browsing est ce qui fait repartir le compteur.
Téléphone, navigation privée, second navigateur
Ouvrez le site en 4G, pas sur le Wi-Fi du bureau. Navigation privée, sans extension de pub. Un second navigateur si Chrome affiche « site trompeur » et pas Firefox — les listes divergent. Le cadenas HTTPS ne dit rien : Safe Browsing classe le contenu. Cadenas et site dangereux.
Parcourez home, une page intérieure, le formulaire, le checkout s'il existe. Un skimmer ne se voit pas sur la vitrine. Boutique : vitrine vs boutique. Restaurant / hôtel : le moteur de résa. Site resto ou hôtel.
Si un client vous envoie encore une capture après votre « c'est bon », croyez la capture. Relisez fichiers et base. Ne lui répondez pas que son téléphone est mal réglé.
- 4G + navigation privée.
- Home, page type, formulaire, checkout.
- Capture avec URL si quelque chose diverge.
Le clic Google et la requête site:
Tapez une requête qui affiche votre page, cliquez le résultat — ne collez pas l'URL. Beaucoup de redirections ne se déclenchent que depuis le referrer Google. Redirection depuis les résultats.
Puis `site:votre-domaine.fr`. Titres en japonais, pharmacies, chemins inconnus : l'infection a été indexée, ou l'est encore. Retirer le générateur ne vide pas l'index tout seul. Pages spam et spam SEO japonais.
Un `site:` propre le jour J et sale le surlendemain : cron ou backdoor. C'est pour ça que le test se refait à 48 h, pas seulement le soir du nettoyage.
Search Console : ce que le robot télécharge
Inspection d'URL : le HTML « vu par Google » doit être le vôtre. Un écart est une preuve de cloaking, pas un bug de l'outil. Gardez ce HTML. Problèmes de sécurité : ne déposez un réexamen que si plus aucune URL sale ne répond 200. Search Console problème de sécurité.
Propriété domaine vs URL : un `www` oublié, un IPv6, un HTTP encore ouvert peuvent servir l'ancienne version. IPv6 ou www non nettoyé, HTTP encore ouvert.
Sans Search Console, les tests visiteurs tiennent. Créez la propriété quand vous pourrez : ce n'est pas bloquant pour l'hébergeur, c'est bloquant pour un réexamen Google propre.
Scan distant : une liste, pas un verdict
Un scan public voit ce qu'un visiteur non conditionné voit. Utile en confirmation, insuffisant seul. Un mu-plugin, une option en base, un cron : hors champ. Servez-vous-en comme d'une radio, pas comme d'une opération.
Un plugin interne « 0 alerte » après un « réparer tout » ne dit pas que le voisin de compte est propre, ni que le CDN a purgé. WAF vs plugin.
Ne joignez pas seulement un screenshot de scan vert au ticket d'abus. Joignez : trouvé, retiré, corrigé, tests visiteurs. Répondre à un ticket d'abus et compte suspendu.
Caches, CDN, IPv6, www
Purge : plugin, objet (Redis), hébergeur, Cloudflare. Un HTML sale en cache fait échouer tous les tests « comme un visiteur » alors que les fichiers sont propres. Cache objet, Cloudflare.
Workers, Page Rules, variantes d'hôte : `www`, nu, IPv6, HTTP. Testez l'URL exacte que Google et les clients utilisent. Un certificat renouvelé pendant que le shell tourne ne change aucun test de contenu.
Mail : un site « propre » qui envoie encore via un PHP à la racine n'est pas fini. Journal d'envoi chez l'hébergeur si la délivrabilité était en jeu.
Quarante-huit heures plus tard
Revenez sur les dates de fichiers à la racine et dans les uploads. Un PHP né cette nuit, un `.htaccess` retouché, un admin créé : la porte était encore là. C'est le test que les gens sautent parce que la home est belle.
Charge CPU : un mineur qui attend un cron. Cryptominage et mineur serveur vs navigateur.
La fenêtre utile est plutôt trente jours qu'une nuit. Surveillance trente jours. Quarante-huit heures attrapent les cron fréquents ; le cron hebdomadaire attend le lundi suivant.
- Dates de fichiers, liste des admins.
- Nouveau `site:`, nouvelle inspection Search Console.
- Charge / facture hébergeur si minage dans l'historique.
Checklist avant réexamen et avant ticket « c'est bon »
Réexamen Safe Browsing : aucune URL frauduleuse en 200, pas de redirection conditionnelle, caches vides, tests visiteurs OK. Un refus rallonge le délai suivant. Lever Safe Browsing.
Ticket hébergeur : référence d'abus, motif, chemins traités, date, tests. Pas « c'est bon » seul. Adresse perso si le mail du domaine est coupé. Guide remise en ligne. Relancer toutes les heures n'accélère pas.
Si un test échoue et que vous ne savez pas lequel des fichiers relire, arrêtez-vous. Isoler n'est pas déclarer victoire. Créer un compte : un technicien reprend, prix avant accès.