Hébergement rapide Prestashop

Prestashop 1.7 – Boostez votre hébergement (ép. 69)

Parfois il y a des choses qu’on ne soupçonne pas du tout, comme par exemple la saturation progressive de votre serveur par un mal invisible… du trafic indésirable, qui saturent les ressources de votre boutique Prestashop.

Avoir un bon serveur est important

Oui ça c’est forcément le 1er élément à prendre en compte, l’hébergement n’est pas un endroit sur lequel il faut économiser, car c’est lui qui va être le « socle » de votre boutique. Si l’hébergement n’est pas performant ou que vous avez une offre « discounter au rabais », il sera difficile d’obtenir de bonnes performances (temps de chargement, rapidité de réponse du serveur). Si vous devez investir à un endroit en priorité, c’est bien sur ce point… ne l’oubliez pas !

Des serveurs VPS au bord de la saturation

C’est ce que j’ai commencé à observer chez certains clients, c’est que la boutique Prestashop avait tendance à être lente… comme si la base de données MySQL était au bord de la saturation. Parfois ces boutiques étaient rapides et parfois très lentes… et on en revient à dire que cela doit être la faute de l’hébergeur (ce qui n’est pas tout à fait faux). On commence aussi à voir dans les logs du serveur des mentions « Too many connections » et là c’est l’inquiétude qui commence à monter…

Les robots tuent votre shop

En fait ces « bots » sont assez intelligents pour duper le serveur, ils ne spamment pas vos pages à 1000 affichages par secondes, mais viennent interroger votre serveur, chaque 30 ou 60 secondes… Quand il y’en a qu’un seul cela reste viable, mais si cela se démultiplie le serveur peut être grandement sollicité et les pages de votre Prestashop vont continuer à se charger… mais très lentement pour vos visiteurs. Cela crée un sentiment de frustration, car on se demande d’où vient la lenteur… alors qu’il semble qu’on a fait les choses en ordre.

Cloudflare

Pour certains clients j’ai déjà utilisé la solution Cloudflare qui permet de filtrer déjà en amont le trafic « déchet » et les tentatives intrusives / à risques. Le problème c’est que même Cloudflare laisse passer ces robots indésirables et se révèle donc impuissant face à ce type d’attaque… Par exemple pour moi « AhrefsBot » pour moi c’est clairement du SPAM… le site ahrefs n’a pas de raison de commencer à scanner n’importe quel autre site dans le but de l’analyser.

Et les hébergeurs dans tout ça ?

Bien souvent la réponse obtenue c’est que le problème se trouve plutôt du côté de la boutique en ligne… et cela est forcément agaçant pour le commerçant qui se trouve une fois de plus impuissant face à la situation. Ce que je peine à comprendre c’est que les hébergeurs ne proposent pas un filtre « automatique » sur tous ces robots connus comme « malsains » avec une liste automatiquement tenue à jour. Ce problème est récurrent et fait saturer beaucoup de serveurs… pourquoi ne pas proposer un tel filtrage de base… on serait tous gagnant non ?

Ressources

Pour ce tutoriel vous avez à disposition :

  • 1 x fichier de règles à ajouter à votre .htaccess
  • 1 x fichier « index.php » pour bloquer tous les types de robots

Télécharger

Résumé de la vidéo : bloquer les robots améliore la vitesse de Prestashop

  • Analyse d’un fichier de logs Apache avec les pages vues et type de bots. Chaque hébergement dispose de ce fichier de logs (vous pouvez y avoir accès via votre panel de gestion).
  • Utilisation de l’agent switcher chrome pour simuler la visite d’un robot.
  • Mise en place de règles dans le fichier « .htaccess » pour bloquer les robots connus (voir liste recommandée par Infomaniak).
  • Utilisation du fichier « index.php » et compréhension du code avec l’intégration de règles personnalisées pour bloquer tous les types de robots indésirables.
  • Je conseille de laisser tourner le fichier des logs pendant 1 ou 2 jours, puis ensuite vous pouvez faire une analyse pour voir s’il y a des indésirables / parasites permanents.

