Una pagina può apparire completa nel browser e risultare incompleta quando un assistente AI prova a leggerla. Per un’azienda il rischio da verificare è concreto: descrizione del servizio, caratteristiche del prodotto o condizioni commerciali potrebbero non arrivare al sistema che sta cercando informazioni. La schermata del sito, da sola, non risponde a questa domanda.
Il tema torna da un’analisi di Glenn Gabe pubblicata il 19 ottobre 2026, che recuperiamo per il suo interesse operativo. È un’osservazione sul comportamento di alcuni strumenti, non l’annuncio di una nuova regola SEO né una misura esaustiva delle capacità di tutti gli assistenti.
Che cosa mostra il test di Glenn Gabe
Nella sua analisi sui contenuti JavaScript, Gabe chiede a ChatGPT, Claude, Perplexity, Gemini e Copilot di restituire il primo e l’ultimo paragrafo di pagine con contenuti dinamici. Nei tre esempi illustrati, i primi tre strumenti non recuperano correttamente il corpo principale; Gemini restituisce i contenuti descritti dall’autore, mentre Copilot riesce nei primi due casi e fallisce nel terzo.
Questi risultati documentano le prove raccontate da Gabe. Non dimostrano che ogni versione di quelle piattaforme abbia sempre lo stesso comportamento. Il successo di una risposta, inoltre, non permette da solo di stabilire se il sistema abbia eseguito JavaScript o recuperato informazioni da un indice o da un’altra copia della pagina.
Cinque passaggi che non vanno confusi
Per diagnosticare il problema conviene separare le fasi del percorso. La distinzione seguente è un modello di lavoro: serve a formulare domande verificabili, senza presumere che ogni piattaforma utilizzi la stessa architettura.
| Passaggio | Domanda da verificare | Che cosa non dimostra da solo |
|---|---|---|
| Risposta del server | Quale HTML arriva alla richiesta per quell’URL? | Che il contenuto venga renderizzato o selezionato |
| Rendering nel browser | Che cosa compare dopo l’esecuzione degli script? | Che un altro lettore esegua gli stessi script |
| Estrazione del contenuto | Quale testo recupera lo strumento usato nella prova? | Che quel testo sia presente in un indice di ricerca |
| Indicizzazione | Quale versione è disponibile nel sistema di ricerca verificato? | Che venga scelta per una determinata risposta |
| Citazione nella risposta | L’URL è effettivamente utilizzato come fonte? | Che l’assenza del link dipenda da un errore tecnico |
Un assistente che risponde “posso leggere la pagina” non chiude la verifica. Deve fornire un contenuto riscontrabile. Se restituisce il menu, il banner cookie o un messaggio di errore, ha recuperato qualcosa, ma non necessariamente l’informazione richiesta.
La prima verifica: confrontare HTML e pagina renderizzata
Si può iniziare con un piccolo campione di URL rappresentativi: pagina servizio, scheda prodotto, categoria, articolo e una pagina particolarmente interattiva. La selezione deve includere le risorse importanti per il business, oltre ai diversi template del sito.
Per ogni URL si definiscono prima gli elementi attesi. In una scheda prodotto potrebbero essere nome, descrizione, caratteristiche e condizioni; in una pagina di servizio, destinatari, attività incluse e contatti. L’elenco impedisce di dichiarare “tutto presente” solo perché è stato trovato il titolo.
Per acquisire una risposta HTTP senza eseguire JavaScript, uno sviluppatore può usare una richiesta GET come questa, sostituendo l’indirizzo di esempio:
curl --location --compressed --max-time 30 \
--dump-header intestazioni.txt \
--output risposta.html \
'https://example.com/pagina-da-verificare/'Il comando salva intestazioni e corpo della risposta; non riproduce un browser autenticato e non prova come si comporti un crawler reale. Il risultato va confrontato con la pagina nel browser, controllando URL finale, lingua, stato di accesso e contenuti caricati successivamente.
Occorre cercare testo significativo negli elementi della pagina, non limitarsi a trovare una parola dentro uno script o nei dati di configurazione dell’applicazione. Il nome di un prodotto presente in un oggetto JavaScript non equivale necessariamente a una descrizione già disponibile come contenuto della pagina.
Ripetere la prova nell’assistente con un risultato verificabile
Il test successivo richiede di annotare piattaforma, modello indicato nell’interfaccia, disponibilità della ricerca web, data, URL e istruzione usata. Se la versione del modello non è visibile, si registra questo limite invece di inventarla.
Una richiesta utile può essere: “Apri questo URL e indica quali dei seguenti dati trovi nella pagina, riportando il passaggio che li contiene. Se non riesci ad accedere, dichiaralo”. L’elenco deve riguardare informazioni pubbliche, già note e facili da confrontare. Per esempio, una caratteristica tecnica e una condizione del servizio.
Il testo restituito va confrontato con la pagina corrente. Una risposta plausibile potrebbe essere ricostruita da altre fonti; un’informazione vecchia potrebbe provenire da una versione precedente. Il test permette di documentare un comportamento osservato, non di certificare tutti i processi interni della piattaforma.
La prova va ripetuta dopo una correzione e, quando serve, in un altro momento. Un singolo fallimento non basta a distinguere un problema persistente da un errore temporaneo di accesso o dello strumento.
Se manca il contenuto, controllare anche accessi e infrastruttura
Prima di intervenire sul framework conviene escludere altre spiegazioni. Redirect, autenticazione, risposte diverse per paese, protezioni del sito, errori delle API o tempi di caricamento possono cambiare ciò che uno strumento riesce a ottenere. Il messaggio dell’assistente è un indizio da confrontare con evidenze tecniche.
Il team può verificare log del server e della CDN attorno all’orario della prova, se disponibili. Bisogna distinguere una richiesta effettivamente identificata da un’ipotesi basata soltanto sullo user-agent: una stringa dichiarata non prova l’identità del richiedente. Anche l’assenza di una richiesta nei log di origine va interpretata considerando cache e visibilità dei registri.
Se l’HTML iniziale contiene il testo atteso ma lo strumento non lo restituisce, la sola mancanza di rendering JavaScript non spiega quel risultato. Se invece manca già il corpo principale e il browser lo compone dopo una chiamata successiva, si è individuata una dipendenza da esaminare, non ancora una prova della causa esclusiva del fallimento.
Quali correzioni valutare
La documentazione JavaScript di Google Search spiega che Google esegue JavaScript, ma descrive un percorso di scansione, rendering e indicizzazione. Raccomanda di considerare rendering sul server o prerendering anche perché non tutti i bot eseguono JavaScript. Questo non autorizza a estendere il comportamento di Google a qualsiasi assistente AI.
Per un sito aziendale si può valutare di includere nell’HTML iniziale il contenuto essenziale, lasciando a JavaScript configuratori, filtri e altre interazioni. La soluzione dipende dal progetto: generazione statica, rendering sul server o un cambiamento circoscritto del template possono avere costi e vincoli differenti.
Il contenuto esposto deve restare coerente con ciò che legge il cliente. Se il prezzo viene aggiornato, anche la versione servita inizialmente deve riflettere quella modifica. Una correzione che migliora l’accessibilità del testo ma introduce dati commerciali superati crea un altro problema.
Per Google va verificato separatamente l’esito in Search Console. La guida sulle funzionalità AI della Ricerca richiama l’importanza di contenuti testuali accessibili e delle basi SEO; non promette che una modifica tecnica produca una citazione.
Che cosa consegnare a sviluppatori e responsabili marketing
Una segnalazione utile contiene URL, contenuto atteso, risposta HTTP acquisita, confronto con la pagina renderizzata e risultato della prova nell’assistente. Deve indicare ciò che è stato osservato e ciò che resta da verificare. “Il sito non piace all’AI” non fornisce un problema riproducibile.
La priorità aziendale può essere assegnata considerando importanza della pagina, quantità di informazione mancante e diffusione del template coinvolto. Correggere una dipendenza comune a molte schede strategiche può avere più valore di un intervento su una pagina marginale.
Il criterio di accettazione della modifica deve essere definito prima: i dati essenziali sono presenti nella risposta prevista, corrispondono alla pagina visibile e vengono aggiornati correttamente. La successiva visibilità nelle risposte AI resta un risultato da osservare separatamente, senza trasformarlo in una garanzia contrattuale.
Domande frequenti
Basta aprire il sito nel browser per verificare che un assistente legga i contenuti?
No. Il browser mostra una pagina in determinate condizioni. Per il test serve confrontare quel risultato con la risposta del server e con il contenuto effettivamente restituito dallo strumento utilizzato.
Un errore di lettura dimostra che il problema è JavaScript?
Non da solo. Occorre verificare contenuto iniziale, redirect, accessi, protezioni ed eventuali errori di caricamento. La causa va sostenuta da un confronto tecnico riproducibile.
Serve rifare tutto il sito?
La decisione richiede una diagnosi. Può essere sufficiente intervenire sui template e sui contenuti essenziali; una ricostruzione completa va giustificata da esigenze e costi del progetto.
La correzione garantisce citazioni da parte delle piattaforme AI?
No. Il controllo tecnico verifica la disponibilità delle informazioni. La scelta di utilizzarle o citarle è un passaggio diverso e va misurata separatamente.