I framework JavaScript moderni permettono di costruire interfacce molto ricche, ma spostano una parte importante del lavoro dal server al browser. Per un utente con un dispositivo recente la differenza è quasi invisibile; per un motore di ricerca può essere enorme. Il punto non è se i motori «sanno leggere JavaScript», perché i principali ne eseguono una buona parte, ma quanto rendi facile e affidabile il loro lavoro.
Le strategie di rendering
| Strategia | Dove nasce l'HTML | Cosa riceve il crawler alla prima richiesta |
|---|---|---|
| Client-side rendering (CSR) | nel browser | un guscio quasi vuoto e i file JavaScript |
| Server-side rendering (SSR) | sul server, a ogni richiesta | la pagina completa |
| Generazione statica (SSG) | al momento della build | la pagina completa, già pronta |
| Rigenerazione incrementale | statico, aggiornato periodicamente | la pagina completa |
Client-side rendering
Il server invia un HTML minimo, spesso con un solo <div id="app">, e il contenuto viene costruito dal JavaScript. Per essere indicizzato, il motore deve scaricare gli script, eseguirli e attendere i dati dalle API. È possibile, ma aggiunge passaggi che possono fallire o essere rimandati, e non tutti i crawler, inclusi quelli che generano anteprime per social e app di messaggistica, eseguono JavaScript.
Server-side rendering
Il server produce l'HTML completo e il browser, dopo averlo mostrato, «idrata» la pagina rendendola interattiva. Il crawler vede subito titolo, testo, link e dati strutturati. Il costo è un server che lavora a ogni richiesta e una maggiore complessità di cache.
Generazione statica
Le pagine vengono create una volta sola durante la build e servite come file. È la soluzione più veloce ed economica per contenuti che cambiano poco: blog, documentazione, siti istituzionali. Per cataloghi grandi o dati che cambiano spesso si combina con la rigenerazione periodica.
Nel mio lavoro, per siti di contenuto la scelta predefinita è la generazione statica; il rendering lato client lo riservo alle aree riservate e alle parti applicative che non devono comparire nei risultati.
Il rendering dinamico
Alcuni siti servono una versione pre-renderizzata ai crawler e quella JavaScript agli utenti. Google lo ha descritto come una soluzione di ripiego, non come una pratica consigliata a lungo termine. Introduce due versioni da mantenere e il rischio che divergano. Meglio puntare su SSR o generazione statica.
Errori che rendono invisibili i contenuti
Link che non sono link
<span onclick="router.go('/prodotti')">Prodotti</span>
Questo elemento è cliccabile per l'utente, ma non contiene un URL da seguire. I crawler scoprono le pagine tramite <a href="/prodotti">. Il router del framework può intercettare il clic, ma l'href deve esserci.
URL con il cancelletto
Le vecchie applicazioni a pagina singola usavano percorsi come /#/prodotti. La parte dopo # non viene in genere trattata come URL distinto. Usa percorsi reali con l'API History.
Codici di stato sbagliati
In un'applicazione client-side, una pagina inesistente spesso risponde 200 e mostra un messaggio «non trovato» generato dal JavaScript. Per il motore è un soft 404. Con SSR o generazione statica il server può restituire un vero 404; con il solo CSR, una soluzione è reindirizzare a un URL che risponde 404 oppure aggiungere un meta robots noindex alla vista di errore.
Contenuto caricato solo dopo un'interazione
Testo che compare solo al clic, allo scorrimento o al passaggio del mouse può non essere visto. Il contenuto importante deve essere nel DOM al termine del caricamento iniziale.
Risorse bloccate
Se robots.txt blocca le cartelle degli script o le API che forniscono i dati, il motore non può ricostruire la pagina.
Metadati impostati tardi
Titolo, meta description, canonical e meta robots modificati via JavaScript dopo il caricamento vengono letti in modo meno affidabile. In particolare, un noindex nell'HTML iniziale può far sì che la pagina non venga nemmeno renderizzata, anche se il JavaScript poi lo rimuove.
Come verificare
- Disattiva JavaScript nel browser e apri la pagina: ciò che vedi è ciò che riceve chi non esegue script.
- Guarda il sorgente (non l'ispettore): mostra l'HTML iniziale prima di qualsiasi esecuzione.
- Usa lo strumento di controllo URL negli strumenti per webmaster: mostra l'HTML renderizzato e le risorse che non è stato possibile caricare.
- Lancia un crawler in modalità JavaScript e confronta il risultato con una scansione senza rendering: le differenze indicano cosa dipende dagli script.
In sintesi
- Il rendering lato client aggiunge passaggi che possono fallire o essere rimandati.
- SSR e generazione statica consegnano al crawler la pagina completa da subito.
- I link devono essere veri
<a href>con URL reali, senza cancelletto. - Pagine inesistenti e metadati devono essere corretti già nell'HTML iniziale.
- Verifica confrontando sorgente, versione senza JavaScript e HTML renderizzato.
