I crawler AI non eseguono il JavaScript: il test di 41 giorni che lo dimostra

I crawler delle AI non eseguono il JavaScript. Se i link interni del tuo sito compaiono solo dopo che il browser ha caricato gli script, per GPTBot, ClaudeBot, Bingbot, Amazonbot e i crawler di Meta quelle pagine non esistono. Non “sono penalizzate”: non esistono proprio. Un test controllato durato 41 giorni, pubblicato il 19 agosto 2026 su Search Engine Land, l’ha misurato in modo brutale: su 293 pagine raggiungibili solo tramite link iniettati via JavaScript, otto crawler su dieci ne hanno trovate zero. Googlebot — quello che costruisce l’indice della ricerca — ne ha raggiunte il 2%. Ecco cosa significa per il tuo sito e come verificarlo in dieci minuti.

Sommario

• Il test: 41 giorni, 2.400 pagine, ogni bot loggato
• I numeri: chi ha visto cosa
• Il trucco che inganna metà dei log: Google non è un crawler solo
• Il dato che fa più male: nemmeno gli utenti veri ci arrivavano
• La riparazione funziona. Ma non con tutti
• Dove succede davvero, sui siti italiani
• Come verificare il tuo sito in dieci minuti
• Cosa fare, in ordine di priorità
• Perché questo è un problema GEO prima che un problema SEO
• Domande frequenti
• Cosa significa per le aziende italiane

Il test: 41 giorni, 2.400 pagine, ogni bot loggato

La frase “tanto Google renderizza il JavaScript” gira nel nostro settore dal 2019, da quando Googlebot è diventato evergreen e ha smesso di usare una versione vecchia di Chrome. È una frase vera. È anche una frase che oggi risponde alla domanda sbagliata.

Vinicius Stanula ha deciso di misurarla invece di ripeterla. Ha preso un sito che possiede — una directory brasiliana di classificazione aziendale, circa 2.400 pagine — e ha costruito un esperimento pulito. Ventuno sezioni di primo livello, divise in due gruppi alternati per evitare che il caso raggruppasse le sezioni migliori da una parte sola:

• Gruppo HTML (11 sezioni): tutti i link ai figli scritti direttamente nell’HTML della pagina.
• Gruppo JavaScript (10 sezioni): tutti i link ai figli iniettati da uno script dopo il caricamento. Nell’HTML grezzo c’era un div vuoto. Un bot che non esegue JavaScript non vedeva nessun link.

Poi ha tolto ogni via di fuga: sitemap disattivate (tutti gli URL restituivano 404), briciole di pane rimosse, pannelli di navigazione interna rimossi. Per arrivare a una pagina del gruppo JavaScript esisteva un solo modo: eseguire lo script sulla pagina padre e seguire il link generato.

Un middleware ha registrato ogni singola richiesta dei bot per 41 giorni: percorso, user agent, referrer, IP, timestamp. Gli IP di Googlebot e Bingbot sono stati verificati via reverse DNS per scartare i bot che si spacciano per loro — dettaglio non banale, perché nei log di qualsiasi sito una fetta consistente del “traffico Googlebot” è finta.

Questo è il tipo di test che nel nostro settore si fa troppo poco. Non un’opinione, non un sondaggio fra colleghi: un ambiente controllato, una variabile sola, tutto il resto identico.

I numeri: chi ha visto cosa

Alla fine della prima fase — 27 giorni — questa è la fotografia. Le pagine contate sono solo quelle di gerarchia profonda, cioè quelle in cui un accesso al gruppo JavaScript è prova certa che il bot ha eseguito lo script. Il gruppo HTML conteneva 748 pagine, quello JavaScript 293.

