Contatori visite: i bot che eseguono JavaScript

Publié le 06 novembre 2026

Mano robotica bianca protesa verso una rete di punti luminosi collegati su sfondo blu, simbolo di un bot visitatore

La mattina del 4 novembre 2026, il contatore di VosPosts mostrava un numero lusinghiero: 3.352 visitatori «umani» in un giorno, più altri 2.272 prima dell'una di notte, su un sito che normalmente registra circa 400 visite al giorno. Nessun articolo era stato condiviso, nessun link era diventato virale. Erano semplicemente bot, scambiati dal nostro contatore per lettori.

Ecco come ce ne siamo accorti, perché il vecchio principio «se esegue JavaScript, è umano» non regge più e come individuare questi falsi visitatori nei log del server.

La trappola: «JavaScript è stato eseguito, quindi è umano»

Molti contatori artigianali, incluso il nostro, si basano su un'idea semplice: il server registra la pagina richiesta, poi un piccolo script nel browser invia una seconda richiesta per «certificare» la visita. I vecchi bot scaricavano solo l'HTML senza eseguire codice: la seconda richiesta non arrivava e restavano fuori dalle statistiche.

Ormai questo filtro fa acqua. Oggi molti bot eseguono JavaScript come un vero browser:

I motori di ricerca renderizzano le pagine per comprenderle: Googlebot usa Chromium aggiornato, ma si incontrano anche Baiduspider-render, Applebot, Bytespider (ByteDance) e meta-webindexer.
Il bot pubblicitario di AdSense (Mediapartners-Google) visita le pagine per analizzarne il contenuto.
Gli scraper moderni controllano veri browser senza interfaccia: Chrome headless, Puppeteer, Playwright o motori più leggeri come Lightpanda, pensati per automazione e agenti IA.

Per un contatore basato sull'esecuzione dello script, sono indistinguibili dai lettori. Ancora più sorprendente, il problema esisteva prima dell'attacco: analizzando il normalissimo 3 novembre, abbiamo scoperto che 446 delle 621 visite considerate umane provenivano in realtà da bot. Oltre sette su dieci.

I segnali di uno scraper con browser headless

Il picco del 4 novembre mostrava tutti i segni di uno scraping organizzato. Nessun indizio, preso da solo, dimostra nulla; insieme lasciano pochi dubbi.

Advertising

Un indirizzo IP diverso per ogni pagina

Ogni pagina veniva richiesta da un IP diverso, distribuito nel mondo. È la firma dei proxy residenziali: reti che instradano richieste tramite connessioni domestiche, spesso all'insaputa dei proprietari. Bloccare gli IP è quindi inutile: sono migliaia e appartengono a vere famiglie.

Browser obsoleti da anni

Gli user-agent ruotavano su una breve lista: Chrome 118–120, Firefox 120 e 121, Edge 119 e 120. Sono versioni di fine 2023. Ma Chrome e Firefox si aggiornano automaticamente circa ogni quattro settimane; i nostri lettori reali usavano Chrome 148–156. Un visitatore con un browser vecchio di tre anni è possibile; migliaia in una notte indicano una lista fissa di user-agent copiata in uno strumento di scraping.

In quella rotazione compariva persino, senza alcun travestimento, Lightpanda/1.0.

Un comportamento troppo regolare

Solo computer desktop, nessun dispositivo mobile, mentre la maggioranza del traffico reale arriva da smartphone;
nessun referrer: nessuno arrivava da Google, social network o altri siti;
2.340 ricerche distinte nel motore interno, per estrarre più pagine possibile;
24.772 richieste in giornata, pari al 42% dell'intero traffico del server.

Il rischio nascosto: la pubblicità

Un browser headless esegue tutto, compreso il caricamento degli spazi pubblicitari: quel giorno il bot ha caricato i nostri annunci 2.939 volte. Per un editore AdSense è un problema concreto: le impression generate dai bot costituiscono traffico non valido, che Google sottrae ai ricavi e che, se ricorrente, può mettere a rischio l'account. Un contatore gonfiato non è solo vanità.

Come riconoscere i bot nei log

