Come limitare le richieste per IP su PrestaShop senza bloccare Google

Lunedì mattina. Domenica il negozio è caduto due volte, nel registro degli accessi ci sono tre indirizzi che hanno chiesto ottantamila pagine ciascuno, e li blocchi sul server. Stai tranquillo. Martedì ci sono quaranta indirizzi nuovi che fanno esattamente la stessa cosa.

Bloccare per indirizzo è la prima reazione di tutti e quella che dura meno. Non perché sia un’idea sbagliata, ma perché il problema non è chi chiede, ma quanto chiede. E quello si misura, non si indovina.

Perché bloccare indirizzi non finisce mai

Un crawler che percorre il tuo catalogo non viene da un indirizzo: viene da una rete, o da diverse, e ruota. Quando ne tagli uno, continua con il successivo senza perdere il ritmo. Con i nomi succede lo stesso: si presentano come un browser normale, cambiano identità ogni settimana e ne compaiono tre nuovi ogni mese. La lista di blocco cresce e il carico non scende.

Quello che non possono travestire è il ritmo. Una persona che compra apre una categoria, seleziona due filtri, passa una pagina e va alla scheda prodotto: tre o quattro ricerche costose in tutta la visita. Un crawler ne fa tre o quattro al secondo, da ogni indirizzo che usa. Contare quante ricerche costose fa ogni origine in un minuto distingue i due senza bisogno di sapere come si chiamano.

Cos’è limitare per IP, e perché anche per rete

Limitare per IP significa mettere un tetto: quante richieste il negozio accetta da uno stesso indirizzo in una finestra di tempo — sessanta secondi, di solito. Sotto il tetto passa tutto; sopra, la richiesta riceve un «torna tra un po’» che non costa nulla servire.

Solo con questo, un crawler che distribuisce il lavoro tra duecento indirizzi della stessa rete resta sotto il tetto su ognuno. Per questo il secondo limite è per rete: gli indirizzi che condividono i primi tre blocchi (quello che un tecnico chiama un /24) si contano insieme. Un operatore mobile può somigliare a questo, quindi quel tetto sta più in alto di quello per indirizzo, ma ruotare smette di essere gratis. E un terzo freno, per tutto il negozio, fa da limite di emergenza: quando il totale di ricerche al minuto supera quello che il tuo server regge con margine, passano solo i visitatori che hanno già dimostrato di essere persone.

Dove si mette il limite: sul server o nel negozio

Ci sono tre posti dove si può contare, e non vedono la stessa cosa.

• Nella CDN (le regole di limitazione di Cloudflare, per esempio). Conta per indirizzo e per schema di URL. Non sa quale richiesta è costosa e quale è un’immagine, non sa se il visitatore ha la sessione aperta e tratta Googlebot come chiunque. Per un picco di un pomeriggio va bene; per viverci, o freni troppo i tuoi clienti o troppo poco i bot.
• Nel server web (i moduli di limitazione di Apache o nginx, o fail2ban che legge il registro). Conta tutto quello che entra, CSS e foto compresi, quindi il tetto deve essere così alto da frenare appena. E bisogna saper amministrare un server per toccarlo, cosa che su un hosting condiviso non è nemmeno permessa.
• Nel negozio stesso, prima che PrestaShop inizi a cercare. È l’unico posto che sa cos’è costoso: una ricerca con filtri, il motore di ricerca, una pagina di elenco, un cambio di ordinamento. Solo quello conta per il limite. Sa se il visitatore ha effettuato l’accesso — e allora non lo limita — e può verificare se chi dice di essere Googlebot lo è davvero. È lì che lo mette Anti-Bot per PrestaShop, ed è per questo che il limite può essere basso senza disturbare nessuno che compri.

Come lasciare entrare Google

Questa è la paura che frena la maggior parte delle persone, e a ragione: un limite messo male ti cancella da Google da solo. La soluzione non è una lista di nomi, perché chiunque può presentarsi come Googlebot: è chiedere alla rete. Ogni richiesta che dice di venire da Google viene verificata con una risoluzione DNS inversa, e se l’indirizzo non appartiene a Google, quella richiesta non è di Google, dica quello che dica.

I motori verificati entrano con una quota propria, separata da quella dei visitatori, e ricevono le pagine dei filtri marcate come non indicizzabili. È esattamente ciò che Google raccomanda per la navigazione a faccette: le combinazioni di filtri non devono trasformarsi in migliaia di pagine ripetute. Quando smetti di fargli perdere tempo lì, inizia a scansionare meglio quelle che ti interessano.

Cosa succede quando qualcuno supera il limite

Uno script riceve un «troppe richieste» con l’ora a cui può tornare, e al tuo database non costa nulla. Ma un limite per indirizzo ha un caso scomodo: l’ufficio con trenta persone dietro una sola connessione, o il cliente che filtra molto in fretta. Quelli non vanno cacciati: va verificato che siano persone.

La verifica che funziona è quella che non si vede. Una prova di lavoro — un piccolo calcolo che il browser risolve da solo in millisecondi, senza puzzle né caselle — e un pass di un’ora. Il pass non esenta del tutto, perché risolvere quella prova è economico anche per uno script: chi lo porta mantiene un tetto per indirizzo, solo dieci volte più alto.

I numeri per iniziare

Con una finestra di sessanta secondi, trenta ricerche costose per indirizzo, novanta per rete e seicento per tutto il negozio coprono la stragrande maggioranza dei negozi senza che nessun cliente se ne accorga. Un cliente veloce ne fa venti in un minuto; trenta è già qualcuno che non guarda quello che filtra.

Se ancora non ti fidi, c’è una modalità osservazione: il limite guarda e annota quello che avrebbe fermato, ma lascia passare tutto. Una settimana così e il pannello ti dice quante richieste sarebbero rimaste alla porta e da dove venivano, e decidi con i dati.

Come sapere se il limite è messo bene

Un limite che non si misura è un limite che un giorno disturba un cliente senza che tu lo sappia. Quello da guardare ogni settimana sono tre cose: quante ricerche costose sono state servite e quante fermate, quali origini sono state fermate di più e con quale motivo, e se qualcuna di loro è tua — il tuo monitor di disponibilità, il tuo comparatore di prezzi, un cliente che si è lamentato. A quella si dà un clic di fiducia e non si conta più.

E per i dubbi, un verificatore: incolli l’indirizzo e il browser che compaiono nel registro, la pagina che chiedevano, e ti dice esattamente cosa farebbe con quella richiesta adesso e perché. È il modo di toccare un limite senza farlo alla cieca.

Tutto questo — i tre tetti, il rimbalzo dei cookie, Google verificato via DNS, la verifica invisibile, la modalità osservazione e il pannello con il verificatore — è quello che fa Anti-Bot per PrestaShop dal minuto in cui si installa, su PrestaShop da 1.7.6 a 9 e dietro Cloudflare. E se prima vuoi sapere se il problema è questo, mandaci il registro degli accessi di una giornata brutta dal modulo di contatto: ti diciamo gratis quante di quelle richieste sono persone e quante sono rumore.