Un site hacké perd-il son crawl budget suite aux alertes de sécurité Google ?

Pourquoi Google maintient-il le crawl d'un site compromis ?

La logique de Google repose sur une séparation stricte entre découverte du contenu et affichage dans les résultats. Le crawl sert à indexer les pages, à détecter les modifications, à repérer les problèmes techniques. Si Googlebot arrêtait de crawler un site hacké, il ne pourrait plus vérifier si la correction a été effectuée.

Concrètement, un site compromis continue d'être exploré à la même fréquence — le crawl budget reste intact. En revanche, l'affichage dans les SERP bascule en mode dégradé : avertissement rouge « Ce site peut endommager votre ordinateur », filtrage partiel ou total selon la gravité, parfois désindexation temporaire des pages infectées. Le crawler, lui, ne change pas de rythme.

Quelle différence entre crawl et affichage dans cette situation ?

Le crawl désigne la phase d'exploration : Googlebot visite les URLs, télécharge le HTML, suit les liens, remplit l'index. Cette phase n'est pas affectée par les alertes de sécurité. Le bot continue son travail, collecte les signaux, actualise les données.

L'affichage, c'est la phase de restitution dans les résultats de recherche. C'est là que Google applique les filtres de sécurité : bannières d'avertissement, suppression de certaines pages des SERP, affichage d'un message de type « Site déconseillé ». L'utilisateur ne voit pas le site, même si Google continue de le crawler en arrière-plan.

Faut-il attendre que Google re-crawle après correction pour lever l'alerte ?

Non, le processus est distinct. Une fois le code malveillant supprimé, il faut demander une révision manuelle dans Search Console. Google ne lèvera pas l'alerte automatiquement, même après avoir re-crawlé les pages saines. La révision passe par un examen humain ou semi-automatisé distinct du pipeline de crawl.

Le re-crawl post-correction permet à Google de constater que le malware a disparu, mais c'est la demande de révision explicite qui déclenche la levée de l'avertissement. Sans cette étape, l'alerte peut persister des semaines, même si le site est propre et crawlé quotidiennement.

• Le crawl budget n'est pas impacté par les alertes de sécurité — Googlebot continue d'explorer normalement.
• L'affichage dans les SERP est dégradé : avertissements, filtrage, chute de CTR dramatique.
• La correction doit être rapide : chaque jour avec avertissement = perte de trafic, érosion de confiance.
• L'analyse forensique est obligatoire : identifier le vecteur d'infection pour éviter la récidive immédiate.
• La demande de révision est manuelle : Google ne lève pas l'alerte automatiquement après re-crawl.

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, elle correspond aux cas documentés. Les sites compromis continuent d'apparaître dans les logs de crawl avec des fréquences identiques ou proches de celles d'avant l'infection. La baisse de trafic observée provient exclusivement de l'effondrement du CTR — les impressions chutent parfois aussi, mais par effet de cascade : moins de clics = signal de faible pertinence = rétrogradation progressive.

En revanche, la déclaration de Mueller reste descriptive et ne détaille pas les mécanismes. Rien sur le délai de révision, rien sur le traitement différencié selon le type d'infection (phishing vs malware vs SEO spam), rien sur l'impact indirect d'une alerte prolongée. [A vérifier] si une alerte maintenue plusieurs semaines sans correction finit par déclencher une réduction de crawl pour préserver les ressources.

Quels risques annexes ne sont pas mentionnés dans cette déclaration ?

Premier risque : la contamination des backlinks. Un site hacké qui injecte du spam ou des redirections vers des pages malveillantes peut voir ses backlinks naturels supprimés par les sites sources, qui détectent l'infection et coupent les liens. Perte de PageRank, affaiblissement du profil de liens — impact SEO indirect mais durable.

Deuxième risque : l'effet sur la confiance utilisateur. Un site affiché avec avertissement rouge pendant plusieurs jours perd une partie de son audience fidèle. Même après levée de l'alerte, le trafic direct peut mettre des semaines à revenir. Les utilisateurs mémorisent « ce site n'est pas sûr » et ne reviennent pas immédiatement, même après correction.

Dans quels cas cette règle ne s'applique-t-elle pas strictement ?

Si l'infection entraîne une désindexation manuelle complète (cas extrême : phishing massif, site entièrement transformé en ferme de malware), alors le crawl peut effectivement être réduit. Un site retiré de l'index perd sa priorité dans la file de crawl — logique : pourquoi crawler intensément un site qui ne sera pas affiché pendant des semaines ?

Autre cas : infection récidivante. Un site hacké, corrigé, puis ré-infecté dans les 48 heures peut subir une pénalité de crawl implicite. Google détecte le pattern « correction factice, code malveillant toujours présent », et peut décider de réduire la fréquence de crawl pour ne pas gaspiller de ressources sur un site manifestement non sécurisé. [A vérifier] — observation empirique, pas de confirmation officielle.

Que faut-il faire immédiatement après une alerte de sécurité ?

Isoler le vecteur d'infection en priorité : plugin obsolète, mot de passe FTP compromis, faille dans un thème custom. Nettoyer le code sans comprendre la cause = récidive garantie sous 72 heures. Analyse des logs serveur, recherche de fichiers modifiés récemment, scan antivirus serveur — tout doit être passé au crible.

Ensuite, suppression complète du code malveillant : ne pas se contenter de retirer le script visible, vérifier les injections dans la base de données, les fichiers .htaccess modifiés, les tâches cron suspectes. Un malware bien conçu laisse des backdoors — une porte dérobée qui permet de ré-infecter le site même après nettoyage superficiel.

Comment accélérer la levée de l'alerte dans Search Console ?

Demande de révision uniquement après nettoyage complet et vérification multicouche. Google rejette les demandes si des traces d'infection subsistent — et chaque rejet rallonge le délai de traitement. Avant de soumettre, scanner le site avec au moins deux outils indépendants (Sucuri, Wordfence, VirusTotal pour les fichiers suspects).

Documenter les actions correctives dans la demande : « Suppression de [fichier précis], mise à jour de [plugin], changement des credentials FTP/SSH, audit complet des utilisateurs admin ». Une demande vague type « le problème est résolu » ne suffit pas — Google veut des preuves que tu as identifié la cause racine.

Quelles erreurs éviter pour ne pas aggraver la situation ?

Erreur classique : restaurer une sauvegarde infectée. Si le hack date de trois semaines et que ta dernière sauvegarde saine remonte à deux mois, tu perds deux mois de contenu. Identifier la date exacte de compromission avant toute restauration — vérifier les sauvegardes avec un scan antivirus avant de les remettre en ligne.

Autre erreur : ignorer l'alerte en espérant qu'elle disparaisse. Elle ne disparaîtra pas. Chaque jour sans correction = perte de trafic cumulée, érosion de l'autorité du domaine, risque de blacklistage par d'autres services (navigateurs, antivirus tiers, listes noires publiques). L'impact dépasse rapidement Google.

• Isoler immédiatement le vecteur d'infection (logs, fichiers modifiés, accès compromis)
• Nettoyer l'intégralité du code malveillant, y compris backdoors et injections BDD
• Vérifier avec plusieurs outils de scan avant de demander la révision
• Changer tous les mots de passe (admin, FTP, SSH, base de données)
• Mettre à jour tous les plugins, thèmes, CMS — ne laisser aucune faille ouverte
• Documenter précisément les actions correctives dans la demande de révision