SEO per Astro

TL;DR — Astro è un’ottima scelta per la SEO. Per impostazione predefinita costruisce in anticipo le pagine come semplici file HTML, quindi quando arriva Google (o qualsiasi bot) il contenuto è già lì: non c’è da aspettare l’esecuzione di JavaScript. È anche molto veloce. L’unica cosa da sapere è che Astro ti offre HTML pulito, ma non aggiunge automaticamente title della pagina, sitemap o tag canonical. Devi configurarli tu (è facile).

Che cosa significa «Astro SEO»

Astro è un framework web per costruire siti. La sua idea centrale è «meno JavaScript». Mentre framework come React o Next.js spesso costruiscono la pagina nel browser usando JavaScript, Astro costruisce le pagine come semplici file HTML al momento della build e distribuisce quasi zero JavaScript, a meno che una parte della pagina non ne abbia davvero bisogno. Evidence for this claim Astro prerenders pages as static HTML by default and only sends client JavaScript for explicitly hydrated components. Scope: Astro default static output and islands architecture. Confidence: high · Verified: 2026-07-14 Astro: Why Astro

Questa sola differenza spiega perché Astro sia così favorevole ai motori di ricerca. Quando un motore di ricerca scansiona una pagina, vuole leggerne il contenuto. Con un sito ricco di JavaScript, il contenuto a volte non è ancora nella pagina: il bot deve prima eseguire JavaScript e questo può essere ritardato. Con Astro il contenuto è già nell’HTML dal momento in cui la pagina viene caricata. Non c’è nulla da aspettare.

Gestisco il mio sito, patrickstox.com, con Astro: quindi per me non è teoria. È lo stack su cui costruisco davvero.

Perché Astro è adatto alla SEO

• Il contenuto è subito nell’HTML. Nessun ritardo di rendering, nessun contenuto mancante.
• È veloce. I siti Astro sono leggeri e tendono a ottenere ottimi risultati nelle metriche di esperienza della pagina di Google (Core Web Vitals).
• Ogni pagina è un vero URL autonomo. Nessun routing elaborato da single-page app che possa confondere i crawler.
• JavaScript viene caricato solo dove serve. Una galleria fotografica o una casella di ricerca può essere interattiva senza rallentare il resto della pagina.

Che cosa Astro NON fa per te

Questo manda in confusione. «Astro è ottimizzato per la SEO» è vero solo a metà. Astro offre una base pulita, ma non fa automaticamente queste cose:

• Scrivere i title e le meta description delle pagine.
• Generare una sitemap (aggiungi un plugin ufficiale gratuito per farlo). Evidence for this claim Astro's official sitemap integration generates sitemap files from statically generated routes. Scope: Astro @astrojs/sitemap integration. Confidence: high · Verified: 2026-07-14 Astro: Sitemap integration
• Aggiungere i tag canonical (che comunicano a Google la versione «ufficiale» di una pagina).
• Aggiungere i dati strutturati (il codice che alimenta i risultati avanzati).
• Creare un file robots.txt.

Nulla di tutto questo è difficile: devi solo configurarlo tu. Pensa ad Astro come a una grande cucina: gli elettrodomestici sono eccellenti, ma devi comunque cucinare.

La checklist iniziale semplice

• Aggiungi una sitemap con il plugin ufficiale @astrojs/sitemap.
• Imposta un title, una description e un URL canonical su ogni pagina (di solito a partire da un unico file di layout condiviso).
• Usa il componente Astro integrato <Image /> per le foto: le fa caricare velocemente e impedisce che la pagina salti.
• Metti un file robots.txt nella cartella public/.

Vuoi la versione approfondita — Server Islands, View Transitions, rendering statico rispetto a quello server e gli errori esatti da evitare? Passa alla scheda Advanced. Per il quadro più ampio di come i motori di ricerca gestiscono JavaScript, consulta JavaScript SEO.

TL;DR — Astro è architetturalmente ben predisposto per la SEO: per impostazione predefinita pagine ed endpoint vengono prerenderizzati in HTML statico, quindi per quel contenuto non c’è un’ondata di coda di rendering da aspettare; ma è un’impostazione predefinita, non una garanzia universale, e HTML statico/server da solo non dimostra scansionabilità, indicizzazione, ranking o Core Web Vitals per i tuoi URL in produzione. L’architettura a isole idrata solo i componenti che contrassegni con una direttiva client:*: tutto il resto distribuisce HTML senza il proprio JavaScript di hydration, anche se gli script della pagina, altre isole e i miglioramenti del router possono aggiungere JavaScript altrove nella pagina. Astro non genera automaticamente meta tag, canonical, sitemap o dati strutturati: collegali esplicitamente, idealmente validandoli tramite Content Collections + Zod. Le Server Islands (che richiedono un adapter) servono il guscio statico con contenuto di fallback nel documento iniziale e recuperano il contenuto differito in modo indipendente dopo: verifica cosa recupera davvero un determinato crawler invece di darlo per scontato. Le View Transitions usano history.pushState e sono sicure per la SEO; Google scansiona normalmente le pagine MPA sottostanti. Gestisco patrickstox.com con Astro e le funzionalità sotto sono quelle che uso davvero, validate sul sito distribuito, non solo nello sviluppo locale.

Perché Astro evita del tutto il problema del rendering JavaScript

