Un sito ecommerce ha perso il 47% della visibilità nella ricerca AI dopo un rilascio che ha cambiato il modo in cui le pagine vengono generate. Le stesse pagine prodotto si posizionavano ancora su Google. Ma ChatGPT, Claude e Perplexity non restituivano nessun risultato. La differenza era il rendering JavaScript.
Succede a ogni sito che si affida al rendering lato client. Una landing page SaaS costruita con un framework JavaScript non compare mai nelle risposte di ChatGPT. Un sito di notizie basato su un framework JavaScript non ha nessuna presenza su Perplexity. Una knowledge base che genera i contenuti con un framework JavaScript resta invisibile ai crawler AI. Non sono casi limite. Sono il comportamento predefinito della maggior parte dei framework web moderni.
La differenza tra un sito basato su JavaScript e uno visibile all'AI non dipende dalla complessità o dal budget. Dipende dal capire che cosa succede in quei primi millisecondi, quando arriva un crawler.
Che cosa vedono i crawler AI quando scaricano la tua pagina
Il crawler di Google esegue JavaScript. Aspetta che la pagina venga generata, cattura lo stato visivo finale e lo indicizza. La maggior parte dei crawler AI no.
Quando il crawler di ChatGPT (GPTBot) arriva sul tuo sito, la sequenza è questa: 1. Scarica il file HTML 2. Estrae il testo visibile in quell'HTML grezzo 3. Passa alla pagina successiva
Il JavaScript che genera il tuo titolo, la descrizione del prodotto, il corpo dell'articolo non viene mai eseguito. Il crawler vede i riferimenti ai file JavaScript ma li ignora. La tua pagina appare come un guscio vuoto, senza contenuti.
Succede perché i crawler AI sono pensati per velocità ed efficienza. Eseguire JavaScript è lento. Richiede di avviare un browser, aspettare il caricamento delle risorse, gestire gli errori, controllare i timeout. Quando scansioni miliardi di pagine al giorno, eseguire JavaScript diventa proibitivo.
Google investe in quell'infrastruttura perché i risultati di ricerca dipendono dalla comprensione del rendering visivo. I motori di ricerca AI danno priorità all'estrazione del testo grezzo. Sono ottimizzati per prendere fatti e citazioni direttamente dall'HTML, non da ciò che appare dopo che JavaScript lo ha trasformato.
Quali tipi di rendering creano problemi ai crawler AI
Non tutti i framework JavaScript causano la stessa perdita di visibilità. Il problema riguarda in particolare il rendering lato client (CSR), in cui JavaScript viene eseguito *nel browser* e costruisce la pagina dopo il caricamento dell'HTML.
Rendering lato client (CSR): i framework JavaScript più diffusi, quando sono impostati su CSR. L'HTML arriva vuoto o con segnaposto. JavaScript riempie i contenuti dopo il download. I crawler AI non aspettano.
Rendering lato server (SSR): i framework pensati per il rendering sul server. Il server costruisce la pagina con i contenuti già inseriti nell'HTML. Il browser riceve HTML completo. I crawler AI vedono tutto subito.
Generazione statica (SSG): generatori di siti statici. Le pagine sono già pronte e pubblicate come file HTML statici. Al momento della richiesta non avviene nessun rendering. I crawler AI ricevono i contenuti completi all'istante.
Applicazioni a pagina singola (SPA): la categoria a più alto rischio. Una SPA carica un solo file HTML e usa JavaScript per sostituire i contenuti in base alla navigazione. Ogni percorso appare identico a un crawler, a meno che il server non gestisca ogni percorso in modo specifico.
Nel momento in cui scegli il CSR come strategia di rendering, crei una barriera invisibile tra i tuoi contenuti e ogni crawler AI di internet.
Perché conta più di quanto pensi
La ricerca AI è ancora agli inizi, ma l'adozione sta accelerando. Gli studi mostrano che le ricerche AI crescono più in fretta delle ricerche web tradizionali. ChatGPT, Perplexity e Claude stanno diventando strumenti di ricerca principali per professionisti, studenti e decisori.
Quando qualcuno chiede a ChatGPT i "migliori creatori di siti per piccole imprese", è l'AI a scegliere quali brand citare. Quella scelta dipende dai contenuti che riesce a leggere. Se la tua pagina funziona con JavaScript, è invisibile.
Non è un problema futuro. Un'analisi del 2025 su oltre 500 milioni di richieste di GPTBot ha rilevato che i siti che dipendono da JavaScript ricevevano molte meno citazioni dei concorrenti con rendering lato server nello stesso settore. Il divario era maggiore per contenuti tecnici, pagine prodotto e guide pratiche, cioè proprio i tipi di contenuto che i motori AI privilegiano.
Per le aziende B2B ed ecommerce, le citazioni AI stanno diventando una leva di visibilità competitiva. Essere citati in una risposta di ChatGPT o in uno snippet di Perplexity può portare lo stesso valore di traffico di un posizionamento in prima pagina su Google. Solo che non puoi essere citato se il crawler non riesce a leggere i tuoi contenuti.
Come decidere che cosa fare
Non tutti i siti devono abbandonare il rendering lato client. La decisione dipende da tre fattori: il tipo di contenuto, il tuo pubblico e il valore che la visibilità nella ricerca AI ha per la tua situazione specifica.
Fatti prima queste domande:
I tuoi contenuti meritano di essere citati dall'AI? Notizie, guide pratiche, confronti tra prodotti, articoli di ricerca, consigli di esperti. Questi vengono citati dall'AI. Documentazione tecnica, strumenti interattivi, dashboard pensate soprattutto per utenti con accesso. Questi no. Se il tuo sito è fatto soprattutto di questi ultimi, il rendering JavaScript conta meno.
Il tuo pubblico cerca nei motori AI? Professionisti B2B, chi fa ricerche sui prodotti, studenti, sviluppatori. Usano molto la ricerca AI. Se il tuo pubblico è molto di nicchia e cerca solo su Google, la visibilità AI ha un ritorno meno immediato.
Quanto costa essere invisibili? Per un sito di notizie o una knowledge base, zero citazioni AI sono uno svantaggio competitivo. Per l'intranet di un'azienda o un SaaS riservato ai membri, è irrilevante. Per un sito ecommerce dipende dal fatto che i tuoi clienti scoprano o meno i prodotti tramite i consigli di acquisto dell'AI.
Se hai risposto "contenuti degni di citazione AI", "sì, il mio pubblico usa la ricerca AI" e "perdere visibilità è un costo reale", procedi. Se le risposte sono miste, potresti dare priorità ad altro.
Rendering lato server: la soluzione più completa
L'SSR risolve il problema di JavaScript in modo completo. Il server costruisce la pagina completa con tutti i contenuti prima di inviarla al browser. Quando arriva un crawler, i contenuti sono già lì.
Come funziona: quando qualcuno (o un bot) richiede una pagina, il tuo server esegue il codice e produce l'HTML finale. Quell'HTML include il titolo, il testo dell'articolo, i dettagli del prodotto. Il browser riceve una pagina completa e la mostra subito. JavaScript può comunque migliorare l'interattività, ma i contenuti sono già accessibili.
Strumenti che rendono semplice l'SSR: esistono framework costruiti apposta per rendere l'SSR semplice. Scrivi i componenti una volta sola, il framework gestisce il rendering sul server e la pagina arriva già pronta.
Il compromesso: l'SSR richiede risorse del server. Il tuo server elabora ogni richiesta, costruisce l'HTML e lo invia. Servono più CPU e memoria che per servire file statici già pronti. Pagine lente o complesse possono aumentare il tempo di risposta, che incide su metriche di prestazione come il First Contentful Paint (FCP) e i Core Web Vitals.
Per la maggior parte dei siti, il peso sulle prestazioni è piccolo. Per i siti ad alto traffico con pagine complesse, diventa evidente. Si risolve con cache, edge computing o ottimizzazione del codice, ma richiede scelte di architettura.
Pre-rendering: un approccio più leggero per i contenuti statici
Il pre-rendering costruisce le pagine in anticipo e le pubblica come file HTML statici. Quando arriva un crawler, riceve subito una pagina completa. Quando arriva un visitatore, riceve un file statico che si carica in un attimo.
I servizi di pre-rendering automatizzano tutto questo. Li colleghi al tuo sito, visitano ogni URL della tua sitemap, generano ogni pagina (eseguendo JavaScript), catturano l'HTML finale e servono quelle versioni statiche ai crawler, mentre i browser ricevono ancora la versione interattiva.
Funziona se: i tuoi contenuti cambiano di rado. Articoli del blog, pagine prodotto, documentazione. Contenuti che si aggiornano al massimo una volta al giorno.
Non funziona se: i tuoi contenuti sono dinamici. Numeri di inventario, dati specifici dell'utente, informazioni in tempo reale, contenuti personalizzati. Se la tua pagina appare diversa a ogni visitatore, il pre-rendering non cattura tutte le versioni.
Costi e complessità: i servizi di pre-rendering costano $99-$499 al mese in base al numero di pagine. Mantieni due versioni dei contenuti: una per il browser (JavaScript), una pre-generata per i crawler. Questo raddoppia il lavoro di manutenzione. Quando pubblichi un nuovo articolo, devi ricostruire e ripubblicare la versione statica.
Per i siti con contenuti stabili, il pre-rendering è un compromesso pragmatico tra non fare nulla e passare all'SSR.
Rendering dinamico: un'opzione tattica per alcuni siti
Il rendering dinamico rileva quale user agent fa la richiesta. Se è un crawler, serve HTML generato dal server. Se è un browser, serve la versione JavaScript. Così mantieni il tuo stack tecnologico attuale e dai ai crawler i contenuti completi.
In teoria l'idea è elegante. In pratica è fragile. Devi:
Mantenere un elenco di User-Agent dei crawler AI e aggiornarlo di continuo, man mano che ne compaiono di nuovi. Se ne dimentichi uno, quel crawler vede la pagina vuota.
Costruire il rendering lato server apposta per i crawler, mantenendo il rendering lato client per i browser. In pratica è come costruire due versioni del tuo sito.
Verificare che le due versioni restino allineate. Un bug nella versione per i crawler rovina in silenzio la tua visibilità nella ricerca AI.
Il rendering dinamico funziona per siti di contenuti semplici. Per le applicazioni complesse, crea più problemi di quanti ne risolva. Se devi generare le pagine sul server per i crawler, tanto vale farlo per tutti (è proprio l'SSR).
Come capire se il tuo sito ha questo problema adesso
Non devi andare a intuito. Puoi controllare direttamente.
Guarda il sorgente della pagina: fai clic con il tasto destro sulla pagina, scegli "Visualizza sorgente pagina" e cerca il tuo titolo. Se il titolo non è nell'HTML grezzo, è generato da JavaScript. I crawler AI non lo vedranno.
Scarica la pagina con curl: nel terminale, esegui curl https://yoursite.com/your-page. Se i contenuti non ci sono, li ha generati JavaScript.
Controlla il tuo robots.txt: se impedisci ai crawler di eseguire JavaScript, vedranno solo l'HTML grezzo. Controlla il file robots.txt o le impostazioni di scansione del tuo sito.
Usa uno strumento di scansione: uno strumento di crawling SEO può scaricare le tue pagine come farebbe un crawler. Se i contenuti compaiono nel browser ma non nel crawler, il colpevole è JavaScript.
Cerca direttamente nei motori AI: cerca su ChatGPT, Perplexity o Claude frasi specifiche delle tue pagine. Se i tuoi contenuti non compaiono mai, hai un problema di visibilità legato a JavaScript.
Ottimizzazione per piattaforma, per i diversi crawler AI
Non tutti i crawler AI si comportano allo stesso modo. Hanno capacità di rendering diverse, frequenze di scansione diverse e preferenze di contenuto diverse.
ChatGPT (GPTBot): non esegue JavaScript. Scarica l'HTML grezzo. Usa l'indice di un motore di ricerca esterno per i contenuti in tempo reale. Frequenza: circa settimanale per i contenuti consolidati.
Claude (motore di ricerca esterno): non esegue JavaScript. Scarica l'HTML grezzo. Dà priorità a contenuti recenti e autorevoli. Frequenza: varia in base ai segnali di freschezza dei contenuti.
Perplexity: non esegue JavaScript. Scarica l'HTML grezzo. Dà molto peso alla freschezza. I contenuti più vecchi di 48 ore possono essere penalizzati. Frequenza: alta per gli argomenti di tendenza, bassa per i contenuti statici.
AI Overviews di Google: *esegue* JavaScript perché usa la stessa infrastruttura di rendering di Google Search. Ma ottimizza come se non lo facesse, così sarai più visibile agli altri motori di ricerca AI.
Il punto pratico: non ottimizzare per un solo crawler. Genera sul server i tuoi contenuti essenziali e sarai visibile a tutti.
Come ti aiuta WEMASY
Il creatore di siti di WEMASY produce HTML generato dal server per impostazione predefinita. Ogni pagina che crei è costruita con i contenuti già nell'HTML prima di arrivare al browser. Nessun rendering JavaScript. Le tue pagine sono subito visibili ai crawler AI.
Se stai valutando un creatore di siti e la visibilità nella ricerca AI conta per la tua attività, il rendering lato server dovrebbe essere un requisito, non un ripensamento. Scopri che cosa è incluso in ogni piano WEMASY.
Domande frequenti
Posso usare JavaScript per le funzioni interattive senza bloccare i crawler AI?
Sì. Genera sul server i contenuti principali (titolo, testo dell'articolo, dettagli del prodotto) e usa JavaScript per i miglioramenti (animazioni, validazione dei moduli, widget interattivi). Si chiama "progressive enhancement". I contenuti sono già nell'HTML e JavaScript aggiunge rifiniture sopra. I crawler AI vedono i contenuti principali. I browser ricevono l'esperienza interattiva completa. Con il creatore di siti di WEMASY puoi impostare tutto direttamente sul tuo sito.
Passare al rendering lato server rallenterà il mio sito?
Può succedere, se il tuo server è poco potente o le tue pagine sono complesse. Il rendering lato server moderno con livelli di cache (come la cache edge sulle piattaforme di hosting moderne) può essere persino più veloce del rendering lato client. Per la maggior parte dei siti la differenza è piccola. Se le prestazioni ti preoccupano, prova in un ambiente di staging prima di impegnarti.
Devo cambiare tutto il mio stack tecnologico?
Se usi un framework JavaScript con rendering lato client, passare a un framework SSR significa riscrivere i componenti perché funzionino con il rendering sul server. Non è una sostituzione rapida. Se il tuo sito è nuovo, scegli fin dall'inizio un framework pensato per l'SSR. Se hai un sito già avviato, pre-rendering o rendering dinamico possono essere più pratici nel breve periodo.
E se i crawler AI iniziassero a supportare l'esecuzione di JavaScript?
È possibile, ma non a breve. Eseguire JavaScript costa molto in termini di calcolo su larga scala. Finché il valore delle citazioni AI non giustifica il costo dell'infrastruttura, i crawler continueranno a scaricare l'HTML grezzo. Per ora, genera i contenuti sul server e riduci il rischio.
Il problema di rendering JavaScript del mio sito danneggia il mio posizionamento su Google?
No. Il crawler di Google esegue JavaScript, quindi il tuo posizionamento su Google non ne risente. Il problema riguarda i motori di ricerca AI come ChatGPT, Claude e Perplexity. Non eseguono JavaScript. Genera i contenuti sul server se vuoi visibilità nei risultati della ricerca AI, non perché lo richieda Google. È un problema separato dal SEO.
Anche i siti di notizie hanno lo stesso problema con JavaScript?
Sì, e spesso viene trascurato. Un sito di notizie costruito su un framework JavaScript che genera i contenuti lato client non ottiene nessuna citazione AI, anche se i contenuti sono pubblicati e indicizzati. Gli editori l'hanno scoperto per caso, quando articoli posizionati su Google News non ricevevano nessuna menzione su ChatGPT o Perplexity. Controlla il sorgente della pagina. Se il tuo titolo non c'è, correggi il problema.