JavaScript SEO: SSR, SSG e rendering per i motori di ricerca

Hai un sito sviluppato con React, Vue o Angular? Il tuo negozio online carica contenuti via JavaScript e i motori di ricerca faticano a leggere le pagine? Non sei solo. Lo vediamo ogni giorno nei progetti che ci arrivano: siti moderni con framework JavaScript che Google non indicizza correttamente. Il problema non è il framework — è come viene servito il rendering.

In questa guida operativa ti spieghiamo perché succede, quali soluzioni esistono (SSR, SSG, ISR, prerendering ibrido) e come implementarle senza reinventare la ruota. Nessuna teoria astratta: partiamo dal codice che abbiamo scritto e testato su progetti reali.

Il problema: JavaScript e i crawler non parlano la stessa lingua

I motori di ricerca moderni (Google, Bing) sanno eseguire JavaScript, ma lo fanno con limiti precisi: crawling budget limitato, timeout (spesso 10 secondi), e incapacità di gestire interazioni utente complesse. Un sito che carica tutto via JS (client-side rendering o CSR) obbliga Google a:

• Scaricare HTML quasi vuoto
• Scaricare JS bundle (spesso centinaia di KB)
• Eseguire il codice in un headless browser
• Attendere che i dati asincroni arrivino

Se uno di questi passaggi fallisce, la pagina viene indicizzata come una scatola vuota. Zero risultati in SERP per parole chiave importanti.

Noi, di Meteora Web, abbiamo ereditato progetti con questo problema: un e-commerce React che indicizzava solo la homepage. Dopo aver implementato SSR con Next.js, le pagine prodotto sono passate da 0 a 1500 impression giornaliere in 6 settimane.

Segnali che il tuo sito ha un problema di rendering JS

1. Nessun contenuto nella cache di Google: cerca site:tuodominio.com e controlla i risultati. Se vedi solo poche pagine, il resto non è stato indicizzato.
2. Contenuto assente in anteprima: usa lo strumento “Controllo URL” in Google Search Console. Se l'anteprima è vuota o mostra solo la struttura vuota, il rendering JS è fallito.
3. Pagine lente su mobile: CSR spesso genera First Contentful Paint (FCP) alti perché il browser deve scaricare e processare JS prima di mostrare qualsiasi contenuto.

Le soluzioni: SSR, SSG, ISR, prerendering ibrido

Non esiste una bacchetta magica. La scelta dipende da caso d'uso e stack tecnologico.

Server-Side Rendering (SSR)

Il server genera HTML completo per ogni richiesta. Il browser riceve pagine già pronte, senza attendere JS. Ideale per siti con contenuti dinamici (e-commerce, dashboard, portali).

Esempio con Next.js 13+ (App Router):

// app/prodotti/[slug]/page.jsx
export default async function ProdottoPage({ params }) {
  const res = await fetch('https://api.example.com/prodotti/' + params.slug);
  const prodotto = await res.json();
  return (<div><h1>{prodotto.nome}</h1><p>{prodotto.descrizione}</p></div>);
}

Attenzione: SSR richiede un server Node.js sempre attivo. Con Next.js, il deploy su Vercel o su un VPS con PM2 è semplice. Noi preferiamo VPS su Hetzner o AWS EC2 e gestiamo il processo con systemd.

Static Site Generation (SSG)

Il contenuto viene generato al momento del build. Ogni pagina diventa un file HTML statico. Ideale per blog, landing page, documentazione. Veloce, sicuro, zero carico server.

Esempio con Next.js:

// app/blog/[slug]/page.jsx
export async function generateStaticParams() {
  const posts = await fetch('https://api.example.com/posts').then(r => r.json());
  return posts.map(post => ({ slug: post.slug }));
}
export default async function BlogPost({ params }) {
  const res = await fetch('https://api.example.com/posts/' + params.slug);
  const post = await res.json();
  return (<article><h1>{post.title}</h1><div>{post.content}</div></article>);
}

Pro: velocità massima, hosting statico (Netlify, Vercel, S3+CloudFront). Contro: ogni modifica richiede un rebuild. Per siti con contenuti che cambiano poco, è perfetto.

Incremental Static Regeneration (ISR)

Un ibrido: pagine statiche che si rigenerano automaticamente a intervalli definiti (es. ogni 60 secondi). Unisce i vantaggi di SSG e SSR.

// app/prodotti/[slug]/page.jsx
export const revalidate = 60; // secondi
export default async function ProdottoPage({ params }) { ... }

