Cosa ricevono davvero gli agenti IA: rendering e JavaScript

Tu vedi una pagina completa. L’agente riceve un file HTML grezzo. Se il tuo contenuto viene assemblato nel browser da JavaScript, c’è una possibilità concreta che dall’altra parte sia arrivato solo un guscio vuoto. L’unica misurazione pubblica che ho trovato sul tema — condotta da Vercel e MERJ nel dicembre 2024 — conclude che nessuno dei principali crawler IA esegue JavaScript: i file JS li scaricano (l’11,50% delle richieste di ChatGPT, il 23,84% di quelle di Claude) ma non li eseguono mai. Google è l’eccezione: effettua il rendering con una versione evergreen di Chromium, pur fermandosi anch’esso a 2 MB. Il test in sé richiede due minuti e una riga di curl.

L’unica domanda che conta: cosa c’è nell’HTML iniziale?

C’è una differenza tra ciò che il tuo sito mostra e ciò che il tuo sito invia. Il browser riceve un documento HTML, scarica i file JavaScript, li esegue, effettua ulteriori chiamate API e da tutto questo assembla la pagina che vedi. L’intera catena avviene sulla macchina dell’utente, non sul tuo server. Un agente che richiede l’URL e si ferma lì riceve solo il primo passaggio.

Sulla maggior parte dei content management system classici il problema non si pone, perché l’HTML arriva dal server già completo. La difficoltà comincia quando il sito è costruito come un’applicazione lato client: React, Vue o Angular che generano il contenuto dopo il caricamento. In quel caso il documento che lascia il tuo server può essere tre kilobyte di tag vuoti con un <div id=”root”></div> nel mezzo, e tutto il resto viene costruito soltanto nel browser.

Un punto merita di essere sottolineato: non è una questione di permessi. Puoi dare a ogni bot accesso completo, restituire 200 a ogni richiesta e non comparire comunque in nessuna risposta — semplicemente perché non c’era contenuto da leggere. Ho analizzato il livello dei permessi separatamente nella mappa dei bot 2026; questo è il livello che viene subito dopo.

Cosa è stato davvero misurato — e cosa no

Il tema richiede cautela, perché è pieno di numeri che circolano senza fonte. Ciò che esiste: uno studio congiunto di Vercel e MERJ pubblicato il 17 dicembre 2024, che analizza log reali di siti di grandi dimensioni. La conclusione centrale è che nessuno dei principali crawler IA — GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot e gli altri — esegue JavaScript. Scaricano i file JS ma non li eseguono. L’eccezione nel loro elenco è AppleBot, che effettua il rendering tramite un browser.

Lo stesso studio dà anche un’idea dei volumi: circa 569 milioni di richieste mensili da GPTBot e circa 370 milioni da Claude, insieme all’incirca un quinto del volume di richieste di Googlebot in quel periodo.

Google è l’eccezione, non la regola

Google Search Central afferma esplicitamente, in una pagina aggiornata il 4 marzo 2026, che Google Search esegue JavaScript con una versione evergreen di Chromium e che Googlebot mette in coda per il rendering tutte le pagine che restituiscono uno status code 200. Nello stesso documento Google aggiunge la precisazione più rilevante in questo contesto: non tutti i bot sono in grado di eseguire JavaScript.

Vale la pena conoscere due limiti pratici di Google. Primo, secondo la documentazione di Googlebot, il crawler preleva i primi 2 MB di un tipo di file supportato e si ferma lì. Se il tuo HTML è più pesante, tutto ciò che supera la soglia semplicemente non viene letto. Secondo, sulle funzionalità basate sull’IA, Google afferma che non esistono requisiti tecnici aggiuntivi oltre al fatto che la pagina sia indicizzata e idonea a comparire con uno snippet. Nessun file speciale e nessun markup dedicato: ciò che si legge bene in Search si legge bene anche lì.

Tre schemi che svuotano la pagina