Crawler	Esegue JS?	Pagine HTML trovate	Pagine JS trovate
Googlebot (indice ricerca)	Sì	35 (5%)	7 (2%)
GoogleOther	Sì	495 (66%)	142 (48%)
GPTBot (OpenAI)	No	748	0
ClaudeBot (Anthropic)	No	748	0
Bingbot	No	282	3
OAI-SearchBot (ricerca ChatGPT)	No	10	0
Meta-ExternalAgent	No	537	0
Amazonbot	No	735	0
ChatGPT-User (navigazione live)	No	46	0
PerplexityBot	No	0	0

Guarda la colonna di destra. Non è “poco”. È zero.

GPTBot ha spazzato il gruppo HTML in un giorno solo, tutte e 748 le pagine, fino al livello più profondo. Sul gruppo JavaScript ha visitato le 10 pagine di sezione — quelle linkate in HTML dalla home — e si è fermato lì. Mai un livello sotto. ClaudeBot ha fatto la stessa identica cosa il giorno dopo: scansione profonda e sistematica dell’HTML, muro netto al confine del JavaScript.

Bingbot è stato attivo 20 giorni su 27. Ha ri-scansionato le 10 pagine di sezione del gruppo JavaScript in 18 di quei giorni. Non ha mai seguito un link iniettato. Microsoft documenta dal 2019 un Bingbot evergreen basato su Edge in grado di renderizzare: su questo sito, quella capacità non è stata applicata.

Il dato non è un caso isolato. Analisi indipendenti su oltre 500 milioni di richieste di GPTBot non hanno trovato nessuna evidenza di esecuzione di JavaScript, nemmeno quando il bot scarica i file .js — cosa che fa in circa l’11,5% dei casi. Li scarica e non li esegue. La documentazione OpenAI per gli sviluppatori è esplicita nel dire che il crawler non renderizza JavaScript.

Il trucco che inganna metà dei log: Google non è un crawler solo

Qui c’è la parte che, secondo me, è la più utile del test — e la meno raccontata.

Nella tabella ci sono due righe Google, e fanno due mestieri diversi. GoogleOther ha renderizzato: 48% delle pagine JavaScript raggiunte. Sembra un buon numero. Googlebot — l’unico crawler che alimenta l’indice della Ricerca — si è fermato al 2%. Sei sezioni JavaScript su dieci non hanno ricevuto una singola visita di Googlebot in profondità in 27 giorni.

Il 48% di GoogleOther non dice niente sulla tua visibilità su Google. GoogleOther serve altri prodotti e altri usi interni: non costruisce l’indice. Se apri i log del server, sommi tutti gli user agent che contengono “Google” e ti tranquillizzi, stai leggendo il numero sbagliato.

Lo stesso Stanula mette una cautela onesta su questo punto, e la riporto perché è corretta: il sito del test era un dominio nuovo, senza link esterni, quindi con un crawl budget di Googlebot molto basso. Su un sito consolidato Googlebot investirebbe di più in rendering. Il divario 14:1 fra GoogleOther e Googlebot è probabilmente un artefatto del dominio giovane, non una legge universale.

Ma questa cautela vale solo per Google. Gli altri otto crawler hanno fatto zero, e per loro non c’è nessuna interpretazione alternativa: non eseguono JavaScript, punto.

C’è anche un secondo effetto misurato sul lato Google: le pagine linkate in JavaScript sono state scoperte dal 18% al 27% più tardi rispetto a quelle linkate in HTML, a ogni livello di profondità. Il ritardo si accumula perché Google deve prendere la pagina padre, metterla in coda per il rendering, eseguire lo script, estrarre gli URL e solo allora programmare i figli. Con i link in HTML salta tre passaggi.

Dettaglio controintuitivo: una volta scoperta, una pagina linkata in JavaScript viene ri-scansionata alla stessa velocità delle altre, a volte più in fretta. Il problema non è il ritmo. È l’ingresso. Le pagine che non superano la fase di scoperta non sono lente: non ci sono.

Il dato che fa più male: nemmeno gli utenti veri ci arrivavano

Nella tabella c’è una riga che vale più di tutte le altre messe insieme: ChatGPT-User, 46 pagine HTML, 0 pagine JavaScript.

