Sfoglia altri articoli simili con le etichette:
Next.js 15 è uscito a ottobre 2024 con React 19 supportato di default e architettura Turbopack stabilizzata. Astro 5 è stato rilasciato a dicembre 2024 con Content Layer API che ha riscritto il modo in cui il framework gestisce i contenuti. Core Web Vitals nel 2024 ha sostituito FID con INP come metrica primaria di interattività. Tre cambiamenti tecnici che insieme hanno spostato il quadro operativo della SEO per Single Page Application in modo rilevante. Le scelte tecniche che facevamo nel 2022 portano oggi penalty di performance e indicizzazione. Il problema vero è che molti progetti continuano a essere costruiti con stack obsoleti, riproponendo gli stessi errori.
Il punto di partenza concreto resta uno: senza Server-Side Rendering o Static Site Generation, una SPA classica nel 2026 perde la partita prima ancora di scendere in campo.
SPA, SSR, SSG, ISR nel 2026
Una SPA pura (rendering client-side completo) era la moda del 2018-2020. React, Vue, Angular renderizzati direttamente nel browser. Per Google e per gli altri crawler, il problema strutturale è che il contenuto viene generato dopo che il bot ha già letto la pagina. Googlebot esegue JavaScript dal 2019, ma con limiti: latency aggiuntiva nel rendering, budget di crawl più stretto, indicizzazione differita a un secondo passaggio.
Per i crawler dei motori AI generativi il problema è amplificato. ChatGPT-User, OAI-SearchBot, PerplexityBot eseguono JavaScript in modo meno consistente di Googlebot. Per molti contenuti SPA il content estratto è solo l’HTML iniziale senza il dynamic content. Significa che la pagina viene letta vuota, e il sito è di fatto invisibile ai motori generativi.
SSR (Server-Side Rendering) risolve il problema renderizzando l’HTML lato server prima della consegna al browser. Il crawler riceve HTML completo, l’utente vede contenuto immediato, lo JavaScript poi idrata l’interattività. Next.js, Nuxt, SvelteKit, Remix supportano SSR nativamente.
SSG (Static Site Generation) renderizza tutto a build-time. Risultato: file HTML statici servibili da CDN, performance massima, indicizzazione perfetta. Trade-off: i contenuti non cambiano in real-time, ogni modifica richiede un rebuild. Adatto a blog, documentation, marketing site.
ISR (Incremental Static Regeneration) è il compromesso intelligente che Next.js ha introdotto. Genera staticamente all’inizio, rigenera incrementalmente quando un contenuto specifico cambia. La maggior parte dei contenuti restano statici (veloci, indicizzabili), solo i contenuti aggiornati passano per la rigenerazione.
Next.js 15 nel 2026
Next.js 15 ha consolidato l’App Router come default. Il vecchio Pages Router resta supportato per compatibilità, ma i progetti nuovi partono dall’App Router. Le novità che impattano la SEO direttamente: streaming SSR, server components stabili, metadati con generateMetadata function, supporto per React 19 e per i Server Actions.
Il punto operativo è che App Router permette di scegliere rendering strategy per route. Una pagina marketing è static. Una pagina di prodotto in catalogo è ISR. Una pagina dashboard utente è dynamic. La scelta è per route, non per applicazione. Significa che un singolo progetto Next.js può ottimizzare ogni sezione con la strategia di rendering più adatta.
Turbopack, il nuovo bundler che ha sostituito Webpack per gli ambienti dev e (sempre più) per i build production, ha tagliato i tempi di build del 30-50% sui progetti medi. Per chi gestisce siti grandi, è un guadagno operativo concreto sul ciclo di sviluppo.
L’errore tipico che vedo nei progetti Next.js è l’uso eccessivo dei “use client” directive. Marcare tutto come client component vanifica i benefici dei server components e riporta il progetto verso un’architettura client-heavy poco SEO-friendly. La regola pratica è: usa server components di default, marca client solo dove l’interattività JS è necessaria.
Astro 5 e l’approccio islands
Astro ha un approccio diverso, particolarmente interessante per i siti content-heavy. Renderizza tutto a HTML statico per default, attiva JavaScript solo per le “islands” interattive specifiche. Risultato: bundle JavaScript a zero per la maggior parte delle pagine, performance LCP eccellente, indicizzazione perfetta.
Astro 5 ha introdotto Content Layer API che permette di gestire contenuti da fonti diverse (markdown, CMS headless, database, API esterne) in modo unificato. Per progetti di blog, documentation, marketing site, Astro è spesso la scelta migliore del 2026.
Il limite di Astro è la curva di adozione: chi viene da React puro deve adattarsi a un modello differente. Per applicazioni con molta interattività JS (dashboard, app web complete) Astro non è la scelta giusta. Per siti dove il contenuto è il prodotto, è quasi sempre la scelta più asciutta.
Core Web Vitals nel 2026 con INP
INP (Interaction to Next Paint) ha sostituito FID (First Input Delay) come Core Web Vital primario di interattività a marzo 2024. La differenza è sostanziale. FID misurava solo la latency della prima interazione. INP misura la latency di ogni interazione lungo la sessione, considerando la peggiore. Soglie:
- Buono: INP sotto 200ms
- Da migliorare: tra 200ms e 500ms
- Scarso: oltre 500ms
Per le SPA, INP è la metrica più punitiva. Le interazioni complesse (filtri, ricerche, navigazione interna) tendono a richiedere lavoro JavaScript pesante, e su mobile a medio range il problema esplode. Le tecniche di ottimizzazione INP nel 2026 girano attorno a: code splitting aggressivo, lazy loading dei componenti non visibili, debouncing delle interazioni con effetti laterali pesanti, uso di Web Workers per logica complessa, evitare re-render non necessari nei framework reactive.
LCP (Largest Contentful Paint) resta importante. Soglia: sotto 2,5 secondi. Sui mobile italiani con connessione 4G media, raggiungere LCP sotto 2,5s richiede ottimizzazioni: immagini lazy-loaded con priorità per quella above-the-fold, font preload, critical CSS inline, riduzione del JavaScript bloccante.
CLS (Cumulative Layout Shift) è meno problematico per le SPA moderne, ma resta un punto da curare. Soglia: sotto 0,1. Le immagini senza dimensioni esplicite, gli ads injection, i font fallback con metriche diverse sono le cause più comuni di CLS alto.
Rendering per crawler AI nel 2026
I crawler dei motori AI generativi hanno comportamenti diversi rispetto a Googlebot. ChatGPT-User non esegue sempre JavaScript. PerplexityBot fa fetch più aggressivi ma con timeout più stretti. ClaudeBot rispetta robots.txt ma è meno tollerante con il client-side rendering.
La pratica operativa per chi vuole essere visibile ai motori AI nel 2026 è: servire HTML completo al primo render. Significa SSR o SSG, mai SPA pura. Significa anche evitare contenuto critico iniettato via JavaScript dopo il primo paint. Il contenuto deve essere nel HTML che il bot legge nella prima request.
Schema markup è altro punto importante. Article, BreadcrumbList, FAQ, Product, Organization, Person. I motori AI pescano i dati strutturati come segnali di trust e contesto. Un sito con schema markup completo viene citato più frequentemente di un sito senza, a parità di altri segnali.
Robots.txt deve essere esplicito sui bot AI. La maggior parte dei siti italiani che ho audito nel 2025-2026 ha robots.txt che non considera GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot. La decisione strategica è: permettere o bloccare? Bloccare significa rinunciare alla visibilità nei motori generativi. Permettere significa fornire contenuti al training dei modelli. Non è una scelta tecnica, è una scelta editoriale che ogni publisher deve fare consapevolmente.
Errori specifici che vedo nei progetti SPA italiani
Tre errori che si ripetono nei progetti che ho audito tra 2024 e 2026.
Il primo è il rendering interamente client-side per siti content-heavy. Magazine online, e-commerce, marketing site costruiti come SPA pure. Risultato: traffico organico inferiore del 40-70% rispetto a quello che il contenuto meriterebbe, perché Google indicizza tardi e i motori AI non indicizzano affatto.
Il secondo è l’over-engineering. Progetti che usano Next.js + GraphQL + headless CMS + Redux + 15 librerie quando un Astro con markdown porterebbe gli stessi risultati con un decimo della complessità. La complessità tecnica si traduce in fragilità operativa, performance peggiore, costi di sviluppo più alti.
Il terzo è il monitoraggio Core Web Vitals solo via Lighthouse o PageSpeed Insights. Sono test in modalità lab, ottimistici. I dati reali vengono dal CrUX e dal field monitoring (Web Vitals via JavaScript injection). Sulla base dei dati lab molti siti pensano di stare bene mentre nel mondo reale fanno scarso.
Per chi vuole una vista più ampia sulle strategie AIO e su come le architetture web influenzano la visibilità nei motori generativi, vale la pena considerare la performance tecnica come parte integrante della strategia di posizionamento, non come dettaglio operativo separato. La formazione tecnico-professionale di chi opera nel settore richiede un’integrazione di competenze SEO classiche, AIO, e architettura web che molti corsi convenzionali non offrono ancora.
Le SPA del 2026 ben fatte sono quelle che hanno scelto consapevolmente di non essere SPA in senso classico. SSR, SSG, ISR sono le opzioni vincenti. Client-side rendering puro è una scelta che ha senso solo per applicazioni con dashboard pesanti dove l’indicizzazione non è il KPI principale. Per qualsiasi altro caso, l’architettura va ripensata.