Il motivo per cui la SEO JavaScript è difficile è la seconda ondata. Google recupera prima l’HTML grezzo, poi accoda la pagina per il rendering successivo in Chromium headless: ed è quella coda il rischio. La documentazione di Google lo descrive così: “Googlebot queues all pages with a 200 HTTP status code for rendering unless a robots meta tag tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that.” (traduzione) «Googlebot mette in coda per il rendering tutte le pagine con stato HTTP 200, a meno che un meta tag robots non dica a Google di non indicizzare la pagina. La pagina può restare in questa coda per pochi secondi, ma può volerci più tempo». Per una SPA renderizzata dal client, il contenuto non esiste finché non viene eseguita quell’ondata di rendering.

La modalità di output predefinita di Astro è statica: pagine ed endpoint vengono prerenderizzati in un file HTML completo al momento della build. Quindi, per una route che usa questa modalità predefinita, l’HTML grezzo è la pagina renderizzata. Evidence for this claim Astro uses static output and prerenders routes at build time by default. Scope: Astro default output mode; routes can opt out of prerendering. Confidence: high · Verified: 2026-07-14 Astro: On-demand rendering Non c’è una seconda ondata da aspettare per quella route, perché non resta nulla da eseguire. Googlebot vede il contenuto completo al primo fetch. Come dice Joost de Valk (fondatore di Yoast), “From an SEO perspective, static HTML on a CDN is a better starting point than most CMSes will ever give you.” (traduzione) «Dal punto di vista SEO, l’HTML statico su una CDN è un punto di partenza migliore di quello che la maggior parte dei CMS potrà mai offrirti».

Questa è però la modalità predefinita, non una proprietà universale di ogni route. Imposta output: 'server' e la modalità predefinita passa al rendering on demand (ne parleremo sotto); anche in un progetto con predefinito statico, un adapter permette a una singola route di rinunciare al prerendering con export const prerender = false. Nulla di tutto questo è garantito dalla sola architettura: HTML statico o server, isole e adapter non garantiscono da soli scansionabilità, indicizzazione, ranking o Core Web Vitals. Dipendono dalla route distribuita e dal crawler specifico, quindi verificali invece di presumere che sia il framework a gestirli.

Questo aiuta anche con i crawler che non possono fare rendering. Google nota chiaramente che “not all bots can run JavaScript” (traduzione) «non tutti i bot possono eseguire JavaScript» — ed è la realtà del 2026 per la maggior parte dei crawler AI e molti strumenti di terze parti. L’output HTML-first di Astro è leggibile da ognuno di loro quando è davvero prerenderizzato, non soltanto da Googlebot. (È lo stesso punto che sostengo in SEO per un CMS headless: la modalità di rendering è il prodotto.)

Architettura a isole: JavaScript solo dove lo chiedi

Astro renderizza i tuoi componenti in HTML e, per usare le sue parole, distribuisce “just HTML & CSS, stripping out all client-side JavaScript automatically.” (traduzione) «solo HTML e CSS, eliminando automaticamente tutto il JavaScript lato client». L’interattività è opt-in. Contrassegni un componente con una direttiva client:* — client:load, client:idle o client:visible — e solo quell’isola viene idratata con JavaScript. Tutto il resto rimane HTML statico. Evidence for this claim Astro client directives selectively hydrate interactive islands while other components remain static HTML. Scope: Astro islands and client directives. Confidence: high · Verified: 2026-07-14 Astro: Islands

Per la SEO è quasi ideale. Il contenuto che Googlebot deve indicizzare è semplice HTML e i widget interattivi non lo trascinano verso il basso. client:visible è particolarmente utile: un componente sotto la piega non inizia nemmeno a idratarsi finché non entra nella viewport, quindi non blocca mai il tuo LCP. Il concetto viene da Jason Miller (creatore di Preact), che ha descritto “rendering HTML pages on the server, and inject[ing] placeholders or slots around highly dynamic regions” (traduzione) «renderizzare pagine HTML sul server e iniettare placeholder o slot attorno a regioni altamente dinamiche» per l’hydration selettiva.

Due sfumature richiedono precisione, perché i contenuti dei concorrenti tendono a confonderle:

• client:only è un’altra cosa. A differenza di client:load/client:idle/client:visible, un componente client:only salta interamente il rendering server: sul server non produce HTML. Qualsiasi contenuto indicizzabile collocato solo dentro un componente client:only non è nel documento recuperato da Googlebot; esiste solo dopo che il browser lo idrata. Non mettere lì il contenuto principale.
• Questa è hydration selettiva, non resumability. Astro riesegue da zero nel browser il codice client di ogni isola; non riprende uno stato di esecuzione serializzato sul server come fa un modello di resumability (quello di Qwik, per esempio). Nei contenuti scritti le due cose vengono confuse: non sono lo stesso meccanismo.

E un componente non idratato non esaurisce il quadro JavaScript della pagina. «Zero JS» descrive un componente senza una direttiva client:*: Astro può comunque distribuire tag <script> a livello di pagina, il router View Transitions e altre isole altrove nella stessa pagina. Descrivi ciò che viene distribuito per componente/route, non fare un’affermazione assoluta sulla pagina.

Che cosa Astro NON fa automaticamente

Astro genera HTML semantico pulito — e, per la SEO, nient’altro. Non ci sono metadati, canonical, sitemap o dati strutturati pronti all’uso. Il mito che «Astro sia automaticamente ottimizzato per la SEO» è proprio questo: un mito. Sono responsabilità tue:

• Meta tag (title, description, Open Graph, Twitter)
• URL canonical
• La sitemap (tramite l’integrazione ufficiale)
• Dati strutturati / JSON-LD
• robots.txt

Astro è la base migliore che abbia usato, ma è una base, non una casa finita.

La sitemap: @astrojs/sitemap

