Faut-il vraiment contacter son hébergeur après un piratage de site ?

Pourquoi Google insiste sur le rôle de l'hébergeur dans la gestion d'un piratage ?

Quand Google détecte un site piraté, la priorité est de stopper la diffusion de contenu malveillant avant de lever les pénalités de classement. Mais nettoyer le site côté CMS (WordPress, Joomla, etc.) ne suffit pas toujours.

Si le serveur lui-même est compromis, les fichiers malveillants peuvent se régénérer automatiquement. Un hébergeur averti peut vérifier l'intégrité de la pile système (Apache, PHP, MySQL), repérer des processus suspects, et restaurer une version saine depuis un snapshot infrastructure.

L'autre raison : votre site n'est peut-être pas le seul affecté. Les hackers ciblent souvent des failles dans les environnements mutualisés. Prévenir l'hébergeur lui permet de protéger l'ensemble de ses clients et de corriger la brèche en amont.

Quelles sont les mesures correctives qu'un hébergeur peut prendre immédiatement ?

Un bon hébergeur dispose d'outils de détection automatisée des anomalies : pics de trafic suspect, requêtes SQL anormales, modifications de fichiers core en dehors des plages de maintenance. Une fois alerté, il peut isoler votre compte dans un conteneur temporaire pour éviter la propagation.

Côté correctif, il peut restaurer les permissions fichiers (souvent modifiées pour exécuter du code arbitraire), réinitialiser les mots de passe FTP/SSH, et scanner les cron jobs malveillants. Certains hébergeurs premium offrent même un service de nettoyage inclus dans leur SLA.

L'hébergeur a-t-il toujours les compétences pour gérer un piratage avancé ?

Soyons honnêtes : tous les hébergeurs ne se valent pas. Les mutualisés low-cost répondent souvent par un ticket générique conseillant de "vérifier vos plugins". Les infrastructures managées (WP Engine, Kinsta, etc.) ont des équipes spécialisées en sécurité WordPress.

Dans les cas complexes (injection SQL persistante, rootkit, cryptomining dissimulé), l'hébergeur se limite parfois à fournir les logs d'accès. C'est déjà précieux pour identifier le vecteur d'intrusion, mais le nettoyage reste à votre charge.

• Contactez l'hébergeur dès la détection du piratage, avant même de toucher aux fichiers (pour préserver les traces forensiques).
• Demandez un snapshot infrastructure propre si disponible, plutôt que de restaurer manuellement fichier par fichier.
• Vérifiez si votre plan inclut un support sécurité : certains hébergeurs facturent ce service à la demande.
• Exigez les logs Apache/Nginx des 7 derniers jours pour analyser les requêtes suspectes et identifier la backdoor.
• Isolez le site piraté dans un sous-domaine temporaire pendant le nettoyage pour éviter que Google n'indexe du contenu malveillant supplémentaire.

Cette recommandation est-elle alignée avec les pratiques observées sur le terrain ?

Oui, et c'est une des rares fois où Google et les praticiens SEO sont d'accord sans réserve. Les hébergeurs ont accès à des logs et des outils système que vous n'avez pas depuis cPanel ou Plesk. Ignorer cette étape, c'est risquer de nettoyer en surface pendant que le malware se régénère depuis un cronjob caché.

Par contre, l'efficacité de cette démarche dépend totalement de votre hébergeur. Les retours terrain montrent que les mutualisés à 3€/mois se contentent souvent de suggérer une réinstallation complète. Les hébergeurs spécialisés (notamment ceux avec des SLA sécurité) peuvent bloquer l'attaque en moins d'une heure. [A vérifier] : Google ne précise jamais quel niveau de support attendre, ce qui est problématique pour dimensionner l'effort.

Quelles sont les limites de cette approche en environnement complexe ?

Si vous êtes sur un VPS ou un serveur dédié non managé, contacter "l'hébergeur" revient à envoyer un ticket à OVH ou AWS qui vous répondra : "c'est votre responsabilité". Dans ce cas, la recommandation de Google est caduque : vous devez soit avoir des compétences sysadmin, soit faire appel à un prestataire spécialisé.

