JavaScript SEO: Come Google Renderizza JS e Dove Si Rompe

Cercate “JavaScript SEO” e i risultati si dividono in due generi antiquati: il panico degli anni 2018 (“Google renderizza davvero JavaScript?”) e l’entusiasmo per i framework (“Next.js è SEO-friendly, lanciatelo”). Entrambi non vedono dove il danno accade realmente oggi. Google renderizza JavaScript — questo dibattito è concluso. La vera domanda è più precisa e molto più costosa: la pagina che Google ha indicizzato è la stessa pagina che avete pubblicato? Contenuti solo client-side, errori di hydration e redirect JavaScript possono produrre siti che sembrano perfetti nel browser ma arrivano incompleti all’indice — e poiché la pagina “funziona,” nessuno se ne accorge finché il report del traffico non lo rivela.

Questa guida spiega come Google crawla e renderizza effettivamente JavaScript, quali trappole di indicizzazione sopravvivono all’era del rendering, e perché un redirect JavaScript fa perdere autorità diversamente da un 301 server-side. Il metodo utilizzato è repo-first: su un sito moderno, ogni uno di questi errori è visibile in pochi file sorgente — next.config, middleware.ts, i confini dei client component — prima ancora che qualsiasi crawler giri. Questo è lo strato JavaScript del nostro pilastro SEO agentico, e segue la stessa regola del technical SEO audit: nessuna correzione è completata finché la Search Console non mostra che il numero è cambiato.

Come Google crawla e renderizza effettivamente JavaScript

Google elabora una pagina JavaScript in fasi, e il divario tra di esse è dove vive il JavaScript SEO. Innanzitutto, Googlebot recupera l’HTML grezzo — qualsiasi cosa il server restituisca prima che uno script giri. I link e il contenuto trovati lì entrano immediatamente in elaborazione. Qualsiasi cosa che esista solo dopo l’esecuzione di JavaScript attende la seconda fase: la pagina entra in una coda di rendering, e quando le risorse lo permettono, il Web Rendering Service di Google la carica in un Chromium headless aggiornato — mantenuto al passo con Chrome stabile dal 2019 update di Googlebot di Google — esegue gli script e indicizza il risultato renderizzato.

Due proprietà di quella pipeline contano più della pipeline stessa. La coda di solito è veloce — Martin Splitt di Google ha stimato l’attesa mediana di rendering intorno a cinque secondi, con la coda lunga in minuti — quindi “Google impiega settimane per renderizzare JS” è per lo più folklore ormai morto. Ma il rendering è best-effort: script che errori, risorse bloccate dalle regole robots, chiamate API che timeout o richiedono credenziali, e contenuti che compaiono solo dopo un clic o uno scroll falliscono tutti silenziosamente. Googlebot non clicca pulsanti, non compila moduli e non scorre come farebbe un utente — la stessa documentazione JavaScript SEO di Google dice che il contenuto caricato sull’interazione non sarà indicizzato. Quello che renderizza è quello che viene indicizzato. Quello che fallisce renderizza come assenza, e l’assenza non produce messaggi di errore.

Le trappole di indicizzazione che sopravvivono all’era del rendering

Poiché il rendering funziona per lo più, i fallimenti che rimangono sono quelli silenziosi: pagine che passano ogni test visivo e comunque si indicizzano incomplete. Tre pattern rappresentano la maggior parte di questi, e tutti e tre sono diagnosticabili dal sorgente prima ancora che un crawler giri.

Contenuto solo client-side: la pagina che arriva vuota

Il pattern classico di single-page-app — servire una shell, recuperare il contenuto reale con JavaScript client-side dopo il caricamento — mette il vostro contenuto primario dalla parte sbagliata del divario di rendering. Se il fetch è veloce, pubblico e privo di errori, Google di solito lo ottiene. Ogni “se” in quella frase è una modalità di fallimento. Su un sito che abbiamo controllato, le pagine dei prodotti sembravano complete in ogni browser mentre il testo del corpo si caricava da una chiamata API che falliva nelle condizioni di Googlebot — la versione indicizzata era un template: navigazione, boilerplate, nessun prodotto. Il sito non è stato penalizzato. È stato semplicemente indicizzato come la cosa vuota che serviva. Nel repo questo è una diagnosi di un solo file: contenuto recuperato in un useEffect o dietro un confine ’use client’ è solo client-side; il contenuto recuperato in un server component è spedito nell’HTML e non entra mai nella coda di rendering.

