Hai installato un plugin per rilevare i bot, ma il registro non mostra tutte le visite? Prima di cambiare le soglie, controlla dove viene servita la pagina.
Una CDN o una cache può rispondere senza eseguire WordPress. In quel caso, il codice PHP del plugin non vede quella richiesta alla pagina. Questo dettaglio cambia il modo in cui interpreti i risultati.
Faccio parte del team WebDecoy. Qui uso il nostro plugin libero per WordPress come esempio concreto. Il testo italiano è stato preparato con assistenza IA.
Guarda il registro cambiare in 20 secondi
Nel video, una richiesta controllata al canary produce due rilevazioni nel registro locale di WordPress. La modalità monitor registra senza bloccare. È una prova del percorso di rilevazione, non un benchmark della cache: le verifiche con cache attiva restano da eseguire sul proprio sito. Il video contiene testo in inglese.
Prepara una prova ripetibile
Usa un sito di staging, con una pagina pubblica e un modulo nativo di WordPress. Annota URL, ora del test e configurazione della cache. Non usare dati reali dei clienti.
Installa WebDecoy dal catalogo di WordPress oppure con WP-CLI:
wp plugin install webdecoy --activate
wp webdecoy config set mode monitor
wp webdecoy status
La modalità monitor registra le rilevazioni senza bloccare le richieste. Il funzionamento locale non richiede account o chiavi API; il collegamento a WebDecoy Cloud è facoltativo. Il plugin richiede WordPress 6.1 o successivo e PHP 7.4 o successivo.
Separa tre percorsi
| Percorso | Cosa verificare |
|---|---|
| Pagina non servita dalla cache | La richiesta raggiunge WordPress? Quali eventi compaiono nel registro? |
| Stessa pagina servita dalla cache | Il server di origine viene contattato? Il codice del browser è ancora presente? |
| Invio del modulo | Quale endpoint riceve l’invio? Il controllo avviene anche se la pagina iniziale era in cache? |
Non interpretare la mancanza di un evento come una prova di assenza di bot. Potrebbe mancare il segnale, oppure la richiesta potrebbe non aver raggiunto il componente che lo registra.
Controlla il modulo con un test controllato
Prima completa un percorso normale: commento, login o registrazione, se disponibile. Poi, solo sul sito di prova, individua un campo trappola effettivamente generato da WebDecoy ed esegui un invio controllato che lo compili.
Confronta ora, percorso ed evento nel registro. In modalità monitor stai verificando la rilevazione del segnale: non aspettarti un blocco.
Per un modulo di terze parti, controlla l’integrazione specifica. Il fatto che un plugin protegga i moduli nativi di WordPress non significa che intercetti automaticamente ogni endpoint REST o modulo personalizzato.
Non confondere una visita sospetta con un’identità
WebDecoy combina esche, analisi delle richieste e segnali del browser. Questi elementi aiutano a investigare l’automazione, ma non identificano da soli una persona o uno specifico agente IA.
Se il sito è dietro un proxy, controlla inoltre come viene determinato l’indirizzo del client. Una politica basata su un IP interpretato male può raggruppare visitatori diversi.
Nel registro locale puoi esportare gli eventi in CSV e configurare la conservazione, impostata a trenta giorni per default. Confronta i risultati con i tuoi log prima di scegliere una risposta più restrittiva.
Il risultato utile del test
Alla fine dovresti poter rispondere a tre domande:
- Quali richieste arrivano davvero a WordPress?
- Quali segnali restano disponibili con la cache attiva?
- I percorsi legittimi continuano a funzionare?
Se non riesci a rispondere, raccogli prima queste prove. Cambiare una soglia non risolve un punto cieco nella raccolta dei segnali.
Puoi installare WebDecoy da WordPress.org e leggere il codice su GitHub. Se provi questa verifica con una cache particolare, indica nei commenti configurazione e passaggi riproducibili, senza pubblicare IP dei visitatori o log privati.
Top comments (0)