Installala con npx astro add sitemap. Esegue il crawling delle route generate staticamente ed emette una sitemap-index.xml più file sitemap-0.xml suddivisi in blocchi al momento della build. Due cose causano problemi: Evidence for this claim Astro's official sitemap integration generates sitemap files from statically generated routes. Scope: Astro @astrojs/sitemap integration. Confidence: high · Verified: 2026-07-14 Astro: Sitemap integration

• Devi impostare site: in astro.config.mjs. Senza, l’integrazione non genera nulla in silenzio. È la causa più comune del «dov’è la mia sitemap?».
• Devi aggiungere tu la riga della sitemap a robots.txt. Astro non lo fa.

Per avere controllo, filter() esclude le route (pagine preview/draft — è esattamente ciò per cui lo uso su questo sito), serialize() permette di impostare lastmod/changefreq/priority e l’opzione i18n emette voci hreflang nella sitemap. È ciò che specifica la documentazione attuale di @astrojs/sitemap: se usi una release più vecchia, verifica la versione installata, perché il comportamento dell’integrazione è già cambiato tra major version.

L’ambito che trae in inganno: l’integrazione scopre le route generate staticamente. Se alcuni URL esistono solo a runtime — route renderizzate server (output: 'server') o generate on demand invece che al momento della build — non dare per scontato che siano nella sitemap. Aggiungili esplicitamente con customPages, poi apri davvero sitemap-index.xml dopo una build per confermare che ci siano. Non fidarti dell’idea che «l’integrazione gestisca tutto» per una route statica che non è di build time.

Meta tag e canonical: il pattern BaseLayout

Astro non ha uno speciale componente <Head>: controlli direttamente <head> nei file .astro. Il pattern standard (e quello che uso io) è un unico BaseLayout.astro che riceve title, description e canonicalURL come props e scrive l’head. Imposta il canonical esplicitamente su ogni pagina e mantienilo coerente con og:url. Non ti serve una libreria, ma il pacchetto community astro-seo (npm) è un comodo wrapper a componente unico per title/description/OG/Twitter/canonical, se lo desideri.

Content Collections come rete di sicurezza SEO

Questa è la funzionalità SEO sottovalutata di Astro. Le Content Collections sono un livello di contenuti type-safe per Markdown/MDX/JSON, con validazione dello schema Zod. Questo significa che puoi rendere obbligatori title e description: se una pagina ne manca uno, la build fallisce. Non puoi distribuire per errore una pagina senza title. Le funzioni di query (getCollection(), getEntry()) generano pagine statiche al momento della build, quindi l’output è semplice HTML quando viene distribuito. E poiché MDX conserva il markdown grezzo come fonte di verità, quei file sono anche contenuti sorgente puliti per i crawler AI e i pattern in stile llms.txt. Questo stesso sito è costruito con Content Collections e frontmatter validato da Zod.

astro:assets: immagini fatte bene (con una trappola)

Il componente <Image /> converte automaticamente in WebP, deduce le dimensioni per “avoid Cumulative Layout Shift (CLS),” (traduzione) «evitare il Cumulative Layout Shift (CLS)», imposta loading="lazy" per impostazione predefinita e richiede alt: un alt mancante è un errore di compilazione. <Picture /> estende il comportamento con elementi <source> AVIF/WebP/fallback.

La trappola è che il loading="lazy" automatico è sbagliato per la tua immagine LCP (di solito l’hero). Il caricamento lazy dell’immagine più importante la ritarda. Per le immagini above-the-fold, sostituiscilo con loading="eager" e fetchpriority="high". Le immagini remote richiedono width e height espliciti.

Server Islands: cosa vedono davvero i crawler

Le Server Islands (Astro 4.12+) sono la funzionalità che la maggior parte delle guide concorrenti sbaglia. Con server:defer, un componente viene renderizzato sul server indipendentemente dalla pagina principale. Il guscio statico viene servito subito; secondo la documentazione di Astro, “Your page will be rendered immediately with any specified fallback content as a placeholder. Then, the component’s own contents are fetched on the client and displayed when available.” (traduzione) «La pagina viene renderizzata immediatamente con l’eventuale contenuto di fallback specificato come segnaposto. Poi i contenuti del componente vengono recuperati sul client e mostrati quando disponibili».

Due cose richiedono precisione. Primo, le Server Islands richiedono un adapter: sono una funzionalità on demand, non qualcosa che una build completamente statica produca da sola. Secondo, la sequenza è questa: il documento iniziale viene distribuito con il contenuto di fallback configurato e il contenuto reale dell’isola viene recuperato con una richiesta separata e indipendente dopo il caricamento della pagina, tramite un proprio endpoint. Questo stabilisce un limite netto per ciò che contiene il primo documento: non generalizzerei oltre su ciò che ogni crawler specifico recupera dopo, senza testare direttamente i tuoi URL distribuiti.

La conseguenza SEO è concreta: l’HTML statico che un crawler legge al primo fetch contiene il contenuto di fallback, non quello dell’isola differita. È perfetto per ciò a cui servono le Server Islands — dati personalizzati e specifici della sessione (stato di accesso, conteggio del carrello, raccomandazioni) che non dovrebbero comunque essere messi in cache o indicizzati. È sbagliato per il contenuto principale indicizzabile. Metti tutto ciò che deve posizionarsi nel template principale Astro e lascia alle Server Islands i dettagli dinamici che lo circondano.

Modalità di output: statico rispetto a server e override per route