Fallimenti di hydration: spedito due volte, indicizzato una volta

I framework moderni renderizzano lato server l’HTML, poi lo hydra — il JavaScript client prende il markup statico e lo rende interattivo. Quando il markup del server e il rendering client non concordano, i framework risolvono la discrepanza scartando la versione server e ri-renderizzando lato client — il che silenziosamente converte la vostra pagina server-rendered di nuovo in una client-rendered, divario di rendering e tutto. Peggiori sono gli errori adiacenti all’hydration che annullano interi sottorami di componenti: un’eccezione non gestita in un componente e tutto ciò che si trova sotto svanisce dal DOM renderizzato. La pagina comunque restituisce 200. Nulla in un report di crawl lo segnala. L’indicazione è nella Search Console: lo strumento URL Inspection della rendered HTML è la verità su cui Google ha costruito — fatene un diff rispetto al vostro DOM e i sottorami mancanti si annunciano da soli.

Link e metadata che esistono solo dopo il rendering

La discovery gira sull’HTML grezzo prima. La navigazione renderizzata puramente client-side, i gestori onClick che fungono da link, e la paginazione che muta lo stato invece di puntare a URL nascondono il vostro grafico di link interno dalla prima, fase di crawling più economica — e un link che Google non può vedere è autorità di link che non fluisce. Lo stesso vale per i metadata: titoli, canonicali e direttive robots impostati da JavaScript client-side arrivano tardi, e un canonicale o noindex che cambia tra l’HTML grezzo e renderizzato è un’ambiguità che avete dato a Google da risolvere. La regola repo-first è netta: veri elementi <a href> per ogni percorso di crawl, e metadata emessi server-side — in termini Next.js, generateMetadata, mai document.title.

Redirect JavaScript vs 301: la perdita lenta

I redirect sono dove il JavaScript SEO smette di essere sottile. Un 301 server avviene al livello HTTP: il crawler richiede l’URL vecchio, il server risponde “spostato permanentemente, ecco dove” nello stato della risposta, e Google consolida i segnali all’URL nuovo — nessun rendering, nessuna interpretazione, nessuna coda. Un redirect JavaScript — window.location in uno script — è invisibile a quel livello. L’URL vecchio restituisce 200 con una pagina allegata. Per scoprire anche che un redirect esiste, Google deve crawlare la pagina, metterla in coda, renderizzarla, eseguire lo script e inferire lo spostamento. La stessa documentazione di redirect di Google è inequivocabile sulla gerarchia: i redirect permanenti lato server sono il metodo preferito, e i redirect JavaScript sono l’ultimo ricorso, per quando nient’altro è disponibile per voi.

“Ultimo ricorso” sottovaluta il costo, perché Google non è più l’unico lettore che conta. Ogni consumatore dei vostri URL che non esegue JavaScript — scrapers social che costruiscono anteprime di link, la maggior parte degli strumenti SEO che mappano i vostri redirect, e, in modo decisivo, i crawler AI — vede un redirect JavaScript come una pagina 200 viva che non si è mai mossa. L’URL vecchio continua ad accumulare riferimenti. Il nuovo inizia da meno di quanto dovrebbe. Questa è la perdita: non una penalità, solo il consolidamento del segnale che arriva tardi per Google e mai per tutti gli altri.

Il repo rende questo audit quasi imbarazzantemente veloce. In una base di codice Next.js, i redirect legittimi vivono esattamente in tre posti — redirects() in next.config, NextResponse.redirect in middleware, e redirect() chiamate nel codice server — tutti i quali emettono codici di stato HTTP reali. Qualsiasi altra cosa è una perdita: grep i bundle client per assegnazioni window.location e chiamate router.replace che stanno al posto di movimenti che dovrebbero essere server-side, e avrete trovato in minuti quello che un audit di redirect basato su crawl ricostruisce nel corso di giorni.

Il punto cieco: i crawler AI non renderizzano

Ecco la piega dell’era del rendering che la maggior parte delle guide JavaScript SEO non ha ancora colto: i lettori più recenti del vostro sito si comportano come quelli più antichi. Un’analisi del 2024 del traffico dei crawler AI da parte di Vercel e MERJ ha scoperto che i principali crawler AI — GPTBot di OpenAI, ClaudeBot di Anthropic, PerplexityBot — recuperano HTML ma non eseguono JavaScript. Gemini è l’eccezione solo perché utilizza l’infrastruttura di rendering di Googlebot. Per tutti gli altri, il vostro sito è esattamente quello che il server restituisce: il contenuto solo client-side non esiste, i redirect JavaScript non sono mai accaduti, e una pagina renderizzata client è una shell vuota che indossa un 200.

