Bot e ricerca a faccette di PrestaShop: CPU al 100 % e cadute

Sabato pomeriggio. Arriva un'email dell'hosting che avvisa che il tuo account è da ore al 100 % di CPU. Apri le statistiche aspettandoti una valanga di clienti e trovi l'opposto: quarantamila pagine viste e zero ordini.

Non è un attacco, non è un modulo rotto, non è il tuo negozio che fa cose strane. È che qualcuno si è messo a percorrere, uno per uno, tutti i filtri del tuo catalogo.

Cosa sta succedendo esattamente

Il tuo negozio ha la ricerca a faccette: taglia, colore, marca, prezzo, disponibilità, e sopra l'ordinamento dei risultati. È ciò che lo rende comodo da usare.

Il problema è che ogni combinazione di quei filtri è un indirizzo web diverso. Taglia M in blu di una marca ordinata per prezzo è uno. Taglia M in blu di quella marca ordinata per novità è un altro. E così con tutte le combinazioni possibili: in un negozio medio vengono fuori centinaia di migliaia; in uno grande, milioni.

I crawler dei social e dei servizi di intelligenza artificiale —quelli di Facebook, quelli di TikTok, quelli di mezza dozzina di aziende di cui non hai mai sentito parlare— hanno deciso che devono vederle tutte. E le chiedono tutte, insieme, senza pause.

Ognuno di quegli indirizzi non è una pagina che hai in magazzino: è una ricerca nuova contro il tuo database.

Il modulo che c'è dietro: la Ricerca a faccette di PrestaShop

I filtri del tuo negozio li disegna un modulo preciso, Ricerca a faccette (ps_facetedsearch), quello incluso in PrestaShop dalla 1.7 che ha sostituito la vecchia Navigazione a livelli. Se hai i filtri nelle categorie, ce l'hai attivo.

Riconoscerlo nei tuoi registri è facile: ogni combinazione viaggia nel parametro q dell'indirizzo, con questo aspetto.

/12-magliette?q=Taglia-M/Colore-Blu/Marca-Adidas

Se aprendo il registro degli accessi vedi migliaia di righe con ?q=, tutte diverse e una dietro l'altra, sai già cosa ti sta mangiando la macchina.

Ed ecco perché costa tanto. Quando arriva una di quelle richieste, il modulo non cerca solo i prodotti che rispettano il filtro: ricalcola anche i contatori di tutti gli altri filtri —quel «Blu (12)», «Verde (5)» accanto a ogni casella— e per farlo lancia diverse query di conteggio sulle sue tabelle di indice. Moltiplicalo per un catalogo grande e per migliaia di richieste al minuto.

Due leve che stanno nel modulo stesso e che quasi nessuno tocca, in Catalogo → Ricerca a faccette:

• Togliere il numero di prodotti accanto a ogni filtro. È la parte più costosa di ogni richiesta e, nella maggior parte dei negozi, quella che manca meno.
• Rivedere i modelli di filtri per categoria. Ogni filtro che lasci moltiplica le combinazioni possibili. Otto filtri in una categoria non sono otto indirizzi: sono migliaia.

Nessuna delle due risolve il problema da sola, ma entrambe abbassano il costo di ogni colpo prima di toccare altro.

Perché fa così male

Una ricerca filtrata è una delle operazioni più costose che fa un negozio: deve scorrere tutto il catalogo, incrociare attributi, contare quanti prodotti restano sotto ogni filtro e ordinare il risultato. Un cliente ne fa tre o quattro in tutta la visita. Un crawler ne fa tre o quattro al secondo.

Ed ecco la parte che spiazza tutti: la cache non ti salva. La cache serve quando molti visitatori chiedono la stessa cosa. Qui non si ripete niente: ogni combinazione è unica, quindi sono tutte «prime visite» e arrivano tutte al database.

Il risultato è sempre lo stesso. Le richieste si accumulano, il server resta senza spazio e il negozio smette di rispondere — al robot e al cliente che stava per pagare. Se poi capita in piena campagna, hai pagato pubblicità verso un sito che non si apriva.

Come capire se è il tuo caso

Quattro segnali, e se due si sommano è quasi certo:

