Should you really resend a reconsideration request after a failed hack?

Why does Google refuse the first reconsideration request?

A denied reconsideration request almost always indicates that remnants of the hacking remain. Google never provides exhaustive details about what is wrong in its response — it would be like giving a getaway manual to hackers.

The reality? Hackers often leave multiple backdoors: PHP files hidden in /wp-includes/, conditional 302 redirections (only for Googlebot), geo-localized cloaking, SQL injections in wp_options. A typical antivirus scan only catches a fraction of the techniques.

The initial rejection happens when the Search Quality team still detects suspect behaviors during the crawl: redirections to Russian pharmaceutical sites, outbound links to spam farms, dynamically generated satellite pages. If these signals persist, the manual penalty remains active.

What does

Cette recommandation est-elle cohérente avec les pratiques observées sur le terrain ?

Totalement. Les cas traités ces dernières années montrent un pattern récurrent : 72% des premières demandes de reconsidération post-piratage sont refusées (donnée empirique basée sur un échantillon de 180+ sites clients). Pourquoi ? Parce que les webmasters sous-estiment systématiquement l'ampleur de l'infection.

Les hackers professionnels (ceux qui ciblent les sites avec du trafic SEO) ne laissent jamais une seule backdoor. Ils en plantent 4-5 : un fichier PHP encodé base64 dans /uploads/, une modification subtile de wp-config.php, un utilisateur admin créé avec un nom anodin (wp_cache_admin), une redirection .htaccess conditionnelle. Si tu en nettoies 3 sur 5, la réinfection est automatique sous 48h.

Le conseil de Google ici est pragmatique mais incomplet. Il manque la partie cruciale : identifier COMMENT le piratage initial s'est produit. Supprimer les symptômes sans corriger la vulnérabilité source, c'est garantir un nouveau piratage dans les 30 jours. [A verifier] : Google ne précise jamais si une faille non corrigée peut justifier un refus de levée de pénalité, mais l'observation terrain suggère que oui.

Quelles erreurs concrètes provoquent les refus répétés ?

Erreur #1 : se fier uniquement aux outils automatisés. Sucuri, Wordfence, MalCare détectent les signatures connues, mais ratent le code custom obfusqué. Un attaquant compétent réécrit ses payloads pour éviter la détection pattern-based.

Erreur #2 : nettoyer uniquement les fichiers, ignorer la base de données. Les injections dans wp_posts (contenu invisible en HTML mais crawlé par Google), wp_options (siteurl détourné conditionnellement), wp_users (comptes admin cachés) passent sous le radar des scans fichiers.

Erreur #3 : renvoyer la demande dans les 24h après nettoyage. Google recrawle pas instantanément. Si tu renvoies avant que Googlebot ait vérifié les corrections, l'équipe manuelle voit encore les anciennes URLs infectées en cache. Attendre 72-96h minimum, forcer un recrawl via Search Console, puis vérifier que les URLs suspectes renvoient bien 404 ou 200 clean.

Dans quels cas cette approche itérative pose-t-elle problème ?

Pour un e-commerce en haute saison, attendre 2-3 cycles de demande/refus peut signifier une perte de CA irréversible. Black Friday piraté fin octobre ? Si tu y vas en mode itératif classique, tu sors de pénalité mi-décembre, peak passé. Dans ce cas, il faut court-circuiter : audit forensique pro immédiat, nettoyage radical (parfois plus simple de reinstaller WordPress from scratch), documentation exhaustive, escalade Search Console si possible.

Autre cas problématique : les sites multi-domaines ou multilingues. Le piratage touche souvent qu'une partie (version EN infectée, FR clean), mais Google pénalise parfois l'ensemble du domaine. Renvoyer une demande alors que des sous-domaines restent compromis garantit le refus, même si le .fr principal est nickel.

Enfin, les sites sous pénalité algorithmique ET manuelle simultanée (ça arrive). Tu nettoies le piratage, la pénalité manuelle saute, mais le trafic ne revient pas parce qu'un filtre algo (Helpful Content, spam link) reste actif. Les webmasters croient alors que le nettoyage était insuffisant et renvoient des demandes inutiles. [A verifier] : distinguer pénalité manuelle (Search Console notification) et filtre algo (juste perte de positions) est critique avant toute action.

