Quando lavoravamo su GeoSonar, ci siamo trovati davanti a un problema molto pratico: potevamo valutare se un sito fosse pronto per essere letto, capito e citato dai motori generativi, ma non vedevamo ancora bene che cosa succedeva dopo, sul server, quando quegli stessi sistemi iniziavano a fare richieste reali.

L'audit GEO analizza questa prima area: struttura dei contenuti, accessibilità per i crawler, qualità delle fonti, leggibilità semantica, probabilità che una pagina venga usata come fonte in una risposta generata.

Ma durante i test restava sempre una domanda aperta: quali bot stanno arrivando davvero? E tra quelli che arrivano, quali sono autentici e quali stanno solo usando un nome credibile nello user-agent?

Non bastava più ragionare su una pagina come farebbe un SEO specialist davanti a Search Console. Nel traffico generativo non hai sempre una query, una SERP, un click, una sessione e una conversione. Spesso hai una richiesta HTTP, un bot, un IP, una pagina richiesta, un referrer assente o incompleto, e poi magari, più avanti, una citazione dentro una risposta AI o una visita con utm_source=chatgpt.com.

Agent Analytics è stato costruito per questo: osservare il traffico dei bot AI senza mettere sullo stesso piano richieste molto diverse tra loro.

Per riconoscere quegli agenti non usiamo una lista chiusa, scritta una volta e poi lasciata invecchiare. Agent Analytics usa anche Known Agents come riferimento esterno per la classificazione: un dataset/API mantenuto per riconoscere AI agents, crawler e bot che arrivano sulle pagine web. Quel riferimento aiuta a dare un nome ordinato alle richieste. Poi resta il passaggio più delicato: capire se quel nome è credibile.

Nel traffico dei bot, lo user-agent è una dichiarazione. Non è ancora una prova.

Perché i normali analytics non bastano

Gli strumenti di web analytics tradizionali sono pensati soprattutto per gli utenti umani.

Misurano sessioni, pageview, eventi, conversioni, sorgenti di traffico, campagne. Sono utilissimi quando il visitatore è una persona davanti a un browser, con JavaScript attivo, cookie, referrer e un percorso di navigazione abbastanza leggibile.

I bot AI non si comportano così.

Molti non eseguono JavaScript. Alcuni non caricano CSS o immagini. Alcuni leggono solo HTML, metadati, snippet json, robots.txt, sitemap, pagine tecniche o endpoint specifici. Altri fanno richieste molto rapide, in sequenza, probabilmente su liste di URL già note. Altri ancora arrivano perché un utente ha fatto una domanda a un assistant e il sistema deve recuperare una fonte in tempo reale.

Da fuori sembrano tutte visite. Nei log no.

Googlebot, per esempio, spesso si comporta ancora come un crawler legato all'esperienza web completa: legge il robots.txt, scarica risorse, renderizza JavaScript, cerca di capire che cosa vedrebbe un utente reale. Un bot AI user-triggered, invece, può essere molto più diretto: arriva su una pagina, prende il contenuto utile e sparisce. Non gli interessa se il bottone è arancione, se il layout è elegante o se il diagramma è animato.

Per un SEO specialist, a quel punto cambia la domanda.

La domanda non è solo: "La pagina si posiziona?"

Bisogna chiedersi anche: "Quale agente l'ha richiesta? Era un agente vero? Da quale rete arrivava? Ha chiesto la home, la sitemap, un articolo, una pagina prodotto? Dopo quella visita abbiamo visto segnali di citazione o referral da AI?"

Un analytics generico di solito non nasce per rispondere a queste domande.

Il pixel server-side

Agent Analytics funziona come un pixel analytics, ma lato server.

La differenza è pratica. Un pixel client-side misura quello che succede nel browser. Uno strumento server-side vede la richiesta mentre passa dal server, prima che diventi una pageview, una sessione o un evento marketing.

Nel nostro caso installiamo lo SDK Node.js sull'applicazione che serve il sito. Quando arriva una request, il server risponde normalmente. Lo SDK osserva request e response, prepara un record e lo invia all'ingest di GeoSonar Agent Analytics.

Il record contiene i dati che servono per leggere una visita bot senza dover partire ogni volta dal log grezzo:

