Dynamic rendering: cosa risolve su un sito JavaScript (e cosa no)
Di Toy Wen Da, Co-founder · Aggiornato · 7 min di lettura
Tradotto dall'originale in inglese. Leggilo in inglese
Il dynamic rendering significa che il tuo server controlla se chi visita la pagina è un browser o un bot dei motori di ricerca, poi invia ai bot una versione HTML statica e prerenderizzata della pagina, mentre le persone ricevono la normale esperienza JavaScript. Risolve i problemi dei siti in cui Googlebot non riesce a leggere contenuti che compaiono solo dopo l'esecuzione degli script, ma non risolve ogni problema di indicizzazione.
Prima di toccare qualsiasi codice del server, controlla cosa vede Googlebot sulla pagina in questione. Il Googlebot Simulator gratuito recupera un URL come farebbe il crawler di Google e ti mostra l'HTML renderizzato: in un minuto capisci se i tuoi contenuti JavaScript mancano in ciò che il bot riceve.
Come funziona
Riconoscere chi visita
Il tuo server, o un livello CDN davanti ad esso, controlla l'header User-Agent a ogni richiesta. Quando l'header corrisponde a un crawler noto come Googlebot o Bingbot, o sempre più spesso a un crawler di intelligenza artificiale, la richiesta viene instradata in modo diverso rispetto a quella inviata da un normale browser.
Servire due versioni della stessa pagina
Le persone continuano a ricevere la tua app React, Vue o Angular con tutta la sua interattività. I bot ricevono uno snapshot HTML prerenderizzato, generato da uno strumento basato su browser headless come Puppeteer o Rendertron, oppure da un servizio di terze parti come Prerender.io; poiché lo snapshot è statico, per vedere i contenuti non serve eseguire alcuno script.
Perché i siti ne hanno bisogno
Googlebot è in grado di eseguire JavaScript, ma il rendering richiede molte risorse e avviene in differita, quindi spesso le pagine vengono sottoposte a crawling una volta e renderizzate di nuovo più tardi, il che può bloccare l'indicizzazione. La maggior parte dei motori di risposta basati su IA non esegue affatto JavaScript, quindi una pagina che dipende dal rendering lato client può risultare invisibile per loro fin dall'inizio. Una pagina che non viene mai indicizzata non ottiene visibilità e nemmeno un click-through rate, figuriamoci uno buono.
Risolverlo dentro il tuo sito, passo dopo passo
- Verifica che ci sia davvero una differenza: recupera la pagina come farebbe un bot e confrontala con ciò che carica un normale browser. Se i contenuti coincidono, non ti serve nulla di tutto questo.
- Stabilisci se il problema riguarda un solo template, una sezione del sito o tutto, perché da questo ambito dipende quanto lavoro di infrastruttura ti stai assumendo.
- Aggiungi il riconoscimento dello user agent a livello di server o CDN, per esempio con un Cloudflare Worker o una regola Nginx, che controlli le richieste in arrivo rispetto a un elenco di bot aggiornato.
- Instrada il traffico dei bot verso un servizio di prerendering che generi HTML statico per ogni URL e lo metta in cache, così non devi rifare il rendering a ogni visita di un bot.
- Mantieni i contenuti equivalenti: la versione prerenderizzata deve corrispondere a ciò che una persona vede alla fine, con lo stesso testo, gli stessi link e gli stessi dati strutturati.
- Ripeti il test dopo il lancio e di nuovo dopo ogni deploy del front-end, perché una modifica all'interfaccia può rompere in silenzio ciò che il servizio di prerendering cattura.
- Monitora la configurazione in modo continuativo. Se il servizio di rendering va offline, i bot possono iniziare a ricevere pagine vuote o errori, e questo può causare una rapida deindicizzazione.
Quando bastano i tuoi strumenti e quando no
Controllare una singola pagina è un lavoro diverso dal sistemare il rendering di un intero sito.
| Situazione | Cosa stai controllando | Strumento giusto | La via gratuita basta? |
|---|---|---|---|
| Un URL ti sembra a posto ma non compare nell'indice di Google | Cosa vede Googlebot su quella pagina | Googlebot Simulator | Sì, conferma o esclude una differenza di rendering in pochi minuti |
| Intero sito costruito con React/Vue/Angular senza rendering lato server | Scansionabilità dell'intero sito | Un crawl tecnico completo più un audit del rendering | No, è una modifica all'infrastruttura, non un controllo su una pagina |
| Il layout mobile di una pagina sembra fuori posto insieme al problema di indicizzazione | Rendering mobile, viewport, usabilità | Test di compatibilità mobile gratuito | Sì, per diagnosticare la parte specifica del mobile |
| Le pagine erano indicizzate correttamente, poi sono sparite dopo un restyling | Regressione ricorrente, non un caso isolato | Monitoraggio continuo più una revisione della configurazione di prerendering | No, un singolo controllo non individua un problema che si ripresenta a ogni deploy |
Un controllo una tantum su un singolo URL è esattamente ciò per cui sono pensati gli strumenti gratuiti, mentre uno schema ricorrente su tutto il sito indica una soluzione infrastrutturale, che di solito coinvolge uno sviluppatore e un servizio di prerendering.
Confronto con le alternative
| Approccio | Come funziona | Adatto a | Carico di manutenzione |
|---|---|---|---|
| Dynamic rendering | Serve HTML statico ai bot, l'app JS alle persone | Siti ricchi di JS con problemi di crawl budget o di visibilità nell'IA che non possono ancora fare una riscrittura completa | Alto, c'è una pipeline di rendering separata da mantenere |
| Server-Side Rendering (SSR) | Il server genera l'HTML a ogni richiesta, per tutti | Nuovi sviluppi o siti con le risorse per ricostruire il front-end | Medio, un unico percorso di rendering per tutti |
| Static Site Generation (SSG) | L'HTML viene creato in anticipo al momento del deploy | Contenuti che non cambiano a ogni richiesta, come blog o pagine di marketing | Basso, si ricostruisce quando cambia il contenuto |
| Client-side rendering (nessuna soluzione) | Il browser costruisce la pagina da JavaScript, i bot ricevono lo stesso | Strumenti interni, non pagine pubbliche pensate per la ricerca | Poco impegno, alto rischio per la ricerca |
La guida di Google inquadra la tecnica come un ripiego e non come il punto di arrivo, e SSR o SSG sono le soluzioni più durature una volta che puoi permetterti la ricostruzione.
Si considera cloaking?
No, finché lo fai in buona fede. La documentazione di Google Search Central afferma che Googlebot in genere non lo tratta come cloaking, a patto che i contenuti renderizzati serviti ai bot siano equivalenti a quelli che le persone alla fine vedono. La violazione non sta nell'esistenza di due versioni, ma nel mostrare a bot e persone contenuti davvero diversi, per esempio una pagina piena di parole chiave sulle scarpe da corsa per i crawler mentre i visitatori vedono una pagina su tutt'altro. Mantieni la sostanza uguale in entrambe le versioni e sei dalla parte giusta della regola.
Errori comuni
- Considerarlo permanente, quando si limita a mascherare un problema di scansionabilità e non elimina la necessità, prima o poi, di un'architettura più facile da scansionare.
- Lasciare che il servizio di prerendering diventi obsoleto, così i bot vedono una versione superata o rotta della pagina ogni volta che non coglie una modifica al front-end.
- Affidarsi a un elenco di bot con lacune, perché il riconoscimento dello user agent funziona solo per i bot che hai inserito, e un nuovo crawler di IA che le tue regole non riconoscono riceve la versione JavaScript grezza, che probabilmente non riesce a leggere.
- Saltare i nuovi test dopo i deploy, anche se una release del front-end che nessuno ha ricontrollato rispetto alla versione destinata ai bot è la ragione più comune per cui una configurazione come questa si rompe in silenzio.
- Applicarlo a un sito che non ne ha bisogno, perché i siti piccoli e per lo più statici raramente hanno un problema di rendering che giustifichi tanta infrastruttura.
Domande frequenti
Il dynamic rendering danneggia il mio posizionamento?
Non di per sé. Il rischio sta in una versione configurata male che serve pagine obsolete o errori e si discosta da ciò che vedono le persone.
Il dynamic rendering è la stessa cosa del cloaking?
No. Il cloaking significa servire a bot e persone contenuti sostanzialmente diversi, mentre questa tecnica serve lo stesso contenuto in un formato diverso, cosa che i motori di ricerca consentono esplicitamente.
Come faccio a sapere se il mio sito ha davvero bisogno del dynamic rendering?
Recupera una pagina come Googlebot e confrontala con la versione del browser. Se i tuoi contenuti principali e i link mancano nella vista del bot, hai il tuo segnale.
Qual è l'alternativa a lungo termine al dynamic rendering?
Il server-side rendering o la static site generation, che servono lo stesso HTML renderizzato a tutti invece di mantenere due percorsi separati.
I siti delle piccole imprese possono ignorare del tutto il dynamic rendering?
Di solito sì. Conta soprattutto per siti grandi, ricchi di JavaScript, con contenuti che cambiano spesso o vincoli di crawl budget, non per un tipico sito piccolo costruito su template di pagina standard.
Controlla la tua pagina prima di costruire qualsiasi cosa
Non iniziare a costruire una pipeline di prerendering a sensazione. Recupera la pagina in questione, guarda cosa riceve Googlebot e investi nell'infrastruttura solo se c'è una vera differenza tra ciò che vedono i bot e ciò che vedono le persone. Se vuoi un secondo paio d'occhi su ciò che frena la tua indicizzazione, parla con il team e richiedi un report SEO di esempio.
Fonti
Sull'autore
SearchBlueprint ha ricercato, scritto e valutato questo articolo con la stessa pipeline di contenuti che i nostri clienti usano sui loro siti. Il punteggio indicato nella firma è quello che il nostro motore di contenuti ha assegnato a questa pagina prima della pubblicazione. Nulla qui è rivisto a mano, ed è proprio questo il punto: è il risultato del prodotto, pubblicato dove chiunque può verificarlo.