ChatGPT-User non è un crawler di addestramento. È l’agente che va a prendere una pagina in quel momento, perché una persona in carne e ossa ha fatto una domanda a ChatGPT e il modello sta cercando la risposta. È domanda reale, di un utente reale, adesso.

Durante il test, query di utenti veri hanno portato quell’agente su decine di pagine del gruppo HTML. Le pagine dietro ai link JavaScript sono rimaste irraggiungibili per le stesse identiche query. Tradotto: le pagine che una persona stava attivamente cercando di raggiungere erano esattamente quelle che non poteva raggiungere.

Se hai un e-commerce e il tuo catalogo per categoria si costruisce via JavaScript, questo è il momento di smettere di leggere e andare a controllare. Come ChatGPT legge concretamente una pagina l’ho raccontato in dettaglio: legge poco, legge presto, e legge solo quello che trova nell’HTML iniziale.

La riparazione funziona. Ma non con tutti

Dopo 27 giorni Stanula ha convertito tutti i link JavaScript in HTML statico. Nient’altro: stesse pagine, stessi URL, stesso contenuto, stesso server. È cambiato solo dove stavano i link.

Chi ha recuperato in fretta:

• GPTBot: due giorni. Una sola passata sotto le tre ore, 250 pagine nuove — contro zero in 27 giorni.
• Bingbot: 212 pagine, arrivando al livello più profondo di sezioni in cui non era mai entrato.
• Meta-ExternalAgent: si è unito entro il giorno 41.

Chi non ha recuperato:

• Amazonbot: aveva finito e lasciato il sito al giorno 21, sei giorni prima della correzione. Copertura finale del gruppo JavaScript: zero.
• ClaudeBot: qui la cosa si fa interessante. Ha continuato a scansionare il sito dopo la correzione — centinaia di richieste fino al giorno 41 — ma solo su pagine che già conosceva. Non ha raccolto una sola pagina nuova. Come se avesse disegnato una mappa alla prima visita e continuasse a lavorare su quella, settimane dopo.
• Google: il più lento di tutti, ironicamente. Il budget aggressivo della prima visita era già stato speso. Al giorno 41 Googlebot aveva visitato una pagina nelle sezioni convertite. GoogleOther nessuna.

La lezione operativa è netta e vale per chiunque stia per mettere online un sito nuovo o un restyling: la prima scansione di un sito nuovo la fai una volta sola. Se in quel momento la navigazione è dietro al JavaScript, i crawler AI si costruiscono una mappa mutilata del tuo sito. Alcuni la aggiornano in 48 ore quando sistemi. Altri se la tengono per settimane. Google, sui domini nuovi, non torna in fretta.

Dove succede davvero, sui siti italiani

“Il mio sito è in WordPress, non è un’app React, non mi riguarda.” È la risposta che mi aspetto e nove volte su dieci è sbagliata. Il rendering lato client non è solo un problema dei framework moderni. Ecco dove lo trovo più spesso nei siti delle PMI che mi passano davanti:

• Menu costruiti dal page builder in JavaScript. Molti temi e plugin generano il mega-menu o il menu mobile via script. Se quello è l’unico posto dove vive il link a una categoria, per GPTBot quella categoria non esiste.
• Paginazione e “carica altri prodotti”. Il bottone che carica in AJAX i prodotti successivi è comodissimo per l’utente. Se dietro non c’è una paginazione con URL reali e link in HTML, hai un catalogo di 800 prodotti di cui le AI ne conoscono 24.
• Filtri e navigazione a faccette. Gli e-commerce WooCommerce con filtri per taglia, colore, prezzo generano pagine di grande valore commerciale. Quasi sempre raggiungibili solo cliccando, mai linkate in HTML da nessuna parte.
• Tab e accordion con contenuto iniettato. Le schede prodotto con “Descrizione / Specifiche / Recensioni” in cui il contenuto delle schede arriva via chiamata asincrona. Il contenuto migliore della pagina è quello che nessun crawler AI legge.
• Mappe punti vendita e store locator. Il caso peggiore: ogni negozio ha una pagina, tutte raggiungibili solo dalla mappa interattiva. Zero link in HTML. Per un’attività locale è visibilità buttata.
• Cookie banner e overlay bloccanti. Se il contenuto viene montato solo dopo l’accettazione dei cookie, il bot vede una pagina vuota. È un caso limite ma lo incontro ancora.

