La condizione tecnica GEO da verificare prima della strategia di citazione
Se un fatto importante compare solo dopo l'esecuzione di JavaScript, un agente AI potrebbe non riceverlo mai.
Questo riguarda funzionalità del prodotto, conclusioni delle pagine di confronto, condizioni di prezzo, risposte della documentazione, dati dell'autore e prove che vorreste vedere citate da un sistema AI. Il fatto che una persona veda la pagina completa in Chrome non dimostra che un crawler, un estrattore di articoli o un agente browser abbia ricevuto lo stesso contenuto.
Un professionista SEO ha confrontato HTML grezzo e pagina renderizzata per diversi template. In articoli, tutorial, negozi, corsi, landing page e categorie, la maggior parte del contenuto visibile era già nell'HTML; solo una parte minore compariva dopo JavaScript. La lezione non è la percentuale esatta. La domanda è: la prima risposta HTML contiene già la risposta che volete far comprendere a un agente?
Nel GEO questa è una verifica di idoneità prima della citazione. Il sistema deve poter recuperare i fatti centrali della pagina prima di valutare le prove o sceglierla come fonte.
I vari percorsi di accesso hanno budget JavaScript diversi. Il fetch grezzo e l'estrazione degli articoli dipendono di solito dalla sola risposta HTML.
Il rendering di Google non è una promessa per ogni agente
È vero che Google può renderizzare JavaScript. Ma trasformare questo fatto nell'assunzione che ogni prodotto di ricerca AI e ogni agente vedrà la pagina finale del browser è rischioso.
Lo stesso URL può arrivare attraverso più percorsi:
| Percorso di accesso | Cosa riceve il sistema | Dipendenza da JavaScript |
|---|---|---|
| Fetch HTTP grezzo | La risposta HTML iniziale | Non esegue |
| Reader o estrattore di articoli | Testo selezionato dall'HTML | Di solito non esegue |
| Automazione del browser | DOM renderizzato | Può eseguire, con limiti di timeout e policy |
| Pipeline di indicizzazione | Fetch, coda e possibile rendering | Dipende dalla piattaforma |
| Agente con tool | Output del tool web fetch scelto | Spesso vicino al fetch grezzo |
La capacità di rendering di Google non è una garanzia trasferibile. Altri answer engine, sistemi di retrieval interni, agenti di navigazione e strumenti di estrazione web possono prendere solo HTML o fermarsi prima del caricamento di dati client lenti. Basare l'architettura del sito sulla capacità di una piattaforma è una scommessa inutile.
La regola sicura è semplice: i fatti pubblici importanti per la scoperta e la citazione devono essere leggibili già nella prima risposta.
Controllate dove compare il fatto, non il framework in uso
SSR contro CSR non è un voto GEO. Un sito React, Vue o Next.js può essere adatto agli agenti; un sito tradizionale renderizzato dal server può nascondere fatti importanti dietro una chiamata API client.
Controllate il livello in cui ogni blocco importante diventa disponibile.
| Livello di contenuto | Esempio tipico | Rischio GEO |
|---|---|---|
| HTML iniziale | Titolo, testo, specifiche, FAQ, autore, data | Basso |
| HTML ottenuto dal server | Prezzo corrente o disponibilità regionale | Basso o medio |
| Request API nel client | Vantaggi del prodotto, tabella di confronto, corpo della documentazione | Alto |
| Dopo l'interazione utente | Tab, accordion, filtri, risultati di scroll infinito | Alto |
| Dopo il login | Dashboard o knowledge base privata | Non aspettatevi una citazione pubblica |
Un fatto che volete venga ripetuto dall'AI in una risposta pubblica non dovrebbe dipendere da un clic, da una request client riuscita o da un'attività JavaScript lunga. Mantenete l'interazione dove aggiunge valore, ma anticipate il livello esplicativo.
Errori comuni sono pagine prodotto che restituiscono solo una schermata di caricamento, confronti la cui tabella compare dopo hydration, documentazione che carica il corpo con routing client, categorie che dipendono solo dallo scroll infinito e moduli visivi in cui la conclusione esiste solo in un'immagine o Canvas.
Una pagina renderizzata può avere un aspetto eccellente e rivelare comunque troppo poco significato nella prima risposta HTML.
Confrontate due stati della pagina invece di indovinare
Non chiedete se il sito usa React. Salvate due versioni dello stesso URL:
- L'HTML grezzo ottenuto senza eseguire JavaScript.
- Il testo
mainrenderizzato dopo aver aperto la pagina in un browser e atteso il contenuto principale.
Potete iniziare con un fetch semplice:
curl -sL "https://example.com/product" -o raw.html
Confrontate blocchi semantici, non header, banner Cookie e footer:
- H1 e risposta breve
- Primo paragrafo esplicativo
- Fatti e limiti del prodotto
- Tabelle di confronto
- Risposte FAQ
- Autore e data di aggiornamento
- Link interni e URL canonical
Non usate networkidle come unica condizione di disponibilità del browser. Script analitici, widget chat e connessioni lunghe possono mantenere la pagina occupata per sempre. È meglio attendere il selettore del contenuto principale o il completamento della fonte dati che fornisce i fatti critici.
Il confronto può diventare una metrica di release:
esposizione del contenuto centrale = blocchi importanti presenti nell'HTML grezzo / blocchi importanti richiesti dalla pagina
L'obiettivo non è inserire ogni pixel nell'HTML. È rendere le prove necessarie per comprendere la pagina indipendenti dal successo del runtime client.
Correggete la consegna dei contenuti prima di riscrivere il front end
La maggior parte dei team non deve riscrivere tutto il sito. Spostate le informazioni pubbliche stabili nella prima risposta e continuate a usare JavaScript per filtri, preferenze salvate, mappe, animazioni e personalizzazione.
| Situazione | Modalità di consegna più adatta |
|---|---|
| Articoli, tutorial e glossari stabili | Generazione statica o prerender durante il build |
| Prezzi, stock o dettagli regionali che cambiano | Server rendering con cache e invalidazione esplicita |
| Pagina interattiva con spiegazione stabile | Renderizzate spiegazione, fatti e FAQ sul server; idratate l'interazione nel client |
| Documentazione pubblica in una grande app | Prerender delle route pubbliche e risposta centrale non dipendente dal login |
| Dipendenza da più API interne | Aggregate i dati critici nel server o in un livello BFF condiviso da HTML e applicazione |
JSON-LD è utile, ma non sostituisce contenuti di pagina leggibili. I dati strutturati devono descrivere fatti che visitatori ed estrattori trovano anche nel documento.
Piano di due settimane per il team GEO
Giorni 1-2: elencate i template che influenzano scoperta organica, citazioni AI, supporto alle vendite o customer support. Articoli, pagine prodotto, documentazione, confronti e categorie sono spesso sufficienti.
Giorni 3-5: prendete URL campione per ogni template. Salvate HTML grezzo e contenuto renderizzato. Segnalate H1, spiegazioni, fatti prodotto, FAQ e link interni mancanti.
Giorni 6-9: correggete prima le pagine più preziose e stabili. Spostate definizioni, fatti, conclusioni dei confronti e FAQ nel server o nell'output di build.
Giorni 10-14: ripetete gli stessi test e aggiungete un gate di release. Un template non deve essere pubblicato se l'HTML iniziale manca di H1, risposta principale, fatti critici o link canonical.
Questo non garantisce una citazione da ogni prodotto AI. Elimina però un errore evitabile: pubblicare informazioni pubbliche che un potenziale agente non riesce a leggere in modo affidabile.
Il punto di vista di Auspia
Le conversazioni GEO iniziano spesso da menzioni del brand, qualità delle fonti, chiarezza delle entità e struttura della risposta. Tutto questo presuppone che il sistema abbia prima ottenuto la pagina.
JavaScript non è il problema in sé. Il problema è trattare la spiegazione pubblica come effetto collaterale del runtime client. Lasciate a HTML la responsabilità dei contenuti e a JavaScript quella dell'esperienza. Questa divisione migliora anche test, SEO tecnico e accessibilità per gli agenti.
FAQ
Se Google renderizza JavaScript, serve ancora un audit dell'HTML grezzo?
Sì. La capacità di Google non significa che altri crawler, reader e agenti seguano lo stesso percorso. Il controllo dell'HTML grezzo rivela anche ritardi di rendering e fallimenti nelle request client.
SSR è sempre migliore di CSR per GEO?
No. Generazione statica, server rendering e prerender possono tutti funzionare. Per elementi molto interattivi potete mantenere il rendering client. Il criterio è che i fatti essenziali della pagina pubblica siano leggibili nella risposta HTML iniziale.
Bisogna evitare JavaScript in tutta la pagina?
No. Usatelo per filtri, animazioni, mappe, impostazioni salvate, personalizzazione ed esperienze dopo il login. Date priorità ai contenuti che spiegano il tema della pagina e forniscono fatti citabili.
llms.txt risolve i contenuti che compaiono solo dopo JavaScript?
No. Anche se un sistema legge llms.txt, non ottiene automaticamente l'intero articolo o i dati dell'API client. La pagina pubblica deve continuare a rendere accessibile il proprio contenuto centrale.
Nota sulla fonte
Questo articolo è ispirato a un post di Adrian Skowron che confronta i contenuti visibili in SSR e CSR . Il grafico nel post riflette le misurazioni dei template dell'autore, non un benchmark per l'intero settore.
Autore: Julian Mercer, professionista di SEO tecnico con 14 anni di esperienza in Auspia. Julian scrive di crawling, rendering, dati strutturati e della base tecnica che permette a ricerca e AI di capire i contenuti.
