SEO per Siti Statici: Jamstack, SSG e Farsi Trovare

TL;DR: La SEO per siti statici parte da un vantaggio concreto: i contenuti importanti possono arrivare sotto forma di HTML già pre-renderizzato, invece di aspettare l’esecuzione di JavaScript. Ma Astro, Hugo, 11ty, Gatsby, Jekyll e le esportazioni statiche di Next.js non risolvono automaticamente canonicals, metadata, dati strutturati, redirect, link interni o quei widget renderizzati lato client che possono “nascondere” contenuti ai crawler. Valuta l’HTML effettivamente pubblicato, non l’etichetta del framework.

Cosa ottengono davvero “gratis” i siti statici

Un generatore di sito statico come Astro, Hugo, 11ty, Jekyll, Gatsby o Next.js in modalità di esportazione statica esegue template e contenuti durante la fase di build. Produce file HTML insieme a CSS, JavaScript e asset necessari per ciascuna pagina. Lo strato di hosting può servire quei file senza interrogare un database e senza eseguire il rendering della pagina per ogni richiesta.

Questo conta perché Google elabora le pagine attraverso crawling, rendering, indicizzazione e serving. La nostra guida a come funziona l’indicizzazione di Google descrive quelle fasi in dettaglio. Il vantaggio del sito statico è più semplice: se il testo e i link sono già presenti nell’HTML scaricato, a Google non serve JavaScript per scoprirli.

“Ricorda che il rendering lato server o la pre-rendering restano un’ottima idea, perché rendono il tuo sito più veloce per utenti e crawler, e non tutti i bot sono in grado di eseguire JavaScript.”

È una formulazione di Google Search Central in Comprendere le basi della SEO per JavaScript. È anche l’argomento più forte per la SEO dei siti statici: la pre-rendering rimuove una dipendenza. Non crea rilevanza, autorevolezza, scrittura utile o un’architettura coerente (e anzi, delegherei volentieri tutto e quattro a un comando di build).

Anche la cache dei file statici è più semplice sugli edge del CDN. Eliminare il rendering per richiesta riduce una fonte di latenza e failure. La documentazione di Google sui Web Vitals definisce “buone prestazioni” come LCP entro 2,5 secondi, INP pari o inferiore a 200 millisecondi e CLS pari o inferiore a 0,1. Queste soglie vengono valutate al 75° percentile, separatamente per traffico mobile e desktop.

Non trasformare questa cosa in “i siti statici passano automaticamente i Core Web Vitals”. Un’immagine hero da 3 MB, font che bloccano il rendering, script di terze parti e un bundle di hydration grande possono comunque rovinare LCP o INP. L’architettura statica ti dà spazio per ottenere performance solide. Non impone un budget degli asset.

Inoltre, la velocità non fa classificare una pagina irrilevante. È infrastruttura, non un sostituto di domanda, contenuti o link.

Il test “view-source” intercetta il più grande fallimento Jamstack in ottica SEO

Un sito statico può comunque essere un’app JavaScript con addosso una “scatola” statica.

Le Astro islands, i widget React, le griglie prodotti caricate lato client, i componenti recensioni, i commenti e le liste “carica altro” possono popolare solo dopo l’hydration. Se i contenuti rilevanti per la SEO arrivano tramite una richiesta API lato browser, non sono presenti nella risposta iniziale. A quel punto torni in territorio di JavaScript SEO, anche se il deployment contiene file HTML.

Google descrive direttamente il problema dell’app-shell: “l’HTML iniziale non contiene il contenuto reale”, quindi Google deve eseguire JavaScript prima di poter vedere il contenuto generato. Nella stessa documentazione dice anche che una pagina può restare nella coda di rendering “per pochi secondi, ma può volerci di più”. Alcuni bot non possono eseguire JavaScript affatto.

Apri l’URL pubblicato e usa view-source. Non affidarti al pannello Elements di DevTools perché mostra il DOM dopo che gli script lo hanno modificato. Cerca nel codice la headline, diverse frasi distintive, link importanti, dettagli prodotto e gli attributi alt delle immagini.

Se mancano, sposta i dati nella build. Recuperali durante la generazione e fai renderizzare nell’HTML prodotto l’articolo, la lista, le recensioni o le informazioni del prodotto. Tieni il JavaScript del browser per l’interazione, non come contenuto primario. La guida al framework spiega come tenere i contenuti di Next.js, React e Nuxt dalla parte corretta di questo confine.

