Réexamen Google refusé : pourquoi, et comment ne pas recommencer
Google a encore trouvé une ressource, ou vous avez demandé trop tôt. On relit le motif, on teste l'URL citée comme un robot, on attend que le site soit stable. Renvoyer la même demande le jour même allonge le délai. Un refus n'est pas une condamnation : c'est un fetch encore sale ou trop frais.
Google a encore trouvé une ressource. Relisez le motif, testez l'URL citée, attendez que le site soit stable. Renvoyer la même demande le jour même aggrave le délai.
Lire le motif, pas seulement « rejected »
GSC / l'e-mail cite parfois une URL ou un type (malware encore présent, contenu encore trompeur). C'est votre todo n°1. Sans URL, partez des dernières listées dans le rapport, plus la home, plus les sous-domaines.
Un refus « trop tôt » n'est pas toujours écrit ainsi. Le symptôme : vous avez déposé le jour du clean à 16 h, CDN encore chaud. Traitez-le comme tel.
Traduisez le libellé EN/FR. Ne le prenez pas pour une attaque personnelle. Un refus n'est pas « Google qui nous en veut ». C'est un fetch encore sale, un cache, un hôte oublié, ou une demande trop tôt. La suite est technique : URL, chaîne de redirects, stabilité. Relancer le même pavé le jour même allonge ; corriger puis attendre une nuit, raccourcit.
Tester l'URL citée — toute la chaîne
Inspection directe, curl -I, suivre les 302. Un 200 quelque part sur la chaîne suffit. Un 403 « Forbidden » sur un kit : parfois encore classé. Préférez 410.
Le HTML rendu vs le source. Un JS qui drop après paint. HAR anonyme.
Vous voyez 404, Google 200 : cache POP, ou cloak. cloaking. Purge, retest, alors seulement redemander.
- URL du mail / rapport.
- Redirects jusqu'au corps.
- www / nu / http / https.
Les causes de refus qui reviennent
URL encore 200. Copie du kit sur `old.`. `radio.php` ressuscité par cron. Réexamen à H+1. Texte « on a mis un plugin » sans 410. Mauvais rapport (demande SB alors que le problème est un sitemap — ça n'échoue pas toujours, ça rate la cible).
Un zip `backup-kit.zip` listable. Un `?file=` encore actif. Un `old.` que personne n'ouvre. Un objet CDN. Ces quatre-là expliquent plus de refus « mystérieux » que le texte du formulaire. Avant la seconde demande, listing par date sur tout le compte + purge + inspection des URL du premier rapport, pas seulement de la home.
IP / hôte CDN qui sert l'ancien objet. Purge par URL.
Stabiliser avant de redemander
Corrigez. Attendez que le live soit le même à T0 et T0+3 h (pas un 200 intermittent). Les caches se vident. Le cron de 3 h est passé une fois sans réécrire.
Porte fermée : sinon le fetch de la seconde demande retrouve un fichier neuf.
Documentez ce que vous avez trouvé après le refus. La seconde phrase : « suite refus du [date], URL X était encore servie par le CDN / un jumeau sur old. ; 410 depuis [heure]. »
Combien attendre entre deux demandes
Pas de délai officiel public. Le sens : après correction et stabilité (souvent la nuit + un contrôle matin). Pas 20 minutes. Pas « toutes les heures jusqu'à ce que ça passe ».
SB : après un refus, le cycle suivant paraît plus long si vous spammez. 24-72 h se comptent après un fetch réussi, pas après le premier clic manqué.
Un statut « en cours » n'est pas un refus. N'empilez pas. La fourchette 24 à 72 h se compte après un fetch réussi, pas après le premier clic manqué. Annoncez-le aux clients : un refus reset l'horloge. Mieux vaut un second dépôt jeudi matin qu'un troisième mercredi 18 h identique au premier.
Quand le motif est vide ou générique
Refaites la todo complète : `site:` paths dangereux, listing dates, sous-domaines, GSC liste, logs `GET` Googlebot vers des PHP bizarres. Le motif vide veut dire « on a encore vu quelque chose » sans vous le donner. Cherchez plus large, pas plus de texte dans le formulaire.
Un prestataire qui relit les fetches aide ici. L'aveugle coûte des semaines.
Vérifiez les hôtes hors GSC (un CDN `*.cloudfront` que vous oubliez).
CDN, autre hôte, autre schéma
Le refus porte sur `http://exemple.fr/x` alors que vous n'avez nettoyé que `https://www`. 301 vers le kit encore ? Suivez. Tuez les quatre coins.
IPv6, ancien A, second serveur de preprod public. `dig` / panel DNS.
Un Load balancer avec un nœud pas à jour. Rare en mutualisé, réel en VPS mal patché.
Ne pas ouvrir cinq tickets en parallèle
Forum Produit + GSC + e-mail inventé + un « expert whitelist » + un second compte GSC. Les réponses se croisent, vous redéposez trop tôt. Un canal, une frise.
SmartScreen et Norton : autres files, OK en parallèle une fois le site propre. Pas cinq fois Google.
L'hébergeur « dites à Google de nous enlever » : ils ne peuvent pas. Ils peuvent vous donner des logs.
Si ça refuse encore : checklist froide
Toutes les URL du rapport, 410. Home A≡B inspection. Pas de PHP dans uploads. Cron vide d'inconnus. DNS un seul docroot propre. CDN 0 objet kit. Une nuit calme. Alors une demande. rédiger.
Toujours rouge après ça : délai de file, ou un path que personne n'a listé (`/wp-json/` qui sert un payload — rare, existe). Logs Googlebot.
Vous pouvez déclarer. Un refus + l'URL citée, c'est un brief précis. On ne promet pas un passage en force.
- Motif et URL lus.
- Chaîne 200 éliminée.
- Stabilité heures / une nuit.
- Une nouvelle demande, pas cinq.