Chi legge davvero il tuo sito?

Quando guardiamo le statistiche di un sito di informazione, tendiamo a pensare che dietro ogni visita ci sia un lettore. In realtà non è così: una parte significativa delle richieste che arrivano ogni giorno ai server proviene da bot e sistemi automatizzati e, secondo il 2026 Imperva Bad Bot Reportdi Thales e Imperva, nel 2025 il traffico automatizzato ha rappresentato il 53% del traffico web globale, superando per la prima volta quello generato dagli utenti umani.

Ovviamente, ci sono i crawler dei motori di ricerca, ma negli ultimi anni si sono aggiunti anche i bot di IA che raccolgono contenuti per addestrare i propri modelli, gli agenti che consultano le pagine web per rispondere alle domande degli utenti e gli scraper che scaricano automaticamente grandi quantità di contenuti.

Per un editore, però, non si tratta soltanto di una questione tecnica. Ogni richiesta al server significa consumo di risorse e, soprattutto, accesso a contenuti che hanno un costo. Dietro ogni articolo ci sono infatti giornalisti, redattori, infrastrutture e un lavoro editoriale che richiede tempo e investimenti. Se un sistema di IA accede regolarmente a questi contenuti, diventa quindi utile sapere da dove arriva il traffico, quali pagine vengono consultate e con quale frequenza.

Ed è proprio da questa esigenza che nasce HoneyLog, lo strumento di analytics lato server sviluppato dal team di Publytics.

La novità è che HoneyLog ora supporta il Model Context Protocol (MCP), uno standard che permette di interrogare i dati direttamente attraverso un assistente AI. In altre parole, invece di aprire dashboard, applicare filtri ed esportare report, è possibile fare una domanda in linguaggio naturale e ottenere una risposta basata sui dati del proprio sito.

Il traffico che gli analytics tradizionali non possono vedere

Per capire perché questo tipo di analisi può essere utile, bisogna fare un passo indietro.
Molti strumenti di web analytics funzionano attraverso uno script inserito nelle pagine del sito. Quando un lettore apre un articolo, lo script registra informazioni sulla visita: la pagina visualizzata, la provenienza, il tempo trascorso sul sito e, in alcuni casi, anche eventuali conversioni.

Il problema è che non tutte le richieste arrivano da browser in grado di eseguire JavaScript.
Un crawler, per esempio, può chiedere direttamente una pagina al server senza eseguire lo script di analytics. Di conseguenza, quella richiesta può non comparire mai nelle statistiche tradizionali.

È qui che entra in gioco l’analisi dei log .
HoneyLog lavora direttamente a livello server, analizzando i log del server e della CDN. In questo modo può osservare le richieste che arrivano al sito indipendentemente dal fatto che dietro ci sia un browser, un crawler, un agente AI o un altro tipo di bot.

Publytics e HoneyLog: due prospettive sullo stesso sito

HoneyLog nasce accanto a Publytics, ma i due strumenti non fanno la stessa cosa.
Publytics guarda principalmente a ciò che fanno i lettori nel browser. Permette a editori e testate di capire quali contenuti vengono letti, da dove arrivano gli utenti, come si muovono sul sito e quali azioni compiono.
HoneyLog guarda invece alle richieste che arrivano al server. Questo significa includere anche il traffico generato da programmi che non eseguono JavaScript e che quindi può sfuggire agli strumenti tradizionali.

Le due prospettive possono quindi essere utilizzate insieme. Da una parte ci sono le persone e il loro comportamento sul sito. Dall’altra ci sono tutte le richieste ricevute dall’infrastruttura, comprese quelle generate dai bot. Per un editore, avere entrambe le informazioni significa poter distinguere meglio il traffico umano da quello automatico.

Quando i dati del server diventano una domanda da fare all’AI

È qui che l’integrazione con MCP diventa interessante. Il Model Context Protocol è uno standard aperto che permette agli assistenti AI di collegarsi a strumenti e fonti di dati esterni. Una volta collegato HoneyLog a un client compatibile, i dati possono essere interrogati in qualsiasi momento senza necessariamente conoscere la struttura dei database o costruire manualmente una serie di filtri.

Si può semplicemente chiedere, per esempio:

«Quali crawler AI sono passati sul sito nell’ultimo mese? Ordinali per numero di richieste e, per ciascuno, indicami le dieci pagine che ha scaricato di più.»

Una domanda utile per capire quali sistemi stanno accedendo con maggiore frequenza ai contenuti.

«Fammi una sintesi delle richieste mensili di GPTBot e ClaudeBot da gennaio a oggi e indicami quali sezioni del sito hanno visitato più spesso.»

Un report di questo tipo può essere utile anche quando si vuole ricostruire nel tempo l’attività dei diversi crawler.

«Negli ultimi 14 giorni quali bot hanno richiesto pagine sotto /premium/ e con quante richieste ciascuno?»

Per un editore può essere particolarmente interessante capire se e quanto i bot accedono a contenuti che normalmente vengono messi a disposizione degli utenti attraverso un abbonamento o un paywall.

«Il traffico dei bot è aumentato rispetto al mese scorso? Indicami i giorni con i picchi più anomali e quali bot li hanno generati.»

In questo caso il dato non serve soltanto a capire chi sta effettuando le richieste, ma anche a individuare eventuali variazioni nel comportamento del traffico.

«Quali pagine restituiscono più errori 404 a Googlebot e ai crawler AI questo mese?»

Un modo per incrociare il traffico dei crawler con un problema più tradizionale: la gestione delle pagine non trovate e degli errori di scansione.

«Da quali Paesi arriva il traffico dei bot malevoli questa settimana e quali pagine sta colpendo?»

L’analisi dei log può essere utile anche per individuare pattern di traffico anomalo e richieste concentrate su determinate aree del sito.

7. Cosa è successo sull’intero network?

«Riassumi l’attività dei crawler AI della settimana scorsa su tutti i nostri siti ed evidenzia le variazioni più importanti rispetto alla settimana precedente.»

Per chi gestisce più testate o diversi domini, la possibilità di interrogare i dati in linguaggio naturale può rendere più semplice passare dal singolo sito a una visione complessiva del network.

Perché questo tema interessa sempre di più gli editori

Il tema diventa particolarmente interessante quando si parla di licensing dei contenuti. Se un’azienda di IA utilizza regolarmente i contenuti di una testata, per un editore diventa importante avere dati concreti sull’entità di questo utilizzo.

Sapere quali crawler accedono al sito, quante richieste effettuano, quali pagine consultano e con quale frequenza significa poter ricostruire nel tempo l’attività dei diversi sistemi di IA. HoneyLog permette di raccogliere e conservare proprio questo tipo di informazioni direttamente dai log del server.

Sono dati che possono diventare una base importante quando arriva il momento di discutere un accordo di licensing. Invece di affrontare la trattativa senza sapere quanto e come i propri contenuti vengano effettivamente consultati, puoi avere a disposizione uno storico delle richieste e dei contenuti interessati. Ciò non significa che questi dati stabiliscano da soli il valore di una licenza, ma possono fornire elementi concreti su cui impostare la discussione e aiutare entrambe le parti a partire da una fotografia più precisa dell’utilizzo dei contenuti.

Come iniziare a utilizzare HoneyLog

Per saperne di più su HoneyLog e capire come può essere utilizzato sul proprio sito, è possibile contattare direttamente il team di HoneyLog oppure rivolgersi al team di Publytics. In alternativa, è possibile richiedere una demo gratuita o iniziare una prova gratuita di 14 giorni, senza carta di credito