I log di accesso Apache o Nginx nel formato «combined» contengono tutto il necessario. Bastano pochi comandi. Prima gli user-agent più frequenti:

awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -30

Poi la distribuzione delle versioni di Chrome. Su un sito normale, quasi tutto si concentra sulle ultime quattro o cinque versioni; un grande gruppo di versioni vecchie salta subito all'occhio:

grep -oE 'Chrome/[0-9]+' access.log | sort | uniq -c | sort -t/ -k2 -n

Il volume orario permette di individuare con precisione inizio e fine di un'ondata:

awk '{print substr($4, 2, 14)}' access.log | sort | uniq -c

Infine, per una firma sospetta, confrontate il numero di richieste con quello degli IP distinti. Se i valori sono quasi uguali, avete trovato la rete di proxy:

grep -c 'Chrome/119.0.0.0' access.log
grep 'Chrome/119.0.0.0' access.log | awk '{print $1}' | sort -u | wc -l

Un dettaglio utile: dal 2022 Chrome invia solo il numero principale della versione, seguito da .0.0.0. La forma Chrome/119.0.0.0 è quindi normale; è il numero 119 a tradire il bot.

Le misure che abbiamo adottato

Non contare, senza bloccare

Primo livello: il contatore decide lato server se registrare la visita. Non la considera più umana quando lo user-agent è vuoto, dichiara un bot (bot, spider, crawler, strumenti HTTP come curl o Python, browser headless) o indica Chrome o Firefox più vecchi di due anni e mezzo. La soglia viene ricalcolata in base alla data, senza aggiornare manualmente i numeri di versione:

$jours = (time() - mktime(0, 0, 0, 12, 5, 2023)) / 86400; // Chrome 120, décembre 2023
$version_actuelle = 120 + (int)floor($jours / 28);           // une version toutes les 4 semaines
if (preg_match('/Chrome/(d+)./', $ua, $m) && (int)$m[1] < $version_actuelle - 32) {
    return true; // navigateur trop ancien pour être un lecteur réel
}

Una salvaguardia importante: un utente autenticato viene sempre contato, qualunque browser utilizzi. Il filtro prende di mira gli sconosciuti, non i membri fedeli che non hanno aggiornato un vecchio computer.

Respingere gli scraper, lasciar passare i motori

Secondo livello, più aggressivo: il server restituisce ora un errore 403 alle firme dello scraper, con un'eccezione esplicita per i crawler legittimi. In Apache bastano poche righe:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Lightpanda|HeadlessChrome) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Chrome/1(18|19|20).0.0.0 [OR]
RewriteCond %{HTTP_USER_AGENT} Firefox/12[01].
RewriteCond %{HTTP_USER_AGENT} !(bot|spider|crawl|google|bing|facebook) [NC]
RewriteRule ^ - [F]

Le prime tre condizioni sono collegate da [OR], l'ultima si aggiunge con un «e» implicito: si blocca una firma, salvo che lo user-agent dichiari di essere un motore di ricerca o un social network. Dopo l'attivazione abbiamo verificato entrambi i casi: lo scraper riceve 403, mentre Chrome recente, iPhone, Googlebot, Bingbot e il bot AdSense continuano ad accedere.

Bloccare Googlebot per errore può costare molto più di statistiche gonfiate. Provate ogni regola con gli user-agent dei motori di ricerca prima di metterla in produzione.

I limiti da ricordare

Uno user-agent si falsifica in una riga. Quando questo scraper si presenterà come Chrome 155, le regole non lo riconosceranno più. Non è una difesa definitiva, ma una misura igienica: elimina i bot meno sofisticati, che sono la maggioranza, e rende di nuovo leggibili i numeri. Per andare oltre occorre incrociare più segnali (assenza di referrer, una pagina per IP, nessun movimento del mouse o scorrimento) o usare servizi specializzati nel rilevamento dei bot.

La vera lezione è un'altra: un contatore che mente una volta all'anno durante un picco clamoroso probabilmente mente anche negli altri giorni, più discretamente. Se non avete mai esaminato i log di accesso, dedicate dieci minuti a eseguire i comandi qui sopra in una giornata normale. Il risultato potrebbe sorprendervi.