Bloquer les bots sur PrestaShop: nettoyer ps_connections et stopper les erreurs 500

Votre boutique tombe en erreur 500 chaque matin. La table ps_connections pese plusieurs gigaoctets. Les logs affichent des adresses IP negatives incomprehensibles. Ce guide explique comment identifier les bots responsables, les bloquer efficacement et remettre votre base de donnees a plat, sans sacrifier votre SEO.

Pourquoi les bots saturent PrestaShop

Un bot scraper parcourt methodiquement votre catalogue. Chaque URL visitee genere une ligne dans plusieurs tables statistiques. Multiplie par dix bots actifs en parallele, le volume d ecritures devient ingerable pour MySQL.

Le role de ps_connections et des tables statistiques

PrestaShop enregistre chaque visite dans un ecosysteme de tables liees : ps_connections, ps_connections_page, ps_connections_source, ps_guest, ps_page_viewed et ps_pagenotfound. Le module Gamme de statistiques (statsdata) pilote ces enregistrements. Il est active par defaut sur la plupart des installations.

Sur une boutique de taille moyenne, ces tables grossissent lentement. Des qu un bot agressif parcourt 5 000 pages par jour, elles enflent a vue d oeil. On voit regulierement des ps_connections depasser 3 Go la ou 50 Mo suffisent.

Quand le trafic bot devient une attaque DDoS par accident

AhrefsBot, SemrushBot, Bytespider, PetalBot, DataForSeoBot, ClaudeBot et MJ12bot ne cherchent pas a vous nuire. Ils alimentent leurs index commerciaux. Le probleme : ils ignorent souvent Crawl-delay et frappent simultanement.

Resultat typique : la base sature vers 3h du matin, MySQL rejette de nouvelles connexions et PrestaShop renvoie des erreurs 500 aux premiers visiteurs de la journee. La methodologie complete pour diagnostiquer une erreur 500 PrestaShop detaille les autres causes, mais les bots figurent dans le top 3 des declencheurs en 2026.

Identifier le probleme dans ps_connections

Avant de bloquer quoi que ce soit, il faut savoir qui frappe. Une requete suffit, a condition de comprendre pourquoi vos IP s affichent en negatif.

Pourquoi vous voyez des IP negatives

La colonne ip_address de ps_connections est stockee en INT signe sur 32 bits. Ce choix remonte a MySQL 5.5 et anterieurs, avant que INET6_ATON ne standardise le stockage IPv4/IPv6. PrestaShop a prefere un entier signe pour rester compatible avec les anciens schemas.

Consequence : toute IP dont le premier octet depasse 127 (donc la moitie d Internet, incluant les plages Amazon, Google, Alibaba) deborde la valeur maximale d un INT signe (2 147 483 647) et s affiche en negatif. Exemple : l IP 203.0.113.42 est stockee sous la forme -873 600 982. Illisible en l etat.

Convertir correctement une IP negative

La formule canonique consiste a ajouter 2^32 (soit 4 294 967 296) a toute valeur negative, puis a passer le resultat dans INET_NTOA :

-- Conversion d'une IP signee vers sa forme lisible
SELECT
    INET_NTOA(IF(ip_address < 0, ip_address + 4294967296, ip_address)) AS ip_lisible,
    ip_address AS ip_brute
FROM ps_connections
WHERE id_connections = 12345;

Le IF conditionnel evite de corrompre les IP deja positives (plage 0.0.0.0 a 127.255.255.255). La documentation officielle de INET_NTOA sur dev.mysql.com confirme cette mecanique.

Requete SQL pour lister le top des IP agressives

Voici la requete a lancer en priorite pour identifier les bots les plus bruyants des 7 derniers jours :

-- Top 20 des IP les plus actives sur la derniere semaine
SELECT
    INET_NTOA(IF(ip_address < 0, ip_address + 4294967296, ip_address)) AS ip,
    COUNT(*) AS hits,
    MIN(date_add) AS premiere_visite,
    MAX(date_add) AS derniere_visite
FROM ps_connections
WHERE date_add > DATE_SUB(NOW(), INTERVAL 7 DAY)
GROUP BY ip_address
ORDER BY hits DESC
LIMIT 20;

Une IP qui cumule plus de 2 000 visites hebdomadaires sans generer de commande est presque toujours un bot. Croisez l adresse avec un service comme ipinfo.io pour confirmer : AWS, Hetzner, OVH dedie ou Alibaba Cloud trahissent instantanement un scraper.

Bloquer les bots : 4 methodes classees par efficacite

Aucune methode n est parfaite seule. La combinaison des niveaux 1 et 2 suffit dans 80% des cas. Les niveaux 3 et 4 s ajoutent si les bots changent regulierement d IP.

