Astro SEO: come far posizionare un sito Astro sui motori di ricerca

TL;DR: Astro ti dà una solida base SEO perché effettua il prerendering di HTML statico e, per impostazione predefinita, rimuove il JavaScript lato client. Imposta site in astro.config.mjs, tieni i contenuti indicizzabili fuori dai componenti client:only e configura metadati univoci, canonical assoluti, una sitemap e un unico formato URL coerente. Poi ispeziona l’HTML generato. Una struttura dei componenti pulita non dimostra che la pagina pubblicata sia effettivamente crawlable.

Astro è valido per la SEO, ma non fa la SEO al posto tuo

La parte più forte della SEO in Astro non è un pacchetto SEO. È il modello di rendering di Astro.

“Per impostazione predefinita, Astro renderizza automaticamente ogni componente UI solo in HTML & CSS, rimuovendo automaticamente tutto il JavaScript lato client.”

Questa è la descrizione di Astro nella sua documentazione sull’architettura Islands. Astro “idrata” solo i componenti esplicitamente marcati per l’esecuzione nel browser, mentre il resto della pagina rimane come HTML statico.

Questa distinzione conta perché Google non tratta il download ed esecuzione di JavaScript come la stessa operazione.

“Google elabora le web app JavaScript in tre fasi principali: 1. Crawling 2. Rendering 3. Indicizzazione”

Google Search Central spiega inoltre che un headless Chromium rende la pagina una volta che le risorse di Google sono disponibili. Google può eseguire JavaScript, ma i contenuti che esistono solo dopo l’esecuzione dipendono da quella fase aggiuntiva. Il default di Astro basato su HTML statico elimina questa dipendenza, perché i contenuti significativi possono già essere presenti nella risposta. La nostra guida alla JavaScript SEO entra nel meccanismo in modo più approfondito.

Questa è un’autentica competenza tecnica. Non è un vantaggio automatico in termini di ranking. L’HTML statico non può rimediare a pagine sottili, titoli duplicati, link interni deboli, canonicalizzazione accidentale o contenuti che nessuno ha bisogno di leggere.

Astro fornisce un’infrastruttura decisamente ben fatta. Ma devi comunque collegarla.

Imposta prima l’URL del sito in produzione

Prima di aggiungere un componente SEO, configura site in astro.config.mjs:

La Configuration Reference di Astro definisce site come l’URL finale distribuito e dice che usa quel valore per generare sitemap e canonical URL. Il default è undefined e Astro raccomanda fortemente di impostarlo.

Una singola riga controlla diversi sistemi:

• Astro.site è indefinito se non lo imposti.
• @astrojs/sitemap lo richiede per generare gli URL della sitemap.
• @astrojs/rss lo usa per creare i link agli articoli.
• Canonical e URL delle immagini social richiedono un’origine produzione affidabile.

Abbiamo visto l’immagine speculare di questa dipendenza durante la migrazione da seojuice.io a seojuice.com nel gennaio 2026. Le canonical, le voci della sitemap, gli URL di Open Graph e i riferimenti interni dovevano convergere su una sola origine di produzione. Una migrazione rende il problema evidente; un valore site dimenticato nasconde la stessa classe di errore dentro una build altrimenti riuscita.

Imposta l’URL di produzione, fai build e verifica l’output prima di fare debug delle integrazioni a valle (una sola origine, più sintomi).

Crea un singolo componente head, non decine di varianti

Astro non fornisce un’astrazione speciale per i metadati. Titoli e descrizioni sono tag HTML ordinari. Per la maggior parte dei siti, l’approccio manutenibile è un layout condiviso che accetta valori specifici della pagina tramite Astro.props.

La prima e la terza riga sono le “frontmatter fences” di Astro. Ogni pagina o voce di contenuto dovrebbe fornire il proprio titolo e la propria descrizione. Un fallback è utile per intercettare dati incompleti, ma non lasciare che un default valido per tutto il sito diventi silenziosamente i metadati di ogni URL.