• Consumo alto senza vendite. Moltissime pagine viste, nessun carrello. Visite e ordini non tornano nemmeno lontanamente.
• L'hosting ti avvisa che consumi troppo, o ti sospende l'account per un po' «per proteggere gli altri clienti».
• Cade a orari strani: di notte, di domenica, a tratti senza alcuna logica commerciale.
• Nel registro degli accessi ci sono migliaia di indirizzi consecutivi con parametri di filtro, tutti diversi, richiesti in pochi secondi.

Se nel frattempo anche il pannello di amministrazione arranca, hai la conferma: non è la parte pubblica, è la macchina satura. Lo raccontavamo in quando la lentezza è del negozio e quando del server.

Cosa ti proporranno, e perché non basta

Questo problema attira parecchie soluzioni popolari che nella pratica non reggono:

1. «Bloccali nel file robots.txt». Quel file è una richiesta educata, non una porta. I crawler che lo rispettano non sono il tuo problema; quelli che ti stanno buttando giù non lo leggono. E se esageri, quello che obbedisce è Google, e ti cancelli dai risultati da solo.
2. «Blocca Facebook e TikTok per nome». Funziona una settimana. Cambiano identità, entrano da migliaia di indirizzi diversi e ne spuntano tre nuovi ogni mese. È un elenco che non finisci mai di mantenere.
3. «Segnale come noindex e via». Che una pagina abbia il tag noindex non evita la spesa: il robot deve comunque chiederla per poter leggere quel tag. Serve al motore, non alla tua CPU.
4. «Prendi un server più grosso». Pagare il doppio per servire gratis il catalogo a un robot è un pessimo affare: il picco successivo sarà più grande, perché più rispondi bene, più in fretta te lo chiedono.
5. «Disattiva la ricerca a faccette». Risolve il consumo e rompe il negozio: i filtri sono il modo in cui la gente trova quello che comprerà. Si vede nella conversione il giorno dopo.
6. «Metti un CDN davanti e via». Un CDN accelera ciò che si ripete. Qui non si ripete nulla: ogni combinazione è unica e arriva comunque al tuo database.
7. «Attiva la modalità sotto attacco». O la rendi difficile anche ai tuoi clienti — e a Google — oppure i robot passano lo stesso. Serve a reggere un pomeriggio, non a viverci.

Tutte condividono lo stesso difetto: curano il sintomo, cioè il traffico, invece della causa, cioè che il tuo negozio è disposto a fabbricare milioni di pagine diverse a chiunque le chieda.

Dove sta la soluzione vera

Quello che regge si costruisce su tre livelli, e nessuno consiste nello spegnere i filtri:

• Decidere quali combinazioni esistono. Di tutte quelle che il tuo negozio potrebbe generare, solo una manciata ha senso per un cliente o per Google. Le altre non hanno bisogno di un indirizzo proprio, e togliendolo il campo di gioco passa da milioni a qualche migliaio.
• Impedire che il costoso arrivi in fondo. Le richieste che sono rumore ricevono risposta prima di toccare il database, e si limita quante ricerche al minuto può lanciare una stessa origine. Un cliente ne fa tre; chi ne fa trecento non è un cliente, comunque si chiami.
• Separare chi compete per le risorse. La scansione non dovrebbe mai litigare per la stessa CPU del checkout di qualcuno. Montato bene, il robot può aspettare; il cliente no.

Con questo, di solito il consumo crolla già il primo giorno e il negozio smette di cadere, senza toccare un solo filtro lato cliente e senza perdere posizioni su Google. Anzi: quando smetti di far spendere a Google il suo tempo su quattrocentomila pagine ripetute, inizia a guardare quelle che ti interessano — ed è esattamente ciò che raccontavamo in da dove partire quando non compari.

Se è da mesi che ci combatti

È un problema antipatico perché non si fa vedere: non c'è un errore da guardare, solo un negozio che certi giorni va e certi no, e un hosting che dà la colpa a te.

Se hai già provato un paio delle soluzioni dell'elenco e sei al punto di prima, scrivici. Guardiamo i tuoi registri, ti diciamo quante di quelle richieste sono reali e quante sono rumore, e ti lasciamo il filtraggio montato e sotto misura. L'abbiamo fatto parecchie volte e si vede dal primo giorno.

Raccontaci il tuo caso