SEO di un sito Astro passo dopo passo: rendering statico o server, tag head, sitemap, hreflang, immagini, JSON-LD e redirect, verificati nella documentazione.

In questa pagina
In breve
Astro è uno dei framework web più favorevoli alla SEO, perché prerenderizza le pagine in HTML puro e non invia JavaScript al browser a meno che tu non lo chieda. Google e i crawler delle IA ricevono così il contenuto completo fin dalla prima richiesta. Astro però non fa la SEO al posto tuo: titoli, meta description, canonical, hreflang, dati strutturati e redirect restano da aggiungere, soprattutto in un componente head condiviso e con l'integrazione ufficiale per la sitemap.
Vuoi approfondire? Chiedi a
Quiz veloce
La SEO fa per te, e come iniziare?
Sorank corrisponde alle tue risposte
Provalo per 3 giorni sul tuo sito e scopri a che punto sei su Google, ChatGPT e le altre IA.
Prova gratis per 3 giorni3 giorni gratis, poi smetti quando vuoi. Garanzia risultati o rimborsati di 90 giorni.
La SEO con Astro consiste nel trasformare questo HTML pulito in pagine che si posizionano. La guida di Google alle nozioni di base sulla SEO per JavaScript spiega che i siti JavaScript vengono elaborati in tre fasi (scansione, rendering, indicizzazione) e afferma che il rendering lato server o il pre-rendering resta un'ottima idea, perché non tutti i bot eseguono JavaScript. Astro parte già da lì. Questa guida copre il resto, impostazione per impostazione, con ogni comportamento verificato nella documentazione ufficiale di Astro. Per la cronaca, il sito sorank.com che stai leggendo gira su Astro.
Sì, sul piano tecnico. Astro trasforma i componenti in HTML in fase di build e rimuove il JavaScript che framework come React o Vue invierebbero normalmente al browser. Evita così i problemi classici descritti nella nostra guida alla SEO per JavaScript: gusci HTML vuoti, contenuti che compaiono solo dopo il rendering, link che non sono veri tag di ancoraggio. Evita anche le trappole di routing di una single page application, perché ogni route di Astro è un vero URL con il proprio file HTML.
Quello che Astro non fa conta altrettanto. Non c'è un plugin SEO integrato, né meta description automatica, né tag canonical automatico, né dati strutturati. La tabella separa ciò che ottieni gratis da ciò che devi costruire.
| Elemento SEO | Cosa offre Astro | Cosa aggiungi tu |
|---|---|---|
| HTML scansionabile | HTML prerenderizzato per impostazione predefinita | Niente, a meno di contenuti renderizzati solo lato client |
| Title e meta description | Un head che controlli in ogni layout | Un componente SEO condiviso alimentato da ogni pagina |
| Tag canonical | Astro.site e Astro.url per costruire URL assoluti | Il tag link vero e proprio, con una barra finale coerente |
| Sitemap XML | L'integrazione ufficiale @astrojs/sitemap | Installarla, impostare l'opzione site, filtrare le pagine private |
| hreflang | Il routing i18n e un'opzione i18n della sitemap | I link alternate nell'head di ogni pagina |
| Immagini | I componenti Image e Picture che ottimizzano i file | Testi alternativi descrittivi, dimensioni adeguate |
| Dati strutturati | Niente di specifico | Script JSON-LD per tipo di pagina |
| Redirect | Un'opzione redirects nella configurazione | Veri 301 a livello di hosting per i siti statici |
La documentazione di Astro sul rendering on demand è chiara: per impostazione predefinita, pagine, route ed endpoint API vengono prerenderizzati in fase di build come pagine statiche. Per la SEO, l'output statico è la scelta più sicura: ogni URL è un file HTML finito, servito da una CDN, veloce e identico per ogni visitatore e ogni bot.
Il rendering on demand (lato server) richiede un adapter per il tuo hosting (per esempio Node, Netlify, Vercel o Cloudflare). Poi escludi una singola route dal pre-rendering con export const prerender = false, oppure passi l'intero progetto a output: 'server' e riattivi lo statico pagina per pagina. Entrambe le modalità producono HTML completo, quindi Google vede la stessa cosa. Le differenze sono altrove:
La regola pratica: tieni statiche le pagine commerciali, gli articoli del blog e la documentazione, e renderizza on demand solo le route che hanno bisogno di dati in tempo reale. La documentazione di Astro dà lo stesso consiglio: mantenere la modalità statica predefinita finché la maggior parte delle pagine non richiede il rendering on demand.
Crea un unico componente SEO (spesso chiamato BaseHead o Seo) e includilo nell'head di ogni layout. Riceve un titolo, una descrizione, un'immagine facoltativa e un indicatore noindex facoltativo, e produce:
Imposta prima l'opzione site in astro.config.mjs: canonical, sitemap e tag social dipendono da lei. Scegli poi una regola trailingSlash ('always' o 'never') e rispettala, così /blog/articolo e /blog/articolo/ non competono mai come due versioni della stessa pagina. Togli i parametri di query dal canonical, perché i parametri di tracciamento non creino duplicati.
Consiglio
Se i tuoi articoli stanno in content collections, rendi titolo e descrizione campi obbligatori nello schema della collection. La build fallisce quando un autore dimentica la meta description, invece di mandare a Google uno snippet vuoto.
Usa l'integrazione ufficiale documentata nella pagina di @astrojs/sitemap. Il comando npx astro add sitemap la installa e la aggiunge alla configurazione. Richiede l'opzione site e, in fase di build, scrive un file sitemap-index.xml che rimanda a file numerati (sitemap-0.xml, poi altri sui siti grandi). Ogni file contiene fino a 45.000 voci per impostazione predefinita, valore regolato dall'opzione entryLimit. Se il formato ti è nuovo, la nostra voce di glossario sulla sitemap XML spiega cosa ne fa Google.
Tre impostazioni contano per la SEO:
Attenzione
La documentazione precisa che l'integrazione non può generare voci di sitemap per le route dinamiche in modalità SSR. Se le tue pagine prodotto o i tuoi articoli sono renderizzati on demand, mancheranno nella sitemap, a meno di prerenderizzarli o di aggiungerli tu.
Per il robots.txt, sulla maggior parte dei siti basta un file statico nella cartella public. Se il contenuto cambia tra staging e produzione, generalo invece da un endpoint (src/pages/robots.txt.ts). In entrambi i casi aggiungi una riga Sitemap che punta a sitemap-index.xml e prova il risultato con un controllo del robots.txt prima del lancio. La stessa tecnica produce un file llms.txt; la nostra guida per installare un file llms.txt ne descrive il contenuto.
Il routing i18n integrato di Astro gestisce la parte degli URL. Nella configurazione dichiari una defaultLocale e un elenco di locales, e scegli se anche la lingua predefinita ha un prefisso (prefixDefaultLocale). Funzioni come getRelativeLocaleUrl costruiscono i link localizzati, e Astro.currentLocale dice a ogni pagina in che lingua si trova.
La guida al routing non tratta i tag hreflang nell'head, quindi prevedi di scriverli tu nel componente SEO: per ogni pagina un link alternate per versione linguistica più un x-default, tutti come URL assoluti, e ogni versione deve elencare tutte le altre (link di ritorno). Generarli dallo stesso elenco di lingue del routing evita l'errore più comune, un'alternativa che punta a una pagina inesistente. Per controllare la logica su qualche URL, il nostro generatore di hreflang produce il set completo di tag di una pagina. Attiva poi l'opzione i18n della sitemap come secondo segnale.
La velocità è il terreno su cui Astro guadagna di più, e si vede nei Core Web Vitals. La guida alle immagini di Astro descrive il componente Image di astro:assets: ottimizza le immagini locali, ne converte il formato, aggiunge caricamento lazy e decodifica asincrona e ricava le dimensioni dell'immagine per evitare il Cumulative Layout Shift. L'attributo alt è obbligatorio, il che impone una regola di base della SEO delle immagini. Il componente Picture va oltre e serve AVIF o WebP con un fallback.
Due abitudini completano il quadro. Tieni in src le immagini da ottimizzare (i file in public vengono serviti così come sono, senza elaborazione). E non rimandare il caricamento dell'immagine principale in cima alla pagina: caricala subito, perché non rallenti il Largest Contentful Paint.
L'architettura a isole tiene sotto controllo il JavaScript. Un componente resta HTML statico finché non aggiungi una direttiva client: client:load lo idrata subito, client:idle quando il browser è libero, client:visible solo quando entra nell'area visibile. Riservare client:load a ciò che deve reagire immediatamente (un menu, un carrello) è il modo più semplice per proteggere l'Interaction to Next Paint. Le server islands (server:defer) caricano un blocco personalizzato dopo la pagina in cache, senza rallentare il contenuto principale.
Da sapere
Un'isola ritarda solo la propria interattività, non il proprio testo, purché il componente sia renderizzato prima sul server. I contenuti caricati nel browser in un secondo momento sono un altro discorso: i crawler che non eseguono JavaScript, tra cui molti crawler delle IA, non li vedranno.
Astro non ha una funzione dedicata agli schema, il che ti lascia il pieno controllo. Costruisci un oggetto JavaScript per tipo di pagina (Article, Product, Organization, BreadcrumbList, FAQPage) e inseriscilo in un tag script di tipo application/ld+json, con la direttiva set:html e JSON.stringify perché il JSON non venga sottoposto a escape. Alimentalo con gli stessi dati di frontmatter o di collection della pagina visibile: il markup corrisponde sempre a ciò che vedono gli utenti, un requisito delle linee guida di Google sul markup schema.
Per scrivere il JSON di un nuovo tipo di pagina, il nostro generatore di schema gratuito ti fornisce un blocco iniziale valido da trasformare in template. Convalida un campione di pagine compilate con il test dei risultati multimediali di Google dopo ogni modifica al template.
Le migrazioni da WordPress o Next.js sono il momento più rischioso per un sito Astro. Conserva ogni URL che riceve traffico o backlink e associa gli altri uno per uno al loro equivalente più vicino con redirect permanenti, come spiega la nostra guida ai redirect SEO.
La configurazione di Astro accetta un oggetto redirects che associa i vecchi percorsi ai nuovi. Con un adapter diventano veri redirect HTTP. In una build puramente statica, Astro scrive invece una pagina HTML con meta refresh, che Google segue ma tratta come un segnale più debole di un 301 lato server. Per un sito statico dichiara i redirect nel formato del tuo hosting (un file _redirects su Netlify o Cloudflare Pages, un file vercel.json su Vercel), così i crawler ricevono un vero 301.
Essere citati da ChatGPT, Perplexity o Gemini comincia dall'essere leggibili. Molti crawler delle IA scaricano l'HTML grezzo senza eseguire JavaScript: un sito che consegna tutto il testo nella prima risposta, come fa Astro per impostazione predefinita, toglie un ostacolo che i siti renderizzati lato client hanno ancora. Titoli chiari, paragrafi che rispondono subito, dati strutturati e un file llms.txt rendono poi ogni pagina più facile da citare.
Dopo il lancio, misura invece di indovinare. La dashboard GEO e SEO di Sorank riunisce i dati di Search Console e le visite provenienti dagli assistenti IA, per verificare se il nuovo sito mantiene le sue posizioni.

