Astro Narrow mantiene la scrittura vicina al Markdown puro, usando le Astro Content Collection per validare il frontmatter a build-time. Un articolo è un file .md o .mdx sotto src/content/posts/<lingua>/; il nome del file diventa lo slug pubblico.
Parti dal frontmatter minimo utile#
Per un articolo sono richiesti solo title e pubDate. Aggiungi campi solo quando la pagina ne ha davvero bisogno.
---title: "La mia prima nota"description: "Cosa ho imparato configurando il sito."pubDate: 2026-06-26categories: ["Note"]tags: ["Astro", "Markdown"]toc: "side"---description viene usata nelle card delle liste e nei metadati della pagina. updatedDate è utile quando una revisione sostanziale deve essere visibile. Il campo cover è opzionale; ometterlo produce una card più sobria, incentrata sul testo, adatta a note brevi.
Usa categorie e tag in modo consapevole#
Le categorie rispondono alla domanda “che tipo di articolo è?”, mentre i tag descrivono le tecnologie o le idee coinvolte. Una convenzione utile è una categoria e un piccolo insieme di tag precisi:
- Categoria:
Guide - Tag:
Astro,Markdown,Content Collections
L’Archivio individua questi termini dagli articoli pubblicati nella lingua corrente. Non esiste un registro da aggiornare, ma ortografia e maiuscole contano comunque: GitHub Pages e Github pages verrebbero trattati come termini diversi.
Usa le bozze prima di pubblicare#
Imposta draft: true mentre un articolo è incompleto. Le bozze sono escluse dalle liste pubbliche, dall’Archivio, dalla ricerca, dall’RSS e dai conteggi della taxonomy.
draft: truePrima di pubblicare, verifica che la description abbia senso anche fuori dal contesto dell’articolo, che i termini di taxonomy corrispondano all’ortografia già in uso, e che i link interni siano consapevoli di lingua e base path. Poi rimuovi il flag draft ed esegui pnpm build; gli errori di schema falliscono durante il build invece di trasformarsi in pagine di produzione rotte.