Questo test l’ho fallito su pagine che in Chrome sembravano perfettamente complete. Il browser aveva recuperato i dati abbastanza in fretta da far sembrare tutto a posto durante la revisione, mentre in view-source c’era poco più di un elemento root e i riferimenti agli script. Un segno di spunta verde sul deployment non è un test di indicizzazione (né, purtroppo, lo è “funziona sul mio computer”).

È la distinzione che mi interessa di più, tra i siti statici che verifichiamo su SEOJuice. La scelta del framework riceve molta attenzione, ma il crawler riceve una risposta HTTP, non le tue intenzioni architetturali.

Il lavoro SEO che il tuo generatore ti lascia addosso

Genera e verifica la XML sitemap

Il comportamento delle sitemap varia in base al generatore. Hugo genera sitemap.xml di default; la sua documentazione include persino una sezione su la disabilitazione della generazione della sitemap, che è una spia che è attiva a meno che tu non la spenga.

Una sitemap minima valida ha un blocco url per pagina:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-07-19</lastmod>
  </url>
</urlset>

Astro adotta un approccio diverso. La sua documentazione sulla sitemap dice che @astrojs/sitemap ha bisogno dell’URL del sito pubblicato prima di poter generare una sitemap. Una volta configurata, l’integrazione aggiunge file sitemap index e sitemap nella directory di output.

Per altri generatori, controlla la documentazione attuale e l’ecosistema di plugin invece di dare per scontato che esista una sitemap. Il test non è se una dipendenza compare nel tuo file package. Il test è se la sitemap pubblicata carica, restituisce il content type corretto e contiene gli URL di produzione che vuoi davvero indicizzare.

Poi verifica un esempio. Cerca host di staging, varianti slash non canoniche, URL con parametri, sezioni mancanti e pagine che dovrebbero essere escluse. Una sitemap può essere sintatticamente valida mentre descrive il sito sbagliato.

Astro merita attenzione extra perché l’URL del sito configurato è utile anche per costruire URL assoluti. Il nostro Astro SEO checklist approfondisce sitemap, canonical e problemi specifici delle island.

Costruisci i canonical a partire dall’URL di produzione

In genere i generatori di siti statici non decidono da soli gli URL canonical per te. Il tuo layout deve generare un canonical per ogni pagina indicizzabile usando l’URL base di produzione e il path normalizzato della pagina. Un dominio di staging o un valore localhost “infornato” nella produzione indica ai motori di ricerca la versione sbagliata.

Anche i canonical relativi sono un’ambiguità evitabile. Genera URL assoluti e poi definisci un’unica policy per slash finali, file index e maiuscole/minuscole negli URL. Il tuo canonical, i link interni, le voci della sitemap e le regole di redirect dovrebbero essere coerenti.

Abbiamo spostato SEOJuice da seojuice.io a seojuice.com a gennaio 2026. La navigazione visibile era la parte facile. La migrazione vera includeva tag canonical, voci di sitemap, link interni, URL per dati strutturati, riferimenti ad asset e redirect a livello di host. Un vecchio hostname incorporato in un template condiviso può essere copiato in ogni pagina generata prima che chiunque se ne accorga (un modo sorprendentemente efficiente per scalare un errore).

Non mi fido di un componente canonical universale copiato tra framework. Base path, comportamento degli slash, helper per gli URL e variabili d’ambiente differiscono. Controlla l’HTML finale all’URL finale. I template sono dettagli implementativi; l’output pubblicato è ciò che ricevono i crawler.

Smetti di distribuire un solo title in tutto il sito

I title delle pagine, le meta description, i campi Open Graph e i tag social provengono di solito da front matter passati a un layout condiviso. Se il front matter manca o il fallback è troppo generico, centinaia di pagine possono ereditare un solo title indistinto.

Rendi espliciti nell’architettura dei contenuti i metadati essenziali. Dai a ogni pagina indicizzabile un title unico e descrittivo e una description pertinente. Definisci logiche di fallback per casi prevedibili, ma non permettere che una stringa di brand a livello sito diventi silenziosamente il title di ogni pagina.

Poi fai crawl del sito generato per duplicati, valori vuoti, tag malformati e valori inaspettatamente lunghi. La generazione statica crea coerenza, inclusa la coerenza degli errori.

Aggiungi dati strutturati alla pagina reale

Google Search Central definisce dati strutturati come “un formato standardizzato per fornire informazioni su una pagina e classificare il contenuto della pagina”. Google raccomanda JSON-LD e afferma che il markup deve essere inserito nella pagina che descrive.