La qualità tecnica rende solo con contenuti da posizionare. Il generatore di articoli per blog con IA di Sorank scrive e pubblica articoli ottimizzati per Google e per le IA, e si collega via webhook a un sito su misura, come un progetto Astro.
Astro ti dà per impostazione predefinita un HTML veloce e scansionabile; il posizionamento dipende comunque da tag head, sitemap, hreflang, dati strutturati e redirect che aggiungi tu. Imposta per primi il componente SEO condiviso e la sitemap, poi ripercorri la tabella qui sopra prima del lancio.
No. Astro non ha un plugin SEO ufficiale tutto in uno: title, meta description, canonical e tag social si scrivono in un componente head condiviso. L'integrazione ufficiale @astrojs/sitemap copre la sitemap. Esistono pacchetti della community, ma un piccolo componente tuo è facile da mantenere e resta interamente sotto il tuo controllo.
Entrambi possono produrre HTML completamente renderizzato, quindi Google può indicizzarli bene tutti e due. Astro invia molto meno JavaScript per impostazione predefinita, il che di solito rende più veloci i siti di contenuti e aiuta i Core Web Vitals. Next.js è più adatto alle applicazioni molto interattive; per blog, siti vetrina e documentazione, Astro è la scelta più semplice per la SEO.
Sì. Una pagina renderizzata on demand restituisce comunque a Googlebot un HTML completo, esattamente come una pagina prerenderizzata. I punti da controllare sono il tempo di risposta del server, che incide sulla velocità di caricamento, e l'integrazione della sitemap, che non elenca le route dinamiche in modalità server a meno che non le aggiunga tu.
HANNO PROVATO SORANK PRIMA DI TE
