Comment Google traite-t-il les sites piratés et quels leviers SEO actionner pour se rétablir ?

Que signifie concrètement un site piraté pour Google ?

Un site piraté n'est pas un simple incident technique. Pour Google, c'est un risque utilisateur direct : pages de phishing, redirections sauvages vers des sites tiers, injection de spam, malwares. L'algorithme détecte ces signaux et peut déclencher un avertissement dans la Search Console, voire déclasser massivement les URLs compromises.

Le moteur distingue plusieurs types de piratage : injection de contenu spam (souvent en cloaking), détournement de redirections, défiguration visible ou encore backdoor discret qui échappe à l'audit visuel. Chaque variante appelle une réponse différente, mais la priorité reste la même : couper l'hémorragie avant que l'index ne se remplisse de pages pourries.

Pourquoi Google propose-t-il une ressource dédiée plutôt qu'un traitement automatique ?

Parce que le nettoyage d'un hack ne se résume jamais à un clic. Google ne peut pas accéder au serveur ni modifier le code à votre place. La responsabilité incombe au webmaster de colmater la brèche, supprimer les fichiers malveillants, purger la base de données et renforcer les accès. C'est un chantier technique qui dépasse le périmètre d'un moteur de recherche.

La ressource /webmasters/hack existe pour cadrer la démarche : diagnostic, nettoyage, demande de réexamen. Elle évite que des milliers de webmasters paniqués ne multiplient les erreurs (suppression brutale de fichiers légitimes, réindexation précipitée sans avoir tout nettoyé). Un hack mal traité peut pourrir durablement le Trust Flow d'un domaine, même après correction.

Quels sont les impacts SEO directs d'un site compromis ?

Premiers symptômes : chute brutale du trafic organique, baisse de visibilité sur les mots-clés stratégiques, apparition de pages inconnues dans l'index (souvent en langues étrangères ou avec du contenu pharmaceutique/casino). Si Google Safe Browsing détecte le hack, un bandeau rouge s'affiche dans les SERPs et tue le CTR à 0,1 %.

Plus insidieux : le piratage peut injecter des liens sortants vers des réseaux de spam, ce qui pollue votre profil de liens. Certains hacks installent des cloakings qui affichent du contenu légitime à l'utilisateur mais du spam pur au bot Google. Résultat : indexation de milliers de pages fantômes qui diluent le crawl budget et cannibalisent les vraies URLs.

• Perte de confiance algorithmique : Google peut appliquer une action manuelle ou un filtre automatique qui persiste même après nettoyage si la demande de réexamen est bâclée.
• Indexation parasitaire : des milliers d'URLs malveillantes peuvent s'indexer en quelques jours, polluant durablement la structure du site.
• Contamination du maillage interne : certains hacks modifient les templates pour injecter des liens cachés, créant un réseau de spam interne invisible en front mais flagrant pour le crawler.
• Dégradation de l'UX : redirections intempestives, pop-ups malveillants, scripts lourds qui plombent les Core Web Vitals et détériorent le ranking mobile.
• Risque de blacklist : si Google Safe Browsing ou des antivirus tiers signalent le site, le domaine peut finir sur des listes noires externes qui mettent des mois à se résorber.

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

Oui et non. Google fournit effectivement un guide complet, mais la réalité du support est plus nuancée. La ressource /webmasters/hack est riche en diagnostic mais pauvre en accompagnement post-nettoyage. On observe régulièrement des sites qui ont correctement purgé le hack, soumis une demande de réexamen, et qui attendent des semaines sans retour tangible.

Le vrai problème : Google ne donne aucun délai garanti pour le réexamen. Un site peut rester partiellement déclassé pendant 2-3 mois même après correction totale, simplement parce que le recrawl des milliers d'URLs pourries prend du temps. Et si une seule URL malveillante reste indexée, l'action manuelle peut persister. [A vérifier] : l'efficacité réelle du processus dépend fortement de la taille du site et de la nature du hack, sans qu'aucune métrique publique ne permette d'anticiper le délai.

Quelles erreurs fréquentes rendent le nettoyage inefficace ?

Première erreur : nettoyer le visible sans traquer la backdoor. Le hack réapparaît 48 h plus tard parce que le fichier malveillant est resté planqué dans un dossier obscur du serveur. Beaucoup de webmasters se concentrent sur les symptômes (pages spam) sans éradiquer la cause (accès FTP compromis, plugin WordPress obsolète, mot de passe admin trop faible).