L’oggetto deve corrispondere ai contenuti visibili e includere tutte le proprietà richieste per essere idoneo a una presentazione migliorata in Search. L’idoneità non è una garanzia di rich result. Lo schema chiarisce il significato per le macchine; non costringe Google ad abbellire un risultato.

Genera i dati strutturati dalla stessa fonte della pagina visibile, quando possibile. Duplicare nomi prodotto, prezzi, date e informazioni sull’autore in campi manuali separati crea disallineamenti. Dopo il deployment, valida i tipi di pagina rappresentativi: non limitarti a verificare il template JSON-LD in isolamento.

Scrivi i fondamentali, quelli poco “glamour”

Ti servono ancora un file robots.txt corretto, testo alt utile per le immagini, livelli di heading coerenti, anchor descrittivi e link interni. La generazione statica non impedisce pagine orfane. Un URL può esistere nella directory di output e nella sitemap, restando però scollegato dai percorsi che utenti e crawler seguono.

Da quello che vediamo nei siti che usano SEOJuice, spesso questo è il punto in cui una “bella architettura” smette di aiutare. Il sito si builda in fretta e si serve in fretta, ma le pagine correlate non sono collegate, la copertura dei metadati è irregolare e i contenuti vecchi stanno a più livelli di distanza rispetto a qualsiasi pagina attuale. Nessuno di questi difetti richiede una migrazione di framework. Richiede manutenzione.

Lavoro noioso, perlopiù. Ma con un impatto concreto.

I redirect stanno su host o CDN

Un deployment puramente statico non ha un router applicativo lato server attivo per ogni richiesta. Perciò i redirect vanno messi nello strato di hosting o nel CDN, non in un componente lato client.

La documentazione di Netlify dice che il suo motore di redirect elabora la prima regola che combacia dall’alto verso il basso e usa 301 di default. L’ordine conta. Una wildcard troppo ampia sopra una regola di migrazione specifica può intercettare la richiesta per prima.

Vercel espone redirect, clean URL e comportamento degli slash come configurazione di progetto. Cloudflare Pages supporta anche un file _redirects, ma di default usa 302 invece del 301 di Netlify. Imposta esplicitamente lo stato quando intendi uno spostamento permanente (ho dovuto controllare quella differenza due volte; nomi file identici incoraggiano l’assunzione sbagliata).

Mantieni la mappa dei redirect vicino alla sorgente e testa le vecchie URL dopo il deployment. Copri pagine rinominate, articoli consolidati, varianti di dominio, cambi di protocollo e la policy sugli slash che hai scelto. Testa status restituito e destinazione, incluse eventuali catene di redirect.

Un router lato client che vede un vecchio path e cambia l’URL nel browser non è equivalente. La risposta originale rimane un 200 o un 404 e i client non-JavaScript non ricevono mai il redirect previsto.

Le funzionalità dinamiche vanno bene fuori dal percorso del contenuto principale

I form possono usare una feature dell’host, un endpoint di terze parti o una funzione serverless. L’interazione dell’invio non è contenuto indicizzabile, ma la pagina dovrebbe includere testo pre-renderizzato che spiega cosa fa il form.

La ricerca lato client può usare un indice locale o una API ospitata. In generale, i risultati di ricerca non dovrebbero diventare l’unico percorso di scoperta per i tuoi contenuti. Ogni risultato importante ha bisogno del suo URL statico e di almeno un link interno indicizzabile, esterno all’interfaccia di ricerca.

I commenti e i widget di recensione richiedono più attenzione. Se si “idratano” dopo il caricamento, il loro contenuto potrebbe non esistere nell’HTML originale. Quando le recensioni supportano davvero una pagina prodotto, renderizza il contenuto delle recensioni rilevanti durante la build e genera dati strutturati accurati a partire dalla stessa fonte.

Personalizzazione, raccomandazioni ed esperimenti possono rimanere lato client se la pagina principale non dipende da loro. La mia regola è netta: definisci i contenuti indicizzabili durante la build; aggiungi l’interazione opzionale nel browser.

Un processo di rilascio che intercetta i difetti SEO dei siti statici