Autre limite : les architectures cloud distribuées (CloudFlare Workers, Vercel, Netlify). Le piratage peut provenir d'un bucket S3 mal configuré ou d'une API tierce compromise. L'hébergeur de votre front-end n'y peut rien. Google reste vague sur ces cas d'usage modernes, ce qui trahit une vision très "LAMP stack classique" du web.

Faut-il vraiment attendre l'action de l'hébergeur avant de nettoyer soi-même ?

Non, et c'est là que la formulation de Google peut induire en erreur. "Contacter l'hébergeur" ne signifie pas "attendre passivement". Si vous avez les compétences, commencez le nettoyage en parallèle : supprimez les fichiers suspects, changez tous les mots de passe, désactivez les comptes utilisateurs inconnus.

L'hébergeur intervient surtout pour sécuriser la couche infrastructure (firewall, IDS, restauration de snapshots système). Vous, vous nettoyez la couche applicative (CMS, base de données, thèmes/plugins). Les deux actions sont complémentaires, pas séquentielles. Attendre 48h qu'un hébergeur réponde pendant que Google indexe du spam pharma est une erreur tactique.

Que faire concrètement dans les premières heures après détection d'un piratage ?

Ouvrez immédiatement un ticket prioritaire chez votre hébergeur, même si vous pensez pouvoir gérer seul. Mentionnez les symptômes précis : redirections 301 non désirées, fichiers .php suspects dans /wp-content, alertes Search Console "Site piraté". Plus vous êtes précis, plus la réponse sera rapide.

Pendant ce temps, mettez le site en mode maintenance via un plugin ou un fichier .htaccess pour stopper l'hémorragie SEO. Google continuera de crawler, mais au moins il ne trouvera pas de nouvelles pages spam. Ensuite, téléchargez une copie complète du site (fichiers + base) avant toute modification : vous aurez besoin de ces "preuves" pour l'analyse forensique.

Comment vérifier si l'hébergeur a effectivement pris des mesures correctives ?

Demandez-lui explicitement : quels logs a-t-il consultés, quelles IP a-t-il bloquées, quels processus suspects a-t-il killt. Un hébergeur sérieux vous fournira un rapport d'intervention (même sommaire). S'il répond "on a renforcé la sécurité" sans détail, considérez que rien de concret n'a été fait.

Vérifiez côté serveur : les permissions des dossiers critiques doivent être 755 (dossiers) et 644 (fichiers). Si vous trouvez du 777 partout, l'hébergeur n'a rien corrigé. Inspectez aussi les tâches cron (commande `crontab -l` en SSH) : les malwares y planifient souvent des réinfections automatiques.

Quelles erreurs éviter absolument dans la gestion d'un piratage avec l'hébergeur ?

Ne restaurez jamais une sauvegarde sans avoir identifié le vecteur d'intrusion. Si la faille est toujours présente (plugin obsolète, mot de passe faible), vous serez piraté à nouveau sous 72h. L'hébergeur peut restaurer un snapshot système propre, mais c'est à vous de corriger la vulnérabilité applicative.

Autre erreur classique : changer uniquement le mot de passe admin WordPress. Les hackers créent souvent des comptes administrateurs cachés, modifient les credentials FTP, et injectent des backdoors dans le code. Un nettoyage complet implique de réinitialiser TOUS les mots de passe (base de données, FTP, SSH, comptes email du domaine) et de scanner chaque fichier modifié récemment.

• Ouvrir un ticket hébergeur avec captures d'écran des symptômes et logs Search Console
• Demander explicitement : snapshot disponible ? Logs d'accès des 7 derniers jours ? IP suspectes bloquées ?
• Mettre le site en maintenance publique pendant le nettoyage (évite l'indexation de nouvelles pages spam)
• Télécharger une copie complète (fichiers + BDD) AVANT toute modification pour analyse
• Vérifier les permissions fichiers/dossiers après intervention hébergeur (644/755 attendu)
• Scanner les cron jobs et comptes utilisateurs système pour détecter les backdoors persistantes