Nessuna di queste cose è un errore di sviluppo. Sono tutte scelte ragionevoli fatte pensando all’esperienza dell’utente umano. Il punto è che oggi hai due pubblici, e uno dei due non ha un browser.

Come verificare il tuo sito in dieci minuti

Non serve un tool a pagamento. Serve dieci minuti e un briciolo di metodo.

1. Disattiva il JavaScript e naviga

In Chrome: apri gli strumenti per sviluppatori, premi Ctrl+Maiusc+P (Cmd+Maiusc+P su Mac), scrivi “javascript”, scegli Disable JavaScript. Ora naviga il tuo sito come se fossi GPTBot. Prova a raggiungere, partendo dalla home e cliccando soltanto:

• la tua pagina servizio più redditizia
• una categoria prodotto del secondo livello
• la scheda di un prodotto che vendi bene
• la pagina di un punto vendita, se ne hai

Se non ci arrivi cliccando, non ci arriva nemmeno l’AI.

2. Confronta HTML grezzo e DOM renderizzato

Tasto destro, “Visualizza sorgente pagina”: quello è ciò che vede un crawler AI. Cerca con Ctrl+F l’URL di una pagina figlia. C’è dentro un tag <a href>? Bene. Trovi solo un div vuoto o un data- attributo? Male. Fai lo stesso confronto con “Ispeziona elemento”, che invece mostra il DOM dopo l’esecuzione degli script: la differenza fra le due viste è esattamente il tuo buco di visibilità.

3. Leggi i log del server separando gli user agent

Questo è il passaggio che quasi nessuna PMI fa e che vale più di tutti gli altri. Chiedi al tuo hosting i log degli accessi degli ultimi 30 giorni e conta le richieste separando: Googlebot, GoogleOther, GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, Bingbot, meta-externalagent, Amazonbot. Se un crawler AI tocca solo la home e le pagine di primo livello e non scende mai, hai la risposta senza bisogno di altro.

Occhio a una trappola: molti bot dichiarano di essere Googlebot senza esserlo. Verifica gli IP con il reverse DNS prima di trarre conclusioni.

4. Controlla che il divieto non venga da te

Prima di dare la colpa al rendering, apri il tuo robots.txt. Nel 2024 tantissime aziende hanno bloccato per prudenza tutto quello che aveva “AI” nel nome, e oggi pagano il conto. Ne ho scritto in dettaglio: robots.txt e i bot di ChatGPT, cosa blocca davvero. Se hai vietato OAI-SearchBot, il problema non è il JavaScript.

Cosa fare, in ordine di priorità

Non tutto quello che è in JavaScript va riscritto. Distinguere è la parte che fa risparmiare soldi.

Priorità 1 — I link di navigazione vanno in HTML. Sempre. Questa è la regola non negoziabile. Un widget che si carica in JavaScript peggiora leggermente una pagina. Una navigazione che si carica in JavaScript fa sparire intere sezioni del sito da ogni indice che alimenta un assistente AI. Sono due problemi di ordine di grandezza diverso.

Priorità 2 — Rendering lato server per i percorsi che portano fatturato. Se il sito è su un framework moderno, attiva il server-side rendering o la generazione statica almeno sulle rotte commerciali. Se è WordPress, quasi sempre basta configurare il tema per emettere il menu in HTML e sostituire i “carica altri” con una paginazione vera.

Priorità 3 — Ripristina i percorsi di scoperta alternativi. Nel test erano stati tolti apposta. Sul tuo sito devono esserci tutti: sitemap XML aggiornata e pulita, briciole di pane in HTML, link contestuali dentro i testi, pagine hub che linkano i figli. Ridondanza è resilienza.