1. Fai build con configurazione di produzione. Verifica che hostname reale e base path siano disponibili ai template.
2. Ispeziona l’HTML grezzo. Controlla title, description, canonicals, heading, link, alt text, JSON-LD e contenuto primario.
3. Apri sitemap e robots.txt. Verifica che entrambi siano pubblicati e coerenti internamente.
4. Disattiva JavaScript. Controlla che informazioni principali e navigazione restino disponibili.
5. Testa le vecchie URL. Verifica che l’host restituisca lo status previsto e la destinazione finale.
6. Misura pagine rappresentative. Confrontale con le soglie LCP, INP e CLS invece di dare per scontato che “static” significhi veloce.
7. Fai crawl dopo il deployment. Trova metadati duplicati, canonicals mancanti, pagine orfane, link rotti e codici di stato non previsti.

Esegui questo processo per tipologie di pagina, non solo per la homepage. Articoli del blog, pagine prodotto, paginazione, archivi tag, pagine della documentazione e landing page spesso usano layout diversi. Una homepage sana ti dice praticamente nulla su mille URL generate.

Per le migrazioni, conserva l’elenco delle vecchie URL e testalo automaticamente dopo il rilascio. Durante il trasferimento del dominio su SEOJuice abbiamo imparato che i check di migrazione devono includere ciò che gli utenti non possono vedere quanto ciò che possono vedere. I canonical e gli identificatori dei dati strutturati si perdono facilmente in una revisione visiva.

Dove si inserisce SEOJuice, e dove no

SEOJuice applica in continuo link interni, meta title e description, markup schema e testo alt delle immagini su un sito live. Si può installare tramite uno snippet JavaScript o un plugin WordPress/CMS ed è disponibile un piano gratuito senza bisogno di carta di credito.

Esiste un confine importante per i siti statici. Metadati, schema e link inseriti tramite snippet dipendono dal rendering lato client, quindi non sono presenti nell’HTML originale della fase di crawl e potrebbero non essere disponibili ai bot non-JavaScript. Mantieni nel file HTML generato, quando controlli la build, i contenuti principali, i canonical, i title e le description essenziali e i JSON-LD critici. Usa lo snippet per lavori incrementali “on-page” che possono degradare con grazia, non come scusa per pubblicare una shell vuota.

SEOJuice non sostituisce nemmeno la tua sitemap, i redirect sul CDN, l’architettura di build o la strategia dei contenuti. Se vuoi capire quali parti dello strato on-page mancano, parti dal free SEO audit. Correggi prima i problemi strutturali nella build, poi automatizza lo strato ripetitivo solo dove questo compromesso ha senso.

Domande frequenti

I siti statici sono adatti alla SEO?

Sì, come architettura di partenza. L’HTML pre-renderizzato rimuove la dipendenza dal rendering JavaScript per i contenuti presenti nella sorgente, mentre la consegna via CDN rende più facile raggiungere prestazioni solide. Ti servono comunque contenuti rilevanti, metadata, canonical, una sitemap, dati strutturati, link interni e redirect.

I siti statici hanno bisogno di una XML sitemap?

Sì. Hugo genera sitemap.xml di default, mentre Astro richiede l’integrazione della sitemap e un URL del sito configurato. Altri generatori potrebbero richiedere una configurazione specifica del progetto o un plugin. Ispeziona la sitemap pubblicata invece di presumere che la build l’abbia creata correttamente.

Jamstack è buono per la SEO?

Jamstack può offrire gli stessi vantaggi di markup pre-renderizzato e consegna via CDN delle altre architetture statiche. Il rischio emerge quando contenuti importanti vengono recuperati tramite API lato browser. Se mancano dall’HTML generato, Google deve eseguire JavaScript per vederli e altri bot potrebbero perderli del tutto.

Come imposto i redirect su un sito statico?

Configura i redirect su host o CDN. Netlify supporta _redirects e netlify.toml, Vercel usa la configurazione di progetto e Cloudflare Pages supporta un file _redirects. Specifica deliberatamente gli status permanenti, tieni le regole sotto version control e testa la risposta HTTP dopo il deployment.

Google indicizza JavaScript su siti statici?

Google può eseguire JavaScript, ma il rendering avviene dopo il crawling e potrebbe essere rimandato. Google nota anche che non tutti i bot sono in grado di eseguire JavaScript. Se il contenuto principale appare solo dopo l’hydration, renderizzalo nell’HTML generato invece di dipendere dall’esecuzione in browser.

I siti statici richiedono ancora meta tag e tag canonical?

Sì. I generatori di siti statici non inventano in modo affidabile title unici, description, tag Open Graph o URL canonical per ogni progetto. Generali dai dati della pagina, usa l’URL base di produzione per i canonical assoluti e ispeziona l’HTML finale per duplicati o valori di staging.