Il negozio non prendeva ordini e la CPU era all'80%: il colpevole era un bot di Amazon

Il negozio non prendeva ordini e la CPU era all'80%: il colpevole era un bot di Amazon

Un caso reale su una parafarmacia online PrestaShop: per tre giorni non è arrivato un ordine, il back office non faceva più entrare nessuno e poco dopo l'hosting ha avvisato che la CPU del piano era oltre l'80%. La causa non era un attacco né un errore nel codice. Era un bot di Amazon che passava le giornate a cliccare i filtri del catalogo.

Te lo racconto con i numeri presi dai log del server. Anche la parte in cui all'inizio ho sbagliato strada.

Il sintomo: niente ordini, e nessuno se ne accorge subito

Il negozio era su. La home si apriva, le schede prodotto pure. Da fuori sembrava tutto normale.

Il primo segnale è arrivato da il cliente: non riusciva più a entrare nel back office. Inseriva la password, la pagina si ricaricava e la rimandava al login. All'infinito.

Quando ho guardato il database, il quadro era un altro. L'ultimo ordine risaliva alla mattina del 19 ottobre. L'ultimo carrello a un paio d'ore dopo. Poi più niente.

Un negozio con le luci accese e la porta chiusa a chiave.

Hai un problema simile sul tuo PrestaShop adesso? Se preferisci che ci guardi io, scrivimi o richiedi il controllo gratuito. Altrimenti continua a leggere.

Il mio primo errore: ho guardato nel posto sbagliato

Un login che va in loop di solito dipende dai cookie del browser o dal controllo dell'indirizzo IP. Ho seguito quella pista, ho cambiato quell'impostazione e ho chiesto a il cliente di riprovare da una finestra in incognito.

Non è servito. E gliel'ho detto chiaro: la diagnosi era sbagliata, si ricomincia.

Lo scrivo perché succede. Il punto non è non sbagliare mai. È accorgersene in fretta e non far pagare al cliente il tempo perso a difendere un'ipotesi.

La causa vera: il database era pieno di "cache dei filtri"

Il 22 ottobre ho trovato il blocco. L'hosting aveva messo il database in stato «limitato»: quota superata, scritture bloccate.

E con le scritture bloccate PrestaShop non riesce a salvare niente. Né la sessione di chi entra nel back office (ecco il login in loop), né i carrelli, né gli ordini.

Su 2.092 MB di database, 1.630 MB erano una sola tabella: la cache del modulo dei filtri prodotto. Quasi l'80% dello spazio per una cosa che si rigenera da sola.

Perché era così gonfia? Perché ogni combinazione di filtri che qualcuno apre (prezzo, marca, formato, ordinamento) diventa una riga in quella cache. Un cliente ne apre tre o quattro. Un bot le apre tutte.

Ho svuotato la tabella: 255.859 righe tolte, nessun dato vero perso. Il back office è tornato accessibile e gli ordini sono ripartiti. Ho anche svuotato il log degli errori PHP, che era arrivato a 8 GB.

Quattro giorni dopo: «CPU oltre l'80%»

Il 26 ottobre l'hosting ha mandato un altro avviso: il piano aveva consumato oltre l'80% dei secondi di CPU del mese. Al 100% il sito resta rallentato fino a fine mese.

Stavolta sono andato dritto ai log di accesso degli ultimi tre giorni. Ho contato chi chiedeva cosa.

Il risultato:

• 73.454 richieste al sito in tre giorni
• 65.032 fatte da un solo visitatore: Amazonbot, il bot con cui Amazon scansiona il web
• cioè l'89% del traffico totale, circa 21.500 richieste al giorno
• quasi tutte su una sola zona: le pagine dei filtri della categoria parafarmaci

Non erano clienti. Non era Google. Era un bot che provava una combinazione di filtri dopo l'altra, e ogni richiesta faceva lavorare PHP e database. Lo stesso meccanismo che aveva gonfiato la cache.

Cosa ho fatto (senza toccare clienti e Google)

Bloccare Amazonbot ovunque sarebbe stato facile. Ma non serviva e poteva avere effetti che non volevo.

Ho fatto tre interventi mirati, ognuno con backup prima:

1. Blocco solo sui filtri. Amazonbot riceve un rifiuto (errore 403) solo sulle pagine con filtri e ordinamenti, prima ancora di arrivare a PHP. Home, categorie e schede prodotto restano aperte a tutti. Ho verificato: 403 al bot, pagina normale al browser.
2. robots.txt. Ho aggiunto le regole che dicono ai bot educati di non scansionare le combinazioni di filtri. Chi le rispetta smette da solo.
3. Log degli errori pulito. Il log si riempiva di circa 85 KB al minuto di avvisi «Deprecated», rumore della versione di PrestaShop sul PHP attuale. Li ho esclusi: gli errori veri restano registrati, il rumore no.

Il risultato: −87% di richieste in un giorno

Il giorno dopo il blocco, il 27 ottobre:

• Amazonbot: 75 richieste (contro le circa 21.500 al giorno di prima)
• richieste totali al sito: 3.078, contro le 23-24.000 dei giorni precedenti
• cioè −87% di lavoro per il server, con gli stessi clienti di prima

Il sito non è diventato più veloce per magia. Ha semplicemente smesso di lavorare per un visitatore che non compra.

Cosa puoi controllare tu sul tuo PrestaShop

• Guarda la dimensione delle tabelle. Se la cache dei filtri pesa più del catalogo, qualcuno sta esplorando combinazioni che nessun cliente apre.
• Conta chi visita, non quanti. Le statistiche dicono "tante visite". I log ti dicono chi sono. Più traffico non vuol dire più clienti.
• Non fidarti del "sito su". Una home che si apre non garantisce che carrelli e ordini si stiano salvando. Controlla la data dell'ultimo ordine.
• Blocca dove serve, non ovunque. Un blocco totale a un bot può costarti visibilità. Un blocco sui soli filtri no.

È lo stesso schema del caso Riso Guerrini: là era Googlebot, qui Amazonbot. I filtri a faccette sono la trappola più comune che vedo sui PrestaShop.

Vuoi sapere se sta succedendo anche a te?

Hai tre strade, scegli tu:

• Controllo gratuito. Mi dici cosa vedi sul tuo negozio, ti dico se c'è qualcosa che non torna. Scrivimi qui.
• Analisi PrestaShop (497 €). Guardo log, database, filtri, velocità e tutto quello che ti fa perdere ordini, e ti consegno cosa sistemare e in che ordine. Vedi l'Analisi.
• Negozio Sempre al Top (297 €/mese). Lo tengo d'occhio io ogni mese, così un caso come questo lo vedo prima che diventi tre giorni senza ordini. Vedi i servizi.

Frank
Francesco Ingrosso · Visioweb