L'URL de phishing répond encore 200 : le réexamen échouera

Ce que Google relit au moment du réexamen

Le réexamen Safe Browsing n’est pas un jugement sur vos intentions. C’est un téléchargement. Googlebot ouvre l’URL signalée et regarde ce qu’elle sert maintenant. Si le HTML est encore une fausse page bancaire ou une copie du kit, le refus est enregistré. Le délai suivant est plus long que le premier.

C’est pour ça qu’un site « propre à la home » ne suffit pas. L’alerte site trompeur pointe souvent une URL profonde : /wp-includes/images/login/, /paypal/secure/, /client/update/. Vous, vous testez l’accueil. Eux, ils relisent le chemin frauduleux. Tant que ce chemin répond 200, le dossier n’avance pas.

Le protocole phishing hébergé commence par couper cette URL, puis seulement le reste (porte, mots de passe, constat). Inverser — nettoyer le thème, laisser le kit en 200 — produit exactement le refus que les gens décrivent : « j’ai demandé le retrait, Google a dit non ».

• Noter l’URL exacte (email Search Console, capture client, Transparency Report).
• La tester en navigation privée, sans cookie d’admin.
• La tester via l’inspection d’URL Search Console, pas seulement le navigateur.

200, 301 vers l’accueil, 404, 410 : ce que ça dit

Un 200 dit : cette ressource existe, voici son contenu. Pour une URL de phishing, c’est le pire statut possible, même si le contenu a été remplacé par une page blanche ou un « page introuvable » en HTML. Google lit le code HTTP d’abord. Un faux 404 servi en 200 reste une page vivante.

Un 404 dit : je n’ai rien à cet endroit. C’est acceptable. Google finit par sortir l’URL de l’index. Un 410 dit : cette ressource a existé, elle est volontairement retirée, ne revenez pas. C’est le signal le plus clair après un kit. Sur nginx ou Apache, c’est une règle sur ce chemin (et ses variantes), pas un article WordPress « brouillon ».

Un 301 ou 302 vers l’accueil dit : cette URL est la même chose que la home. Pour une URL d’hameçonnage, Google peut y voir de l’évitement — vous « rangez » la page au lieu de la tuer. Dans les dossiers que nous reprenons, ce 301 vers / est le geste le plus fréquent des agences pressées, et le plus souvent cité dans un second refus.

Pourquoi la redirection home est le pire réflexe

Le raisonnement paraît logique : « au moins le visiteur arrive sur le vrai site ». Pour un lien cassé de 2019, oui. Pour /secure-paypal/login.php vu par Safe Browsing, non. Vous affirmez que la page frauduleuse et votre accueil sont la même ressource. Le crawler suit, voit une vitrine, et peut quand même garder le signalement : le chemin existe encore, il mène quelque part.

Autre effet : les victimes qui ont le lien dans l’historique, ou un email encore en circulation, atterrissent chez vous. Elles voient une menuiserie ou un cabinet, pas une banque. Une partie d’entre elles signale à nouveau. Vous venez de relancer le bruit autour d’un domaine déjà chaud.

La bonne réponse au visiteur humain, si vous tenez à en avoir une, est une 410. Le navigateur affiche « gone » ou une page d’erreur neutre. Pas de discours sur l’attaque, pas de formulaire, pas de lien vers le checkout. Le guide phishing le dit en une phrase : la page frauduleuse doit cesser d’exister.

• Pas de 301/302 vers /, /accueil, /fr/, ni vers une page « nos services ».
• Pas de 200 avec un HTML « 404 » fait à la main.
• Pas de maintenance globale du domaine si seule l’URL du kit doit mourir.

Couper le fichier, le dossier, puis le générateur

Souvent le kit est un dossier : des HTML, un PHP qui envoie les saisies, parfois une image de logo bancaire. Retirer un seul index.html laisse les autres chemins en 200. Listez le dossier, retirez-le, puis posez la 410 sur le préfixe (/paypal, /secure, /wp-content/uploads/2024/11/x/).

Ensuite le générateur. Un script à la racine, un mu-plugin, une règle de réécriture qui fabrique /login-bnp/ à la volée : tant qu’il tourne, de nouvelles URL naissent. Désindexer une à une est perdu d’avance. C’est le même principe que les pages spam indexées : on coupe la machine, puis on parle à Google.

Copiez avant de supprimer. Le dossier est une preuve (assureur, hébergeur, parfois police). Une archive hors serveur, pas un zip dans le même compte. Puis changez le mot de passe du panel : un kit remis en ligne à 3 h du matin, c’est presque toujours un accès encore ouvert, pas un « fantôme ».

Vérifier ce que Googlebot télécharge encore