Niveau 1 - Bloquer par IP dans .htaccess

Sur Apache 2.4 (standard depuis 2014), la syntaxe moderne utilise Require :

# A placer dans le .htaccess a la racine de PrestaShop
# Blocage d'IP et de plages abusives
<RequireAll>
    Require all granted
    Require not ip 54.36.148.0/23
    Require not ip 114.119.128.0/17
    Require not ip 47.128.0.0/14
</RequireAll>

Sur un hebergement Apache 2.2 ancien, utilisez la syntaxe legacy :

Order Allow,Deny
Allow from all
Deny from 54.36.148.0/23
Deny from 114.119.128.0/17
Deny from 47.128.0.0/14

Placez ces directives avant les regles de reecriture PrestaShop pour eviter qu Apache ne consomme des ressources avant de rejeter la requete.

Niveau 2 - Bloquer par User-Agent

Les bots declarent leur identite dans l en-tete User-Agent. Filtrer sur ce critere attrape ceux qui tournent en IP rotative :

# Blocage par User-Agent des principaux scrapers commerciaux
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (AhrefsBot|SemrushBot|Bytespider|PetalBot|DataForSeoBot|ClaudeBot|MJ12bot|DotBot|BLEXBot) [NC]
RewriteRule .* - [F,L]

Le flag [F] renvoie un 403 Forbidden direct, sans executer PHP, donc sans ecriture en base. C est le gain principal face a un blocage via module PrestaShop.

Completez avec un robots.txt propre pour les bots qui respectent encore les standards :

User-agent: AhrefsBot
Disallow: /

User-agent: SemrushBot
Disallow: /

User-agent: DataForSeoBot
Disallow: /

Attention : certains bots mentent sur leur User-Agent. Le blocage htaccess reste indispensable.

Niveau 3 - Cloudflare gratuit comme filtre en amont

Le plan gratuit de Cloudflare inclut le Bot Fight Mode et des regles WAF. Activez dans l ordre :

• Security > Bots > Bot Fight Mode : ON
• Security > WAF > Custom Rules : bloquer (cf.client.bot) and not (http.user_agent contains "Googlebot")
• Speed > Caching : cachez les pages produits (TTL 2h minimum)

Filtrer en amont soulage votre serveur : les bots recoivent un challenge Cloudflare et ne touchent jamais PrestaShop. Combine a un audit de performance cote serveur, l effet sur les temps de reponse d une boutique lente est immediat.

Niveau 4 - Fail2ban pour les cas avances

Si vous avez acces SSH, Fail2ban detecte et bannit dynamiquement les IP agressives. Jail minimale pour Apache :

# /etc/fail2ban/jail.local
[apache-scraper]
enabled  = true
port     = http,https
filter   = apache-scraper
logpath  = /var/log/apache2/access.log
maxretry = 100
findtime = 60
bantime  = 86400

Le filtre associe /etc/fail2ban/filter.d/apache-scraper.conf :

[Definition]
failregex = ^<HOST> .* "(GET|POST) .* HTTP.*" (200|404) .*$
ignoreregex =

Traduction : si une IP emet plus de 100 requetes en 60 secondes, elle est bannie 24h au niveau iptables. Methode efficace mais a calibrer, sinon Googlebot y passe aussi.

Nettoyer la base de donnees gonflee

Bloquer les bots sans nettoyer laisse votre base obese. Voici comment la remettre a plat sans casser la prod.

Les 6 tables PrestaShop a vider en priorite

Avant toute intervention, sauvegardez la base complete (mysqldump). Puis :

-- Sauvegarde d'abord, ces commandes sont irreversibles
TRUNCATE TABLE ps_connections;
TRUNCATE TABLE ps_connections_page;
TRUNCATE TABLE ps_connections_source;
TRUNCATE TABLE ps_guest;
TRUNCATE TABLE ps_page_viewed;
TRUNCATE TABLE ps_pagenotfound;

Ces tables ne contiennent que de la donnee analytique. Aucun impact sur les commandes, les clients ou le catalogue. En revanche, vos statistiques back-office repartent de zero.

Si votre table est trop lourde pour un TRUNCATE rapide (verrouillage MySQL), preferez un DELETE par lots :

-- Suppression progressive par blocs de 10 000 lignes
DELETE FROM ps_connections
WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY)
LIMIT 10000;
-- Repeter jusqu a ce que ROW_COUNT() renvoie 0

Desactiver definitivement le module statsdata

Sans cette etape, les tables se re-remplissent des le prochain passage de bot :

-- Desactivation du module statistique responsable des ecritures massives
UPDATE ps_module SET active = 0 WHERE name = 'statsdata';