Priorità 4 — Fallo prima del lancio, non dopo. È la lezione più cara del test. Se stai per pubblicare un sito nuovo o rifare quello esistente, la verifica “navigo senza JavaScript” va fatta in staging, non tre mesi dopo il lancio quando ti accorgi che ChatGPT non ti nomina mai. La prima scansione non si ripete.

Cosa NON fare: non riscrivere tutto il front-end in HTML statico per paura. Non serve. Le animazioni, i caroselli, i configuratori, i calcolatori interattivi possono restare esattamente dove sono. L’unica cosa che deve stare nell’HTML iniziale sono i link e i contenuti testuali che vuoi far citare.

Perché questo è un problema GEO prima che un problema SEO

Nella logica SeoZoom, l’autorevolezza topica (TZA) e la citabilità nei motori generativi si costruiscono su una precondizione banale: il contenuto deve essere raggiungibile. Puoi avere la migliore Zoom Authority del tuo settore e restare invisibile a ChatGPT se le pagine che dimostrano quella competenza stanno dietro a un link che il bot non vede.

La differenza rispetto alla SEO classica è la tolleranza. Google, male che vada, ti trova comunque: ha la sitemap, ha i link esterni, ha vent’anni di storia del tuo dominio, ha una pipeline di rendering. Ti trova tardi e ti trova poco, ma ti trova. I crawler AI no. Non hanno pazienza, non hanno un secondo tentativo programmato, non hanno una coda di rendering. Passano una volta, prendono quello che c’è nell’HTML, e la mappa che si costruiscono in quel momento è quella su cui lavoreranno per settimane — il comportamento di ClaudeBot dopo la correzione lo dimostra bene.

C’è anche una conseguenza di misurazione. Se stai monitorando la tua visibilità nelle risposte AI e vedi numeri bassi, l’istinto è pensare che il contenuto non sia abbastanza buono e riscriverlo. Può darsi. Ma prima verifica che sia leggibile: riscrivere un contenuto che nessun bot raggiunge è lavoro sprecato al 100%. È lo stesso ragionamento che vale per tracciare il traffico che arriva dalle AI: prima misuri se il canale esiste, poi ottimizzi.

Il trade-off onesto, perché ci sia: il rendering lato server costa. Costa in tempo di sviluppo, a volte in hosting, spesso in complessità di manutenzione. Se hai un sito vetrina di dodici pagine tutte linkate dal menu principale, questo articolo per te è una lettura di cultura generale, non un intervento urgente. Se hai un catalogo, una struttura profonda o più sedi, è la cosa più redditizia che puoi guardare questo mese.

Domande frequenti

Google renderizza il JavaScript o no?

Sì, ma è una risposta parziale. Nel test, i crawler di Google sono stati gli unici a eseguire gli script e seguire i link iniettati. Il problema è che quasi tutto quel lavoro l’ha fatto GoogleOther, che non costruisce l’indice della Ricerca. Googlebot, il crawler che determina se compari su Google, ha raggiunto il 2% delle pagine linkate in JavaScript. Il rendering avviene, ma con un budget separato, in coda, e distribuito in modo molto irregolare.

GPTBot e ClaudeBot eseguono JavaScript?

No. Nel test hanno trovato zero pagine su 293 raggiungibili solo via JavaScript, pur avendo scansionato integralmente e in profondità tutte le 748 pagine linkate in HTML. La documentazione OpenAI per gli sviluppatori conferma che GPTBot non renderizza JavaScript, e analisi su centinaia di milioni di richieste non hanno mai rilevato esecuzione di script. Vale lo stesso per Bingbot, Amazonbot, Meta-ExternalAgent, PerplexityBot e OAI-SearchBot.

Se sistemo i link adesso, recupero la visibilità persa?

