Un cas pratique de Negative SEO

Pour ceux et celles qui s’en souviennent, mon serveur s’était fait hacker en début d’année 2012. J’avais reçu une attaque de bots automatiques et autant vous dire que j’avais du tout remettre à zéro (réinstallation des CMS, changements des mots de passes, etc…).

Et puis en mars, rebelote, ma passoire de serveur qui se mange à nouveau une attaque de bots automatiques. Non-seulement ça m’a bien énervé comme il faut mais en plus mon hébergeur faisait un peu la sourde oreille.

Afin de vous éviter d’avoir de mauvaises surprises, je vous donne son nom : il s’agit de Dreamhost. Alors bien évidemment, je suis parti de là le plus vite possible.

A partir de là, il est déjà trop tard et Google avait considéré presque tous mes domaines comme des sites piratés ou qui ne respectaient pas les bonnes pratiques. Pour mémo, les résultats pour mes domaines ressemblaient un peu à ça :

La toute puissance de la sécurité des serveurs Dreamhost

Bien laid, n’est-ce pas ? J’avais eu plein de pages d’erreur 500 générées avec des super title et meta description et j’étais devenu le roi du spam.

Bref, vu que j’avais une alerte dans Google Webmaster Tools, j’ai commencé à modifier certains trucs :

Première tentative

J’ai donc tout réinstallé de zéro, en important ma BDD (non-touchée). Une fois en place, j’ai fait une demande reconsidération auprès de Google en expliquant ce qui m’était arrivé et aussi que je n’avais aucun rapport avec les domaines qui me faisait du “link stuffing”.

Résultat : non-concluant. 5 jours après ma demande considération, j’avais toujours un message m’affirmant que d’après Google, je n’avais pas réglé le problème.

Deuxième tentative

Plutôt que de retenter une autre demande, je me suis dit qu’il fallait que je trouve un moyen de prouver ma bonne foi envers Google.

De ce fait, j’ai commencé à analyser tous les patterns d’URL qui avaient été généré par l’attaque de bots automatiques. Bien sûr, impossible qu’ils disparaissent avec le temps car il y avait des backlinks vers ces fausses pages 500.

Et bien entendu, hors de question que je fasse des 301 de ces fausses pages vers ma home, à moins de vouloir la mort absolue de mon domaine.

Ainsi, j’ai ajouté tous les patterns d’URL foireuses dans mon fichiers robots.txt et j’ai fait ça pour mes 3 domaines.

Une fois la tâche effectuée, j’ai refait une autre demande de considération à Google, mais cette fois-ci en précisant que je ne connaissais pas les domaines A, B et C qui me faisaient du linking non-désiré et que je n’ai jamais tenté de faire d’achat de liens ou d’acquisition de liens artificielle pour mon blog. J’ai également évoqué la modification de mon fichier robots.txt et que j’étais victime d’une attaque de bot (volontaire ou non).

Résultats : concluant : 4 jours plus tard, Google me répond dans le Webmaster Tools que la pénalité a été retirée et ce, sans exception pour chacun de mes sites (domaines et sous-domaines). Par contre, Google m’affiche tout de même un message d’alerte m’indiquant que mon fichier robots.txt bloque des pages importantes de mon site (trop drôle ce Google).

Le mail qui vous donne le sourire aux lèvres...

 Conclusion

On aura beau dire que Google fait ce qu’il veut, il y a des gens en face qui lisent vraiment ce que vous écrivez dans la demande de reconsidération. Je ne sais pas si la modification du fichier robots.txt est une bonne solution mais en tout cas, de mon côté, ça a fonctionné.

Reste qu’il s’agit d’un cas spécifique. Après, si vous faites du backlink comme un cochon vers vos vraies pages, ça risque d’être bien plus délicat et vous vous prendrez un vilain pingouin mérité en pleine face !

 

13 réflexions au sujet de “Un cas pratique de Negative SEO”

  1. quand un truc comme cela t’arrive, tu n’a pas moyen de remonter à l’auteur de l’attaque et de lui rendre la monnaie de sa pièce ?

  2. Dans ce cas les hackers ne feraient plus d’attaque. Avant d’attaquer il se rendent anonymes se qui paraît normal. Quand on commet un crime on n’écrit pas en partant sur la porte : c’était moi !

    Pour contrer ça il faut sécuriser ses hébergements et site au maximum. =)

    L’histoire fini bien quand même et heureusement !

  3. Bah il faut retrouver les logs du serveur au niveau de l’attaque, ensuite l’ip d’origine, sauf qu’il y aura surement un vpn ou une ip tempon…

    Mais ensuite…il faut quand même de bonnes notions de hacking

  4. ca vient peut être de ton cms qui n’est pas assez secure, ou comme tu l’as dit, de ton hébérgeur qui est en carton.

  5. Effectivement il faut recup les log du serveur pour l’ip.
    Par contre souvent le Hacker est un peu hédoniste c’est sa faille à lui, du coup très souvent il laisse son blase sur une page ou sur un fichier,…
    Si tu as fréquenté le milieu tu sais repérer plus facilement ce genre d’empreinte.
    Ensuite il ne te reste plus qu’a tapé son nom dans google et la tu remontes la piste, souvent un forum.
    T as plus qu’a t’inscrire si tu peux pour lui laisser un message personnel en général ça fait son effet, car il est toujours persuadé que tu ne remonteras jamais jusqu’à lui.

  6. @Newmag et Nalex : Dreamhost fait parti des rares hébergeurs ou tu ne peux avoir tes logs que pour une période définie. En clair, impossible de les récupérer. J’avais alors dû m’installer Crawltrack pour voir ce qui se passait un peu.

    @referenceur grenoble : j’y pensais mais tout était bien à jour, les règles d’accès bien établies. C’était vraiment le serveur, d’autant plus que Dreamhost l’avait reconnu publiquement la première fois. La seconde par contre…

  7. Merci pour ce partage. On se dit parfois que Google a d’autres chats à fouetter que de se préoccuper de ce qu’un webmaster peut lui dire. A tort pour ton cas apparemment…

  8. Intéressant, et désolé pour ces mauvaises aventures.

    En revanche, ce qui m’aurait intéressé, et de savoir comment le site a été hacké, d’où venait la faille, et quelles mesures tu as pris afin de combler cette faille.

    Je pose cette question car je travaille sur des sites qui ont beaucoup d’ennemis dû à leur portée idéologique, politique etc.

  9. Tu as réagi de manière méthodique, c’est surtout cela l’essentiel ! Pour le coup l’histoire finit effectivement bien !

  10. Dreamhost rame pas mal en place, en http ou ftp. C’est bien dommage.

    Au passage, certes “Google” lit, mais il s’amuse parfois à faire l’autruche. Et c’est bien dommage, même si on peut être heureux qu’on puisse les contacter.

  11. Pour ma part, j’ai constaté des baisses de 20% du trafic moteur après un crash serveur de 48 heures. Mais le flux de visiteurs est reparti en 1 à 2 semaines.

  12. Je suis d’accord, d’où mes tentatives multiples mais de façon différente. Et ce n’est pas la première fois que ça marche.

  13. Ca fait toujours mal une attaque, que ce soit le CMS ou l’hébergeur le fautif..quand le viagra ou autre spam prend la place dans les titres c’est jamais bon signe, c’est qu’il y a de gros flags bien visibles qui remontent via les google hacks.
    On a eu un problème une fois avec un plugin js pour flash mais ça ne touchait que IE, les autres navigateurs n’affichaient pas le spam…
    Comme quoi on est jamais à l’abri :(

Les commentaires sont fermés.