Preferisco validare i metadati obbligatori durante la build invece di scoprire omissioni settimane dopo in Search Console. Se una pagina pubblica di contenuto non ha titolo o descrizione, far fallire la build è spesso la scelta più gentile.

Dovresti usare il pacchetto astro-seo?

Il pacchetto della community astro-seo può racchiudere i tag comuni. Installalo con npm install astro-seo, importa SEO dal pacchetto e renderizza il componente all’interno della document head. Il suo repository elenca il supporto per titoli, descrizioni, canonical, direttive robots, Open Graph, Twitter card, title templates, alternates di lingua e tag personalizzati.

Chiarisci bene cosa sia: astro-seo è un componente di terze parti mantenuto da jonasmerlin, non un’integrazione ufficiale @astrojs. Lo userei quando la sua API elimina una ripetizione significativa. Per un piccolo sito marketing, un componente head locale spesso è più semplice da sottoporre a audit e più difficile da “superare” (meno dipendenze possono essere un vantaggio, non una preferenza estetica).

Tieni i metadati social accanto a quelli di ricerca

Open Graph e Twitter cards sono meta tag standard. Generali nello stesso componente head condiviso, così il titolo della pagina, la descrizione, la canonical URL e l’immagine non possono divergere in modo indipendente. Le immagini social dovrebbero usare URL assoluti basati su Astro.site; i percorsi relativi sono una causa comune per cui le anteprime funzionano su un servizio e falliscono su un altro.

Genera le canonical a partire dall’origine produzione e dal percorso corrente

Astro espone i due valori necessari per una canonical. Astro.site restituisce un URL basato sul sito di produzione configurato, mentre Astro.url rappresenta l’URL della richiesta corrente.

L’API Reference ufficiale mostra questo pattern:

In questo modo combini il percorso corrente con l’origine produzione, evitando che un hostname di sviluppo o di anteprima diventi canonical solo perché ha servito la richiesta (gli host di preview non dovrebbero ricevere “voti”).

Nota che lo schema usa Astro.url.pathname, non l’URL completo della richiesta. Quindi rilascia i parametri di query. In genere è corretto per i parametri di tracking e per pagine di contenuto ordinarie, ma non vale universalmente. Paginazione, collezioni filtrate e pagine davvero distinte con parametri richiedono una policy canonical esplicita.

Una canonical non è un marker generico “abilita la SEO”. È una dichiarazione su quale URL rappresenta la versione autorevole di una pagina. Controlla il valore finale.

Rendi la scelta degli slash finali una decisione deliberata

L’opzione trailingSlash di Astro ha un default ignore. Le impostazioni always e never impongono una forma per le route on-demand in produzione, mentre il default accetta entrambe le forme nello sviluppo e durante il rendering on-demand.

Per l’output statico, anche il comportamento dell’host e i file generati influenzano il risultato. Scegli una forma canonical, genera i link interni in quella forma e testa come l’host distribuito gestisce entrambe le varianti. Cambiare la configurazione di Astro da sola non garantisce che ogni host statico applichi i redirect che ti aspetti.

Il risultato che vuoi è accordo: link interni, canonical, voci della sitemap e redirect devono puntare tutti allo stesso formato URL. Il nostro SEO per sviluppatori guide copre la disciplina di implementazione più ampia dietro questa decisione.

Installa l’integrazione sitemap ufficiale

Esegui npx astro add sitemap per installare l’integrazione ufficiale @astrojs/sitemap di Astro.

Secondo la documentazione ufficiale sulla sitemap, l’integrazione ha bisogno dell’URL del sito distribuito, che deve iniziare con http:// oppure https://. Senza site, non genera una sitemap.

Dopo una build, Astro aggiunge sitemap-index.xml e sitemap-0.xml nella directory di output. L’indice richiama i file numerati della sitemap. Il limite predefinito è 45.000 voci per file; oltre questo, vengono creati altri file numerati (45.000 è una soglia di splitting, non un consiglio per “fabbricare” pagine).

