TL;DR: I framework JavaScript rompono l’SEO per impostazione predefinita. Con il rendering lato client, i motori di ricerca vedono un guscio vuoto — e i crawler AI non eseguono JavaScript affatto. Next.js (con Server Components e la Metadata API) è l’opzione migliore per l’SEO al momento. Nuxt è molto vicino per chi lavora con Vue. Le React SPA “pure” non andrebbero mai usate per pagine che vuoi indicizzare. Questa guida contiene il codice esatto, gli errori esatti e le correzioni esatte. Niente giri di parole.
La regola: Se un URL deve posizionarsi su Google o essere citato da un’AI, deve restituire HTML completo nella risposta iniziale. Fine. “Ma Google può eseguire JavaScript” — sì, eventualmente, in modo non affidabile, dopo una coda che può durare giorni, su un’infrastruttura che Google gestisce a costi enormi proprio perché così tanti sviluppatori pubblicano gusci HTML vuoti e si aspettano che il motore di ricerca faccia lui il lavoro di rendering. E i crawler AI non proveranno nemmeno.
ISR è... aspetta, facciamo un passo indietro. Credevo che ISR fosse un chiaro vantaggio rispetto a SSR nella maggior parte dei casi. Dopo aver visto bug di revalidazione far sì che contenuti obsoleti restassero in pagina per settimane su alcuni siti client, sono molto meno convinto. Su un sito e-commerce di un cliente, le pagine ISR servivano prezzi vecchi per 6 ore perché la revalidazione falliva in silenzio — niente errori nei log, nessun alert, solo prezzi sbagliati mostrati a clienti e crawler. ISR è eccellente quando funziona. Quando non funziona, debuggare problemi di cache “stale” è davvero frustrante. SSR è più prevedibile, anche se è più lento.
Next.js merita la sezione più lunga, e quindi ce l’ha. È il framework React più popolare e, dato che nell’App Router di Next.js 13+ è diventato predefinito, è diventato anche il miglior framework JavaScript per l’SEO. Non “quasi” — significa davvero meglio delle alternative.
Se stai costruendo un progetto nuovo nel 2026 e l’SEO conta, usa Next.js con l’App Router. È la raccomandazione. Il resto della sezione spiega perché.
Next.js ha due sistemi di routing. L’App Router (introdotto in Next.js 13, stabile in 14+) e l’ormai legacy Pages Router. Entrambi possono produrre risultati SEO buoni, ma l’App Router è migliore in quasi tutto ciò che conta per i motori di ricerca:
'use client'. Meno JavaScript inviato significa pagine più veloci e HTML completo per i crawler.Il Pages Router continua a funzionare bene. Se hai un grande codebase già avviato su quello, non farti prendere dal panico: non c’è bisogno di migrare subito.
Ma per progetti nuovi? App Router, senza dubbi.
Prima dell’App Router, l’SEO in Next.js significava installare next-seo e collegare manualmente le meta tag. La Metadata API — che io considero una delle cose migliori dell’App Router, nonostante i miei problemi con lo “scotto” della migrazione — gestisce tutto in modo pulito come funzionalità di primo livello del framework.
Metadati statici per una pagina:
// app/about/page.tsx
import { Metadata } from 'next'
export const metadata: Metadata = {
title: 'Chi siamo | La tua azienda',
description: 'Costruiamo strumenti che rendono l’SEO automatico.',
openGraph: {
title: 'Chi siamo',
description: 'Costruiamo strumenti che rendono l’SEO automatico.',
type: 'website',
},
alternates: {
canonical: 'https://example.com/about',
},
robots: {
index: true,
follow: true,
},
}Metadati dinamici per pagine con parametri (blog, prodotti, ecc.):
// app/blog/[slug]/page.tsx
import { Metadata } from 'next'
type Props = { params: { slug: string } }
export async function generateMetadata({ params }: Props): Promise<Metadata> {
const post = await getPost(params.slug)
return {
title: `${post.title} | Il tuo blog`,
description: post.excerpt,
openGraph: {
title: post.title,
description: post.excerpt,
type: 'article',
publishedTime: post.publishedAt,
authors: [post.author.name],
images: [{ url: post.ogImage, width: 1200, height: 630 }],
},
alternates: {
canonical: `https://example.com/blog/${params.slug}`,
},
}
}
export default async function BlogPost({ params }: Props) {
const post = await getPost(params.slug)
return (
<article>
<h1>{post.title}</h1>
<p>{post.content}</p>
</article>
)
}Questa è una Server Component. Niente direttiva 'use client'. Viene eseguita interamente sul server. L’HTML che arriva a Googlebot include tutto il contenuto dell’articolo e tutte le meta tag. Nessun rendering JavaScript richiesto.
Errore comune che vedo continuamente: gli sviluppatori mettono il recupero dati in una 'use client' component, il che significa che il contenuto viene caricato tramite JavaScript dopo che l’HTML iniziale è già stato inviato. Googlebot riceve una pagina vuota. Sul serio. Sposta il recupero dati nelle Server Components o in generateMetadata. E se non sai se un componente è server o client, controlla la direttiva 'use client' in cima al file — se c’è, niente di quella “component tree” finirà nella risposta HTML iniziale.
Next.js App Router ha supporto nativo per la sitemap. Crea app/sitemap.ts e genererà automaticamente /sitemap.xml:
// app/sitemap.ts
import { MetadataRoute } from 'next'
export default async function sitemap(): MetadataRoute.Sitemap {
const posts = await getAllPosts()
const products = await getAllProducts()
const postEntries = posts.map((post) => ({
url: `https://example.com/blog/${post.slug}`,
lastModified: new Date(post.updatedAt),
changeFrequency: 'weekly' as const,
priority: 0.7,
}))
const productEntries = products.map((product) => ({
url: `https://example.com/products/${product.slug}`,
lastModified: new Date(product.updatedAt),
changeFrequency: 'daily' as const,
priority: 0.8,
}))
return [
{
url: 'https://example.com',
lastModified: new Date(),
changeFrequency: 'daily',
priority: 1,
},
...postEntries,
...productEntries,
]
}Per siti con più di 50.000 URL, usa generateSitemaps() per creare più file sitemap. Il limite di Google è 50.000 URL per file sitemap.
Stesso schema. Crea app/robots.ts:
// app/robots.ts
import { MetadataRoute } from 'next'
export default function robots(): MetadataRoute.Robots {
return {
rules: [
{
userAgent: '*',
allow: '/',
disallow: ['/api/', '/dashboard/', '/admin/'],
},
],
sitemap: 'https://example.com/sitemap.xml',
}
}Next.js può generare immagini Open Graph al volo usando next/og (basato sulla libreria Satori di Vercel). È utile — invece di creare manualmente OG image per ogni articolo, definisci un template e viene renderizzato al momento della richiesta:
// app/blog/[slug]/opengraph-image.tsx
import { ImageResponse } from 'next/og'
export const size = { width: 1200, height: 630 }
export const contentType = 'image/png'
export default async function Image({
params,
}: {
params: { slug: string }
}) {
const post = await getPost(params.slug)
return new ImageResponse(
(
<div style={{
display: 'flex',
flexDirection: 'column',
justifyContent: 'center',
padding: '60px',
background: 'white',
width: '100%',
height: '100%',
}}>
<h1 style={{ fontSize: 48, fontWeight: 700 }}>
{post.title}
</h1>
<p style={{ fontSize: 24, color: '#666' }}>
{post.excerpt}
</p>
</div>
),
{ ...size }
)
}Next.js imposta automaticamente il tag og:image per puntare a questa immagine generata. Nessun collegamento manuale richiesto.
Il componente next/image gestisce lazy loading, conversione automatica in WebP/AVIF, sizing responsive e previene i cambi di layout (CLS). Tutte queste cose impattano direttamente i Core Web Vitals, che Google usa come segnale di ranking.
import Image from 'next/image'
// Questo fa automaticamente:
// - Genera varianti WebP/AVIF
// - Carica in lazy le immagini sotto la “fold”
// - Imposta width/height per prevenire CLS
// - Serve dimensioni responsive
<Image
src="/hero.jpg"
alt="Screenshot del prodotto che mostra la dashboard"
width={1200}
height={630}
priority // Above-the-fold: disabilita il lazy loading
/>Due errori che vedo fare sempre: dimenticare priority sull’immagine LCP (la tua immagine più grande above-the-fold) e usare tag <img> “grezzi” invece di next/image. Entrambi peggiorano i Core Web Vitals.
Aggiungi dati strutturati JSON-LD direttamente nelle tue Server Components. Nessun pacchetto terzo necessario:
// app/blog/[slug]/page.tsx
export default async function BlogPost({ params }) {
const post = await getPost(params.slug)
const jsonLd = {
'@context': 'https://schema.org',
'@type': 'Article',
headline: post.title,
description: post.excerpt,
datePublished: post.publishedAt,
dateModified: post.updatedAt,
author: {
'@type': 'Person',
name: post.author.name,
},
image: post.ogImage,
}
return (
<>
<script
type="application/ld+json"
// Nelle Next.js Server Components, è sicuro —
// il JSON viene generato lato server dal tuo database
{...{ children: JSON.stringify(jsonLd) }}
/>
<article>
<h1>{post.title}</h1>
<p>{post.content}</p>
</article>
</>
)
}Li vedo praticamente su ogni sito Next.js che analizzo. Ognuno di questi costa posizionamenti.
'use client' components — il tuo contenuto viene caricato dopo l’esecuzione di JavaScript. Googlebot vede uno spinner di loading vuoto. Sposta il data fetching nelle Server Components./blog/my-post sia /blog/my-post?ref=twitteralternates.canonical nei metadati.metadata. Le pagine dinamiche richiedono generateMetadata. Ho visto siti con metadati perfetti sulla homepage e <title>undefined</title> su ogni pagina prodotto.loading.tsx per contenuti critici — il file di loading mostra uno skeleton mentre il contenuto “streama” dentro. Googlebot potrebbe indicizzare lo skeleton invece del contenuto reale. Usa loading.tsx per UI non critiche, non per il contenuto principale della pagina.router.push() per i redirect. I motori di ricerca non seguono in modo affidabile i redirect JavaScript. Usa redirect in next.config.js o middleware per 301/302 lato server.Mi dà fastidio dover scrivere questa sezione. Siamo nel 2026. (Se stai ancora usando Create React App per un sito pubblico nel 2026, dobbiamo parlarne.) Ma arrivano ancora le email, quindi eccoci qui.
Non usare una plain React SPA per pagine che vuoi indicizzare. È il punto. Una plain React SPA — Create React App, Vite con React, quello che vuoi — invia un guscio HTML vuoto a ogni crawler che passa. Google potrebbe renderizzarla prima o poi. I crawler AI no. Usala per dashboard, pannelli admin, qualsiasi cosa dietro un login. Non usarla per contenuti che devono comparire nei risultati di ricerca.
Se sei bloccato con una React SPA e non riesci a migrare a Next.js (capisco — succede), ecco l’approccio “nastro adesivo”:
// Usando react-helmet-async per le meta tag
import { Helmet } from 'react-helmet-async'
function ProductPage({ product }) {
return (
<>
<Helmet>
<title>{product.name} | Il tuo store</title>
<meta name="description" content={product.description} />
<link rel="canonical"
href={`https://example.com/products/${product.slug}`} />
</Helmet>
<h1>{product.name}</h1>
</>
)
}React Helmet gestisce le tue <head> tag. Ma — ed è fondamentale — funziona ancora lato client. Googlebot deve comunque eseguire JavaScript per vedere queste tag. Ti serve un servizio di prerendering (Prerender.io, Rendertron o la tua configurazione con Puppeteer) per servire HTML già renderizzato ai crawler.
Funziona. L’ho visto funzionare. Però è fragile, aggiunge latenza alle richieste dei crawler, costa denaro e stai combattendo il framework invece di lavorare con esso.
Se la tua SPA ha più di 50 pagine che devono essere indicizzate — e queste pagine hanno contenuti dinamici che cambiano ogni settimana — quindi la cache di prerendering deve essere invalidata continuamente — il che significa che qualcuno del tuo team ora deve mantenere l’infrastruttura per i crawler invece di costruire feature di prodotto — allora il costo di mantenere un setup di prerendering supera quello di migrare a Next.js. Ho fatto questi conti per clienti.
Come hanno documentato Addy Osmani e Jason Miller su web.dev, il prerendering in genere aggiunge una latenza lato server percepibile per ogni richiesta dei crawler e i casi limite con contenuti dinamici o stati autenticati producono spesso snapshot stale o errati. È un ponte valido, non una soluzione permanente (web.dev: Rendering on the Web).
Se il tuo team è nell’ecosistema Vue, Nuxt sta a Vue come Next.js sta a React. Stessa idea: prendi un framework lato client, aggiungi server rendering, gestione dei metadati e routing basato su file. (Devo ammettere: ho passato molto meno tempo con Nuxt rispetto a Next.js, quindi prenditi le mie opinioni con un po’ di sale in più.) La storia SEO è solida — non proprio rifinita come Next.js in alcuni aspetti, ma abbastanza vicina da non dover essere decisiva tra i due ecosistemi.
Nuxt usa universal rendering out of the box. Ogni pagina è renderizzata sul server al primo caricamento, poi viene “idrata” per la navigazione lato client. Non devi abilitare nulla. Devi disabilitare. È l’impostazione giusta per l’SEO.
Il sistema composable di Nuxt per i metadati è pulito. Due opzioni in base a quanta gestione vuoi avere:
<!-- pages/blog/[slug].vue -->
<script setup>
const route = useRoute()
const { data: post } = await useFetch(`/api/posts/${route.params.slug}`)
// Opzione 1: useSeoMeta — tip-safe, copre i casi più comuni
useSeoMeta({
title: () => post.value?.title,
description: () => post.value?.excerpt,
ogTitle: () => post.value?.title,
ogDescription: () => post.value?.excerpt,
ogType: 'article',
ogImage: () => post.value?.ogImage,
twitterCard: 'summary_large_image',
})
// Opzione 2: useHead — controllo completo delle <head> tag
useHead({
link: [
{
rel: 'canonical',
href: `https://example.com/blog/${route.params.slug}`,
}
],
script: [
{
type: 'application/ld+json',
innerHTML: JSON.stringify({
'@context': 'https://schema.org',
'@type': 'Article',
headline: post.value?.title,
datePublished: post.value?.publishedAt,
}),
},
],
})
</script>
<template>
<article>
<h1>{{ post?.title }}</h1>
<p>{{ post?.content }}</p>
</article>
</template>Mi piace molto useSeoMeta(). È più “opinato” della Metadata API di Next.js, ma copre il 90% di ciò che ti serve con meno boilerplate. La tipizzazione significa che il tuo IDE ti segnala refusi nei nomi delle meta tag — una cosa che ha causato bug reali in progetti su cui ho lavorato.
Le routeRules di Nuxt ti permettono di mescolare strategie di rendering per route. È uno di quei punti in cui Nuxt, a dirla tutta, è probabilmente davanti a Next.js come esperienza per lo sviluppatore:
// nuxt.config.ts
export default defineNuxtConfig({
routeRules: {
'/': { prerender: true }, // SSG — homepage
'/blog/**': { isr: 3600 }, // ISR — revalidate ogni ora
'/products/**': { ssr: true }, // SSR — sempre aggiornato
'/dashboard/**': { ssr: false }, // CSR — pagine con autenticazione
'/docs/**': { prerender: true }, // SSG — documentazione
}
})Un solo oggetto di configurazione, cinque strategie di rendering diverse. Con Next.js, imposteresti export const dynamic = 'force-static' o export const revalidate = 3600 su ogni singolo file di pagina. (A dire il vero, non è del tutto corretto — anche il middleware di Next.js può gestire una parte di tutto questo in modo centralizzato. Ma l’approccio di Nuxt è più esplicito.) (Mi ricorda il debug del livello GraphQL di Gatsby alle 2 di notte — alcuni framework ottimizzano l’esperienza del dev a scapito della tranquillità.) L’approccio di Nuxt scala meglio quando hai pattern chiari a livello di route.
Nuxt non ha una generazione sitemap integrata “come Next.js”. Ti serve il modulo @nuxtjs/sitemap (che è mantenuto ufficialmente ed è ben supportato):
// nuxt.config.ts
export default defineNuxtConfig({
modules: ['@nuxtjs/sitemap'],
sitemap: {
sources: ['/api/__sitemap__/urls'],
exclude: ['/dashboard/**', '/admin/**'],
},
site: {
url: 'https://example.com',
},
})Il modulo scopre automaticamente le tue pagine statiche dal routing basato su file. Per pagine dinamiche (blog, prodotti), fornisci un endpoint API che restituisce la lista degli URL. I file di indice della sitemap vengono generati automaticamente quando superi 50.000 URL.
Se stai costruendo un blog o un sito di documentazione con Nuxt, vale la pena conoscere il modulo @nuxt/content. Legge file Markdown/MDX da una directory content/, genera pagine con supporto completo SSG e include una ricerca integrata. Per l’SEO, il vantaggio chiave è che ogni pagina di contenuto viene prerenderizzata come HTML statico — la consegna più veloce possibile per i motori di ricerca.
Correzione: renderizza lato server i contenuti critici. Se devi mostrare stati di loading, assicurati che compaiano solo per elementi dell’interfaccia non critici. Verifica: disabilita JavaScript in Chrome DevTools (Impostazioni > Debugger > Disable JavaScript), ricarica la pagina. Quello che vedi è ciò che vede la maggior parte dei crawler. Se vedi uno spinner, lo vede anche Google.
I dati strutturati JSON-LD aiutano i motori di ricerca a capire di cosa tratta la tua pagina. Pagine prodotto senza schema Product. Articoli senza schema Article. Pagine FAQ senza schema FAQPage. Ogni tipo di schema mancante è un’occasione persa per rich results.
Correzione: aggiungi JSON-LD a ogni tipo di pagina. Verifica: esegui Google's Rich Results Test su ogni tipologia di pagina. Sia Next.js che Nuxt rendono tutto questo semplice — guarda gli esempi di codice qui sopra. Oppure lascia che SEOJuice lo gestisca automaticamente.
Usare JavaScript (window.location.href, router.push(), navigateTo()) per i redirect invece dei 301/302 lato server. I motori di ricerca non seguono in modo affidabile i redirect JavaScript. Il “link equity” non si trasferisce. Le pagine che dovrebbero essere consolidate restano separate.
Correzione: usa redirect lato server. In Next.js, configurali in next.config.js o usa il middleware. In Nuxt, usa routeRules per i redirect. Verifica: curl -I https://your-site.com/old-url — dovresti vedere uno stato 301 o 302 con header Location. Se vedi 200 OK, il redirect è solo lato client.
Questa è la novità. Anche se la tua configurazione SSR è perfetta per Googlebot, verifica che il tuo robots.txt non blocchi i crawler AI. Alcuni provider CDN (soprattutto Cloudflare con l’opzione “AI Bot”) bloccano GPTBot e crawler simili di default. Se vuoi visibilità sui motori di ricerca AI, assicurati che possano accedere ai tuoi contenuti. Verifica: curl https://your-site.com/robots.txt e cerca GPTBot, ClaudeBot, PerplexityBot. Se sono vietati e non li hai messi tu lì, è stata la tua CDN.
Ed ecco un ultimo controllo che copre tutto quanto sopra: tasto destro su qualsiasi pagina, Visualizza sorgente pagina. Se i tuoi contenuti sono nell’HTML grezzo, il rendering lato server sta funzionando. Se vedi un <div id="root"></div> vuoto, allora no. Esegui anche l’audit SEO di Lighthouse — punta a 100: è raggiungibile con il server rendering. Come hanno scritto Jason Miller e Addy Osmani su web.dev: le strategie di rendering comportano tradeoff reali e non puoi permetterti di dare per scontato che il tuo JavaScript venga eseguito correttamente da ogni crawler (web.dev: Rendering on the Web).
I framework JavaScript e l’SEO hanno una storia complicata. Per anni il consiglio era “usa solo server-side rendering” ed era praticamente tutto. Ora il quadro è più sfumato, ma anche più gestibile.
Next.js con l’App Router è l’opzione migliore per la maggior parte dei team nel 2026. I Server Components significano che le tue pagine vengono renderizzate lato server di default, la Metadata API è con tipizzazione e completa, e l’ecosistema è maturo. Se lavori nell’ecosistema Vue, Nuxt ti dà gli stessi vantaggi di base con una superficie di API leggermente diversa.
Le React SPA “pure” non andrebbero usate per pagine pubbliche. Sono stanco di vedere React SPA sui siti marketing. Siamo nel 2026. Dovremmo saperne di più. E non cambierà — anzi, con la crescita dei crawler AI che non eseguono JavaScript, diventa più difficile, non più facile.
Una cosa però mi è davvero incerta: l’evoluzione nel lungo periodo di Remix rispetto a Next.js per l’SEO. La filosofia di Remix, “SSR only, no caching layer”, è interessante per la sua semplicità. Con edge computing che diventa più economico, l’argomento a favore di ISR (la via di mezzo di Next.js) si indebolisce. Io non punterei contro Remix nel 2027. Però oggi Next.js ha più funzionalità SEO integrate, un ecosistema più ampio e una documentazione migliore. Usa ciò che risolve il tuo problema adesso.
Se tutto questo ti suona come “tanta configurazione da sistemare” — è vero. Ecco perché esiste SEOJuice: scegli la strategia di rendering, noi automatizziamo il resto.
Sì, ma con alcune condizioni. Google usa il Web Rendering Service (un Chromium sempre aggiornato) per eseguire JavaScript. Il rendering avviene in un secondo passaggio — dopo il crawl iniziale — e può richiedere da pochi secondi a giorni. Per siti già consolidati con budget di crawling alto, di solito è veloce. Per siti nuovi o con poca autorevolezza, il ritardo può essere consistente. E soprattutto: il rendering di Google non è garantito. Le pagine che dipendono da interazioni JavaScript complesse, richiedono autenticazione o hanno errori di rendering potrebbero non essere mai renderizzate completamente. L’approccio più sicuro è sempre servire HTML completo nella risposta iniziale.
Scegli in base a se il tuo team scrive Vue o React, non in base alle differenze SEO.
Il percorso più veloce: aggiungi Prerender.io o un servizio di prerendering simile come middleware. Intercetta le richieste dei crawler e serve HTML prerenderizzato. Ci mette circa un’ora per essere impostato e rende subito i tuoi contenuti visibili ai motori di ricerca. Poi pianifica una migrazione graduale verso Next.js — l’App Router può convivere con le pagine esistenti, così puoi migrare route per route invece di fare una riscrittura “big-bang”. Parti dalle pagine con più traffico.
no credit card required