Intervento rapido
Il server va al 100% di CPU e nessuno sta comprando. Il sito risponde a scatti, o non risponde affatto. Le statistiche segnano visite record e gli ordini restano fermi. Quasi sempre è traffico automatico.
Il negozio è giù adesso? Scrivi a info@prestashops.it con il dominio, oppure usa il modulo in fondo alla pagina. Se puoi, allega un pezzo del log di accesso.
I bot non sono tutti uguali e non si trattano allo stesso modo. Chi copia i prezzi va rallentato, chi prova password va bloccato, chi testa carte rubate sul checkout va fermato prima che arrivi al gateway. E i crawler dei motori di ricerca devono continuare a passare.
Concorrenti e comparatori che scorrono l'intero catalogo, pagina per pagina, molte volte al giorno. Innocuo in apparenza, pesante sul database.
Liste di password rubate provate sul login clienti e sul pannello di amministrazione, una richiesta dopo l'altra.
Micro pagamenti a raffica per capire quali carte rubate funzionano. Ti restano le commissioni, i rimborsi e il rischio di perdere il gateway.
Ricerche interne e filtri di catalogo richiesti a ripetizione: ognuna è una query pesante, e la cache non le copre.
Il pannello dice che il carico è alto. I log dicono chi lo sta causando: quali indirizzi, quali percorsi, con che ritmo, dichiarando quale browser. Da lì si capisce se il traffico è automatico e di che tipo.
Prima di bloccare qualsiasi cosa si mette al riparo ciò che deve passare: i crawler dei motori di ricerca e le notifiche server-to-server dei gateway di pagamento. È il passo che quasi tutti saltano, e che rompe gli incassi.
Regole sul server per i percorsi sensibili: login, ricerca interna, checkout. Limiti per indirizzo e per sessione, tarati su come si muove un cliente vero, non su un numero preso a caso.
Quando il volume è alto, la richiesta non deve nemmeno arrivare al server. Una cache delle pagine pubbliche in rete di distribuzione risponde al posto suo, e PHP e il database restano liberi per chi compra.
Un controllo periodico che guarda i log e avvisa quando qualcosa cambia. I bot cambiano indirizzo e comportamento: una regola scritta una volta invecchia in fretta.
Casi reali, anonimizzati
Un negozio andava in ginocchio ogni volta che partiva una campagna, con la home richiesta migliaia di volte al minuto. La proposta ovvia era aggiungere core al server. Abbiamo messo la home in cache sul bordo della rete: il carico sul server è sparito e i core sono rimasti quelli.
Su un altro negozio i pagamenti con un gateway italiano risultavano falliti pur essendo andati a buon fine. La notifica server-to-server del gateway arrivava senza browser e senza cookie, e le difese anti-bot la scambiavano per un attacco. Riconosciuta e lasciata passare, gli ordini si sono chiusi di nuovo da soli.
Su una parafarmacia online abbiamo scritto i filtri sul server e un controllo periodico che analizza i log e segnala i nuovi pattern. Le regole si aggiornano su quello che si vede, non su una lista comprata.
Dai log del server. Un bot fa richieste con un ritmo regolare, ignora immagini e CSS, gira su pagine che nessun cliente visita in quell'ordine, e spesso dichiara un browser che non corrisponde a come si comporta.
Raddoppiare i core sposta il muro di qualche ora e raddoppia il conto. Se il traffico è automatico va filtrato, oppure servito da una cache che non tocca PHP e il database.
Sì, ed è la parte delicata. Le notifiche server-to-server dei gateway di pagamento e i crawler dei motori di ricerca arrivano senza browser e somigliano a bot. Vanno riconosciuti prima di alzare le difese, non dopo.
No. Molto si fa sul server, con filtri e limiti di frequenza. Una rete di distribuzione davanti al sito aiuta quando il volume è alto, perché la richiesta non arriva nemmeno al server.
Capita spesso. In quel caso il problema è la configurazione della piattaforma, le query o la cache: se ne parla in SEO e performance.
Dominio, da quando, e cosa vedi: carico alto, sito lento, tentativi di login, pagamenti strani. Se hai accesso ai log del server, dillo.