Dopo la distribuzione, controlla più voci. Verifica protocollo, hostname, percorsi, convenzione degli slash e se sono entrate anche pagine private o di utilità. Poi apri anche l’indice della sitemap e segui i link figli. Ho visto file sitemap tecnicamente validi distribuiti in percorsi che nessuno aveva testato.

Una sitemap aiuta la scoperta; non obbliga l’indicizzazione. Per il resto del processo, vedi come funziona l’indicizzazione di Google.

La trappola delle “isole” Astro è specificamente client:only

Le isole di Astro non sono di per sé cattive per la SEO. Dire il contrario confonde idratazione selettiva con rendering client-only.

La directives reference di Astro dice che client:only “salta il rendering HTML lato server e fa il rendering solo sul client”. Qualsiasi cosa dentro quel componente non è presente nell’HTML iniziale renderizzato dal server e dipende dall’esecuzione di JavaScript.

Non inserire nel client:only testo degli articoli, descrizioni prodotto, risposte FAQ, navigazione primaria, link interni o altri contenuti indicizzabili. Riservalo alle interfacce che non possono renderizzare lato server e i cui contenuti non devono comparire nella risposta iniziale.

client:load, client:idle e client:visible sono diversi. Renderizzano l’HTML iniziale lato server e poi controllano quando avviene l’idratazione. Il problema non è React, Vue, Svelte o le isole in sé. Il problema è saltare il rendering lato server oppure recuperare contenuti essenziali solo ed esclusivamente nel browser.

Da quanto vediamo su diversi siti controllati con SEOJuice, il fallimento “rivelatore” nelle build basate su framework JavaScript spesso non è una sitemap mancante. È una pagina che sembra completa in un browser, mentre la parte di testo davvero importante manca nella risposta HTML grezza. In Astro, un confine client:only è un posto ovvio dove guardare per primo, anche se anche il fetch di dati solo lato browser può produrre lo stesso effetto.

Questa è un errore che ho fatto rivedendo solo la pagina renderizzata. Più precisamente, ho controllato ciò che il browser aveva ricostruito, non ciò che il server aveva restituito. Guardare la sorgente della risposta avrebbe chiuso l’indagine molto prima. È lo stesso problema “app-shell” di cui parliamo nelle nostre SPA SEO best practices.

Usa output statico a meno che il rendering on-demand risolva un problema reale

“Per impostazione predefinita, l’intero sito Astro verrà prerenderizzato e le pagine in HTML statico verranno inviate al browser.”

Questa informazione viene dalla guida al rendering on-demand di Astro. La modalità predefinita output: 'static' genera pagine durante la build. È la scelta più semplice per documentazione, articoli, landing page e contenuti prodotto che non dipendono da dati specifici della richiesta.

output: 'server' rende le pagine su richiesta e richiede un adapter per il runtime target, come Node, Netlify, Vercel o Cloudflare. Il rendering server può restituire HTML completo e non è intrinsecamente peggiore per la SEO. Aggiunge semplicemente infrastruttura runtime, latenza e un’ulteriore superficie di fallimento. Usalo perché la pagina ne ha bisogno, non perché SSR suona “più capace”.

Puoi combinare entrambi i comportamenti. In modalità statica, esporta prerender = false da una pagina che deve essere renderizzata on-demand. In modalità server, esporta prerender = true per una pagina che dovrebbe essere generata in anticipo.

Tutorial più vecchi potrebbero consigliare output: 'hybrid'. Astro 5 ha inglobato il vecchio comportamento ibrido in 'static'; la Astro 5 upgrade guide descrive 'hybrid' e 'static' come confluiti in una singola configurazione statica. I progetti attuali dovrebbero usare static o server con override di prerender per singola pagina.

Aggiungi RSS quando il sito pubblica contenuti ricorrenti

Astro fornisce il pacchetto ufficiale @astrojs/rss per feed generati tramite endpoint API. Installalo con npm install @astrojs/rss, poi crea un endpoint come src/pages/rss.xml.js che restituisce l’helper RSS con site: context.site e gli elementi del feed.