Questi campi esistono nel modello canonico della visita ingestita. La dashboard poi li usa in modi diversi: alcuni restano nel dettaglio della visita, altri alimentano le viste aggregate, altri servono a preparare tabelle più facili da interrogare.

Qui conta una cosa: il sistema non salva soltanto il log grezzo. Dal record iniziale ricava anche campi già pronti per l'analisi, come is_primary_analytics, analytics_segment e risk_level. La UI e l'assistant li usano per distinguere traffico primario, traffico security e casi ambigui senza reinventare la classificazione ogni volta.

La pizza, il fattorino e la citazione

L'esempio più chiaro è quello di un'app di delivery.

Immaginiamo che il sito sia la pizzeria. L'utente non viene in pizzeria di persona: apre un'app, ordina una pizza e aspetta a casa. Nel nostro caso l'app è ChatGPT, Claude, Perplexity o un altro sistema generativo. Quando l'assistant decide che gli serve una fonte dal web, manda un fattorino a ritirare qualcosa: un bot, un fetcher, un crawler, comunque un agente che arriva al nostro server e chiede una o più risorse.

Agent Analytics osserva quello che succede in pizzeria. Vede quando il fattorino arriva, come si presenta, da quale rete proviene, quale pagina chiede, se la richiesta va a buon fine, quanti byte vengono serviti e quale contenuto il server gli consegna. In pratica misura la parte che avviene al banco: che cosa ci è stato chiesto e che cosa abbiamo dato al fattorino.

Questo livello è molto concreto, ma ha un limite: dopo il ritiro, il fattorino esce dalla pizzeria. Da quel momento non siamo più dentro la scena osservata da Agent Analytics. Non possiamo guardare direttamente che cosa succede a casa dell'utente: se la pizza viene mangiata tutta, se lascia i bordi, se la divide con qualcuno o se non la mangia affatto.

Tradotto fuori dalla metafora: Agent Analytics può dire che ChatGPT-User ha chiesto una pagina, che arrivava da una rete Microsoft compatibile, che il server ha risposto 200 e che ha servito quel contenuto. Non può dire, da solo, che il modello abbia poi usato semanticamente quel contenuto nella risposta finale.

Qui entra in gioco GeoSonar nel suo insieme. Se una settimana prima, a parità di domanda, il brand non veniva citato, e una settimana dopo viene citato; oppure se dopo la visita vediamo traffico di ritorno con utm_source=chatgpt.com; oppure se nei citation test compare quella pagina come fonte, allora abbiamo un secondo livello di evidenza.

Non è la stessa prova. Il ritiro della pizza in pizzeria e il consumo a casa dell'utente sono due momenti diversi. Però, se li osserviamo entrambi, possiamo ricostruire molto meglio il percorso: prima il bot ha chiesto e ricevuto il contenuto dal server; poi GeoSonar rileva una citazione, un referral o un cambiamento nella risposta dell'LLM.

Questa distinzione è importante perché evita due errori.

Il primo è dire: "Il bot ha visitato la pagina, quindi l'AI l'ha usata". È una conclusione troppo forte.

Il secondo è dire: "Non possiamo sapere nulla". È troppo debole.

Alcune cose le misuriamo direttamente sul server. Altre le osserviamo dopo, nei risultati GEO, nei referral o nelle citazioni. Se teniamo separati questi livelli, l'analisi resta leggibile; se li confondiamo, iniziamo a raccontarci una storia che i dati non possono sostenere.

Il problema dello spoofing

Nel traffico bot, fidarsi solo dello user-agent è pericoloso.

Uno script può dichiararsi Googlebot, GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot o qualunque altro nome. Cambiare lo user-agent è banale. Bastano poche righe di codice.

Una dashboard che si fida solo di quel campo può raccontare una storia falsa.

Magari mostra un picco enorme di "OpenAI" o "Googlebot", ma in realtà quelle richieste arrivano da uno scraper senza identità, da una rete residenziale, da un server compromesso o da uno scanner che sta cercando vulnerabilità. Se quei dati finiscono dentro le metriche GEO, sporcano tutta l'analisi.

Per questo Agent Analytics separa tre identità:

Questa distinzione regge tutta la parte di verifica.

