Prerendering

## Cos’è il prerendering? Definisco il prerendering, in ambito SEO, come la consegna ai crawler di ricerca di uno snapshot HTML già completamente renderizzato di una pagina molto dipendente da JavaScript, così che i contenuti rilevanti siano disponibili nella risposta iniziale. Uso questa definizione ristretta perché i team spesso fanno confusione, includendo in modo troppo ampio server-side rendering, static generation e dynamic rendering. Nelle attività SEO pratiche, questo diventa importante quando una single-page application (SPA) o un sito renderizzato lato client invia per prima cosa un guscio HTML sottile e poi si affida a JavaScript per recuperare e “dipingere” i contenuti reali in un secondo momento. Quando analizzo siti di questo tipo, il pattern di fallimento ricorrente è familiare: un crawler richiede la pagina e ottiene poco più di un contenitore vuoto, testo in ritardo o metadati incompleti. L’obiettivo del prerendering è semplice: assicurarsi che i bot ricevano una pagina che contenga già il testo principale, i link, i metadati e i dati strutturati necessari per l’indicizzazione. Questo aiuta a prevenire il classico problema del “div vuoto” e può preservare la visibilità organica senza richiedere una ricostruzione completa del front end. Questa definizione deve rimanere precisa. Qui, per prerendering si intende **la consegna di uno snapshot HTML renderizzato per l’accesso dei crawler su pagine fortemente dipendenti da JavaScript**. È più utile quando i framework lato client rallentano la scansione, riducono la scoperta dei contenuti o creano incertezza su quali elementi importanti siano presenti nell’HTML che i bot processano. ## Perché il prerendering conta per la SEO Google può eseguire il rendering di JavaScript e Google Search Central spiega che la SEO basata su JavaScript dipende da rendering, disponibilità delle risorse e fasi di elaborazione. Il mio riscontro pratico da quella guida è semplice: “Google può renderizzare JS” non equivale a “tutti gli elementi importanti della pagina verranno visti immediatamente e in modo affidabile”. Il divario è ancora più rilevante perché non tutti i crawler hanno le capacità di rendering di Google. Bing, gli strumenti di audit SEO, i social scraper, i bot di uptime e gli strumenti di ricerca interna possono gestire JavaScript in modo diverso. Questo significa che una pagina può essere tecnicamente funzionante per gli utenti e comunque performare peggio in ricerca, perché: - il crawler vede solo una pagina “shell” al primo request - i contenuti chiave vengono iniettati troppo tardi - i link interni sono nascosti dietro l’esecuzione di JavaScript - i metadati o i canonicals mancano nell’HTML iniziale - i dati strutturati sono incompleti o aggiunti in modo inaffidabile Il prerendering risolve questi problemi restituendo in anticipo una versione HTML scansionabile. Nella mia esperienza, molti team lo prendono in considerazione quando hanno bisogno di un miglioramento SEO concreto senza i costi e le tempistiche di migrare una SPA verso un server-side rendering completo. ## Come funziona il prerendering Un flusso di prerendering tipico assomiglia a questo: 1. Un bot richiede una pagina guidata da JavaScript. 2. Il server o un middleware identifica la richiesta come probabilmente proveniente da un crawler. 3. Invece di inviare solo la JavaScript app shell, lo stack restituisce uno snapshot HTML renderizzato. 4. Quello snapshot include i contenuti visibili, le heading, i link interni, i metadati e spesso anche i dati strutturati. 5. Gli utenti umani ricevono ancora l’esperienza normale renderizzata lato client, a meno che il sito non usi il rendering universale per tutti. Questo può essere implementato con: - un servizio di prerendering come Prerender.io - static generation a livello di framework - una pipeline con browser headless che cattura snapshot HTML - logica di edge o middleware che serve output renderizzati ai bot I dettagli di implementazione possono variare, ma lo scopo SEO resta lo stesso: i bot ottengono contenuti subito, non dopo un’esecuzione JavaScript incerta. ## Prerendering vs server-side rendering vs dynamic rendering Questi termini vengono spesso usati in modo approssimativo, ma non sono identici. **Prerendering** di solito significa generare in anticipo o su richiesta uno snapshot HTML già renderizzato, e poi servire quell’output pronto ai crawler o a richieste specifiche. **Server-side rendering (SSR)** significa che il server renderizza l’HTML della pagina al momento della richiesta, sia per utenti sia per crawler. Framework come Next.js possono farlo nativamente. **Static site generation (SSG)** costruisce le pagine in file HTML prima del deploy. Io di solito lo considero l’opzione più pulita quando i contenuti cambiano in modo prevedibile e non richiedono personalizzazione per singola richiesta. **Dynamic rendering** è il termine di Google per servire contenuti renderizzati diversi a bot e utenti quando JavaScript crea problemi per l’indicizzazione. Google ha descritto il dynamic rendering come una soluzione di ripiego, non come un requisito di lungo periodo. Nella pratica, il prerendering focalizzato sui crawler spesso si comporta come una forma di dynamic rendering. ## Quando il prerendering è una buona scelta Il prerendering di solito vale la pena prenderlo in considerazione quando: - il tuo sito è una React, Vue, Angular o simile SPA - i crawler recuperano le pagine ma l’HTML indicizzato appare sottile o incompleto - contenuti importanti di prodotto, categoria o editoriali vengono iniettati lato client - i link interni non sono visibili nell’HTML grezzo - le pagine vengono scoperte lentamente nonostante un buon linking - gli snippet di ricerca o altri riepiloghi generati dalla ricerca sembrano mancare il copy principale - una riscrittura completa del framework non è realistica nel breve periodo Lo vedo generalmente come una soluzione ponte iniziale. Se l’azienda ha bisogno di una SEO migliore subito, ma l’ingegneria non può migrare immediatamente a SSR o SSG, il prerendering può ridurre il rischio mantenendo la velocità di sviluppo. ## Cosa dovrebbe esserci in uno snapshot prerenderizzato? Uno snapshot prerendered utile dovrebbe contenere la stessa principale sostanza di contenuto che un utente normale può accedere nella pagina. Al minimo, includi: - titolo della pagina e meta description - tag canonical - direttive robots, quando appropriato - heading principale e testo del corpo (body copy) - link interni e percorsi di navigazione rilevanti per la scoperta - dati strutturati, se usati - tag immagine con alt text significativo, quando rilevante - segnali di paginazione o navigazione a filtri (faceted navigation), se applicabili Non tratterei lo snapshot come un placeholder “snellito”. Se l’HTML renderizzato esclude i contenuti che vuoi indicizzare, il prerendering non risolverà il problema. ## Vantaggi SEO del prerendering Se implementato con cura, il prerendering può aiutare a: - rendere indicizzabili i contenuti subito - ridurre la dipendenza dal rendering JavaScript ritardato - esporre prima i link interni ai crawler - migliorare la coerenza tra ciò che recuperano gli strumenti e ciò che vedono gli utenti - supportare un debugging più ricco negli strumenti di ispezione URL e test dei crawler - recuperare la visibilità persa dalle architetture “shell page” Questi benefici non sono garantiti. I risultati dipendono da architettura del sito, pattern di crawling, qualità dei contenuti, controlli anti-duplicazione e dal fatto che l’HTML prerenderizzato sia davvero completo. ## Rischi e limiti Il prerendering non è una soluzione magica. Le limitazioni comuni includono: ### Freschezza dello snapshot Se i contenuti cambiano spesso, snapshot non aggiornati possono creare discrepanze tra ciò che vedono gli utenti e ciò che ricevono i bot. ### Preoccupazioni sul cloaking Servire ai bot contenuti sostanzialmente diversi rispetto agli utenti può creare rischi di policy. L’approccio sicuro è mantenere lo stesso significato nell’HTML prerenderizzato e gli stessi contenuti principali, evitando pratiche manipolative. ### Debito tecnico Un layer di prerendering diventa un ulteriore sistema da monitorare, mettere in cache, invalidare e debuggare. ### Soluzioni parziali Se il problema reale è debole architettura dell’informazione, contenuti duplicati o canonicals scorretti, il prerendering da solo non migliorerà i ranking. ### Gestione delle risorse Se lo snapshot omette direttive critiche, hreflang, dati strutturati o link, puoi peggiorare involontariamente la SEO. ## Come verificare il prerendering Usa una combinazione di verifiche manuali e basate su strumenti: - Visualizza l’HTML grezzo da una richiesta di un bot e verifica che il testo nel body sia presente. - Confronta lo snapshot con ciò che vede un browser normale. - Usa lo strumento Ispezione URL di Google Search Console per testare la pagina live. - Controlla se title, canonical e dati strutturati appaiono nell’HTML renderizzato. - Esegui il crawl del sito con uno strumento in grado di confrontare output renderizzato e non renderizzato. - Controlla a campione i log per confermare che i bot stiano davvero ricevendo risposte prerenderizzate. Quando risolvo problemi di prerendering, di solito inizio con la risposta del bot, non con la vista del browser. Le indicazioni di Google sulla SEO con JavaScript e gli strumenti di Ispezione URL sono riferimenti utili qui. Se una pagina resta indicizzata senza il testo chiave, il problema potrebbe essere snapshot non aggiornati, risorse bloccate o una canonicalizzazione debole, piuttosto che il rendering in sé. ## Best practice - Mantieni l’HTML prerenderizzato semanticamente equivalente alla pagina visibile all’utente. - Includi copy principale e link interni nello snapshot. - Invalida o aggiorna gli snapshot quando i contenuti cambiano. - Mantieni canonical, hreflang, direttive robots e markup dello schema. - Monitora le risposte dei bot, non solo la vista del browser. - Tratta il prerendering come un layer di compatibilità duraturo oppure come un ponte temporaneo verso un’architettura di rendering più solida. ## Considerazioni finali Penso al prerendering come a uno strato di compatibilità SEO pratico per siti con forte dipendenza da JavaScript. Fornisce ai crawler uno snapshot HTML completamente renderizzato, così da poter accedere subito a contenuti indicizzabili. Per le SPA che altrimenti espongono ai bot pagine “shell”, contenitori vuoti o contenuti in ritardo, questo può fare la differenza tra una pagina teoricamente crawlable e una pagina davvero comprensibile nella pratica. La chiave è mantenere snapshot completi, aggiornati e realmente allineati a ciò che gli utenti vedono.