La documentazione Astro RSS richiede un sito configurato, perché quell’origine viene usata per generare i link agli articoli. È un’altra ragione per trattare site come una configurazione di base, non come un’opzione specifica della sitemap.

Ispeziona il sito buildato, non solo i componenti sorgente

I componenti di Astro possono sembrare corretti mentre l’output distribuito è sbagliato. Fai build e deploy, poi verifica:

1. La risposta HTML grezza contiene i contenuti principali e i link importanti.
2. Ogni pagina indicizzabile ha un titolo e una meta description adeguati.
3. La canonical è assoluta, usa HTTPS e punta all’hostname di produzione.
4. Canonical, link interni, redirect e URL della sitemap condividono una singola convenzione sugli slash.
5. Le immagini Open Graph e Twitter usano URL assoluti di produzione.
6. sitemap-index.xml esiste e fa riferimento a sitemap figli raggiungibili.
7. Nessun contenuto indicizzabile esiste solo dentro componenti client:only.
8. Le pagine pensate per essere statiche appaiono nell’output build generato.
9. Gli host di preview e staging non si emettono come canonical.
10. I redirect si comportano come previsto sulla piattaforma di hosting reale.

Usa “view source”, recupera l’URL senza affidarti all’esecuzione nel browser e ispeziona i file distribuiti. Il pannello Elements di DevTools mostra il DOM dopo l’esecuzione: è utile, ma risponde a una domanda diversa (mi capita ancora di controllare prima quello “sbagliato”).

Astro gestisce bene la base del rendering. Il lavoro ricorrente è mantenere metadati, link interni, schema e coerenza delle pagine mentre il sito cresce. SEOJuice può girare su Astro tramite uno snippet JavaScript e applicare continuamente correzioni sul sito, come link interni, meta titoli e descrizioni, markup dello schema e testo alternativo delle immagini. Anche la free SEO audit è un modo senza registrazione per ispezionare metadati e canonical effettivamente pubblicati.

Non sostituisce l’impostazione di site, la generazione della sitemap o il tenere i contenuti indicizzabili nell’HTML iniziale. L’automazione deve stare sopra una build corretta.

Domande frequenti

Astro è valido per la SEO?

Sì. Astro prerenderizza HTML statico e rimuove per impostazione predefinita il JavaScript lato client, quindi i contenuti possono essere presenti nella risposta iniziale invece di dipendere dalla fase di rendering differita del JavaScript di Google. Il ranking dipende comunque da contenuti utili, metadati, link interni, canonical e altre scelte di implementazione.

Come aggiungo titoli e meta description in Astro?

Aggiungi tag standard title e meta-description a un layout condiviso, poi passa valori univoci tramite Astro.props per ogni pagina. Il pacchetto astro-seo della community è un’altra opzione, ma non è un’integrazione ufficiale di Astro.

Come aggiungo una sitemap a un sito Astro?

Esegui npx astro add sitemap e imposta site sull’URL distribuito in astro.config.mjs. Dopo una build, viene emesso sitemap-index.xml e sitemap-0.xml. Senza la configurazione del sito, l’integrazione non può generare la sitemap.

Come imposto canonical URL in Astro?

Usa lo schema documentato da Astro: crea un URL con new URL(Astro.url.pathname, Astro.site), poi stampa quel valore in un tag link canonical. Configura prima site, perché Astro.site altrimenti risulta indefinito.

Qual è la differenza tra output statico e SSR in Astro?

output: 'static' è il default e prerenderizza le pagine in HTML durante la build. output: 'server' renderizza on-demand e richiede un adapter. Puoi miscelare il comportamento per pagina con prerender = false in modalità statica oppure prerender = true in modalità server.

Perché la mia sitemap o la mia canonical URL in Astro non funzionano?

Controlla prima site. Di default è indefinito, mentre la generazione della sitemap, la costruzione di Astro.site, le canonical, i link RSS agli articoli e molte URL social assolute dipendono da questo valore. Impostalo sull’origine finale HTTPS, ricostruisci e ispeziona l’output generato.