Google: il rendering JavaScript rischia contenuti ‘non disponibili’ per l’AI.

Questo può far sì che il motore di ricerca e le sue nuove AI Overviews vedano solo un messaggio di «non disponibile», ignorando le informazioni essenziali caricate successivamente tramite JavaScript.

Immaginate di cercare su Google l’orario di apertura di un negozio. La pagina web, però, invece di mostrarvelo subito, vi presenta un messaggio: «Non disponibile». Dopo qualche secondo, un piccolo script JavaScript si attiva e magicamente sostituisce quel testo con l’orario corretto.

Per voi utenti, è solo un attimo di attesa. Per Google, e soprattutto per il suo motore di ricerca potenziato dall’intelligenza artificiale, potrebbe essere un problema che rende quella informazione invisibile.

È proprio su questo rischio tecnico, apparentemente di nicchia, che John Mueller, uno dei volti più noti del team di Google Search, ha acceso i riflettori pochi giorni fa, il 13 febbraio 2026.

Il suo avvertimento, rivolto a sviluppatori e webmaster, è chiaro: fare troppo affidamento su JavaScript per mostrare contenuti dopo uno stato iniziale di «non disponibile» può compromettere seriamente l’indicizzazione, generare snippet errati nei risultati di ricerca e causare problemi persino nelle nuove AI Overviews, le risposte sintetiche generate dall’IA di Google.

Mueller, che ricopre il ruolo di Search Advocate, ha risposto a un webmaster che lamentava come l’AI di Google segnalasse erroneamente il suo sito come offline. La causa? Il sito utilizzava JavaScript per sostituire un testo segnaposto «non disponibile» con il contenuto vero e proprio.

Se lo script non viene eseguito correttamente o non in tempo da Googlebot, il crawler che scandaglia il web, l’unica cosa che Google vede e indicizza è quel messaggio di indisponibilità.

La raccomandazione di Mueller è netta: «Avere le informazioni corrette nell’HTML di base», in modo che siano immediatamente accessibili a tutti gli utenti e ai motori di ricerca, senza dipendere dall’esecuzione di codice JavaScript.

Se usi JavaScript per cambiare il testo da “non disponibile” a “disponibile”, stai creando una situazione in cui Google potrebbe indicizzare la versione sbagliata.

— John Mueller, Search Advocate di Google

Questa non è una novità assoluta, ma il timing e il contesto la rendono significativa.

L’avvertimento arriva in un momento in cui Google sta spingendo con forza sull’integrazione dell’intelligenza artificiale in Search, con le AI Overviews che sintetizzano informazioni attingendo dai migliori risultati web.

Se il sistema di indicizzazione tradizionale può già inciampare su questi contenuti «nascosti», il rischio si amplifica per i modelli di IA, che devono estrarre e riassumere informazioni in modo affidabile.

La posta in gioco per i siti web è alta: essere mal interpretati da Google oggi significa non solo perdere posizioni nel ranking classico, ma anche essere esclusi o citati in modo errato nelle risposte generate dall’IA, che stanno diventando il primo punto di contatto per milioni di ricerche.

Perché Google fatica a «vedere» il JavaScript

Il rapporto tra Google e JavaScript è una storia di amore e (molto) complicazione. Per anni, il motore di ricerca leggeva le pagine web come un libro statico, limitandosi all’HTML iniziale. Con l’esplosione delle applicazioni web dinamiche, Google ha dovuto evolversi.

Oggi Googlebot utilizza una versione di Chrome «senza testa» (headless) per eseguire JavaScript e renderizzare le pagine più o meno come farebbe un browser normale. Tuttavia, questo processo non è né istantaneo né infallibile. È costoso in termini di risorse computazionali e soggetto a code di elaborazione.

La documentazione ufficiale di Google è chiara: Google può eseguire JavaScript, ma non è garantito che ci riesca sempre con successo. Il crawler prima scarica l’HTML, poi mette la pagina in una coda di rendering. Solo in un secondo momento, se le risorse lo permettono, esegue gli script e indicizza il contenuto finale.

Questo crea una finestra di vulnerabilità.

Se il contenuto cruciale – un prezzo, una descrizione, un orario – è nascosto dietro a uno script che parte da un messaggio tipo «caricamento in corso» o «non disponibile», Google potrebbe fermarsi lì. Potrebbe indicizzare quel placeholder, oppure, se lo script fallisce o viene bloccato, non vedere mai il contenuto vero.

