Visitor Control: bloccare bot malevoli e traffico indesiderato

Apri il back office di PrestaShop, vai su Stats → Visitors online in un pomeriggio tranquillo e potresti vedere più "visitatori" di quanti siano i tuoi clienti reali. Una grossa fetta del traffico di qualsiasi negozio è automatizzata — crawler, scraper, script e sonde che non hanno alcuna intenzione di acquistare. Una parte di questa automazione è vitale per la tua attività: Googlebot deve scansionare il sito per poterlo posizionare. Il resto ti costa denaro. Consuma CPU e banda del tuo hosting, riempie le tabelle dei carrelli di spazzatura, falsa ogni dato di conversione che riporti e — nel caso dei credential stuffer e degli scanner di vulnerabilità — è la prima mossa di un attacco vero e proprio. Questa guida spiega come distinguere queste due categorie in un negozio PrestaShop, individuare quella dannosa nei tuoi log e nel database, e tenerla fuori senza bloccare per errore Google o un cliente reale.

Questo è il capitolo su bot e automazioni del nostro gruppo di guide sulla sicurezza. Rimane volutamente nel suo ambito: il blocco per IP dei singoli disturbatori umani è trattato in Customer Extra Info and IP Bans; il blocco dello spam nei moduli tramite challenge è spiegato in reCAPTCHA for PrestaShop; il sovraccarico specifico della ricerca a faccette causato dai crawler ha il suo approfondimento in come sopravvivere al flood ?q=; e le regole del server web sono raccolte in regole di sicurezza .htaccess per PrestaShop. Per capire dove si colloca il filtraggio dei bot nel quadro generale, parti dalla checklist completa di hardening della sicurezza.

Revisionato a giugno 2026 in base al comportamento attuale delle statistiche PrestaShop e di SQL Manager, e alle linee guida ancora valide per verificare Googlebot tramite DNS inverso.

Non tutti i bot sono nemici — e bloccare quelli sbagliati fa danni

L'errore più costoso che i commercianti commettono quando bloccano i bot è esagerare. Blocca Googlebot in un impeto da "fermiamo i bot" e non otterrai un negozio più sicuro — otterrai un negozio che scompare dalla ricerca. Il primo lavoro, quindi, è avere una tassonomia chiara, perché le tue regole di blocco tratteranno questi due gruppi in modo opposto.

Nota la conseguenza: uno strumento grossolano che blocca i "bot" basandosi solo sulla reputazione è pericoloso, perché buoni e cattivi usano tecniche che si sovrappongono. Un filtraggio efficace riguarda identità e comportamento, non un singolo interruttore acceso/spento.

Individuare il traffico dei bot malevoli dentro PrestaShop

Non ti serve una dashboard di terze parti per vedere il problema — PrestaShop ne registra già gran parte, e il tuo hosting registra il resto. Tre punti da controllare, in ordine di impegno.

1. Le statistiche del back office (controllo da due minuti)

Sotto Stats, i pannelli Visitors origin, Pages not found e Best-viewed pages sono indizi discreti. Un'ondata di 404 su percorsi che il tuo negozio non ha mai avuto (/wp-login.php, /.env, /administrator/) indica uno scanner di vulnerabilità che sta provando una lista generica di exploit — non sono nemmeno percorsi PrestaShop, ed è proprio così che sai che si tratta di un bot indiscriminato. Una "pagina più vista" che all'improvviso è il login o il recupero password, e non un prodotto, è una firma tipica del credential stuffing.

2. Il database (i numeri onesti)

PrestaShop registra le sessioni in ps_connections e ps_guest. Nota che ps_guest salva attributi del browser e del sistema operativo già analizzati (browser, versione, sistema operativo, risoluzione dello schermo), non una stringa User-Agent grezza — in PrestaShop standard non esiste una colonna http_user_agent, quindi non aspettarti di leggere dal database l'agent letterale. Quello che le tabelle ti danno è il volume di richieste per IP, sufficiente a far emergere una fonte che sta martellando il negozio. Una query come quella sotto (eseguila in Advanced Parameters → SQL Manager, adattando il prefisso) ordina i visitatori recenti per numero di hit:

SELECT c.ip_address, COUNT(*) AS hits FROM ps_connections c WHERE c.date_add > DATE_SUB(NOW(), INTERVAL 1 DAY) GROUP BY c.ip_address ORDER BY hits DESC LIMIT 50;