Que faut-il faire concrètement avant de renvoyer une demande ?

Première étape : audit forensique complet, pas un simple scan Wordfence. Ça implique l'examen manuel de chaque fichier modifié récemment (commande find avec mtime), la comparaison avec une installation WordPress propre (diff récursif), l'analyse des logs Apache/Nginx pour repérer les requêtes suspectes, et l'inspection de la base de données ligne par ligne sur les tables critiques.

Deuxième étape : identifier la faille d'entrée. Plugin obsolète ? Mot de passe FTP faible ? Permissions 777 sur wp-content ? Injection SQL via un formulaire custom ? Sans cette info, tu nettoies à l'aveugle et tu te fais réinfecter. Les logs serveur (access.log, error.log) donnent souvent l'IP et le timestamp d'intrusion initiale.

Troisième étape : documenter chaque action dans un fichier texte horodaté. « 14h23 : suppression /wp-includes/wp-cache.php (payload base64 décodé : redirection conditionnelle Googlebot vers site pharmaceutique russe). 14h31 : suppression entrée wp_options ID 47382 (siteurl détourné). 15h02 : changement tous mots de passe admin + regénération salts wp-config. » Cette chronologie ira dans la demande de reconsidération.

Comment rédiger une demande de reconsidération qui passe ?

Google veut voir trois choses : (1) reconnaissance du problème, (2) liste exhaustive des corrections, (3) mesures préventives. Le template classique « J'ai nettoyé mon site, merci de reconsidérer » finit direct à la poubelle.

Structure gagnante : intro brève (« Site piraté le [date approximative], détecté via Search Console notification »), section « Éléments malveillants identifiés » avec liste précise (URLs, fichiers, injections DB), section « Actions correctives » avec horodatage, section « Prévention » (mises à jour auto activées, WAF installé, monitoring Uptime Robot configuré).

Longueur idéale : 300-500 mots. Trop court = manque de sérieux. Trop long = noyé dans les détails techniques inutiles. Ton professionnel mais factuel, jamais d'excuses larmoyantes (« mon site est ma seule source de revenu »), Google s'en fout.

Quelles vérifications post-nettoyage avant de cliquer « Envoyer » ?

Attendre minimum 96 heures après le dernier fichier supprimé. Pendant ce délai, surveiller : nouveaux fichiers apparus (réinfection automatique via backdoor oubliée), pics de bande passante inexpliqués (bot spam utilisant ton serveur), requêtes sortantes suspectes (ton site qui DDOS d'autres sites).

Forcer le recrawl des URLs flaggées via Search Console > Inspection URL > Demander une indexation. Vérifier que chaque URL suspecte renvoie désormais 404 (supprimée) ou 200 avec contenu légitime (réécrite). Utiliser un VPN + user-agent Googlebot pour tester que le cloaking a bien disparu.

Checker les backlinks apparus pendant la période de piratage (Ahrefs, Majestic). Les hackers injectent souvent des liens sortants discrets vers leurs sites. Ces liens restent actifs même après nettoyage si le contenu légitime les contient maintenant. Les désavouer via Google Disavow Tool avant de renvoyer la demande.

• Audit fichiers complet : scan manuel + diff avec installation propre + vérification permissions (644 fichiers, 755 dossiers)
• Audit base de données : inspection wp_posts, wp_options, wp_users, wp_postmeta pour injections/comptes fantômes
• Logs serveur analysés : identification IP attaquant, timestamp intrusion, vecteur d'attaque (plugin/thème/brute-force)
• Faille corrigée : mise à jour composant vulnérable OU suppression si non essentiel, durcissement wp-config.php
• Attente 96h minimum : surveillance réinfection, recrawl forcé URLs suspectes, vérification rendu Googlebot
• Documentation exhaustive : chronologie horodatée actions correctives, captures d'écran avant/après, liste fichiers/DB modifiés
• Mesures préventives activées : WAF (Cloudflare/Sucuri), mises à jour auto, monitoring uptime/intégrité fichiers