MAJ – illustration générée par ChatGPT, 2026
Ok, après de longues soirées, j’ai donc pu faire redescendre à la normal la charge CPU du serveur Infomaniak et rejoindre mes « copains » du serveur mutualisé. Le combat fut long, stressant et dans la mesure où une fois de plus, je me suis retrouvé seul au monde avec mon problème, je vais en profitez pour vous en faire partager les solutions, puisque déjà quelques autres internautes commencent à rencontrer de problèmes similaires.
Rappel des faits, début du mois, mon hébergement chez Infomaniak devait être isolé car quelques choses saturait le serveur web… et à moi d’en trouver la cause et l’éradiquer. Pas de malware, mise à jour de WordPress et plugins, rien n’y fait, je finis par constater un taux anormal d’appel dans les logs sur une seul et unique page du blog, plus de 10x par secondes et venant de serveurs BingBot officiels Microsoft. La raison reste toujours un mystère, mais mes lectures ont pu montrer d’autres cas similaires. Bug de l’outil, tentative de détournement pour saturer les serveurs…
Tout d’abord, j’ai donc installé un plugin de gestion de cache des pages à la demande d’Infomaniak. Celui-ci n’a pas vraiment fait diminuer la charge CPU, et m’enquiquine plus qu’autre chose d’ailleurs.
Après de nombreux tests, j’ai finalement interdit à BingBot et MSNBot de se rendre sur tout le site contenant la page à problème. Radicale, mais le contenu de celui-ci ne souffrira pas de ce nom référencement… Ceci dit cette solution est à mon goût trop agressive.
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^.*(msnbot).* [NC] # Si le user agent contient la chaine msnbot
RewriteRule ^.* – [F,L] # On interdit alors l’accès à la page
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^.*(bingbot).* [NC] # Si le user agent contient la chaine msnbot
RewriteRule ^.* – [F,L] # On interdit alors l’accès à la page
La solution s’avère efficace, puisque la charge serveur diminue alors de suite, néanmoins les logs restent surchargés, j’adapte donc avec un fichier ROBOTS.TXT qui placé à la racine du site impose aux différents bots ce qu’il peuvent indexer ou non… 24h plus tard, les résultats sont efficaces, mon fichiers LOG de 40mo est passé à 1,5mo !
User-agent: *
Disallow: /wp-*
Disallow: /*.php$
Disallow: /*.js$
Disallow: /*.inc$
Disallow: /*.css$
Disallow: /*%26layout=
Disallow: /*xoops_url
J’impose donc de ne pas indexer tous répertoires ou fichiers commençant par wp- à savoir des fichiers critiques à WordPress, les fichiers .php, .js ou .css et propre à ce cas les urls contenant la chaine de caractère %26layout= ou xoops_url.
Bon, j’espère être tranquille jusqu’à l’année prochaine mantenant !
Allé, pour vous donner un peu de coeur à l’ouvrage… tout cela me rappelle ce morceau de musique écrit en 2002 : Cyborg Jeff – We are the Bots !
…
Lire la suite Lire la suite
Il m’arrive souvent de réaliser des sites web « OneShot » dont le contenu va rapidement se retrouver figé dans le temps. J’utilise WordPress également pour cela, car ce dernier est vraiment très rapide à mettre en place. Cependant, WP étant devenu l’une des plateformes CMS les plus rependues, conserver de vieilles instances présente des risques pour son serveur. Afin de pouvoir conserver le patrimoine web de ce que j’ai créé, j’avais trouvé un plug-in qui semblait intéressant : Static HTML Output. Malheureusement, ce dernier implique d’avoir un WordPress d’une version 3.3 minimale, ce qui était loin d’être le cas de bons nombres de sites web que j’ai créés depuis bientôt… 7 ans.
