Lever une alerte Google Safe Browsing : délais et erreurs
Le délai habituel, une fois le site réellement propre, tient souvent en 24 à 72 heures. Un refus impose d'attendre et de corriger, pas de renvoyer la même demande le jour même. Voici les erreurs qui transforment 48 h en trois semaines.
Délai habituel : 24 à 72 heures après un site réellement propre. Un refus impose d'attendre et de corriger, pas de renvoyer la même demande le jour même.
Safe Browsing, ce n'est pas l'index
SB décide si le navigateur interstitiel s'affiche. L'index décide des extraits `site:`. Vous pouvez sortir de SB et garder 4 000 titres pharmacies. Annoncez les deux délais. Voir pages spam pour le second.
SB ne « pénalise » pas un mot-clé. Il classe une ressource dangereuse. Pas un outil SEO.
Transparency Report : tendance. GSC : actions. Chrome client : cache local. Trois lectures.
Propre veut dire : Google peut retélécharger
Au moment du réexamen, un fetch part. 200 + HTML kit = refus. 404/410 + home métier = candidate à la levée. Inspection « en direct », pas le snapshot d'hier.
Auth, geo, user-agent : le malware qui se cache de Googlebot fait échouer aussi, ou laisse l'alerte (signalements utilisateurs). Tuez le script, ne jouez pas à cache-cache.
Fichiers `.exe`, `.apk`, `.js` qui drop. L'URL exacte du rapport malware. Voir malware GSC. Tant que cette URL répond 200, le réexamen SB échoue même si la home est impeccable. C'est le piège le plus fréquent : on « nettoie le site » à l'œil, on oublie `/uploads/setup.php.jpg`. Inspection de chaque URL du rapport, pas seulement de `/`.
Où cliquer (et qui doit cliquer)
GSC → Sécurité et actions manuelles / problèmes de sécurité (libellé selon l'UI). Propriétaire ou utilisateur avec les droits. Un prestataire avec un accès limité ne voit pas le bouton : donnez-lui le rôle, ou cliquez vous-même.
Sans GSC : vérifier le domaine (enregistrement DNS TXT), puis le flux. Le formulaire grand public existe selon les années ; la vérif propriété reste le chemin stable.
Ne créez pas une propriété URL-prefix `http://` alors que tout est en `https://www` pour « essayer ». Une propriété domaine couvre les hôtes. Voir propriété domaine vs URL.
- Propriété qui voit l'alerte.
- Droits suffisants.
- Un seul déposant.
Le texte qui passe, le texte qui agace
Fait, date, URL retirées, accès fermés. Pas « nous sommes une petite entreprise ». Pas « Wordfence green ». Pas de copier-coller d'un forum 2014.
L'anglais factuel passe. Le français aussi. L'important est vérifiable au fetch.
Joindre un PDF de constat : utile si les pages sont déjà 410 et que vous datez l'intervention. Pas obligatoire.
24, 48, 72 h : ce qui se passe vraiment
File de revue, fetch, mise à jour des listes, push vers les clients Chrome. 24 h : cas simples, volume faible. 72 h : fréquent. Au-delà : soit encore sale, soit file, soit un autre hôte. Voir délai.
Un client Chrome peut rester rouge 24 h après Transparency vert (liste locale). Dites-leur de laisser le navigateur se mettre à jour, pas d'« ignorer » en consigne d'entreprise.
Week-end : les files humaines, s'il y en a, glissent. Le fetch auto, moins. Relancer H+6 n'accélère pas : vous n'avez pas de bouton prioritaire. Un second dépôt identique pendant que le premier est en cours brouille le dossier. Tenez la frise (clic, statut, J+1 puis J+3) et cherchez un 200 oublié plutôt que de renvoyer le formulaire.
Refus : lire, tester, attendre
Le mail / GSC cite parfois une URL. Ouvrez-la comme Google. 200 ? Corrigez. 404 et refus quand même : autre path, cloaking, délai. Voir refus.
Renvoyer le même texte le jour même : le pire réflexe. Attendez que le live soit stable (heures, pas minutes).
Un refus n'est pas une condamnation. C'est un fetch encore sale ou trop tôt.
CDN, cache, et le kit fantôme
Cloudflare, LiteSpeed, un proxy : Google a tapé un POP qui avait encore le HTML. Purge tout, attendez 10-15 min, re-testez live, puis déposez.
Un cookie de cache « bypass pour admin » : vous voyez propre, le POP voit sale. Fetch anonyme.
IPv6 / ancien A record : un fetch tape encore le vieux serveur. DNS propre.
Plusieurs hôtes, une seule alerte
L'alerte peut être sur `exemple.fr` et le kit sur `www`. Ou l'inverse. Nettoyez les deux, et `m.`, `old.`. Une propriété domaine aide à voir.
HTTP 301 vers HTTPS : le fetch suit. Le kit ne doit être nulle part sur la chaîne.
Un CDN hostname (`cdn.exemple.fr`) avec un JS malveillant : l'alerte peut coller à l'apex. Cherchez là aussi. Les propriétés GSC URL-prefix ratent souvent cet hôte. Une propriété domaine + un `dig` des CNAME, le soir du réexamen, évitent le refus « ressource encore présente » sur un hostname que personne n'ouvre dans FileZilla.
Après la levée : ne pas relâcher J+7
Porte ouverte = reclassement. Surveillez. Un second cycle SB est plus dur à expliquer aux clients.
SmartScreen et proxies n'ont pas bougé tout seuls. Voir Edge.
Vous pouvez déclarer le site. On vise un réexamen unique. Pas un bouton magique à H+1 sur un 200. La fourchette 24 à 72 h se dit après le clic, pas avant le 410. Un suivi dans l'espace client évite de relancer Google toutes les heures — ça n'accélère rien.
- Live fetch propre, CDN purgé.
- Texte factuel, une fois.
- 24-72 h, pas de re-submit immédiat.
- J+7 sans nouvelle ressource.