Site piraté ou pénalisé par Google : comment faire la différence ?

Distinguez infection, action manuelle et baisse algorithmique à partir des rapports Search Console, du comportement et des journaux. La priorité consiste à rétablir une situation contrôlée sans effacer les traces utiles au diagnostic. Une modification rapide peut masquer la cause, compliquer une restauration ou déplacer le problème vers une autre page.

Comment reconnaître précisément le problème ?

Une pénalité ne doit pas être supposée à partir d’une courbe. Il faut vérifier le rapport Actions manuelles, les problèmes de sécurité, les dates de mises à jour Google et les changements du site. La correction dépend ensuite de la cause documentée, pas d’une liste générique. Commencez par noter l’heure d’apparition, les dernières modifications, les URL concernées et le comportement observé. Ces quatre informations permettent souvent de réduire immédiatement le nombre d’hypothèses.

Ne vous contentez pas de l’apparence de la page. Relevez le statut HTTP, testez en navigation privée, consultez la console du navigateur lorsque le problème est visuel et examinez les journaux PHP ou serveur lorsqu’une requête échoue. Si le problème n’apparaît que pour certains visiteurs, comparez appareil, pays, rôle utilisateur, cookie et source de trafic.

Un seul signal ne prouve pas encore la cause. Une erreur visible après une mise à jour peut aussi venir d’un cache ancien, d’un changement de PHP ou d’une tâche lancée au même moment. Conservez donc une chronologie et cherchez au moins deux éléments concordants avant d’appliquer une correction durable.

Quelles causes faut-il vérifier en priorité ?

Les causes ci-dessous sont classées pour orienter l’enquête. Elles ne doivent pas être corrigées toutes en même temps. Testez d’abord l’hypothèse la plus proche de la date d’apparition, puis revenez à une configuration connue avant de passer à la suivante.

Consultez les preuves disponibles avant de désactiver ou supprimer un composant. Les journaux, l’historique des fichiers, les événements de la passerelle, Search Console ou le rapport d’état du CMS fournissent souvent un identifiant, une URL ou une heure exacte. Cette information vaut davantage qu’une succession de manipulations au hasard.

Une bonne correction ne fait pas seulement disparaître le symptôme. Elle explique pourquoi le problème est apparu et comment vérifier qu’il ne revient pas.

Que faut-il sauvegarder avant la correction ?

Créez une sauvegarde complète des fichiers et de la base de données, même si une sauvegarde automatique existe déjà. Téléchargez aussi les journaux disponibles et notez les versions du CMS, du thème, des extensions, de PHP et de la base. Si un paiement ou une commande est concerné, exportez les identifiants transactionnels sans copier les données bancaires sensibles.

La sauvegarde doit être placée hors du serveur touché. Une copie conservée dans le même compte peut être supprimée lors d’un incident, chiffrée pendant une attaque ou écrasée par une restauration. Vérifiez que l’archive s’ouvre et que la base contient bien les tables attendues avant de poursuivre.

Lorsque le site produit encore des ventes, formulaires ou inscriptions, définissez une période de maintenance courte et annoncez-la. Évitez qu’une commande arrive pendant le remplacement de la base. Pour une infection, changez d’abord les accès permettant à l’attaquant de revenir, mais conservez les preuves nécessaires pour identifier le point d’entrée.

Comment corriger site piraté ou pénalisé Google étape par étape ?

Appliquez les étapes dans l’ordre. Après chaque changement, répétez le même test et notez le résultat. Si le comportement ne change pas, revenez à l’état précédent avant de tester l’hypothèse suivante. Cette discipline réduit les effets secondaires et permet d’expliquer la résolution.

1. 01

   Étape 1

   Vérifiez séparément Sécurité, Actions manuelles et Indexation.

2. 02

   Étape 2

   Recherchez fichiers, comptes, URL et redirections inconnus.

3. 03

   Étape 3

   Alignez la baisse avec les logs et l’historique SEO.

4. 04

   Étape 4

   Traitez d’abord l’infection si elle existe, puis les conséquences de recherche.

Si une étape nécessite une modification directe de la base ou du code, réalisez-la d’abord sur une copie. Utilisez des outils capables d’annuler la modification et ne remplacez jamais une valeur sans conserver son état précédent. Pour un site e-commerce, rapprochez toujours les commandes et paiements créés pendant l’incident avant de rouvrir le tunnel.

Une restauration constitue parfois la méthode la plus rapide, mais choisissez une sauvegarde antérieure à la cause et comparez-la à l’état actuel. Les commandes, comptes ou contenus créés après cette sauvegarde doivent être préservés. Une restauration aveugle peut remettre le site en ligne tout en supprimant des données récentes ou en réintroduisant une faille.

Comment confirmer que le problème est réellement résolu ?

Refaites le parcours qui échouait avec les mêmes conditions, puis élargissez le test aux fonctions dépendantes. Une correction du checkout doit couvrir le panier, le paiement, la commande, le stock et les e-mails. Une correction SEO doit couvrir statut HTTP, rendu, robots, canonical, sitemap et maillage. Une correction de sécurité doit inclure un contrôle différé de l’intégrité.

Surveillez ensuite les journaux et les indicateurs pendant plusieurs jours. Certains problèmes dépendent d’une tâche planifiée, d’un webhook, d’un pic de trafic ou du passage d’un robot. Une validation immédiate est nécessaire, mais elle n’est pas toujours suffisante pour conclure.

Comment éviter que l’incident se reproduise ?

La prévention doit répondre à la cause identifiée. Ajouter un plugin de sécurité ne corrige pas une mauvaise procédure de mise à jour. Augmenter le serveur ne corrige pas une requête incontrôlée. Documentez donc le mécanisme exact de l’incident, le signal qui aurait permis de le voir plus tôt et la personne responsable du contrôle.

Ajoutez enfin un test simple à votre procédure de déploiement. Il peut s’agir d’une commande test, d’un crawl, d’une vérification des administrateurs ou d’une mesure de performance. Un contrôle court mais systématique détecte souvent le problème avant les visiteurs et réduit fortement le temps de résolution.