Site signalé dangereux par Google : nettoyage et demande de réexamen

Site signalé dangereux par Google : nettoyage et demande de réexamen

Votre site est signalé dangereux par Google ? Identifiez d’abord le message exact, puis consultez le rapport « Problèmes de sécurité » dans Search Console. Si une compromission est confirmée, il faut assainir tout le périmètre concerné, corriger la porte d’entrée et tester les corrections avant de demander un examen. La suppression d’un fichier ou l’achat d’un certificat ne suffit pas à faire lever une alerte Safe Browsing.

Pour une PME, l’urgence est concrète : un prospect voit un avertissement avant d’accéder au formulaire, une équipe hésite à transmettre le lien du site, une campagne continue d’envoyer des visiteurs vers une page potentiellement compromise. La première décision consiste à protéger ces visiteurs et à organiser le diagnostic, pas à leur expliquer comment contourner l’alerte.

1. Alerte de sécurité, action manuelle ou certificat : distinguer les messages

Google Safe Browsing peut afficher un avertissement lorsqu’un internaute ouvre une page considérée comme dangereuse ou télécharge un fichier dangereux. Du contenu malveillant, un formulaire de phishing ou un élément tiers trompeur peuvent être en cause. Le texte affiché varie selon le produit et le contexte : conservez le message complet, l’URL et une capture sans inciter vos collègues à ouvrir la page.

• « Problèmes de sécurité » dans Search Console : ce rapport décrit les problèmes de sécurité détectés par Google, avec des catégories et, lorsqu’elles sont disponibles, des URL exemples. C’est le point de départ de la demande d’examen de sécurité.
• « Actions manuelles » : ce rapport concerne une intervention liée aux règles antispam de Google Search. Il dispose de sa propre procédure. Une action manuelle et un problème de sécurité peuvent coexister ; régler l’un ne prouve pas que l’autre est résolu.
• Erreur de certificat ou de connexion privée : elle concerne notamment la validation de la connexion HTTPS. Son diagnostic relève du certificat, du domaine et de la configuration TLS. Un certificat valide ne garantit pas que le contenu est sain.

Une chute de trafic, à elle seule, ne démontre aucune de ces situations. Inversement, un résultat de recherche encore visible ne prouve pas que le site est sûr. Le diagnostic doit suivre le message réellement observé.

2. Relever le signalement sans limiter le nettoyage aux exemples

Accédez directement à Search Console depuis votre compte habituel, plutôt que depuis un lien reçu dans un courriel suspect. Vérifiez que la propriété correspond au domaine et au protocole concernés. Si personne dans l’entreprise ne dispose de l’accès nécessaire, identifiez le propriétaire légitime et organisez sa récupération ; ne communiquez pas les identifiants par messagerie pour gagner quelques minutes.

Dans le rapport officiel « Problèmes de sécurité », ouvrez chaque catégorie. Relevez la date de détection, le type de problème et les URL fournies. Google précise que ces URL constituent un échantillon, pas une liste exhaustive. L’absence d’exemple ne signifie donc pas que le signalement est vide.

Demandez au responsable technique de rechercher le mécanisme derrière ces exemples : injection dans un modèle commun, page ajoutée sans autorisation, téléchargement, redirection conditionnelle ou ressource externe. Un seul modèle modifié peut affecter plusieurs pages qui ne figurent pas dans le rapport. Supprimer uniquement les URL citées laisserait alors le mécanisme actif ailleurs.

Le rapport peut aussi signaler un comportement que vous ne reproduisez pas sur votre ordinateur. Google explique que les avertissements dépendent du contexte de navigation. Une visite réussie depuis votre compte administrateur ne suffit donc pas à conclure à un faux positif.

3. Protéger les visiteurs et préserver ce qui permettra de comprendre

Si du contenu dangereux est confirmé, convenez avec l’hébergeur des mesures de confinement adaptées : isoler les parties affectées, suspendre un téléchargement ou limiter temporairement le service. Interrompez les campagnes qui y conduisent et utilisez un canal commercial indépendant du site. N’annoncez pas une réouverture avant d’avoir vérifié ce que recevront les visiteurs.

Avant le nettoyage, conservez une copie de l’environnement compromis et des journaux disponibles, avec un accès restreint. La documentation WordPress sur les sites piratés recommande de documenter les symptômes et de sauvegarder avant d’intervenir. Cette copie sert à comprendre l’incident et à revenir sur une erreur de manipulation ; elle ne doit pas devenir une sauvegarde réputée saine.

Pour la reprise générale des accès et le choix entre restauration et nettoyage, le guide site WordPress piraté : reprendre le contrôle complète cette procédure. Ici, le livrable spécifique est un dossier de corrections vérifiables correspondant au signalement Google.

4. Nettoyer le périmètre et fermer la porte d’entrée

Le périmètre du nettoyage doit couvrir les fichiers, la base de données, les comptes et la configuration effectivement concernés. Il faut examiner les composants actifs, les extensions obligatoires, les tâches planifiées et les ressources chargées depuis des tiers. Le périmètre dépend du diagnostic : cette liste guide l’investigation, elle ne prouve pas que chaque élément est compromis.

Réinstaller un composant depuis une source fiable peut remplacer ses fichiers modifiés sans supprimer les fichiers supplémentaires déposés par un attaquant. Restaurer une sauvegarde peut réintroduire la même vulnérabilité ou des accès dérobés. Dans les deux cas, il faut vérifier la cause, actualiser ou retirer les composants à risque, révoquer les accès non autorisés et renouveler les secrets concernés dans un environnement assaini.