Ou via le back-office : Modules > Gestionnaire de modules > rechercher statsdata > Desactiver. Cette desactivation ne casse rien de visible cote client. Elle prive simplement le back-office de quelques graphiques que 95% des marchands ne consultent jamais. La documentation officielle PrestaShop confirme que statsdata n est pas requis pour le fonctionnement transactionnel.

Prevenir le retour du probleme

Un nettoyage sans monitoring vous ramene au meme stade dans trois mois. Deux reflexes a installer.

Monitoring des erreurs 500 et du poids BDD

Surveillez deux metriques minimum :

• Taille de ps_connections : alerte si elle depasse 200 Mo
• Frequence des erreurs 500 : alerte si plus de 5 erreurs par heure

Une requete simple donne la taille des tables :

-- Poids detaille des tables de connexions
SELECT
    table_name,
    ROUND(((data_length + index_length) / 1024 / 1024), 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name LIKE 'ps_connections%'
ORDER BY size_mb DESC;

Un scanner gratuit comme celui de BugRescue audite en une minute les signaux exterieurs visibles (temps de reponse, en-tetes de securite, certificat SSL) qui accompagnent souvent une base saturee.

Mise en place d un garde-fou automatique

Ajoutez un cron mensuel qui purge les connexions anciennes :

# /etc/cron.d/prestashop-cleanup
# Purge des connexions de plus de 90 jours, chaque 1er du mois a 3h
0 3 1 * * mysql -u USER -pPASSWORD DBNAME -e "DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY) LIMIT 50000;"

Adaptez USER, PASSWORD et DBNAME a votre configuration. Le LIMIT evite un verrouillage prolonge en cas de gros volume.

Retour terrain : cas client

Une boutique B2B specialisee en pieces industrielles (environ 1 500 SKU) nous a contactes apres trois semaines d erreurs 500 matinales recurrentes. Diagnostic : un seul bot asiatique emettait 4 200 requetes par jour depuis une plage d IP Alibaba Cloud.

Releves avant intervention :

• ps_connections : 2,3 Go (versus 80 Mo raisonnables)
• Base totale : 4,1 Go
• Temps moyen de reponse : 3,8 s
• Erreurs 500 : 12 a 18 par jour

Resolution : blocage htaccess de la plage IP, purge des 6 tables statistiques, desactivation de statsdata, mise en place de Cloudflare Bot Fight Mode. Intervention bouclee en 2h10. Sept jours plus tard : ps_connections stabilisee a 45 Mo, zero erreur 500, TTFB descendu a 680 ms. Ce type de redressement fait partie du quotidien de notre service de correction de bugs PrestaShop.

Questions frequentes

Faut-il bloquer tous les bots ?

Non. Googlebot, Bingbot et Applebot alimentent votre referencement naturel. L objectif est de filtrer les crawlers commerciaux (SEO tools, IA scrapers) qui ne vous apportent aucun trafic qualifie. Regle simple : bloquez tout bot dont l identite commence par un nom d outil SaaS.

Bloquer AhrefsBot impacte-t-il mon SEO ?

Pas sur Google. AhrefsBot alimente la plateforme Ahrefs, utile a vos concurrents et a votre propre analyse de backlinks, mais sans aucun effet sur votre classement Google ou Bing. Vous perdez simplement la capacite a voir votre profil de liens depuis Ahrefs, compromis acceptable si votre base sature.

Comment differencier un vrai bot d un scraper deguise ?

Resolvez l IP inverse (reverse DNS). Un vrai Googlebot provient d un hostname *.googlebot.com ou *.google.com. Un scraper deguise montre generalement un hostname de cloud provider (AWS, OVH, Hetzner) ou rien du tout. La commande host <IP> depuis un terminal Linux suffit a trancher.

Pourquoi Googlebot n apparait pas comme une IP negative ?

Googlebot utilise majoritairement des IP dans des plages dont le premier octet est inferieur a 128 (notamment 66.249.x.x). Ces valeurs tiennent dans un INT signe sans debordement, d ou une representation positive lisible en base.

Combien pese une table ps_connections saine ?

Pour une boutique de moins de 5 000 visites journalieres, une ps_connections sous 100 Mo est normale. Entre 100 et 500 Mo, l alerte est legere. Au-dela de 500 Mo, il y a toujours un bot hors de controle ou un module statistique qui fuit.

Conclusion

Si votre boutique tombe en erreur 500 depuis plusieurs jours et que votre base de donnees ne cesse de gonfler, ne laissez pas la situation s installer. Un expert PrestaShop peut auditer le probleme en moins d une heure et remettre votre site en ligne avant la prochaine saturation nocturne. Contactez BugRescue pour un diagnostic gratuit.