Questo significa che il divario di rendering che avete chiuso per Google nel 2019 si è silenziosamente riapertura per i sistemi che decidono cosa viene citato nelle risposte AI. Se una quota crescente della vostra discovery gira attraverso motori che leggono HTML grezzo — lo spostamento che il nostro pilastro di AI search copre completamente — allora il server-rendering del vostro contenuto primario smette di essere una gentilezza di performance e diventa la differenza tra essere citate e essere invisibili. La regola pratica collassa in una frase: qualsiasi cosa vogliate che qualsiasi macchina legga deve essere nell’HTML che il server invia. Essere renderizzate è la posta in gioco per Google; essere leggibili senza rendering è il livello per tutto ciò che viene dopo Google.

Google ha impiegato cinque anni per imparare a eseguire il vostro JavaScript — e poi sono arrivati i crawler AI leggendo HTML grezzo come se fosse ancora il 2015. La pagina che vince entrambe le ere è quella che non ha mai avuto bisogno del rendering.

La checklist repo-first del JavaScript SEO

L’auditing JavaScript basato su crawl significa renderizzare il vostro sito pagina per pagina e fare ingegneria inversa delle cause dai sintomi. Repo-first lo inverte: il comportamento di rendering di ogni pagina è determinato da un piccolo insieme di file sorgente, e un difetto in un layout condiviso o config è un difetto su ogni pagina che tocca — conoscibile da una lettura di file. Ecco dove vive ogni domanda in un repository Next.js, e la metrica della Search Console che giudicherà la correzione.

Quindi confermare l’intento rispetto alla realtà una volta: URL Inspection nella Search Console mostra l’HTML renderizzato che Google ha effettivamente costruito — lo strumento JavaScript SEO più sottoutilizzato di tutti, e gratis. Se un blocco di contenuto è nel vostro DOM e manca dalla copia renderizzata di Google, avete una scoperta di divario di rendering con la prova allegata. La versione più ampia a cinque livelli di questo pass — crawl, indicizzazione, canonicali, schema, Core Web Vitals — è l’ technical SEO audit; questa checklist è lo strato che JavaScript mette specificamente a rischio.

Nessuna correzione è completa finché la Search Console non dice così

Le correzioni JavaScript SEO sono insolualmente facili da dichiarare vittoria, perché il sintomo visibile scompare istantaneamente: il contenuto è in view-source, il redirect restituisce 301, l’elemento di audit diventa verde. Nulla di quello è il risultato. Il risultato è Google re-crawling, re-rendering, e re-indicizzazione degli URL interessati — e l’unico posto dove diventa visibile è la Search Console, settimane dopo. Quindi ogni scoperta dalla checklist sopra è spedita con il suo contratto di prova allegato prima della correzione: l’impatto atteso, la metrica che la giudicherà (impressioni per contenuto che è entrato nell’indice, posizione e impressioni per redirect consolidati, CTR per metadata), e il target che conta come successo. Circa tre settimane dopo che la correzione atterra, la metrica è ri-letta e il verdetto registrato: confermato, regredito, o inconcludente.

Questa disciplina ripaga doppia sul lavoro JavaScript, perché le correzioni di divario di rendering sono tra le più verificabili di tutti i SEO: il contenuto che era assente dall’indice inizia a guadagnare impressioni o no. Una migrazione ri-spedita come 301 consolida nei dati di posizione o no. Esegui il loop onestamente e impari anche quali correzioni JavaScript sul vostro sito valgono il tempo di ingegneria — e quali erano igiene che non ha mai mosso un numero, il che è un risultato anche.

Se volete che la ricerca di metà sia eseguita sui vostri dati, il free SEO report collega la vostra Search Console e mostra i sintomi che questo articolo descrive — pagine mostrate molto meno dei loro fratelli, URL che dovrebbero essersi consolidati e non lo hanno fatto. E se preferite che l’intero loop funzionasse come sistema — file sorgente letti, correzioni spedite come pull request, verdetti letti da GSC tre settimane dopo — prenota una chiamata e vi mostreremo come appare sul vostro stack.