Un scanner ou un plugin peut aider à identifier certains indices. Son résultat ne constitue pas, seul, une preuve de nettoyage complet. Les recommandations de sécurisation WordPress replacent les outils dans un ensemble comprenant mises à jour, contrôle des accès, sauvegardes et surveillance.

Si la cause précise reste inconnue, écrivez-le dans le suivi technique. Faites vérifier les hypothèses restantes plutôt que d’inventer une explication destinée au formulaire d’examen. Cette incertitude doit influencer les tests et la surveillance après réouverture.

5. Tester les corrections avant de demander l’examen

La question n’est pas seulement « la page d’accueil fonctionne-t-elle ? ». Pour chaque catégorie signalée, associez un contrôle à la correction effectuée. Faites examiner les URL exemples, les autres pages utilisant le même modèle, les destinations des redirections et les ressources tierces impliquées. Les vérifications doivent être conduites par une personne équipée pour analyser du contenu potentiellement hostile, sans exposer les postes de travail habituels.

• Les éléments malveillants identifiés ont-ils été supprimés sur tout le périmètre retrouvé ?
• Le composant vulnérable ou l’accès détourné a-t-il été corrigé ou retiré ?
• Les parcours publics, formulaires et téléchargements attendus fonctionnent-ils sans comportement indésirable ?
• Les pages utiles restent-elles accessibles à Google pour vérification, sans blocage accidentel ?
• Qui conserve les résultats et traite une nouvelle alerte ?

Masquer le problème derrière une connexion obligatoire ou changer simplement de domaine ne démontre pas sa résolution. Purger un cache peut être utile après une correction pour servir la bonne version ; cela ne supprime ni le code persistant ni un signalement Google à lui seul.

6. Rédiger une demande d’examen précise, sans promesse de délai

Lorsque tous les problèmes listés ont été corrigés et testés, utilisez la commande de demande d’examen du rapport « Problèmes de sécurité ». Décrivez le problème identifié, les mesures prises et les résultats des contrôles. Préférez des opérations vérifiables à une formule comme « tout est maintenant sécurisé ».

Une trame de travail utile comprend : catégorie signalée ; périmètre recherché au-delà des exemples ; éléments supprimés ; cause corrigée ou incertitude restante ; contrôles réalisés. Adaptez-la à ce qui a réellement été fait. N’incluez pas de mots de passe, de secrets techniques ni de données clients dans le récit.

Google indique que les examens peuvent prendre plusieurs jours ou semaines et demande de ne pas renvoyer une demande avant la décision sur celle déjà en cours. Ce n’est pas un engagement de délai : aucun prestataire ne peut garantir la date de retrait de l’avertissement. Un refus impose de reprendre les éléments non résolus, pas de réenvoyer le même texte.

Si une action manuelle est également présente, suivez séparément les instructions de ce rapport. La levée d’une alerte de sécurité ne promet ni le rétablissement immédiat du trafic ni le retour à un classement antérieur.

7. Organiser le rétablissement et la surveillance

Suivez la réponse dans Search Console et les notifications associées. Contrôlez ensuite le signalement, le comportement du site et les parcours commerciaux. Si un avertissement persiste, relevez le produit qui l’affiche et l’URL exacte : un antivirus tiers, une erreur TLS et Safe Browsing ne partagent pas nécessairement la même procédure.

Attribuez un responsable aux mises à jour, aux alertes, aux sauvegardes testées et aux accès. Un contrôle ponctuel répond à l’incident ; la surveillance récurrente vise à détecter un nouveau changement. Le compte rendu doit distinguer ce qui est corrigé, ce qui a été testé et ce qui reste à surveiller.

FAQ : site dangereux et réexamen Google

Un certificat SSL neuf retire-t-il l’alerte ?

Pas si elle concerne du phishing ou un logiciel malveillant. Le certificat protège la connexion ; le contenu et les accès doivent être traités séparément.

Je ne vois aucune alerte : puis-je déclarer un faux positif ?

Pas sur cette seule observation. Comparez le message, les catégories du rapport et les contrôles techniques. Si vous estimez le classement erroné après investigation, documentez cette conclusion et utilisez la procédure officielle adaptée.

Un plugin avec un scan « propre » suffit-il ?

Non. Il faut vérifier le périmètre, la cause et les parcours affectés. Un outil ne voit pas nécessairement tous les comptes, composants ou comportements conditionnels.

Faut-il demander une indexation à la place ?

Non. Une demande d’indexation ne remplace pas l’examen de sécurité. Utilisez le rapport correspondant au problème constaté.

Faire cadrer l’assainissement avant le réexamen

Vous avez besoin de coordonner nettoyage, preuves des corrections, demande d’examen et reprise surveillée ? Présentez le message observé et le périmètre connu lors d’un échange avec Say Digital, sans transmettre de secrets. Le périmètre d’intervention et ses critères de validation doivent être convenus par écrit.

La gouvernance IT et la maintenance permettent de cadrer les responsabilités techniques. L’hébergement Cloud et VPS répond à un besoin d’exploitation distinct : il ne remplace ni un nettoyage confirmé ni la décision de Google sur un examen.

Selon les symptômes observés

Si les URL signalées renvoient les visiteurs vers un autre domaine, commencez par documenter la redirection et ses conditions de déclenchement avant de décrire les corrections dans la demande de réexamen.

Sources officielles

Les procédures liées ci-dessus proviennent de Google Search Console, Google Safe Browsing et WordPress. Elles établissent les étapes et leurs limites ; elles ne constituent pas une preuve que votre site particulier a été assaini.