La modalità di output predefinita di Astro è static: pagine ed endpoint vengono prerenderizzati in HTML al momento della build. Imposta output: 'server' in astro.config.mjs e la modalità predefinita passa al rendering on demand: le pagine vengono renderizzate per richiesta (con un adapter), utile per autenticazione, dati in tempo reale o personalizzazione oltre ciò che coprono le Server Islands. In entrambi i casi puoi sostituire la modalità predefinita per route: in un progetto con predefinito statico, export const prerender = false abilita il rendering on demand; in un progetto con predefinito server, export const prerender = true riporta una route al prerendering durante la build. Quindi «il mio sito è statico» o «il mio sito è SSR» raramente è vero per ogni route: controlla l’impostazione per route, non solo la configurazione al livello superiore.

Dal punto di vista della sola SEO, HTML prerenderizzato e HTML on demand sono equivalenti: entrambi consegnano HTML completo al primo fetch del crawler, dopo che hai effettivamente verificato che la route restituisca 200 con markup completo. Le route on demand possono trasmettere l’HTML in streaming e dati lenti o condizioni di rete possono ritardare blocchi successivi, quindi una risposta in streaming non dimostra automaticamente che ogni parte del contenuto sia arrivata: controlla, non presumere. La differenza reale tra le due modalità è operativa: il contenuto prerenderizzato resta fisso fino alla build successiva (o a un refresh runtime configurato separatamente) e viene servito direttamente dal bordo CDN; il contenuto on demand è sempre aggiornato, ma dipende dall’operatività corretta dell’adapter e del runtime in produzione. Non trattarla come una decisione SEO: scegli in base alla freschezza dei dati e alle operazioni, poi valida route distribuite, status, redirect e header della risposta invece di estrapolare da ciò che ha funzionato nello sviluppo locale.

View Transitions: sicure per la SEO, nonostante l’aspetto da SPA