Rendering lato client. Il caso classico. Il documento che arriva dal server contiene un guscio e il contenuto si carica dopo. Facile da individuare: il sorgente della pagina è molto più breve di ciò che l’occhio vede.

Contenuto che si apre solo con l’interazione. Accordion, tab, «carica altro», scroll infinito. Se il contenuto viene iniettato nel DOM solo dopo un clic, nel documento non esiste. Se è presente nell’HTML ed è semplicemente nascosto via CSS, c’è, e va benissimo così.

Livelli bloccanti davanti al contenuto. Un banner dei cookie che richiede il consenso prima che il contenuto si carichi, un paywall, una modale di login, o un livello di bot management che restituisce un challenge. In questi casi il bot una pagina la riceve — solo che non è la tua.

Come verificarlo in due minuti

Non serve nessuno strumento esterno. Bastano tre righe per sapere esattamente cosa esce dal tuo server:

L’interpretazione è semplice. Se la riga 2 restituisce un numero vicino al conteggio di parole che vedi sulla pagina, va tutto bene. Se restituisce 40 parole per una pagina da 1.200 parole, il contenuto viene costruito nel browser. Se la riga 3 restituisce 0, la tua frase centrale non esiste in nessuna risposta che verrà mai generata da quella pagina. Vale anche la pena rifare la stessa verifica con uno user-agent di browser ordinario e confrontare: un divario ampio tra i due indica un server che serve contenuti diversi ai bot.

Come confermare che il bot sia autentico

Prima di trarre conclusioni dal tuo log, assicurati che chi diceva di essere GPTBot lo sia davvero. Tutti i principali vendor pubblicano elenchi ufficiali di indirizzi IP, e Google pubblica anche un metodo di verifica tramite DNS inverso:

Google è l’unico dei quattro a offrire la verifica tramite DNS inverso. Con gli altri, confrontare l’IP con l’elenco ufficiale è l’unico controllo disponibile. Conviene scaricare questi file automaticamente invece di copiare gli intervalli a mano — cambiano.

Cosa fare quando la risposta è «la pagina è vuota»

La correzione dipende dall’architettura, ma la direzione è la stessa in ogni caso: spostare l’assemblaggio del contenuto dal browser al server.

1. Rendering lato server o generazione statica. Nei framework moderni è un’impostazione per singola pagina, non una riscrittura. Il risultato è HTML completo già nella primissima risposta, il che migliora anche i tempi di caricamento per gli utenti umani.
2. Assicurati che il contenuto principale non dipenda dall’interazione. Un accordion il cui contenuto è nell’HTML e viene nascosto via CSS è una soluzione perfettamente valida. Un accordion che recupera il contenuto al clic non lo è.
3. Controlla cosa succede prima del consenso. Se il banner dei cookie blocca il contenuto fino al clic, il bot non vede nulla. Il contenuto deve essere nel documento anche quando non è stato cliccato nulla.
4. Misura di nuovo; non dare per scontato. Dopo ogni modifica, la stessa riga di curl. La verifica richiede pochi secondi, e dare per scontato che abbia funzionato è esattamente ciò che ha creato il problema all’inizio.

E se ti interessa la domanda più ampia — cosa legge davvero un agente IA sul tuo sito prima ancora che si ponga la questione del rendering — ne ho scritto nel livello di scoperta.

Un ordine di priorità concreto

Se hai un’ora, questo è l’ordine che consiglio. Primo, esegui la verifica curl sulle tre pagine più importanti del sito — la home, la pagina di servizio principale e l’articolo con più traffico. Poi confronta il conteggio delle parole con ciò che è effettivamente visibile. Solo se c’è un divario ha senso aprire la questione architetturale. Sulla maggior parte dei siti WordPress e dei siti vetrina la risposta sarà che va tutto bene, ed è un ottimo esito — meglio saperlo che passare un mese a risolvere un problema che non hai.

Domande frequenti