Un bot che dice "sono OpenAI" non viene trattato automaticamente come OpenAI. Prima controlliamo se l'IP è compatibile con i range pubblicati dal provider, se la rete ha senso, se l'ASN è coerente, se ci sono segnali di abuso o se l'infrastruttura racconta un'altra storia.

La verifica non resta dentro una descrizione della UI. Viene salvata in campi interrogabili: verification_status, verification_source, verification_reason, risk_level, analytics_segment. In questo modo il frontend e l'assistant non devono ricalcolare a modo loro cosa è legittimo e cosa no.

Come verifichiamo gli agenti

La verifica procede per passaggi.

Prima normalizziamo l'agente. Usiamo regole interne, riferimenti come Known Agents e librerie di crawler detection per passare da una stringa disordinata a un nome leggibile: ChatGPT-User, GPTBot, OAI-SearchBot, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, Googlebot, Bingbot, Applebot e così via.

Poi guardiamo l'IP.

Per gli agenti più importanti controlliamo i range ufficiali pubblicati dai provider: OpenAI, Anthropic, Google, Perplexity, Microsoft, Apple, DuckDuckGo, Common Crawl e altri quando disponibili. Se un IP rientra in un range ufficiale compatibile con quello user-agent, possiamo marcare la visita come verificata.

Se invece non c'è una verifica forte, entrano in gioco gli arricchimenti.

MaxMind GeoLite2 ci dà una geolocalizzazione di base. IPinfo aggiunge identità di rete: ASN, nome rete, dominio, paese, eventuale bogon. AbuseIPDB ci dice se quell'IP ha report di abuso. Censys descrive l'infrastruttura esposta: reverse DNS, servizi aperti, software, informazioni WHOIS. GreyNoise, quando configurato, aiuta a riconoscere rumore di fondo, scanner e pattern di security.

Ogni fonte chiarisce un pezzo diverso.

IPinfo non decide se un bot è vero. Dice da quale rete arriva.

AbuseIPDB non decide se un agente è ChatGPT. Dice se quell'IP ha una reputazione problematica.

Censys non interpreta la GEO. Mostra che tipo di macchina c'è dietro quell'indirizzo.

Messi insieme, questi segnali dicono se una visita è coerente con l'identità dichiarata oppure no.

Non tutto deve finire nello stesso grafico

Nella dashboard non tutto deve stare nella overview.

Se uno scraper falsifica Googlebot e bombarda il sito con migliaia di richieste, quel traffico non deve sporcare i grafici principali della GEO. Deve essere visibile, certo, ma nel posto giusto: realtime, history, security, dettaglio visita, filtri per rete, stato di verifica, reputazione.

La overview mostra il traffico significativo: agenti riconosciuti, categorie, top pagine, reti principali, andamento nel tempo.

Il traffico sospetto va letto in modalità diagnostica.

È un altro lavoro.

Se li mettiamo nello stesso grafico, il grafico diventa rumoroso. Un SEO specialist rischia di guardare un picco artificiale e pensare che ChatGPT stia leggendo il sito in modo massiccio, quando in realtà sta guardando spoofing o scanning.

Il rischio non è avere pochi dati. Il rischio è avere grafici pieni di dati sbagliati.

Che cosa si vede nella dashboard

La overview dà una lettura rapida: visite totali degli agenti, traffico verificato, traffico spoofed, copertura della reputation, top agent, top network, pagine più richieste e tipi di risorsa.

La realtime mostra quello che sta succedendo ora, o quasi. È utile durante i test, quando si lancia una pagina nuova, quando si osserva il comportamento di un agent specifico, o quando si vuole capire se un bot sta arrivando davvero.

La history è la vista per lavorare sui dati con calma: filtri, agenti, network, severità, path, status, stato di verifica. È la parte più investigativa.

Le pagine agent detail e page detail rispondono a due domande molto pratiche:

• che cosa ha fatto questo agente?
• che cosa è successo su questa pagina?

Il dettaglio scraping conserva la prova tecnica della visita. Non conviene mostrarlo in ogni tabella, perché diventerebbe ingestibile. Si apre quando una visita è interessante, sospetta o utile per capire che cosa è stato effettivamente servito.

AI referrals: quando la visita torna indietro

Per chi fa SEO e GEO, il collegamento tra bot traffic e traffico da assistant è uno dei punti da tenere d'occhio.

Il bot può arrivare prima. La citazione o il referral possono arrivare dopo.

Se un utente fa una domanda su ChatGPT e poi clicca una fonte, possiamo vedere segnali come utm_source=chatgpt.com o referrer compatibili. Nel sistema questi segnali vengono letti da una tabella dedicata, costruita sul referrer header e sui parametri UTM presenti nelle visite ingestite. Non sono visite bot: sono visite umane arrivate da ChatGPT, Perplexity, Gemini o altri assistant.

Non sempre ci sono e non sempre sono completi. Quando compaiono, vanno letti come segnali di ritorno, non come prova automatica di uso del contenuto.

È l'altro lato del percorso.

Da una parte osserviamo gli agenti che leggono o controllano il sito. Dall'altra osserviamo gli utenti che arrivano dagli assistant quando una risposta genera un passaggio verso il sito.

Per questo nella dashboard esiste una sezione dedicata agli AI referrals.

Questa vista evita di ridurre la GEO a una sola metrica.

Non basta sapere che un bot è passato. Non basta sapere che una pagina è citata. Non basta sapere che è arrivato traffico da ChatGPT.

La cosa utile è vedere come questi segnali si combinano.

Una pagina può ricevere molte visite bot e poche citazioni. Un'altra può ricevere poche visite ma generare referral interessanti. Un'altra ancora può essere molto richiesta da bot sospetti, ma poco rilevante per gli agenti verificati.

Sono casi diversi e portarli nello stesso numero aggregato non aiuta.

Il catalogo degli agenti

Il catalogo evita di dover decifrare ogni user-agent da zero.

Nel lavoro SEO tradizionale siamo abituati a distinguere Googlebot, Bingbot, crawler SEO, tool di monitoring, scraper, bot commerciali. Nel mondo AI la tassonomia è più instabile. Nascono nuovi agenti, cambiano gli user-agent, compaiono fetcher user-triggered, crawler di training, search bot, agenti di assistant, strumenti di data provider.

Non è solo una lista di nomi. È una mappa di categorie: AI Assistant, AI Data Provider, AI Data Scraper, AI Search Crawler, Automated Agent, Fetcher, SEO Crawler, Search Engine Crawler, Undocumented AI Agent.

Per un SEO specialist, la differenza è concreta: bot diversi dicono cose diverse.

Un AI Search Crawler non è la stessa cosa di un AI Data Scraper. Un fetcher user-triggered non è la stessa cosa di un crawler di discovery. Un bot verificato non è la stessa cosa di uno spoofed.

La categoria non chiude l'analisi, ma dà un primo orientamento.

Che cosa abbiamo imparato osservando i log

Osservando GeoSonar per diversi mesi, alcuni comportamenti si ripetono abbastanza da meritare attenzione.

Il primo: i bot AI possono essere molto più rapidi dei crawler tradizionali. In certi casi fanno richieste a distanza di frazioni di secondo. Questo suggerisce che non stiano "navigando" il sito come farebbe una persona, e spesso nemmeno come farebbe un crawler classico che scopre link in sequenza.

Il secondo: diversi provider separano i ruoli. C'è chi controlla regole e sitemap, chi fa discovery, chi arriva quando l'utente chiede qualcosa, chi recupera contenuti in tempo reale. Parlare di "il bot di OpenAI" o "il bot di Perplexity" è spesso troppo generico.

Il terzo: Googlebot e agenti AI non hanno lo stesso obiettivo. Googlebot deve ancora capire una pagina anche come esperienza utente. Molti bot AI sono interessati soprattutto al contenuto testuale e strutturato.

Il quarto: il traffico falso è costante. Scanner, scraper, bot che dichiarano nomi credibili, richieste verso path tecnici, user-agent ambigui. Senza filtro, la dashboard finisce per produrre conclusioni sbagliate.

Il quinto: i segnali successivi cambiano il peso della visita. Una richiesta bot isolata resta una richiesta bot. Se però in un altro punto del sistema vediamo una citazione, un referral, un utm_source=chatgpt.com, o una pagina che inizia a comparire come fonte in risposte generative, il quadro diventa più interessante.

Perché serve a chi fa SEO e GEO

La GEO non sostituisce la SEO. Aggiunge misure che prima mancavano.

La SEO classica continua a lavorare su crawlability, indicizzazione, intento di ricerca, contenuto, link, performance, struttura, snippet, SERP. Ma una parte crescente della discovery passa da sistemi che leggono, sintetizzano e citano senza produrre sempre un click immediato.

Cambia quindi anche il modo di misurare.

Non possiamo più guardare solo ranking e traffico organico. Dobbiamo capire anche se gli agenti raggiungono i contenuti, quali agenti li leggono, quali pagine attirano più bot AI, quali reti compaiono nei log, quali visite possiamo verificare, quali contenuti generano referral o citazioni.

Agent Analytics dà a queste domande una base tecnica.

Non dice al SEO specialist "questa è la formula magica per piacere a ChatGPT". Quella sarebbe fuffa. Anzi fuffissima.

Dice invece: questi agenti sono passati; queste pagine hanno ricevuto richieste; queste visite sono verificate; queste sono sospette; questi referral arrivano da assistant e motori AI; queste risorse sembrano più osservate dai crawler generativi.

È un lavoro più scomodo del classico report sul traffico organico, ma anche più utile quando bisogna capire che cosa stanno facendo davvero gli agenti AI.

Assistant: interrogare i dati, non solo guardarli

Quando i dati sono puliti, normalizzati e interrogabili, l'assistant diventa utile soprattutto nelle analisi che richiederebbero diversi passaggi manuali: filtrare un agent, controllare quali visite sono verificate, separare gli spoofed, aggregare i path, leggere gli ASN principali e trasformare tutto in una rappresentazione comprensibile.

L'esempio qui sotto parte da ChatGPT-User. La domanda non chiede un report generico: chiede di ricostruire il comportamento osservato negli ultimi 28 giorni e di restituirlo in due forme visive. Il flowchart serve a leggere il pattern di visita più ricorrente. Il diagramma di rete serve invece a capire da quali ASN arrivano le richieste, su quali path si concentrano e dove compaiono i volumi anomali o spoofed.

Questo è il tipo di uso in cui l'assistant ha senso: non inventa una metrica nuova, ma interroga il read model e restituisce una sintesi tecnica che un SEO specialist o un analyst può discutere, verificare e usare per decidere dove guardare meglio.

Domanda: Fai un'analisi di ChatGPT-User sugli ultimi 28 giorni: voglio un flowchart Mermaid del pattern di visita più ricorrente e un diagramma Mermaid di rete che colleghi ASN/network principali, path visitati e volumi.

ChatGPT-User — Analisi 28 giorni

Riepilogo generale

Pattern di visita più ricorrente — Flowchart

Il pattern dominante (>95% dei casi) è single-page fetch: ChatGPT-User arriva direttamente su una pagina specifica senza navigazione sequenziale. La homepage è il punto di ingresso principale, seguita dalla sezione /alternatives. Non si osserva crawling ricorsivo né discovery via sitemap/robots.

flowchart TD
    A["ChatGPT-User riceve query utente"] --> B{"Tipo di richiesta"}

    B --> C["Query generica sul brand<br/>o prodotto"]
    B --> D["Query su alternative<br/>o comparazioni"]
    B --> E["Query su funzionalita<br/>o pricing"]

    C --> F["Fetch diretto: /<br/>670 visite - 127 KB"]
    C --> G["Fetch diretto: /en<br/>13 visite - 127 KB"]

    D --> H["Fetch diretto: /en/alternatives/profound<br/>79 visite - 74 KB"]
    D --> I["Fetch diretto: /en/alternatives/rankscale<br/>37 visite - 75 KB"]
    D --> J["Fetch diretto: /en/alternatives/best-ai-visibility-geo-tools-2026<br/>17 visite - 99 KB"]
    D --> K["Fetch diretto: /en/alternatives/omnia<br/>15 visite - 71 KB"]
    D --> L["/en/alternatives - index<br/>11 visite - 72 KB"]

    E --> M["/en/pricing<br/>9 visite - 49 KB"]
    E --> N["/en/features<br/>6 visite - 96 KB"]
    E --> O["/en/how-it-works<br/>4 visite - 105 KB"]

    F --> P{"Esito fetch"}
    G --> P
    H --> P
    I --> P
    J --> P
    K --> P
    L --> P
    M --> P
    N --> P
    O --> P

    P --> Q["200 OK - full_document<br/>fetch completato"]
    P --> R["301 Redirect<br/>/en/comparisons - 9 visite"]
    P --> S["404 Not Found<br/>probe anomali"]

    S --> T["/debug/vars - /settings.json<br/>/config.json - /openai.json<br/>/data/aws/credentials<br/>Spoofed o scanner"]

Il flowchart modella la logica di fetch osservata: ChatGPT-User non naviga il sito, ma recupera direttamente la pagina più pertinente alla query dell'utente. I 404 su path di configurazione/credenziali sono associabili alle visite spoofed o a scanner che si mascherano da ChatGPT-User.

Rete ASN → Path → Volume — Sankey

sankey-beta
Microsoft AS8075,homepage /,700
Microsoft AS8075,/en/alternatives/*,160
Microsoft AS8075,other pages,33
Google AS396982,homepage /,40
Google AS396982,/en/alternatives/*,20
Google AS396982,probe/404,13
Infraly AS400529,/en/alternatives/*,15
Infraly AS400529,other pages,10
BreezeHost AS400810,/en/alternatives/*,9
BreezeHost AS400810,other pages,4
WS Telecom AS209372,homepage /,5
WS Telecom AS209372,other pages,5
WS Telecom AS213541,homepage /,4
WS Telecom AS213541,other pages,3
Other ASN,other pages,10

Il sankey mostra il flusso quantitativo da ASN sorgente → categoria di path → volume di visite. Microsoft (AS8075) domina con 893 visite su 990 totali, concentrate su homepage e alternatives. Google (AS396982) ha 73 IP distinti ma quasi tutti con 1 visita ciascuno — pattern coerente con proxy/egress distribuito. I provider minori (Infraly, BreezeHost, WS Telecom) sono associati alle visite spoofed con reputation score 100 su AbuseIPDB.

Osservazioni analitiche chiave

1. Traffico verificato vs spoofed

• L'88,8% delle visite è verificato tramite la IP list pubblica di OpenAI (openai.com/chatgpt-user.json), transitando su infrastruttura Microsoft Azure (AS8075) — coerente con l'architettura OpenAI.
• L'11,2% spoofed (111 visite) proviene da ASN commerciali con reputazione AbuseIPDB alta: Infraly LLC (AS400529), BreezeHost (AS400810), WS Telecom (AS209372/213541). Questi non compaiono nella IP list OpenAI.

2. Picchi anomali di spoofing

• 8 agosto: 52 visite spoofed su 72 totali (72% del giorno). 🚨 Picco netto.
• 12 agosto: 21 spoofed su 56 (37%).
• Negli altri giorni lo spoofing è sporadico (0–6 visite). I due picchi meritano correlazione con eventi esterni (campagne, scraper coordinati?).

3. Probe sospetti (404)

• Path come /debug/vars, /settings.json, /config.json, /openai.json, /data/aws/credentials, /@fs/root/.config/gcloud/... sono probe di ricognizione tipici di scanner automatizzati che si mascherano da ChatGPT-User. Ipotesi: originano dalle stesse sorgenti spoofed, non da OpenAI reale.

4. Focus contenutistico

• Il 63% delle visite punta alla homepage (/ + /en): ChatGPT risponde a query brand con la root.
• Il 18% punta a /en/alternatives/*: interesse elevato per le pagine di comparazione, in particolare Profound (79 visite) e RankScale (37).
• Nessuna visita a /robots.txt o /sitemap.xml in modo sistematico (solo 3+2 visite isolate): ChatGPT-User non fa discovery — arriva direttamente sulle URL già indicizzate o citate

(e qui si apre un mondo che riguarda il Triggering del traffico AI a fini di WarmUp e inclusione nel training dei modelli...abbiamo scoperto cose mooolto interessanti)

5. Distribuzione geografica

• Le visite verificate originano da US, UK, DE, CH, BR, BE, PL, AU — riflettono la distribuzione degli utenti ChatGPT che fanno query, non la posizione dei server OpenAI.

Domanda: Genera anche un sequence diagram e un network diagram

Dati eccellenti e molto ricchi. Ora costruisco i due diagrammi richiesti.

Sequence Diagram — Due scenari a confronto

Il sequence diagram mostra i due pattern comportamentali distinti osservati: il fetch legittimo verificato (singola richiesta diretta, IP Azure pubblicato da OpenAI) e la sessione spoofed (burst sincrono multi-path, IP non in lista OpenAI, probe di ricognizione).

sequenceDiagram
    participant U as Utente ChatGPT
    participant OAI as OpenAI Backend
    participant AZ as Azure AS8075
    participant SRV as Sito GeoSonar
    participant SPF as Spoofed Actor
    participant GCP as Google AS396982
    participant INF as Infraly AS400529
    participant BRZ as BreezeHost AS400810

    Note over U,SRV: SCENARIO A - Fetch legittimo verificato (88.8% del traffico)

    U->>OAI: Query utente (es. "alternative a Profound")
    OAI->>AZ: Dispatch fetch task
    AZ->>SRV: GET /en/alternatives/profound (IP in chatgpt-user.json)
    SRV-->>AZ: 200 OK - 74 KB full_document
    AZ-->>OAI: Contenuto pagina
    OAI-->>U: Risposta con citazione

    Note over SPF,SRV: SCENARIO B - Sessione spoofed con probe (8 ago, picco 52 visite)

    SPF->>GCP: Orchestrazione burst (gap=0s tra richieste)
    GCP->>SRV: GET /firebase-service-account.json
    SRV-->>GCP: 404
    GCP->>SRV: GET /service_account.json
    SRV-->>GCP: 404
    GCP->>SRV: GET /client_secret.json
    SRV-->>GCP: 404
    GCP->>SRV: GET /backend/config.json
    SRV-->>GCP: 404
    GCP->>SRV: GET /@fs/var/run/secrets/kubernetes.io/serviceaccount/token
    SRV-->>GCP: 404
    GCP->>SRV: GET /fetch?url=http://169.254.169.254/latest/meta-data/
    SRV-->>GCP: 404

    Note over INF,SRV: SCENARIO C - Spoofed con mix content + probe (9 ago, Infraly)

    INF->>SRV: GET /en (200 - pagina legittima)
    SRV-->>INF: 200 OK
    INF->>SRV: GET /instance/config.py
    SRV-->>INF: 404
    INF->>SRV: GET /settings.json
    SRV-->>INF: 404
    INF->>SRV: GET /serverless.yml
    SRV-->>INF: 404
    INF->>SRV: GET /config.json
    SRV-->>INF: 404
    INF->>SRV: GET /vercel.json
    SRV-->>INF: 404

    Note over BRZ,SRV: SCENARIO D - Spoofed con discovery via sitemap (BreezeHost)

    BRZ->>SRV: GET /sitemap.xml (200)
    SRV-->>BRZ: 200 OK
    BRZ->>SRV: GET /config.json
    SRV-->>BRZ: 404
    BRZ->>SRV: GET /instance/config.py
    SRV-->>BRZ: 404
    BRZ->>SRV: GET /alternative/rankscale (200)
    SRV-->>BRZ: 200 OK
    BRZ->>SRV: GET /come-funziona (200)
    SRV-->>BRZ: 200 OK

Il sequence diagram confronta i quattro pattern osservati:
A) il fetch legittimo OpenAI/Azure — singola richiesta verificata, IP pubblicato, full_document;
B) il burst da Google AS396982 (8 ago) — probe SSRF e path traversal in sequenza sincrona (gap=0s), tutti 404;
C) la sessione Infraly che mescola pagine legittime con probe di configurazione;
D) BreezeHost che legge prima sitemap.xml per discovery, poi alterna probe e pagine reali.

Network Diagram — ASN → Path → Esito

flowchart TD
    ROOT["ChatGPT-User<br/>990 visite"] --> VERIFIED["Verificate<br/>879 visite"]
    ROOT --> SPOOFED["Spoofed<br/>111 visite"]

    VERIFIED --> AZ["Microsoft Azure<br/>AS8075<br/>IP in chatgpt-user.json"]
    AZ --> HOME["Homepage<br/>/<br/>670 visite"]
    AZ --> ALT["Alternative pages<br/>profound, rankscale, omnia<br/>159 visite"]
    AZ --> PRODUCT["Product pages<br/>pricing, features, how-it-works<br/>19 visite"]
    AZ --> REDIR["Redirect<br/>/en/comparisons<br/>9 visite"]
    AZ --> TECH["Technical checks<br/>robots + sitemap<br/>5 visite isolate"]

    SPOOFED --> GCP["Google GCP<br/>AS396982<br/>73 visite"]
    SPOOFED --> INF["Infraly<br/>AS400529<br/>25 visite"]
    SPOOFED --> BRZ["BreezeHost<br/>AS400810<br/>13 visite"]
    SPOOFED --> WST["WS Telecom<br/>AS209372/213541<br/>17 visite"]

    GCP --> SSRF["SSRF probe<br/>169.254.169.254<br/>404"]
    GCP --> TRAV["Path traversal<br/>/proc/self/environ<br/>404"]
    GCP --> CREDS["Credential files<br/>client_secret, service_account<br/>404"]

    INF --> CONFIG["Config files<br/>config, vercel, settings<br/>404"]
    INF --> CREDS
    INF --> HOME

    BRZ --> SITEMAP["Sitemap discovery<br/>/sitemap.xml"]
    BRZ --> CONFIG
    BRZ --> ALT

    WST --> HOME
    WST --> ALT

Il network diagram mappa le relazioni tra ASN sorgente, categoria di path visitato ed esito. La separazione visiva tra il blocco "verificato" (Azure) e "spoofed" (GCP/Infraly/BreezeHost) evidenzia come il traffico legittimo OpenAI sia concentrato su path contenutistici con full_document, mentre gli attori spoofed si distribuiscono su probe di credential harvesting, SSRF e path traversal — con pattern di sessione sincrono (gap=0s) incompatibile con il comportamento reale di ChatGPT-User.

Sintesi investigativa

Perché l'abbiamo costruito

Abbiamo costruito GeoSonar Agent Analytics perché, a un certo punto, l'audit da solo non bastava più.

L'audit dice se un sito è pronto per essere letto e citato dai sistemi generativi.

Agent Analytics misura cosa succede quando gli agenti arrivano davvero sul server.

Sono due piani diversi. Se li teniamo separati, capiamo meglio anche come si collegano. Ma li colleghiamo a GeoSonar tramite l'API Key del progetto e l'MCP server che accede al Knowledge Graph e allo storico delle audit! Se poi ci agganciano l'MCP server di Google Analytics....BOOM! Ça va sans dire.

Senza audit, il traffico bot resta una lista di richieste tecniche. Senza Agent Analytics, l'audit valuta il sito ma non segue nel tempo il comportamento reale degli agenti.

In mezzo c'è il lavoro che oggi interessa davvero a chi fa SEO, contenuti e GEO: capire quali pagine sono leggibili dalle macchine, quali vengono effettivamente richieste, quali agenti sono reali, quali segnali arrivano dopo, e quali numeri vanno ignorati perché prodotti da spoofing o rumore automatico.

La parte più delicata è non farsi sedurre dal numero più grande.

Un picco di bot non è per forza una buona notizia. Una visita dichiarata ChatGPT non è per forza ChatGPT. Un referrer AI non basta da solo a spiegare una citazione. Una pagina molto richiesta non è automaticamente una pagina usata nelle risposte.

Agent Analytics tiene separate queste differenze invece di appiattirle in una metrica unica.

Non rende il comportamento degli agenti completamente trasparente. Nessuno, al di fuori dei provider, ha veramente visibilità su tutta la pipeline interna di ChatGPT, Claude, Perplexity e compagnia cantante.

Però riduce l'area in cui siamo costretti a tirare a indovinare.

Per chi lavora sulla visibilità organica nei sistemi generativi, è molto meglio partire da qui che commentare grafici pieni di traffico non verificato.

Piccola disclosure "GEOSonar Agent Analytics" è ancora un tool interno. Stiamo decidendo se includerlo nella suite o tenerlo separato rendendolo opensource. Se vi interessa scriveteci che decidiamo insieme.

Have fun!