Votre navigateur, connecté, avec un cache Cloudflare « bypass cookie », n’est pas Googlebot. Utilisez l’inspection d’URL sur chaque chemin signalé. Le HTML « vu par Google » doit être une erreur, pas votre thème. Si l’outil montre encore le kit, ne déposez pas le réexamen.

Testez aussi les variantes : http et https, www et domaine nu, slash final, index.php, index.html. Un attaquant pose souvent les quatre. Cloudflare ou un CDN peut servir une copie du kit depuis le cache alors que le disque est déjà propre. Purgez le cache sur ces préfixes, pas seulement « tout le site » en priant.

Un écart inspection / écran est une preuve, pas un bug. Gardez la capture. Elle sert au constat et, si le premier réexamen a déjà été refusé, à expliquer que vous avez vérifié après, pas avant. Voir retrait blacklist Google pour le calendrier une fois les URL mortes.

Search Console : retrait d’URL et problèmes de sécurité

Deux outils, deux jobs. « Retrait d’URL » (temporaire) cache un résultat quelques mois : utile pour une URL déjà 410 que Google affiche encore. « Problèmes de sécurité » est le canal du phishing et des logiciels malveillants. On y dépose le réexamen une fois, avec une phrase factuelle : chemins retirés, 410 en place, entrée fermée.

Ne mélangez pas. Un retrait d’URL ne lève pas Safe Browsing. Un réexamen sécurité ne désindexe pas 400 pages spam. Si vous n’avez qu’une propriété préfixe (https://www.) et que le kit est sur http:// ou sur un sous-domaine, vous êtes à l’angle mort. C’est le sujet de propriété domaine vs préfixe.

Les utilisateurs de la propriété comptent. Un compte « agence 2021 » encore propriétaire peut avoir soumis un sitemap pirate. Listez-les le jour J. Ce n’est pas de la paranoïa : c’est la checklist que Google comprend quand on demande pourquoi de nouvelles URL apparaissent.

Safe Browsing n’est pas l’index

L’alerte rouge Chrome peut tomber en 24 à 72 heures après un site réellement propre. Les titres du kit dans `site:votre-domaine.fr` mettent plus longtemps. Ce sont deux horloges. Confondre les deux pousse à redemander un réexamen tous les matins, ce qui n’accélère rien et peut durcir le dossier.

Les antivirus (Norton, Bitdefender) ont leurs propres listes. Une Search Console verte ne les lève pas. On les traite après, avec l’URL déjà en 410. Voir alerte site trompeur pour distinguer certificat, Safe Browsing et antivirus.

Pendant ce délai, ne remettez pas un 200 « on explique l’incident » sur l’ancienne URL. Vous recréez une ressource. Les victimes n’ont pas besoin d’un communiqué à cette adresse ; vos clients légitimes passent par l’accueil, le téléphone, ou un bandeau sur la fiche Google Business.

Les erreurs qui coûtent une semaine

Déposer le réexamen le jour du retrait, alors que Cloudflare sert encore le kit. Rediriger vers l’accueil. Remplacer le HTML du kit par une page « désolé pour le désagrément » en 200. Réinstaller WordPress par-dessus sans retirer le dossier /wp-content/uploads/…/paypal/.

Changer de nom de domaine « pour oublier ». L’ancien nom reste signalé, les emails citent encore l’URL, et vous perdez l’historique. Couper tout le vhost pendant dix jours : Google voit un domaine mort, pas une URL tuée. Le SEO de la vitrine encaisse plus que le kit.

Si vous bloquez ce soir : 410 sur le préfixe, copie hors serveur, mot de passe panel, ticket hébergeur factuel. Puis créer un espace si le générateur ou la porte n’est pas évidente. Un technicien reprend en jours ouvrés ; l’inscription ne demande pas l’accès serveur.

• Pas de réexamen tant que l’inspection montre encore un 200 utile.
• Pas de 301 vers la home.
• Pas de page d’excuse en 200 sur le chemin du kit.

Quand le kit est encore généré à la volée

Si chaque nouvelle URL /bnp-2026-08-27/ répond 200 alors que vous venez d’en tuer trois, ce n’est plus un dossier : c’est un générateur. Cherchez la réécriture, le PHP à la racine, le cron. Tant qu’il tourne, Safe Browsing a raison de refuser.

Les sous-domaines oubliés et le wildcard DNS fabriquent le même spectacle à plus grande échelle. Un * A record + un vhost « catch-all » : spam1.votre-domaine.fr sert le kit. La propriété préfixe www ne le voit pas.

Dans ce cas, déléguez si vous ne lisez pas les vhosts et les journaux. Le coût d’un second refus + une semaine d’alerte Chrome dépasse celui d’une intervention. Le critère n’est pas la peur : c’est « est-ce que je sais prouver que cette URL est morte pour Googlebot, pas seulement pour moi ».