35 commentaires sur “Prestashop 1.7 – Boostez votre hébergement (ép. 69)”

    1. Hello,

      C’est vraiment super si cela fait une différence, cela prouve donc bien que beaucoup de site Prestashop sont pénalisés par ce fléau.

      A bientôt !

  1. Salut Germain
    C’est quand même dingue de voir tout ce qui se fait à notre insu …
    J’ai vu que certains, préconise de modifier le robot.txt pour bloquer les « bot » du style:
    User-agent: SemrushBot
    Disallow: /
    User-agent: SemrushBot-SA
    Disallow: /
    Mais ta méthode est intéressante, surtout pour ceux qui auraient tendance à régénérer le robot.txt via presta.
    Par contre, je me dis que de nouveaux robots ne manquerons pas d’apparaitre et qu’ils nous faut rester à l’affut de ces indésirables pour les ajouter à notre liste. Ne serait il pas possible d’autoriser les « bot » de notre choix et d’interdire tous les autres, ce serait plus simple.
    Mais bon je ne suis pas codeur …

    Merci pour ta perspicacité et le partage de connaissance.

    1. Hello,

      Il y a trop de risques d’autoriser « QUE » les bons bots, mon conseil c’est par exemple de se dire 1 x par mois on laisse tourner le script durant 24h et on regarde ce qui se passe (à noter dans l’agenda). La méthode avec l’index.php reste ma préférée, car elle est très efficace et on comprend facilement ce qui se passe.

      A bientôt !

  2. Bonjour,
    Une fois de plus, superbe tuto.
    J’ai 2 choses qui reviennent très souvent dans mon fichier log:
    bingbot et AppleWebKit. Puis-je les ajouter à la liste ou est-ce-que cela risque d’avoir un impact sur le référencement ?

    Bien cordialement.

    1. Bonjour,

      Ces deux-là vous pouvez les laisser… donc « bingbot » c’est le bot de Microsoft (même si c’est quelques % du marché, mieux vaut le laisser).

      A bientôt & merci !

  3. Rien à dire, tirs aussi efficace!!!

    Bien que je sois pas fan de la 1.7, et que le 80% des prestaUser sont en 1.6, il serai intéressant si cette méthode fonctionne aussi avec cette version.

    De plus, ils semble que l’hébergement est aussi voir autant important !!!

    Mais ce n’est que mon avis

    1. Hello,

      Oui alors la méthode du fichier « index.php » va fonctionner aussi pour Prestashop 1.6… donc tu peux l’appliquer sans problème pour réduire les attaques.

      A bientôt !

    1. Si cela ne fonctionne pas, vous pouvez commencer par activer le debug de Prestashop pour voir si une erreur est générée en arrière-plan.

      1. En fait, on dirait que le fait d’insérer les commandes dans le htaccess exactement comme indiqué, cela fait planter le site et dans ce cas évidement je n’ai plus accès au debug.
        Pourtant j’ai inséré scrupuleusement et juste après le rewrite engine on…
        Par contre en insérant le code dans le htaccess à la racine de l’hébergement, je n’ai pas d’erreur mais je ne sais pas si ça fonctionne. Je n’arrive pas à tester avec le user switch agent.
        Pourrais tu tester stp?
        J’ai normalement bloqué ahrefs, dotbot, semrushbot, sinon je vérifierai les logs demain.

        Merci

  4. Pour donner un petit retour, la methode qui a fonctionné pour moi est celle d’injecter le code suivant dans l’entête du htaccess (dans le repertoire de prestashop)

    #Anti-bots

    SetEnvIfNoCase User-Agent MJ12bot bad_bot
    SetEnvIfNoCase User-Agent AhrefsBot bad_bot
    SetEnvIfNoCase User-Agent YandexBot bad_bot
    SetEnvIfNoCase User-Agent SemrushBot bad_bot
    SetEnvIfNoCase User-Agent DotBot bad_bot
    SetEnvIfNoCase User-Agent Baiduspider bad_bot
    SetEnvIfNoCase User-Agent BLEXBot bad_bot

    Order Allow,Deny
    Allow from all
    Deny from env=bad_bot

    #ENDAnti-bots

    Je pense aussi que c’est le script qui consomme le moins de ressources dans un htaccess.
    Bon WE

    1. Hello,

      Oui c’est effectivement plus « rapide » niveau exécution (préserve aussi encore plus de ressource).

      Merci pour le retour d’expérience !

      1. Bonjour,
        ça fait 2 mois que j’ai mis en place le srcipt, au début j’utilise la méthode de germain, puis quand c’est des bots qui reviennent tout le temps, je met en place la méthode de youssef citée plus haut, ce qui me permet de laisser en place le script de germain sans avoir un fichier robotsDEBUG.txt de 50Go.
        Mais dans mes logs je vois ces robots revenir quand même exemple:
        [25/Jan/2020:11:27:16 +0100] « GET /robots.txt HTTP/1.1 » 403 360 « – » « Mozilla/5.0 (compatible; SemrushBot/6~bl; +http://www.semrush.com/bot.html) » « 20200125112716 »
        juste pour être sur, dans cet exemple le bot s’est bien pris une page 403, mais est ce que c’est normal que je le vois encore dans mes logs?
        Bien cordialement.

        1. Bonjour,

          Oui le BOT peut quand même toujours tenter d’accéder à votre hébergement, par contre dans le fichier de log, vous devriez avoir la mention « BLOCKED » pour le bot « SemrushBot ».

          A bientôt !

          1. Bonjour,
            oui dans le fichier de Log qui est créé avec le script, ça marquait bien BLOCKED, et comme j’ain dit plus haut pour faire moins gaspiler de ressources, après je met dans le htaccess deny from lenomdubot bad_bot
            du coup il ne s’écrit plus dans le fichier robotDEBUG.txt
            mais je le vois dans les vrais logs avec apparemment une page 403

  5. Salut Germain,

    Merci pour ce tuto que j’ai mis en place avec plaisir sur mon site.

    Une information sur les dates dont tu parles dans le tuto, peut-être que ça t’intéresse et que cela peut être utile à tes lecteurs.
    L’écriture des dates années-mois-jours permet simplement de classer facilement des dates par ordre chronologique en utilisant le tri alphabétique qui existe partout.
    Je l’utilise toujours pour mes fichiers, cela permet de s’y retrouver plus rapidement ;o).

    A+, Ruben

    1. Hello,

      Super, oui je l’ai mis en place aussi pour des clients et ça semble assez efficace le serveur sature beaucoup moins (en tout cas chez les clients où j’ai fait le test). Très juste, j’ai pas précisé mais dans les bases de données le format utilisé est effectivement YYYY-MM-DD ce qui permet de faire un classement croissant / décroissant facilement.

      A bientôt !

    1. Hello,

      Merci pour la contribution, voilà une ressource intéressante qui peut faire gagner du temps plutôt que de faire par « déduction » et tester chaque robot… A garder en tête pour un futur potentiel TUTO Prestashop 😉

      A bientôt !

  6. Sympa Merci pour l’astuce
    mais je trouve dommage de bloquer les bot SEO comme « SemrushBot »
    pourquoi ne pas faire une règle ou ont les bloques par exemple uniquement la journée de 05H30 à 00H30

    /* Webbax - TUTO 69 - Sécurité antibots */
    $logs = true;
    $heure = date('Hi');
    if($logs){
        $filename = "BOT.log";
        $log_file = fopen($filename, "a+") or die("Unable to open file!");
    }
    
    $bad_bots = array('AhrefsBot','SEOkicks','SemrushBot');
    $user_agent = $_SERVER['HTTP_USER_AGENT']."\n";
    
    if($logs){
        fwrite($log_file,date('Y-m-d H:i:s').' - '.$user_agent );
        fclose($log_file);
    }
    
    foreach($bad_bots as $bad_bot){
            if ($heure >= 0530 && $heure <= 0030){
                    if(strpos($user_agent,$bad_bot)!==false){
                            if($logs){
                                    $log_file = fopen($filename,"a+") or die("Unable to open file!");
                                    fwrite($log_file,date('Y-m-d H:i:s').' - '."BLOCKED : ".$bad_bot."\n");
                                    fclose($log_file);
                            }
                            die('blocked bot');
                    }
            }
    }
    /* --- */
    
    1. Hello,

      C’est une très bonne remarque… pourquoi ? Et bien parce que je n’y ai pas pensé ahaha… Un grand merci d’avoir contribué à ce tutoriel Prestashop !

      A bientôt !

  7. Bonjour, merci pour ces infos. Je viens de voir que j’ai beaucoup de visiteur et d’ajout au panier, mais avec des robot. Cela doit jouer énormément sur le taux de rebond, non?
    Je suis avec la 1.6.1, la solution suivante fonctionne t-elle?
    #Anti-bots
    SetEnvIfNoCase User-Agent MJ12bot bad_bot
    SetEnvIfNoCase User-Agent AhrefsBot bad_bot
    SetEnvIfNoCase User-Agent YandexBot bad_bot
    SetEnvIfNoCase User-Agent SemrushBot bad_bot
    SetEnvIfNoCase User-Agent DotBot bad_bot
    SetEnvIfNoCase User-Agent Baiduspider bad_bot
    SetEnvIfNoCase User-Agent BLEXBot bad_bot
    Order Allow,Deny
    Allow from all
    Deny from env=bad_bot
    #ENDAnti-bots

    Je vois aussi le passage de semruch, aref, des robot de lituanie et taiwan. Y a du monde quand même!
    Merci pour toutes vos informations qui pourrons m’aider à balayer ces robot nuisant mais en gardant les bons pur le référencement 😉
    Merci pour vos informations

  8. Bonjour Germain,
    Il y a quelques semaines j’ai installé le code et je me suis aperçu que ma page d’accueil était « blocked bot » ainsi que des onglets, j’ai donc supprimé le code mais « blocked bot » est têtu et s’affiche de temps à autre, il faut que je rafraîchisse plusieurs fois la page pour qu’elle s’affiche enfin, j’ai supprimé tous les caches des navigateurs que j’utilise ainsi que le cache de Prestashop, j’ai même supprimé dans le répertoire var/cache/ le dossier Prod.
    Si tu as une explication ou solution je suis preneur…
    Merci d’avance pour ton aide… à bientôt

    1. Hello,

      Hum, délicat… je commencerais par retirer « intégralement » le code concernant le blocage des bots pour voir comment Prestashop réagit. Ensuite, dans la variable $bad_bots essaie de mettre uniquement un seul nom de bot pour commencer (afin de pouvoir identifier d’où vient le problème).

      A bientôt !

        1. Bonjour Germain,
          j’ai testé, mais rien n’y fait, j’ai donc supprimé absolument tout le code dans le .htaccess et le fichier index.php, mais rien n’y fait j’ai toujours des pages « blocked bot » sur la page d’accueil et les onglets qui ramènent à ma page d’accueil… Au secours !!!
          Merci d’avance pour ton aide… à bientôt

    1. Bonjour,

      Difficile d’en dire plus, si le code n’est plus présent il ne peut pas continuer à s’exécuter (ou alors le code n’a pas été retiré correctement). Ce que vous pouvez faire éventuellement c’est de vérifier à nouveau en contrôlant ce fichier (l’index.php Prestashop situé à la racine) le télécharger avec Filezilla, l’ouvrir et vérifier que le code antibot pour n’est plus présent.

      A bientôt !

      1. Bonjour Germain,
        j’ai tout simplement retiré le code et tout est rentré dans l’ordre, je pense…
        Jusqu’à aujourd’hui je n’ai plus de pages « blocked bot », croisons les doigts.
        Merci pour ton aide et à bientôt !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *