Gemini è in grado di leggere contenuti JavaScript Client Side Rendering; ChatGPT e Claude, no. Non perché esegua il codice in tempo reale come un browser, ma sfrutta l’infrastruttura di Google, accedendo a una versione della pagina già processata e indicizzata da Googlebot. Questo è il risultato netto e diretto di un esperimento pratico, nato per tagliare corto con le chiacchiere sulla “SEO per AI” e tornare ai fondamentali tecnici che contano davvero.
Il test che ho documentato nel video è semplice: ho dato in pasto ai tre principali LLM una pagina e-commerce con rendering full client-side, la bestia nera per eccellenza. L’ho fatto per rispondere a una domanda che scavalca ogni nuovo acronimo: questi strumenti, di cui tanto si parla, sono almeno in grado di “vedere” un sito moderno? Prima di chiederci come ottimizzare per l’intelligenza artificiale, dobbiamo avere la certezza che questa possa accedere al contenuto.
La distinzione tra rendering lato client e lato server, un tema che tratto da anni, diventa oggi ancora più critica. Se il tuo sito non consegna un HTML con del contenuto al primo colpo, per due dei tre principali chatbot, semplicemente non esisti. L’esperimento che segue lo dimostra senza filtri.
Video
Trascrizione del video
Buonasera amici SEO. Oggi facciamo un esperimento. In questo periodo si sente parlare di tutto: SEO per AI, AIO, SGE… sembra che ogni giorno nasca un acronimo nuovo per rivoluzionare il modo in cui ottimizziamo i siti internet.
Ma alla fine della fiera, siamo sicuri che le regole del gioco siano davvero cambiate? Spesso, infatti, le basi della SEO — quelle che contano veramente — vengono messe in disparte, in secondo piano, da queste nuove tendenze.
E poi ci sono concetti come il client-side rendering e il server-side rendering, che ho trattato più volte su evemilano.com e che molti ignorano. Non se ne conoscono le differenze, non si capisce l’impatto che un codice JavaScript può avere sul rendering di una pagina web. Questo è un aspetto fondamentale al giorno d’oggi.
In questo video voglio fare un esperimento pratico per andare al cuore del problema. Metteremo alla prova i più noti chatbot LLM e vedremo cosa riescono effettivamente a “vedere” di una pagina web con rendering client-side, quindi generata interamente da JavaScript.
Per farlo, useremo una pagina costruita con rendering full client-side, la “bestia nera” di molti SEO, e verificheremo se questi nuovi strumenti riescono a trovare gli elementi presenti al suo interno.
Sei curioso di vedere i risultati? Iniziamo.
Allora, prendiamo una pagina di Esselunga online, una pagina che non richiede cookie per essere visitata. La apriamo in incognito, inseriamo direttamente l’URL e vediamo che ci porta su una pagina di acquisto, con un menù laterale, i prodotti, eccetera.
Quello che voglio fare è vedere se questi chatbot – useremo ChatGPT, Gemini e Claude, tutti in versione Pro – riescono a interpretare il contenuto della pagina. Questo test nasce perché iniziano ad arrivare richieste strane, del tipo: “Vorrei fare SEO per ChatGPT”. Poi, però, controlli e scopri che hanno un sito che a malapena si visualizza su Chrome, quindi figuriamoci.
Ma polemiche a parte, testiamo questa pagina. Se andiamo a visualizzare il codice sorgente, notiamo che è essenzialmente una pagina vuota: non contiene il contenuto che noi vediamo a schermo. Se invece facciamo un’ispezione del DOM, troviamo tutto il codice. Questo accade perché, come ho spiegato nelle guide su Eve Milano, il codice HTML iniziale contiene degli script JavaScript. Il browser esegue questi script, i quali a loro volta “compilano” e popolano la pagina HTML. Tutto questo lavoro viene fatto lato client (nel browser), a differenza di un sito in WordPress (PHP) che genera il codice HTML completo direttamente dal server.
Qui vediamo, ad esempio, che una voce del menù, “Patatine e dolciumi”, la troviamo nel DOM, con la sua ancora e il link. La stessa voce, invece, non la troviamo nel codice HTML sorgente, perché, come dicevo, quello è solo lo scheletro della pagina.
Per avere una controprova, vediamo cosa succede se disabilitiamo JavaScript nel browser. Ricarichiamo la pagina e… non vediamo nulla. La pagina è bianca, e il codice sorgente è lo stesso scheletro vuoto di prima.
Quindi, partiamo con ChatGPT. Gli pongo la prima domanda: “Quando tu (GPT) navighi una pagina web che ti indica un utente, la visualizzi in modalità desktop o mobile?”. Volevo assicurarmi che provasse a vedere il layout corretto.
La sua risposta: “Quando navigo una pagina web tramite il mio strumento di Browse, la visualizzo in modalità desktop per impostazione predefinita. L’user agent simula quello di un browser desktop standard, come Google Chrome. […] Se un sito ha un layout o contenuti differenti tra mobile e desktop, io vedrò (e analizzerò) la versione desktop”.
Vediamo cosa ci dice Claude: “Quando uso lo strumento web, non ‘visualizzo’ la pagina nel senso tradizionale. Non ho un browser con un’interfaccia grafica. Ottengo, invece, il codice HTML, CSS e JavaScript della pagina. Il contenuto che riceverò è quello che il server web invia in risposta alla richiesta”.
E infine, Gemini: “Non ‘visualizzo’ la pagina come farebbe un essere umano. […] Non la vedo né in modalità desktop né in modalità mobile. Invece, analizzo direttamente il codice sorgente della pagina, l’HTML, insieme ai file CSS e JavaScript”.
Ok, abbiamo i primi riscontri: ChatGPT dichiara di navigare in modalità desktop, mentre Claude e Gemini analizzano il codice sorgente senza un vero e proprio rendering visuale.
Ora, la domanda cruciale: “Esegui il codice JavaScript contenuto o linkato dalle pagine web che visualizzi?”.
ChatGPT risponde: “No, non eseguo il codice JavaScript. Il comportamento è simile a quello di un browser che ha JavaScript disattivato. Contenuti dinamici, redirect in JavaScript o caricamenti asincroni non vengono eseguiti”.
Claude è sulla stessa linea: “No, non eseguo il codice JavaScript contenuto nelle pagine web”.
E Gemini? “No, non eseguo il codice JavaScript come farebbe un browser. […] Quando mi fornisci un link, il mio processo si concentra sull’analisi del contenuto statico. […] Non ho un motore JavaScript”.
Bene, passiamo all’ultimo test. Fornisco loro l’URL e chiedo: “Trascrivi l’elenco delle voci del menù principale, quello a sinistra da desktop, della seguente pagina”.
ChatGPT: “Mi spiace, ma come ti ho spiegato non posso eseguire JavaScript. Il menù laterale […] è dinamico e viene generato tramite codice JavaScript, dunque non viene visualizzato da me”. Test fallito per GPT.
Vediamo Claude: “La pagina sembra non aver restituito contenuto visibile. Probabilmente perché il sito di Esselunga fa affidamento pesantemente su JavaScript per caricare dinamicamente il contenuto”. Anche Claude fallisce il test.
E ora, Gemini: “Ecco l’elenco delle voci: Frutta e verdura, Pesce, Carne…“.
Quindi, Gemini è riuscito a vederle. Sembra che abbia eseguito JavaScript, nonostante abbia detto il contrario. Ci possono essere due spiegazioni:
- Il server di Esselunga implementa il dynamic rendering, fornendo una versione pre-renderizzata (server-side) ai bot come Googlebot. Gemini, arrivando con un user agent simile, riceverebbe questa versione completa.
- Oppure, e credo sia l’ipotesi più probabile, Gemini non visita la pagina in tempo reale, ma attinge a una versione già presente nell’indice di Google. Quella versione, essendo stata scansionata e renderizzata da Googlebot (che esegue JavaScript), è già completa.
In pratica, o il rendering lo fa il server per Googlebot, o lo ha già fatto Googlebot per conto suo. Sta di fatto che Gemini, sfruttando l’infrastruttura del motore di ricerca Google, riesce a “vedere” pagine generate completamente in JavaScript.
Conclusione: Cari manager e imprenditori, se volete che il vostro sito sia accessibile a ChatGPT e Claude, assicuratevi che il suo contenuto fondamentale sia presente nel codice HTML iniziale e che sia quindi visualizzabile anche senza JavaScript.
Restare leggibili senza JavaScript è la base, ma non l’unico fronte: gli agenti AI valutano un sito anche su come l’infrastruttura segnala identità, regole di accesso e capacità transazionali ai loro bot. Cloudflare ha rilasciato un tool che verifica 18 standard tecnici — dal robots.txt agli header HTTP fino a MCP, OAuth e Web Bot Auth — e ne ho fatto un walkthrough completo nella guida al tool isitagentready.com di Cloudflare.
Buona serata, ciao a tutti.
Ah, e non mettete “mi piace” e non iscrivetevi al canale, perché non ho la minima costanza per fare video, purtroppo. Ciao!
Articoli correlati
Autore
Mi chiamo Giovanni Sacheli e dal 2009 aiuto le aziende a farsi trovare online. Sono specializzato in SEO tecnica e PPC, competenze che applico quotidianamente nella mia agenzia, Searcus Swiss Sagl. Mi piace sviluppare strumenti a supporto del mio lavoro, ho creato SEOdata.app e cluster.army e co-scritto il libro SEO Audit Avanzato. Curo maniacalmente questo blog per colleghi e appassionati, dove mi "appunto" quello che imparo. Sono un NERD anni '80, motociclista e orgoglioso papà di due bambini.
Link:
Giovanni Sacheli
SEO Audit Avanzato
Searcus Swiss Sagl
SEOdata.app
cluster.army