Deuxième erreur : demander le réexamen avant d'avoir soumis la suppression des URLs pourries via la Search Console. Google recrawle les pages signalées, les trouve toujours indexées, et rejette la demande. Il faut d'abord purger l'index avec les outils de suppression d'URL, attendre que les 410/404 soient validés, puis seulement demander le réexamen. L'ordre compte.

Dans quels cas cette approche Google atteint-elle ses limites ?

Quand le hack a touché un site e-commerce avec 50 000 URLs indexées et que 30 000 sont compromises. Le nettoyage manuel devient impraticable. Google ne propose aucun outil de désindexation en masse au-delà des suppressions d'URL une par une (limitées à 1000 requêtes par jour). Résultat : on se retrouve à attendre que le recrawl naturel fasse le boulot, ce qui peut prendre des mois.

Autre limite : les hacks sophistiqués qui jouent sur le cloaking IP. Google crawle depuis des plages d'IP connues. Certains hacks détectent le bot et affichent du contenu propre, tout en servant du spam aux vrais users. Le webmaster ne voit rien d'anormal dans la Search Console, mais le trafic organique s'effondre parce que les utilisateurs tombent sur des pages pourries. [A vérifier] : aucun outil officiel Google ne permet de simuler un crawl depuis une IP tierce pour détecter ce type de cloaking.

Que faut-il faire concrètement dès la détection d'un piratage ?

Première étape : isoler le site immédiatement. Passer temporairement en mode maintenance propre (pas de redirection, juste une page statique) pour éviter que le hack ne serve du contenu malveillant pendant l'audit. Changer tous les mots de passe (FTP, SSH, admin CMS, base de données) et révoquer les accès suspects.

Ensuite, scanner le serveur avec des outils spécialisés (Wordfence pour WordPress, Sucuri SiteCheck, ou un audit manuel via grep sur les fichiers PHP modifiés récemment). Chercher les backdoors : fichiers nommés de façon anodine (cache.php, config.php.bak) mais contenant du code eval() ou base64_decode(). Purger la base de données des entrées suspectes (users fantômes, options injectées, posts cachés).

Comment gérer la désindexation des URLs compromises ?

Utiliser l'outil de suppression d'URL dans la Search Console pour chaque page malveillante identifiée. Si le volume dépasse le millier, privilégier les suppressions par pattern (ex : /fr/pharmacy/* si toutes les URLs pharmacy sont pourries). Parallèlement, renvoyer un code 410 Gone ou 404 sur ces URLs pour accélérer la purge.

Soumettre un nouveau sitemap XML propre, excluant toutes les URLs compromises. Forcer un recrawl des pages légitimes via l'outil Inspection d'URL pour signaler à Google que le contenu sain est de retour. Attention : ne jamais demander le réexamen avant d'avoir confirmé que toutes les URLs pourries renvoient bien 404/410 et qu'aucun résidu de hack n'est visible.

Quelles erreurs éviter pour ne pas aggraver la situation ?

Ne jamais supprimer brutalement toutes les URLs suspectes sans audit préalable. Certaines pages peuvent être légitimes mais mal référencées dans l'index à cause du hack. Supprimer à tort des contenus sains créerait des 404 supplémentaires et dégraderait l'expérience utilisateur.

Éviter de soumettre plusieurs demandes de réexamen coup sur coup. Si Google rejette la première, c'est qu'il reste des traces du hack. Attendre le retour, corriger les points signalés, puis resoumettre. Spammer les demandes rallonge les délais de traitement et irrite les reviewers manuels.

• Changer immédiatement tous les mots de passe (FTP, SSH, CMS, base de données) et activer l'authentification à deux facteurs.
• Scanner le serveur avec Wordfence, Sucuri ou un outil forensique pour identifier backdoors et fichiers modifiés.
• Purger la base de données des entrées suspectes (users fantômes, options injectées, contenus cachés).
• Soumettre les URLs compromises à la suppression via la Search Console et renvoyer 410/404 sur chaque page malveillante.
• Soumettre un sitemap XML propre excluant toutes les URLs pourries, puis forcer le recrawl des pages légitimes.
• Demander le réexamen uniquement après validation complète du nettoyage et confirmation que plus aucune trace du hack n'est visible.