Un singolo IP con centinaia di hit in un giorno non è un cliente. Un acquirente reale carica poche pagine; uno scraper percorre tutto il catalogo in ordine. Per vedere lo User-Agent effettivo inviato da ogni IP — il punto in cui gli scraper si tradiscono con agent vuoti, generici o da script — leggi il log grezzo degli accessi del server (trattato sotto) oppure usa un modulo che registri lo User-Agent grezzo, perché le tabelle native di PrestaShop non lo conservano alla lettera.

3. Le tabelle dei carrelli (l'indizio tipico di PrestaShop)

Ecco un sintomo quasi unico di PrestaShop che confonde migliaia di commercianti: decine di carrelli abbandonati senza cliente e senza prodotti, visibili in Orders → Shopping Carts. PrestaShop crea una riga carrello nei suoi flussi di carrello e sessione nel momento in cui viene toccato un endpoint di aggiunta al carrello. I carrelli ospite vuoti possono essere generati da diverse cose — bot e crawler, moduli che pre-creano carrelli, o normale comportamento di sessione — quindi non dare per scontato che il responsabile sia un crawler specifico. Conferma dai log quale fonte abbia davvero colpito l'endpoint prima di accusare, bloccare o mettere in whitelist un crawler. I carrelli sono righe reali del database, ma in questi casi sono artefatti, non vendite perse, e la soluzione è riconoscerli ed eliminarli invece di bloccare un crawler che non hai confermato li abbia creati. Lo abbiamo analizzato nella nostra nota sui carrelli creati dai bot; il punto pratico è che i carrelli ospite vuoti sono di solito una particolarità di registrazione, non un'emergenza.

4. Il log degli accessi del server (la fonte dei fatti)

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

Il log grezzo degli accessi mostra ogni richiesta con IP, User-Agent e tempi — la fonte dei fatti che le analytics non possono falsare, perché le statistiche basate su JavaScript spesso non si attivano nemmeno per la maggior parte dei bot. Cerca un IP che richiede pagine prodotto in perfetto ordine sequenziale, richieste senza User-Agent e raffiche di hit verso /login, /password-recovery e create-account. Quel log è anche il punto in cui confermi se un "Googlebot" è quello vero — il Googlebot autentico risolve verso un host googlebot.com / google.com tramite lookup DNS inverso; uno falso dichiara quel nome ma risolve verso un IP casuale di data center.

La scala di difesa: prima ciò che costa meno e copre di più

Il filtraggio dei bot funziona a livelli, e l'ordine intelligente è partire dai controlli che fermano più traffico con il minimo sforzo e il minor rischio di falsi positivi. Sali la scala solo fin dove lo richiede il problema.

robots.txt — definisce aspettative, non una barriera

PrestaShop può generare per te un robots.txt sensato da Shop Parameters → Traffic & SEO → SEO & URLs → Generate robots.txt. Dice ai crawler ben educati di saltare carrello, procedura di acquisto, risultati di ricerca e pagine account — riducendo lo spreco di crawl da parte dei bot che vuoi mantenere. Il suo limite va capito chiaramente: viene rispettato dai bot buoni e ignorato da quelli cattivi, quindi è uno strumento di crawl budget, mai un controllo di sicurezza. Non inserire lì un percorso sperando di nasconderlo; stai pubblicando una mappa di ciò che preferiresti non far vedere.

Il WAF edge — il passo con più leva

Mettere Cloudflare (o un WAF comparabile) davanti al negozio sposta del tutto la battaglia fuori dal tuo hosting: IP noti come dannosi, richieste che non assomigliano a quelle di un vero browser e flood volumetrici vengono filtrati all'edge prima ancora di raggiungere PHP. Nel piano gratuito ottieni bot-fight mode, un database di reputazione IP, controlli di integrità del browser e regole di limitazione della frequenza di base — abbastanza per togliere dal server la maggior parte delle automazioni spazzatura. Per la maggior parte dei piccoli e medi negozi PrestaShop, questa singola mossa fa più di tutto il resto combinato, ed è lo stesso livello edge su cui faresti ancora più affidamento quando il traffico dei crawler si trasforma nel flood ?q= della ricerca a faccette capace di mandare giù un negozio.

Limitazione della frequenza — distinguere umani e script dalla velocità

Un cliente reale che naviga carica forse da cinque a dieci pagine al minuto; uno scraper che percorre il catalogo ne carica cento. Un limite di frequenza per IP (con risposta HTTP 429 superata una soglia) intercetta automaticamente questo divario. È più affidabile all'edge (Cloudflare) o a livello di server web. Impostalo in modo generoso — tieni il tetto ben sopra la navigazione umana, così un ufficio condiviso o un IP di operatore mobile, dove molti clienti reali stanno dietro lo stesso indirizzo, non viene penalizzato per essere attivo.

Challenge nei moduli e honeypot — per i moduli presi di mira

Gli scraper vogliono le tue pagine; i bot di spam vogliono i tuoi moduli. Registrazione, login, contatto e newsletter sono i punti in cui si concentrano gli invii automatici, e una challenge invisibile li blocca senza infastidire i veri acquirenti — è un tema trattato a parte in reCAPTCHA for PrestaShop. Un honeypot lo completa: un campo nascosto che un essere umano non vede mai ma che un compilatore automatico poco sofisticato riempie diligentemente, segnalando sé stesso come bot senza alcun costo per i tuoi clienti.

Bloccare per identità, dal back office di PrestaShop

I livelli sopra sono infrastrutturali. Ma vuoi anche un controllo accessibile senza SSH o sviluppatori — un posto in cui dire "questo paese mi manda solo frodi e scraper, applica una challenge" oppure "questo User-Agent di un range hosting sta martellando il mio login, bloccalo" direttamente dall'admin. Questo è il livello applicativo, ed è qui che farlo in modo nativo in PrestaShop ripaga: il blocco avviene con pieno contesto di sessione (conosce gruppo cliente, paese, agent) e sopravvive agli aggiornamenti di tema e core perché non è appeso a file di configurazione server che finirai per dimenticare.

Una cautela prima di ricorrere a un blocco IP: sii chirurgico con i ban IP. Gli IP residenziali e mobili vengono riciclati — l'IP dello scraper di oggi può essere il cliente pagante di domani sullo stesso operatore. Blocca singoli IP residenziali solo come misura breve e riesaminata; riserva i blocchi permanenti di intervalli IP a data center e VPN, dove non vive alcun cliente reale. (Bandire per IP una specifica persona abusiva è un lavoro diverso, trattato in Customer Extra Info and IP Bans.) Per interventi ampi, le regole per paese e User-Agent sono di solito più sicure e richiedono meno manutenzione rispetto alla rincorsa dei singoli indirizzi.

Dove si inserisce Visitor Control

Visitor Control conserva nel back office le decisioni di blocco specifiche del negozio.

Mettere in whitelist le reti affidabili evita che le regole di blocco ampie colpiscano il tuo team.

La tabella dei visitatori raccolti è ps_mprvc_info. Questo controllo rapido mostra se un paese o un tipo di dispositivo domina il traffico recente:

SELECT country_code, device_type, COUNT(*) AS hits
FROM ps_mprvc_info
WHERE date_add > DATE_SUB(NOW(), INTERVAL 24 HOUR)
GROUP BY country_code, device_type
ORDER BY hits DESC
LIMIT 20;

È esattamente il vuoto che il nostro modulo Visitor Control è stato creato per colmare. Svolge due compiti dall'interno del back office, senza configurazioni a livello server e senza servizi esterni da collegare. Primo, blocca i visitatori indesiderati per IP, paese o User-Agent — così puoi respingere in silenzio un agent scraper noto o un paese che ti manda solo traffico di card testing, usando la gestione delle richieste di PrestaShop invece di righe .htaccess modificate a mano. Secondo, ti mostra chi sono davvero i tuoi visitatori: dispositivo, IP e paese direttamente nel profilo cliente, così quando devi decidere se un pattern sia un bot o un acquirente reale lavori su prove, non su supposizioni. Cosa ottieni, quindi? La decisione di bloccare o consentire smette di essere un compito da amministratore server che rimandi e diventa una scelta da due minuti, presa dalla stessa schermata con cui gestisci il negozio — e, poiché è un modulo, le regole restano intatte anche dopo il prossimo aggiornamento PrestaShop.

Per il rumore specifico di PrestaShop legato ai carrelli creati dai bot, descritto prima — i carrelli ospite vuoti che distorcono i contatori del back office — gli strumenti dedicati sono sul lato carrello, dove taggano e ripuliscono i carrelli bot senza bloccare i crawler che li creano legittimamente. Il punto di separare questi lavori è la precisione: filtri il traffico che non vuoi mantenendo i bot che ti portano posizionamento e l'indicizzazione che ti porta vendite.

Una configurazione pratica a livelli per un negozio normale

Non ti serve un contratto enterprise di bot management per gestire il flusso quotidiano. Per un tipico negozio PrestaShop, questa combinazione ferma la grande maggioranza delle automazioni dannose con poca configurazione e praticamente nessun rischio per i clienti reali:

• Metti il piano gratuito di Cloudflare davanti al negozio — la più grande riduzione singola del traffico spazzatura, all'edge, prima che ti costi un ciclo CPU.
• Genera un robots.txt corretto da Traffic & SEO, così i crawler buoni saltano carrello, ricerca e pagine account e spendono il loro budget sui prodotti.
• Aggiungi una challenge invisibile ai moduli di registrazione, login, contatto e newsletter.
• Blocca per paese e User-Agent i pattern che hai confermato essere bot, dal back office, e mantieni i ban IP brevi e mirati.
• Dai un'occhiata ogni mese ai log e alla query di SQL Manager — blocca i recidivi confermati e verifica tramite DNS inverso ogni "Googlebot" sospetto prima di fidarti.

Domande frequenti

Bloccare i bot danneggerà il mio posizionamento su Google?

Solo se blocchi quelli sbagliati. I crawler dei motori di ricerca (Googlebot, Bingbot) e gli unfurler social devono poterti raggiungere — se li blocchi, nelle settimane successive le pagine spariscono dalla ricerca, oppure i link condivisi vengono mostrati senza anteprima. Tutto il lavoro consiste nel distinguerli da scraper, credential stuffer e scanner di vulnerabilità. Blocca in base a identità e comportamento confermati, verifica ogni "Googlebot" tramite DNS inverso prima di fidarti e riduci il traffico spazzatura senza toccare i bot che portano clienti.

Perché il mio negozio ha così tanti carrelli abbandonati vuoti senza cliente?

PrestaShop crea una riga carrello nel momento in cui viene toccato un endpoint di aggiunta al carrello, quindi i carrelli ospite vuoti possono arrivare da bot, crawler, moduli che pre-creano carrelli o normale comportamento di sessione. Sono righe reali, ma di solito artefatti, non vendite perse. Non dare per scontato che il responsabile sia un crawler specifico — conferma dal log degli accessi quale fonte abbia davvero colpito l'endpoint, poi ripulisci il rumore invece di bloccare alla cieca un crawler che non hai confermato li abbia creati.

robots.txt basta per tenere fuori i bot malevoli?

No. robots.txt viene rispettato dai crawler buoni e ignorato da quelli cattivi, quindi è uno strumento di crawl budget, mai un controllo di sicurezza. Vale la pena generarlo (Traffic & SEO → Generate robots.txt) per evitare che i crawler educati sprechino budget su URL di carrello, ricerca e account — ma non inserire mai lì un percorso sperando di nasconderlo, perché stai pubblicando una mappa di ciò che preferiresti non far vedere. Per i bot che lo ignorano servono WAF edge, limitazione della frequenza e blocchi basati sull'identità.

Qual è la singola cosa con l'impatto più alto che posso fare?

Per la maggior parte dei negozi piccoli e medi, mettere il piano gratuito di Cloudflare (o un WAF comparabile) davanti al negozio. Filtra IP noti come dannosi, non-browser evidenti e flood volumetrici all'edge prima che raggiungano PHP, e nel piano gratuito hai comunque bot-fight mode, reputazione IP, controlli di integrità del browser e limitazione della frequenza di base. Di solito questa singola mossa fa più di tutto il resto combinato.

Dovrei bannare in modo permanente gli indirizzi IP degli scraper?

Sii chirurgico. Gli IP residenziali e mobili vengono riciclati — l'IP dello scraper di oggi può essere il cliente pagante di domani sullo stesso operatore — quindi blocca singoli IP residenziali solo come misura breve e riesaminata. Riserva i blocchi permanenti di intervalli a data center e VPN, dove non vive alcun cliente reale, e per gli interventi ampi preferisci regole per paese e User-Agent, perché sono più sicure e richiedono meno manutenzione rispetto alla rincorsa dei singoli indirizzi.

La mentalità che mantiene tutto questo sicuro è quella da cui siamo partiti: l'obiettivo non è mai "bloccare i bot", ma "bloccare i bot che ti sottraggono risorse, accogliendo quelli che portano clienti". Definisci bene la tassonomia, leggi le prove del tuo negozio prima di calare il martello e aggiungi livelli solo fin dove il traffico te lo impone. Fatto così, il filtraggio dei bot è una delle vittorie più silenziose nella sicurezza del negozio — invisibile per i clienti che contano, e capace di fermare una perdita costante di risorse, statistiche e superficie d'attacco che altrimenti consegneresti agli script. Quando vuoi inserirlo nel resto delle tue difese, la checklist di hardening della sicurezza e la guida alla sicurezza per titolari di negozi in linguaggio semplice collegano l'intero gruppo di contenuti.