ISR è ottimo per e-commerce con catalogo stabile ma prezzi che variano ogni ora. Noi lo abbiamo usato per un cliente con 10.000 prodotti: build iniziale di 5 minuti, poi aggiornamenti incrementali senza downtime.

Prerendering ibrido (Nuxt, Gatsby, Astro)

Non solo Next.js. Esistono alternative valide per ogni framework:

• Nuxt 3 (Vue): supporta SSR, SSG, e modalità ibrida (per pagina).
• Gatsby (React): SSG puro con plugin per dati dinamici.
• Astro (qualsiasi UI): zero JS iniziale, solo HTML statico + isole interattive.
• SvelteKit: SSR e SSG nativi.

La scelta giusta dipende dal team, non solo dal hype. Se usiamo Laravel con Inertia.js, gestiamo la parte SSR con Laravel stesso (usando server-side rendering di Inertia combinato con Vite).

Come implementare SSR/SSG senza impazzire: guida passo-passo

Supponiamo di dover migrare un sito React (CSR) a Next.js. Ecco i passaggi pratici.

1. Audit del progetto attuale

1. Elenca tutte le pagine e i loro dati dinamici (API, database).
2. Identifica le dipendenze che potrebbero rompersi in ambiente Node (es. localStorage, window).
3. Usa Google Search Console per vedere quante indicizzazioni stai perdendo.

2. Setup iniziale con Next.js

npx create-next-app@latest --typescript
cd nuova-app
npm run dev

3. Converti una pagina critica in SSR

Prendi la homepage. Sposta le chiamate API nel componente pagina e usa async. Assicurati che tutti i componenti client siano contrassegnati con 'use client' se necessario.

// app/page.jsx (Server Component)
export default async function HomePage() {
  const data = await getData();
  return <div>...</div>;
}

4. Testa con Google e strumenti di rendering

• Usa curl per vedere l'HTML restituito: curl http://localhost:3000 | grep '<title'
• Incolla l'URL nel Rich Results Test di Google (link). Se l'HTML include i contenuti, sei a buon punto.
• Attiva JavaScript Rendering Checker in Search Console (Impostazioni > Crawling > Rendering).

5. Gestisci il deployment

Per SSR: deploy su VPS con Node.js + PM2 + Nginx come reverse proxy. Per SSG: build e carica su hosting statico.

Noi abbiamo automatizzato i build con GitHub Actions (guarda la nostra guida pratica su Domain Driven Design per analogie di automazione).

Errori comuni (e come evitarli)

Non testare il rendering su Google

Molti sviluppatori provano solo il rendering client-side. Google non è un browser moderno. Testa sempre con l’URL Inspection Tool.

Dimenticare le pagine di errore e redirect

Se la tua pagina 404 o 500 è gestita lato client, Google vedrà una pagina bianca. Assicurati che gli errori siano renderizzati lato server.

Ignorare il preloading dei dati

Con SSR, se la tua API impiega 3 secondi, la pagina sarà lenta per tutti (utenti e crawler). Usa caching Redis o database query ottimizzate. Noi consigliamo di implementare caching a livello di applicazione (es. con Redis) per dati che cambiano poco.

Strumenti essenziali per diagnosticare il rendering

• Google Search Console (URL Inspection)
• Lighthouse (con flag “Emulate mobile”)
• WebPageTest (guarda il filmstrip del rendering)
• Puppeteer/Playwright per test endpoint: curl con User-Agent di Google

Se non hai mai usato Puppeteer, ecco un comando rapido per vedere cosa vede Google:

# Sostituisci URL con il tuo sito
curl -H "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -H "Accept: text/html,application/xhtml+xml" \
  https://www.tuosito.com | grep '<title'

In sintesi — cosa fare adesso

1. Verifica subito se il tuo sito soffre di rendering client-side: controlla quante pagine Google ha indicizzato vs le tue pagine reali.
2. Identifica la soluzione adatta: SSR per contenuti dinamici, SSG per statici, ISR per una via di mezzo.
3. Inizia con una pagina pilota (es. prodotto più visitato). Convertila in SSR/SSG e monitora l'impatto in Search Console.
4. Automatizza il deploy: usa GitHub Actions per buildare e caricare su server o hosting statico.
5. Non dimenticare la sicurezza e l'ottimizzazione delle immagini (guarda il nostro caso studio su riduzione peso immagini del 60%).

Se hai bisogno di un audit tecnico sul tuo sito JavaScript, contattaci. Valutiamo la situazione e ti proponiamo una soluzione concreta, senza promesse irrealistiche.