<ClientRouter /> di Astro (in precedenza <ViewTransitions />) offre una navigazione morbida simile a una SPA usando l’API View Transitions del browser e la History API. Il fatto decisivo è che naviga con history.pushState, esattamente ciò che Google raccomanda per la navigazione lato client: Google avverte che gli URL basati su frammenti (#hash) sono qualcosa che “can’t reliably resolve” (traduzione) «non riesce a risolvere in modo affidabile». Soprattutto, le View Transitions sono un miglioramento lato browser. Quando Googlebot scansiona, richiede ogni URL e riceve una normale pagina HTML completa: la MPA sottostante non viene toccata. Le transizioni modificano solo ciò che una persona vede nel browser.

Quindi no, le View Transitions non trasformano il tuo sito Astro in una SPA e non rompono la SEO. Una lacuna da tenere presente è che la documentazione Astro sulle View Transitions non ha una sezione SEO, probabilmente per questo persiste il mito «rompe la SEO». Per verificare il tuo sito, recupera direttamente alcuni URL e conferma che ciascuno restituisca HTML completo: non fidarti, controlla la tua distribuzione.

Errori SEO comuni in Astro

1. Presumere che Astro gestisca la SEO per te. Gestisce l’HTML. Meta, canonical, sitemap e schema sono responsabilità tue.
2. Dimenticare site: nella configurazione: la sitemap non viene generata e non lo segnala.
3. Non aggiungere la sitemap a robots.txt: Astro non lo fa.
4. Caricare lazy l’immagine LCP: sostituisci il caricamento dell’hero con eager + fetchpriority.
5. Mettere contenuto indicizzabile in una Server Island: i crawler vedono il fallback, non il contenuto, e le Server Islands richiedono comunque un adapter.
6. Inseguire un punteggio Lighthouse perfetto e fermarsi lì. La velocità è un segnale di ranking, non il segnale di ranking. Una pagina vuota veloce non si posiziona: contenuto, link ed E-E-A-T fanno ancora il lavoro principale.
7. Mettere contenuto indicizzabile solo in un componente client:only. A differenza delle altre direttive client:*, client:only salta completamente il rendering server: per quel componente non c’è HTML finché il browser non lo idrata.
8. Trattare «Astro è statico/veloce» come una garanzia del risultato. HTML statico o on demand, isole e adapter sono meccanismi: non garantiscono da soli scansionabilità, indicizzazione, ranking o Core Web Vitals. Valida la route distribuita, non il diagramma dell’architettura.

Dove si colloca nel cluster

Astro è una risposta specifica e insolitamente favorevole alla SEO alle domande che JavaScript SEO solleva sul rendering, oltre a essere un frontend popolare per le configurazioni di CMS headless. Il lato prestazionale si collega direttamente ai Core Web Vitals nel cluster delle prestazioni web e la disciplina di test «il mio contenuto è davvero nell’HTML?» è la stessa dei cluster crawling e indicizzazione.

Anti-pattern SEO di Astro

Errori concreti che vedo davvero sui siti Astro, non ipotetici. Ciascuno riguarda la prevenzione, non la diagnosi: intercettali prima della distribuzione.

Trattare Astro come «ottimizzato per la SEO» già dalla configurazione iniziale

Astro offre HTML statico veloce e pulito, ed è davvero un grande vantaggio iniziale, ma non equivale a meta tag, canonical, sitemap o dati strutturati. Perché è sbagliato: i team distribuiscono pagine senza variazioni di <title>, senza canonical e senza sitemap perché «Astro gestisce la SEO», poi si chiedono perché nulla sia indicizzato come previsto. Fai invece così: collega fin dal primo giorno le props di BaseLayout.astro a title/description/canonical, aggiungi @astrojs/sitemap e tratta questi elementi come passaggi obbligatori della build, non come impostazioni predefinite.

Dimenticare site: in astro.config.mjs

È la spiegazione più comune per il «perché la mia sitemap è vuota». Perché è sbagliato: @astrojs/sitemap ha bisogno di un URL assoluto del sito per costruire voci <loc> assolute; senza site: impostato, l’integrazione non produce nulla in silenzio (nessun errore, nessun avviso). Fai invece così: imposta site: in astro.config.mjs prima di installare l’integrazione sitemap e controlla che sitemap-index.xml contenga davvero URL dopo la build successiva.

Lasciare la sitemap fuori da robots.txt

Installare @astrojs/sitemap non aggiunge una riga Sitemap: a robots.txt: è un passaggio manuale separato che molti presumono automatico. Perché è sbagliato: i motori di ricerca possono comunque trovare la sitemap se la invii in Search Console, ma perdi il percorso di scoperta passivo su cui fanno affidamento altri bot (e i crawler collegati a Bing/IndexNow). Fai invece così: aggiungi Sitemap: https://yoursite.com/sitemap-index.xml al tuo robots.txt in public/ e conferma che risponda dopo la distribuzione.

Lasciare loading="lazy" predefinito sull’immagine hero

Il componente <Image /> di Astro usa il caricamento lazy per impostazione predefinita: è la scelta giusta per le immagini sotto la piega e quella sbagliata per l’unica immagine che di solito è il tuo elemento LCP. Perché è sbagliato: caricare lazy l’hero ritarda persino l’avvio della richiesta dell’immagine, danneggiando direttamente il punteggio Largest Contentful Paint. Fai invece così: sostituisci esplicitamente l’immagine hero/above-the-fold con loading="eager" e fetchpriority="high", lasciando tutte le altre immagini al caricamento lazy predefinito.

Mettere contenuto indicizzabile dentro una Server Island

server:defer è progettato per contenuti personalizzati e specifici della sessione — conteggi del carrello, stato di accesso, raccomandazioni — non per ciò che vuoi posizionare. Perché è sbagliato: l’HTML statico letto dal crawler contiene il contenuto di fallback specificato per l’isola, non quello recuperato lato client dopo il caricamento della pagina; quindi qualsiasi contenuto principale collocato lì è invisibile ai motori di ricerca al primo crawling. Fai invece così: mantieni il contenuto da posizionare nel template Astro principale e riserva le Server Islands esclusivamente ai dettagli dinamici e personalizzati che non dovrebbero essere indicizzati.

Supporre che un punteggio Lighthouse veloce sia il traguardo

I siti Astro mostrano Core Web Vitals forti quasi per impostazione predefinita ed è invitante fermarsi lì. Perché è sbagliato: la velocità è uno dei molti input del ranking; una pagina veloce, vuota o sottile non supera comunque una pagina più lenta con contenuti, link e profondità tematica migliori. Fai invece così: considera le prestazioni una condizione di base che Astro ti offre gratuitamente, poi dedica l’ottimizzazione vera alla qualità dei contenuti, ai link interni e al lavoro su dati strutturati e meta che Astro non svolge per te.

Supporre che «statico per impostazione predefinita» valga per ogni route

La modalità di output statico di Astro è predefinita, ma è un’impostazione, non una proprietà universale: output: 'server' la cambia e prerender può essere impostato per route in entrambe le direzioni. Perché è sbagliato: i team descrivono l’intero sito come «statico» o «SSR» in base alla configurazione di livello superiore e non controllano le singole route, poi si sorprendono quando una route si comporta diversamente in produzione. Fai invece così: controlla l’impostazione prerender per route di tutto ciò su cui stai ragionando e valida la risposta reale (status, markup completo, comportamento dei redirect) sull’URL distribuito, invece del solo file di configurazione.

Mettere il contenuto solo dentro un componente client:only

client:only non è uguale a client:load/client:idle/client:visible: salta completamente il rendering server. Perché è sbagliato: un componente che usa client:only non produce HTML sul server, quindi ciò che è indicizzabile e collocato solo lì è invisibile a un crawler che legge la risposta grezza; inoltre è facile scegliere client:only per «semplicità» senza rendersi conto del costo SEO. Fai invece così: renderizza il contenuto principale in un componente renderizzato sul server o nel template della pagina; riserva client:only ai widget di sola interazione che non contengono nulla di indicizzabile.

Riepilogo AI

Una sintesi della versione Advanced:

• La modalità di output predefinita di Astro esegue il prerendering in HTML statico al momento della build: per una route che usa quell’impostazione, l’HTML grezzo è la pagina completa, quindi il problema della coda di rendering di Google (la «seconda ondata») non si applica. È un’impostazione, non una proprietà universale: la modalità server la cambia e prerender può sovrascriverla per route in entrambe le direzioni.
• L’architettura a isole idrata solo i componenti contrassegnati con client:*; un componente senza direttiva distribuisce HTML senza il proprio JavaScript di hydration (anche se Astro può comunque aggiungere script della pagina, altre isole e JavaScript del router altrove). client:only è l’eccezione: salta completamente il rendering server, quindi il contenuto indicizzabile non dovrebbe stare solo lì. È hydration selettiva, non resumability. client:visible impedisce al JavaScript sotto la piega di bloccare l’LCP.
• Astro non genera nulla automaticamente per la SEO: meta tag, canonical, sitemap, dati strutturati e robots.txt sono tutti passaggi deliberati della build. «Astro è automaticamente ottimizzato per la SEO» è un mito.
• @astrojs/sitemap scopre le route generate staticamente, ma devi impostare site: nella configurazione (altrimenti non fa nulla in silenzio), aggiungere tu la riga della sitemap a robots.txt e aggiungere esplicitamente gli URL solo runtime tramite customPages.
• Content Collections + Zod possono rendere obbligatori title/description, facendo fallire la build se una pagina ne è priva: una rete di sicurezza SEO.
• astro:assets <Image> converte in WebP, imposta le dimensioni (previene il CLS), usa il caricamento lazy per impostazione predefinita e richiede alt. Sostituisci l’immagine LCP con loading="eager" + fetchpriority="high".
• Le Server Islands (server:defer) richiedono un adapter, servono immediatamente il guscio statico + il fallback nel documento iniziale e poi recuperano l’isola in modo indipendente. I crawler che leggono quel primo documento vedono il fallback, non l’isola: non collocare lì contenuto indicizzabile.
• L’output statico e quello on demand (server) sono equivalenti per la SEO dopo la verifica: entrambi consegnano HTML completo ai crawler al primo fetch, ma le route on demand possono usare lo streaming; quindi conferma che la risposta arrivi davvero completa. Scegli la modalità in base a freschezza dei dati e operatività, non alla SEO.
• Le View Transitions (<ClientRouter />) usano history.pushState e sono sicure per la SEO; Google scansiona normalmente le pagine MPA sottostanti. Sono un miglioramento lato browser, non una conversione a SPA.
• Nessuno degli elementi precedenti garantisce un risultato: HTML statico/server, isole e adapter sono meccanismi, non prove di scansionabilità, indicizzazione, ranking o Core Web Vitals. Valida la route distribuita.
• Astro presenta numeri forti di Core Web Vitals nel proprio benchmark 2023: oltre il 50% dei siti Astro ha superato la valutazione CWV di Google, ben sopra la baseline del settore dell’epoca; trattalo come un dato datato, non come una garanzia attuale.

Documentazione ufficiale

Documentazione di prima mano da Astro e dai motori di ricerca.

Astro

• Architettura a isole — come Astro elimina il JS lato client e idrata solo i componenti interattivi.
• Riferimento delle direttive dei template — client:load/idle/visible/only e server:defer, compreso ciò che client:only salta.
• Ottimizzazione delle immagini (astro:assets) — i componenti <Image>/<Picture>, WebP, dimensioni e CLS.
• @astrojs/sitemap — generazione automatica della sitemap, filter, serialize e i18n.
• Server Islands di Astro — server:defer, il requisito dell’adapter, il contenuto di fallback e il recupero differito sul client.
• Rendering on demand — modalità di output static/server, prerender per route e streaming HTML.
• Riferimento del routing — come pagine ed endpoint vengono prerenderizzati per impostazione predefinita.
• Riferimento delle API runtime di Astro — gestione di Response/redirect e status predefiniti.
• Raccolte di contenuti — contenuti type-safe con validazione dello schema Zod.
• Transizioni di visualizzazione — <ClientRouter /> e navigazione con History API.

Google

• Comprendere le basi della SEO JavaScript — la coda di rendering, i link scansionabili, la History API e la precisazione «non tutti i bot eseguono JavaScript».
• Guida approfondita al funzionamento della Ricerca Google — crawl → render → index e il punto in cui SSG elimina la fase di rendering.

Bing / Microsoft

• IndexNow / indexnow.org — il protocollo push che si abbina bene a una distribuzione Astro statica (collegalo al passaggio di pubblicazione così Bing e Yandex vengono informati subito delle nuove pagine).

Citazioni dalla fonte

Dichiarazioni pubbliche dalla documentazione di Astro, da Google e da professionisti nominati. Ogni link ai motori di ricerca e alla documentazione porta direttamente al passaggio citato nella pagina sorgente.

Google — la coda di rendering che Astro evita

• “Googlebot queues all pages with a 200 HTTP status code for rendering unless a robots meta tag tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that.” (traduzione) «Googlebot accoda per il rendering ogni pagina con stato HTTP 200, salvo che un meta tag robots ne impedisca l’indicizzazione. L’attesa può durare pochi secondi oppure più a lungo». Jump to quote
• “not all bots can run JavaScript” (traduzione) «non tutti i bot sono in grado di eseguire JavaScript» — per questo l’output HTML-first è utile oltre Googlebot. Jump to quote

Documentazione Astro — isole, immagini, sitemap, Server Islands

• “just HTML & CSS, stripping out all client-side JavaScript automatically.” (traduzione) «soltanto HTML e CSS, con la rimozione automatica di tutto il JavaScript lato client» — sull’architettura a isole. Jump to quote
• “infers image dimensions to avoid Cumulative Layout Shift (CLS).” (traduzione) «deduce le dimensioni delle immagini per evitare il Cumulative Layout Shift (CLS)» — sul componente Image. Jump to quote
• “Your page will be rendered immediately with any specified fallback content as a placeholder. Then, the component’s own contents are fetched on the client and displayed when available.” (traduzione) «La pagina viene renderizzata subito usando l’eventuale contenuto di ripiego come segnaposto; successivamente il client recupera i contenuti del componente e li mostra appena disponibili» — sulle Server Islands. Jump to quote

Jason Miller (creatore di Preact, ha coniato «islands architecture»)

• L’hydration selettiva funziona “rendering HTML pages on the server, and inject[ing] placeholders or slots around highly dynamic regions.” (traduzione) «renderizzando le pagine HTML sul server e inserendo segnaposto o slot attorno alle aree molto dinamiche». — citato in Astro Docs: Islands Architecture

Joost de Valk (fondatore di Yoast SEO)

• “From an SEO perspective, static HTML on a CDN is a better starting point than most CMSes will ever give you.” (traduzione) «In ottica SEO, l’HTML statico distribuito da una CDN offre una base migliore di quella raggiungibile con la maggior parte dei CMS». — Joost.blog: Astro SEO Complete Guide

Checklist SEO per Astro

Un controllo per confermare che un sito Astro sia davvero configurato per la ricerca, non solo appoggiato su una buona base:

• site: è impostato in astro.config.mjs (senza, la sitemap non viene generata e non lo segnala).
• @astrojs/sitemap è installato e il riferimento alla sitemap è stato aggiunto manualmente a robots.txt.
• Esiste un robots.txt in public/ e non blocca nulla di ciò che vuoi indicizzare.
• Ogni pagina imposta un title e una description unici (idealmente tramite un BaseLayout.astro condiviso).
• Un canonical autoreferenziale è presente su ogni pagina e corrisponde a og:url.
• Le Content Collections usano uno schema Zod che rende obbligatori title/description (la build fallisce se mancano).
• Le immagini usano <Image /> / <Picture />; tutte hanno alt (uno mancante è comunque un errore di compilazione).
• L’immagine LCP/hero sostituisce il lazy loading predefinito con loading="eager" e fetchpriority="high".
• Nessun contenuto indicizzabile vive in una Server Island (server:defer): i crawler vedono il fallback e le Server Islands richiedono un adapter per funzionare.
• Nessun contenuto indicizzabile vive solo dentro un componente client:only: salta il rendering server, quindi non c’è HTML finché il browser non lo idrata.
• Per ogni route che usa output: 'server' o prerender = false per route, conferma che gli URL solo runtime siano aggiunti esplicitamente alla sitemap (customPages): la scoperta automatica della sitemap mira alle route generate staticamente.
• I dati strutturati (JSON-LD) sono nell’<head> renderizzato dal server.
• Se <ClientRouter /> è abilitato, controlla a campione che ogni URL restituisca ancora HTML completo al fetch diretto.
• Route on demand/server: recupera direttamente un URL live di produzione e conferma status, comportamento del redirect e HTML completo della risposta; non estrapolare dallo sviluppo locale, perché adapter e runtime possono comportarsi diversamente.

Modelli mentali

1. L’HTML grezzo è la pagina completa, per la modalità predefinita di quella route. La modalità di output statica di Astro significa che per una route prerenderizzata non c’è alcuna ondata di rendering da aspettare: ciò che Googlebot recupera è ciò che viene indicizzato. È un’impostazione predefinita per route, non una garanzia per l’intero sito (output: 'server' e prerender per route possono cambiarla), quindi controlla la route, non solo la configurazione di livello superiore. Quando si applica, View Source è la verità (l’opposto di una SPA CSR), ma conferma prima che si applichi, prima di trattarlo come un fatto.

2. Una base, non una finitura e non una garanzia del risultato. Astro ti offre gratuitamente HTML pulito e una solida meccanica delle prestazioni. Tutto ciò che comunica significato ai motori di ricerca — meta, canonical, sitemap e schema — è un passaggio deliberato che aggiungi tu. «Buona architettura» ≠ «finito» e nessuna delle due è una prova di scansionabilità, indicizzazione o ranking: devono ancora essere validate sul sito distribuito.

3. Le isole sono additive, tranne client:only. L’interattività si appoggia all’HTML, non lo sostituisce, per client:load/client:idle/client:visible: quelle direttive aggiungono JS a un componente senza rimuovere il contenuto dalla base scansionabile. client:only rompe questo schema: salta del tutto il rendering server, quindi è una vera lacuna nell’HTML statico se non la consideri. E l’hydration delle isole è selettiva, non resumability: non confondere le due cose.

4. Il guscio statico è ciò che vedono i crawler. Per le Server Islands, il crawler legge il fallback nel guscio statico, non il contenuto differito. Regola decisionale: il contenuto indicizzabile va nel template principale; quello personalizzato/dinamico va nell’isola.

5. Miglioramento del browser ≠ cambiamento strutturale. Le View Transitions cambiano l’esperienza del browser (navigazione morbida tramite history.pushState), ma non l’esperienza di crawling (ogni URL è ancora una pagina HTML completa). I miglioramenti che lasciano intatta la MPA sottostante sono sicuri per la SEO.

6. Valida al momento della build. Content Collections + Zod trasformano «ricordati di aggiungere un title» in «la build non verrà distribuita senza title». Inserisci i requisiti SEO nel sistema dei tipi e smetteranno di essere cose che puoi dimenticare.

SEO per Astro — cheat sheet

Che cosa è automatico e che cosa spetta a te

Modalità di output

Direttive delle isole

• client:load — idrata immediatamente.
• client:idle — idrata quando il browser è inattivo.
• client:visible — idrata quando entra nella viewport (ideale sotto la piega; protegge l’LCP).
• client:only — salta completamente il rendering server. Non c’è HTML per questo componente finché il browser non lo idrata; non è additivo come gli altri.

Regole rapide

• site: mancante → nessuna sitemap (in silenzio).
• Contenuto indicizzabile in una Server Island → il crawler vede il fallback; le Server Islands richiedono un adapter.
• Contenuto indicizzabile solo dentro client:only → nessun HTML per quel contenuto, punto.
• La sitemap copre le route statiche → aggiungi gli URL solo runtime tramite customPages.
• Le View Transitions usano history.pushState → sicure per la SEO, con una MPA sottostante.
• Output statico/server e isole sono meccanismi, non garanzie: valida route distribuita, status e HTML completo prima di dichiarare un risultato.
• Una pagina vuota veloce non si posiziona comunque: la velocità è un segnale, non il segnale.

Verificare l’HTML costruito da Astro

Esegui questo controllo dopo astro build. Verifica l’artefatto che ricevono i crawler, non l’albero dei componenti sorgente:

find dist -name '*.html' -type f | while IFS= read -r file; do
  canonicals=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$file" | wc -l | tr -d ' ')
  titles=$(grep -Eio '<title>[^<]*</title>' "$file" | wc -l | tr -d ' ')
  if [ "$canonicals" -ne 1 ] || [ "$titles" -ne 1 ]; then
    printf '%s\ttitles=%s\tcanonicals=%s\n' "$file" "$titles" "$canonicals"
  fi
done

Un risultato vuoto significa che ogni file HTML generato ha esattamente un title e un canonical; non convalida che i loro valori siano corretti, quindi campiona quelli separatamente. Controlla solo l’artefatto della build: non dice nulla sulle route on demand (output: 'server') o sulle Server Islands, che non esistono come file statici.

Controllare a campione le route live in produzione

Per tutto ciò che viene renderizzato on demand — route output: 'server', disattivazione del prerendering per route o Server Islands — il controllo dell’output di build precedente non si applica. Controlla invece la risposta distribuita reale:

# Replace with your real URLs
for url in "https://example.com/" "https://example.com/some-server-route/"; do
  echo "== $url =="
  curl -sS -D - -o /dev/null "$url" | grep -Ei '^(HTTP|location|cache-control):'
done

Cerca lo status previsto (200 per una pagina live, un vero codice di redirect se reindirizza: non presumere 302 o 301 senza controllare) e conferma che curl -sS "$url" restituisca markup completo, non un guscio di fallback, se stai controllando una pagina che include una Server Island. Esegui il test in produzione, non con astro dev: il comportamento di adapter e runtime può differire da quello locale.

Strumenti per un sito Astro

• @astrojs/sitemap — l’integrazione ufficiale della sitemap (astro add sitemap). Non dimenticare site: nella configurazione.
• astro-seo (npm) — componente community opzionale che riunisce title, description, Open Graph, Twitter e canonical in un unico tag.
• astro-seo-schema (npm) — helper per dati strutturati JSON-LD tipizzati in Astro.
• astro:assets <Image> / <Picture> — ottimizzazione immagini integrata (WebP/AVIF, dimensioni, lazy loading e controllo di alt).
• URL Inspection (Google Search Console) — conferma che il contenuto sia nell’HTML scansionato (con Astro dovrebbe essere già in View Source: un controllo rapido di coerenza).
• Un crawler con rendering JS — Ahrefs Site Audit o Screaming Frog per verificare la parità tra grezzo e renderizzato in tutto il sito (sulle route prerenderizzate dovrebbero coincidere: confermalo, non darlo per scontato, e controlla separatamente ogni route on demand o Server Island).
• IndexNow — collegalo al passaggio di distribuzione/pubblicazione così Bing e Yandex vengano informati subito delle nuove pagine statiche.

Mettiti alla prova: SEO per Astro

Cinque domande rapide su come l’architettura di Astro influenza la SEO. Scegli una risposta per ciascuna, poi controlla.

Risorse che vale la pena consultare

I miei contenuti correlati

• JavaScript SEO: A Definitive Guide — i fondamentali del rendering che spiegano perché l’output HTML-first di Astro sia un vantaggio così grande.
• The Beginner’s Guide to Technical SEO — dove la scelta del framework si inserisce nel quadro più ampio.

I miei interventi

• How Search Works (SlideShare) — la mia spiegazione di crawling, rendering, indicizzazione e ranking, cioè la pipeline che il predefinito SSG di Astro abbrevia. (Avvertenza permanente: «Questa è la mia comprensione dei sistemi… non sarà completa o accurata al 100%».)

Dal settore

• Astro Docs: Islands Architecture — la spiegazione di riferimento di come Astro elimini il JS lato client.
• Astro Docs: @astrojs/sitemap — configurazione ufficiale, requisito site: e opzioni filter/serialize/i18n.
• Astro Docs: Server Islands — server:defer, contenuto di fallback e recupero sul client che i crawler non vedono.
• Joost de Valk: Astro SEO Complete Guide — la guida professionale più autorevole, del fondatore di Yoast; solida sui pattern moderni pronti per l’AI e su IndexNow.
• Google Search Central: Understand JavaScript SEO Basics — coda di rendering, link scansionabili e indicazioni sulla History API seguite dalle View Transitions di Astro.
• Astro: 2023 Web Framework Performance Report — i dati sui Core Web Vitals che confrontano Astro con altri framework.
• Search Engine Journal: Core Web Vitals, WordPress e Astro — analisi indipendente del confronto prestazionale tra Astro e WordPress.

Statistiche che vale la pena citare

Tutte le cifre seguenti provengono dall’Astro 2023 Web Framework Performance Report (e dalla copertura di SEJ): trattale come benchmark dell’epoca 2023, non come numeri attuali.

• Oltre il 50% dei siti Astro supera la valutazione Core Web Vitals di Google: sopra la media del settore, circa 40,5%, e Astro e SvelteKit erano gli unici framework principali a superare quella baseline (Next.js circa 25%, Nuxt circa 20%). Source
• Tasso di superamento INP del 68,8% per Astro: attribuito all’architettura MPA (senza navigazione guidata da JS), che lascia libero il thread principale. Source
• Peso mediano della pagina di 1,65 MB: il più leggero del dataset. Source
• LCP: Astro circa 0,44 s contro WordPress circa 0,81 s: circa il 46% più veloce nel confronto del report. Coverage

Cronologia modifiche