Il problema si aggrava con tecniche come il lazy loading, dove immagini o testi vengono caricati solo quando l’utente scorre la pagina. Se non implementate con attenzione, anche queste possono sfuggire al crawler.

L’avvertimento di Mueller punta il dito proprio su questa pratica rischiosa: usare JavaScript non per arricchire l’esperienza, ma per svelare informazioni fondamentali che dovrebbero invece essere presenti fin dall’inizio.

È come consegnare a Google una scatola vuota con l’istruzione «apri e trova il regalo»: a volte la apre, a volte no, e spesso indicizza la scatola vuota.

L’impatto sull’ai Search: quando l’intelligenza artificiale resta a corto di dati

L’avvento delle AI Overviews e della Ricerca con IA di Google cambia radicalmente le conseguenze di questi problemi tecnici. Questi sistemi non si limitano a elencare link; usano un modello Gemini personalizzato per sintetizzare risposte attingendo dal vasto indice di Google.

Ma quell’indice è lo stesso, con tutte le sue imperfezioni. Se una pagina di un ristorante mostra «Menu non disponibile» nell’HTML che Google ha catturato, l’AI Overview potrebbe riportare proprio quella frase, o peggio, dedurre che il menu non esista.

La sfida per i modelli di IA è duplice. Primo, devono fare affidamento su un processo di rendering che, come abbiamo visto, è asincrono e non deterministico. Secondo, anche quando il rendering avviene, i crawler specializzati per l’IA potrebbero adottare strategie conservative per risparmiare risorse, alternando fasi in cui eseguono JavaScript ad altre in cui si accontentano dell’HTML grezzo.

Il risultato è una potenziale discrepanza tra ciò che vede l’utente umano e ciò che «vede» l’IA di Google, con il rischio di generare risposte incomplete o inaccurate.

Per i publisher, l’implicazione è diretta: un contenuto ben scritto ma mal implementato tecnicamente rischia di essere tagliato fuori dalla più importante innovazione di Google degli ultimi anni.

Mentre l’azienda di Mountain View dichiara che le AI Overviews sono progettate per evidenziare il web e includere link prominenti, per farlo devono prima poter accedere a informazioni corrette e complete. Un sito che affida i suoi dati più preziosi a JavaScript diventa, in questo nuovo ecosistema, un fornitore inaffidabile.

La soluzione è un ritorno alle (solide) basi?

La risposta di Google a questa complessità non è chiedere agli sviluppatori di abbandonare JavaScript, ma di usarlo in modo consapevole e resiliente. Le linee guida promuovono concetti come il server-side rendering (SSR) o il dynamic rendering.

In pratica, si tratta di preparare una versione «pronta all’uso» dell’HTML completo già sul server, da servire specificamente a Googlebot, mentre gli utenti normali continuano a vedere l’applicazione JavaScript interattiva. È un workaround che garantisce l’accessibilità.

Strumenti come l’URL Inspection Tool in Google Search Console diventano fondamentali. Permettono di vedere esattamente cosa «vede» Googlebot dopo il rendering, aiutando a diagnosticare problemi.

La raccomandazione d’oro, però, rimane quella più semplice e antica: il contenuto critico, quello per cui le persone fanno una ricerca, deve essere presente nell’HTML di base. Testi, dati, informazioni essenziali non dovrebbero mai dipendere dall’esecuzione di uno script per essere visibili.

Questa tensione tra innovazione tecnologica (JavaScript complesso, app single-page) e i bisogni fondamentali dei motori di ricerca non è nuova.

Quello che cambia oggi è l’entità della posta in gioco. Con l’IA che si interpone sempre più tra l’utente e il sito web di destinazione, essere correttamente interpretati da Google non è più solo una questione di SEO, ma di sopravvivenza informativa.

L’avvertimento di John Mueller suona come un promemoria: nella corsa a costruire esperienze web sempre più fluide e dinamiche, non possiamo permetterci di dimenticare il primo, fondamentale, linguaggio del web: un HTML solido e significativo.

In un futuro dominato dalle risposte sintetiche dell’IA, la differenza tra «non disponibile» e «ecco qui» potrebbe dipendere proprio da questo.