Quand un site se fait hacker et que Google “l’efface”, le piège classique c’est de tout miser sur une pseudo étape magique: « demander une reindexation ». En vrai, le SEO post-incident ressemble plus à un runbook qu’à un tweak. Il faut stopper l’hémorragie, prouver que c’est clean, puis réparer ce que Google a vu (pages injectées, cloaking, sitemaps toxiques, signaux de sécurité). Et accepter un truc frustrant: parfois tu fais tout bien, et ça reste moche quelques semaines. Ce n’est pas “ton SEO qui est nul”, c’est la réalité du trust après compromission.
Avant de parler Google: prouve que le site est vraiment clean (sinon tu repars dans le mur)
Tu peux bosser toute la nuit sur Search Console, si le malware est encore là (ou si l’attaquant a gardé un accès), tu perds ton temps. Le bon réflexe, c’est de traiter ça comme un incident technique, pas comme un sujet marketing.
Sur WordPress, les hacks “qui flinguent le SEO” ont souvent le même parfum: pages spam injectées (pharma, casino, japonais), redirections conditionnelles (cloaking par user-agent), sitemap bidon qui pointe vers des URLs inexistantes, ou carrément des fichiers core modifiés. Et parfois, c’est plus vicieux: un mu-plugin planqué, une tâche cron qui réinjecte le backdoor, un admin créé en douce, ou un thème “gratuit” qui exécute du code à la volée.
Ce que j’appelle “preuve de propreté”, c’est le combo suivant: tu compares les fichiers au dépôt ou à une version saine (diff), tu passes un scan sérieux côté serveur, tu regardes les logs pour comprendre l’entrée (plugin vulnérable, mot de passe faible, FTP compromis), et tu rotates tout ce qui ressemble à un secret (mots de passe, clés API, DB, comptes admin, accès hébergeur). Si tu ne sais pas comment ils sont rentrés, tu peux nettoyer… et te refaire ouvrir demain.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Google ne “t’efface” pas de la même façon: index, sécurité, action manuelle
Dans la panique, on mélange tout. Or Google peut te mettre dans le dur via plusieurs mécanismes, et la stratégie n’est pas la même.
Premier cas, le plus fréquent: l’indexation bouge parce que Google a crawlé des horreurs (spam, pages auto-générées, redirections cheloues) et a recalculé la qualité du site. Là tu vois des chutes, des URLs bizarres dans l’index, parfois des snippets absurdes. Ce n’est pas forcément une “pénalité”, c’est souvent un recalage brutal du trust.
Deuxième cas: un sujet sécurité. Safe Browsing peut afficher des alertes côté navigateur, ou Search Console peut remonter un problème de type malware/social engineering. Ici, tu peux être “visible” dans l’absolu, mais personne ne clique, et Google ne va pas te refaire confiance tant que les signaux sécurité ne reviennent pas au vert.
Troisième cas: une action manuelle. Là c’est explicite, et tant que tu n’as pas réglé et demandé une révision propre, tu peux attendre longtemps. Beaucoup de sites hackés se prennent des actions manuelles liées au spam (pages doorways, contenu injecté) ou au cloaking. Ce n’est pas une opinion, c’est juste le jeu.
Le triage dans Google Search Console: les écrans qui te font gagner du temps
Quand ton site vient d’être compromis, Search Console n’est pas un dashboard SEO. C’est ton tableau de bord d’incident côté Google. Et il y a un ordre logique.
Commence par vérifier que tu es sur la bonne propriété (idéalement la propriété de type Domain). Ensuite, va voir Sécurité et actions manuelles. S’il y a une action manuelle, tu viens de trouver ta priorité numéro 1 côté Google. S’il y a des problèmes de sécurité, c’est aussi prioritaire, parce que ça peut bloquer la confiance et la distribution.
Puis attaque la partie Indexation. Le rapport Pages (indexées / non indexées) te donne un signal utile, mais ce n’est pas là que tu vas “réparer” le truc. Ce qui t’intéresse surtout, c’est de repérer des patterns: explosion d’URLs inconnues, chemins chelous, paramètres apparus de nulle part, et des statuts HTTP incohérents (des 200 sur des pages qui devraient être mortes, des 3xx en boucle, des 404 massives générées par un spammer).
Enfin, regarde la partie Sitemaps. Les hacks SEO aiment les sitemaps, parce que c’est un canal direct vers Google. Si tu vois un sitemap que tu n’as jamais soumis, ou un sitemap qui a été modifié côté CMS/plugin, c’est un énorme drapeau rouge. Nettoyer un site sans nettoyer ses sitemaps, c’est comme enlever la moisissure en laissant l’humidité.
Nettoyer les traces SEO du hack: pages injectées, cloaking, sitemaps toxiques
Une fois le site techniquement sain, tu dois faire disparaître tout ce que le hack a produit comme “matière SEO”. C’est souvent plus long que le nettoyage du serveur, parce que tu dois être méthodique.
Les pages injectées, tu ne les “supprimes” pas juste dans WordPress. Tu t’assures qu’elles n’existent plus et que le serveur répond proprement. Si l’URL doit mourir, fais-la mourir avec un 404 ou mieux un 410 si tu es sûr de ton coup. Si c’était une URL légitime qui a été détournée, tu rétablis le contenu, et tu vérifies l’intégrité de tout ce qui l’entoure (template, header injecté, liens internes spammy, balises canonicals modifiées).
Le cloaking est le piège qui fait perdre du temps. Les attaquants servent parfois une page “normale” à toi, et une page spam à Googlebot. Donc tu vérifies au moins un échantillon en simulant différents user-agents, et tu compares ce qui sort. Si tu as le moindre doute, tu regardes aussi côté serveur (règles .htaccess, middleware, cache, CDN), parce que le cloaking peut vivre en dehors de WordPress.
Et oui, il faut nettoyer les sitemaps. Non seulement supprimer ceux qui sont malveillants, mais aussi régénérer un sitemap propre, et vérifier qu’il ne contient plus de tags, catégories ou archives générées par le spam (les hacks adorent injecter des taxonomies pour fabriquer des milliers de pages “internes” propres en apparence).
Re-indexation: la bonne façon d’utiliser « Inspection d’URL » (et pourquoi il ne faut pas spammer)
Le bouton « Demander une indexation » peut aider, mais ce n’est pas un accélérateur illimité. Sur un site hacké, il sert surtout à valider des pages clés après correction, pas à “rattraper tout le site”.
Ce que je fais en pratique: je prends la home, quelques pages business critiques, et un échantillon d’URLs qui ont été touchées (ou supposées touchées). Je vérifie que Google voit bien la version clean, que les codes HTTP sont bons, que le canonical est cohérent, et seulement ensuite je demande l’indexation. Si tu balances des centaines d’inspections, tu vas te heurter à des quotas, et tu vas surtout t’illusionner sur le fait que ça “fait revenir le SEO”. Ce qui fait revenir le SEO, c’est la qualité perçue et la stabilité après incident.
Le vrai levier “scalable”, c’est le crawl naturel via des signaux propres: sitemap propre soumis, maillage interne cohérent, pages accessibles, serveur stable, pas de redirections bizarres, pas de variations de contenu selon le user-agent. Google recrawl plus vite un site qui a l’air sain et stable qu’un site qui “supplie” via l’outil.
Accélérer la reprise: les signaux techniques qui rassurent Google
Après un hack, tu veux que Google observe un site prévisible. Les bugs techniques qui traînent deviennent deux fois plus chers, parce qu’ils se mélangent avec la perte de confiance.
Commence par les basiques HTTP. Les pages qui doivent répondre répondent en 200, les pages mortes répondent en 404/410, les redirections sont simples, pas de chaînes, pas de boucles. Tu veux aussi que ton canonical soit propre, surtout si le hack a touché des templates. Et tu vérifies robots.txt, noindex, et les headers. Un grand classique post-incident, c’est un « noindex » laissé en place après une intervention “urgence”, ou une protection serveur qui sert des pages différentes à certains user-agents.
Un petit test que je fais tout le temps, parce qu’il évite des heures de blabla, c’est de regarder les réponses HTTP sur quelques URLs clés.
# Exemple : vérifier status, location (redir) et canonical côté HTML
curl -sI https://example.com/ | sed -n '1,20p'
curl -s https://example.com/page | grep -i -E '<link rel="canonical"|noindex|refresh' | headSi tu es sur WordPress, méfie-toi aussi des caches. Un hack peut avoir “empoisonné” du contenu dans un cache page, un cache objet, ou un CDN. Tu purges, tu invalide, et tu t’assures que ce que Google récupère correspond bien à ce que toi tu vois. C’est bête, mais j’ai déjà vu des sites “clean” en admin, et toujours toxiques côté cache public.
Délais et attentes réalistes: ce qui revient vite, ce qui peut prendre des semaines
La question qu’on te pose toujours, c’est « ça revient quand ? ». La réponse honnête: ça dépend, et c’est normal. Si c’était une injection limitée et que tu as réglé la cause, tu peux voir des signaux positifs en quelques jours. Mais un site qui a servi du spam à Google pendant un moment peut mettre plusieurs semaines à retrouver une distribution stable, surtout si le hack a créé des milliers d’URLs ou a touché des pages importantes.
Le plus contre-intuitif, c’est que le retour n’est pas linéaire. Tu peux récupérer 30% d’un coup, puis plafonner, puis regrimper après un nouveau recrawl plus profond. Et parfois tu “reviens” sur certaines requêtes, mais pas sur d’autres, parce que Google recalcule aussi la pertinence et la qualité perçue à partir de signaux qui ont bougé pendant l’incident.
Si tu as une action manuelle, le délai inclut le temps de traitement de la demande de réexamen. Et là, la qualité de ton dossier compte. Pas besoin d’écrire un roman, mais il faut être clair: ce qui s’est passé, ce que tu as corrigé, comment tu évites la rechute. Les demandes floues du style « on a nettoyé » se font souvent recaler, et tu perds encore du temps.
Les erreurs fréquentes que je vois (et qui coûtent cher)
La première, c’est de restaurer une sauvegarde “ancienne” sans corriger la faille. Tu gagnes une journée, et tu perds un mois. La seconde, c’est de croire que “supprimer des URLs” dans l’outil de suppression Google règle le problème. Cet outil masque temporairement dans les résultats, il ne remplace pas une vraie suppression côté serveur, et il ne nettoie pas une compromission.
Autre erreur: laisser vivre des pages spam en 200 avec un contenu vide, en se disant que Google va comprendre. Non. Un 200, c’est un contenu. Si tu veux dire “cette page n’existe pas”, dis-le techniquement. Et surtout, ne fais pas de redirections massives “vers la home” pour tout et n’importe quoi. Ça peut empirer la perception de qualité et créer un bazar d’URLs qui tournent.
Dernière erreur que je vois beaucoup chez les PME: donner accès à 3 prestas en admin WordPress, partager des mots de passe par mail, et s’étonner que ça recommence. Le SEO post-hack est inutile si la posture de sécurité ne change pas un minimum.
Prévention: le minimum syndical pour ne pas revivre ça (surtout sur WordPress)
Je ne vais pas te vendre une forteresse. Mais tu veux au moins une hygiène stable: mises à jour core + plugins + thèmes, suppression des extensions inutiles, comptes admin au strict nécessaire, mots de passe solides, et idéalement MFA côté hébergeur et côté WordPress. Un WAF ou une protection applicative correcte (Cloudflare ou équivalent) peut calmer énormément de bruit, surtout sur les attaques automatisées.
Et surtout, des sauvegardes restaurables. Pas “j’ai un zip quelque part”, mais une vraie capacité de restauration testée. Le jour où ça part en vrille, c’est ça qui te permet de revenir vite sans bricoler un site en prod.
Le petit plus qui change la vie quand tu gères plusieurs sites: journaliser, garder des traces, et assumer un minimum de process. Quand tu peux dire « voilà la fenêtre de compromission, voilà l’endpoint d’entrée, voilà ce qu’on a corrigé », tu gères mieux la sécurité… et tu fais aussi un meilleur dossier côté Google si tu dois passer par une révision.
Conclusion: ton objectif n’est pas juste de “revenir”, c’est de redevenir crédible
Après un hack, le SEO n’est pas une opération cosmétique. C’est une reconquête de confiance, avec des preuves techniques, des signaux propres et un peu de patience. Si tu prends le problème dans le bon ordre, tu évites les faux combats (reindexation frénétique, suppressions temporaires) et tu remets ton site sur des rails. Et si tu veux faire les choses proprement, la suite logique c’est simple: durcir ton stack, réduire la surface d’attaque, et rendre la prochaine crise moins chère que celle-ci.
Sources
- Reddit r/SEO — HELP - Site Has Been Hacked - Rankings GONE
- Google Search Central — Hacked content (documentation)
- Google Search Console Help — Problèmes de sécurité
- Google Search Console Help — Security issues report (FR si disponible selon contexte)
- Google Search Console Help — Actions manuelles (accès via interface / aide)
- Google Search Central — Sitemaps (overview)
- Google Search Console Help — Outil de suppression d’URL