In parte, e con tempi molto diversi a seconda del crawler. Nel test, dopo la conversione dei link in HTML, GPTBot ha recuperato 250 pagine in meno di tre ore entro due giorni, e Bingbot 212 pagine entro una settimana. ClaudeBot ha continuato a visitare il sito senza scoprire nulla di nuovo. Amazonbot se n’era già andato. Google, sul dominio nuovo del test, al giorno 41 aveva visitato una sola pagina nelle sezioni corrette. Quindi: sì, si recupera, ma non è gratis e non è immediato.

Il mio sito WordPress è a rischio?

Dipende da come è costruito, non dal fatto che sia WordPress. WordPress genera HTML lato server per impostazione predefinita, quindi la base è sana. I rischi arrivano dai livelli sopra: mega-menu generati via script da alcuni temi e page builder, bottoni “carica altri prodotti” in AJAX senza paginazione reale, filtri WooCommerce a faccette, tab di prodotto con contenuto caricato in modo asincrono, store locator basati su mappa. Il test dei dieci minuti con JavaScript disattivato ti dà la risposta esatta per il tuo caso.

Come faccio a sapere se un crawler AI sta davvero scansionando il mio sito?

Guardando i log del server, separando gli user agent uno per uno e verificando gli IP dei crawler dichiarati con il reverse DNS. Non sommare mai tutti gli user agent che contengono “Google”: Googlebot e GoogleOther fanno mestieri diversi e solo il primo conta per la visibilità in Ricerca. Se un bot AI visita solo home e pagine di primo livello e non scende mai in profondità, hai quasi certamente un problema di link non raggiungibili.

Cosa significa per le aziende italiane

Il tessuto delle PMI italiane ha una caratteristica che rende questa notizia più rilevante che altrove: la maggior parte dei siti aziendali non è stata costruita da un team interno, ma da un’agenzia o da un freelance, anni fa, con un tema comprato e un page builder. Nessuno ha mai aperto i log. Nessuno sa cosa vedono i bot. E la scelta di caricare i menu o i cataloghi via JavaScript non è stata una decisione strategica: è stata un’impostazione predefinita del tema.

Il risultato pratico è che, oggi, un’azienda italiana con un catalogo serio può essere completamente assente dalle risposte di ChatGPT, Gemini e Perplexity per una ragione che non ha niente a che vedere con la qualità dei suoi prodotti, dei suoi testi o del suo lavoro. È assente perché il link alla pagina giusta si materializza mezzo secondo dopo il caricamento, e il bot in quel mezzo secondo era già andato via.

Tre implicazioni concrete, in ordine di urgenza.

Per chi vende online. Se hai un e-commerce con più di cento prodotti, la parte del tuo catalogo raggiungibile solo tramite filtri, paginazione asincrona o menu dinamici è, con ogni probabilità, invisibile a chi chiede consigli d’acquisto a un’AI. Non è una perdita di posizionamento: è una perdita di esistenza. E il canale sta crescendo mentre il traffico da ricerca tradizionale non cresce.

Per chi ha più sedi o lavora sul territorio. Le pagine dei punti vendita sono il patrimonio locale più prezioso che hai. Se esistono solo dietro una mappa interattiva, per le AI la tua azienda ha un indirizzo solo. In un Paese dove la ricerca locale conta quanto conta in Italia, è un autogol silenzioso.

Per chi sta rifacendo il sito adesso. Metti una riga sola nel capitolato, prima di firmare: tutti i link di navigazione devono essere presenti nell’HTML servito dal server, verificabili disattivando JavaScript nel browser. Costa zero in fase di progettazione. Costa molto se te ne accorgi dopo, perché la prima scansione di un dominio nuovo non si ripete e Google, nel test, non è più tornato.

Se vuoi capire in che stato sei prima di decidere quanto investire, la verifica dei dieci minuti descritta sopra la puoi fare oggi, da solo, senza spendere niente. Se il risultato ti preoccupa e vuoi un’analisi seria dei log e della struttura di link, ne parliamo insieme.