Perché ho scelto Sanity (e perché oggi lo sceglierei ancora di più)

Tutto quello che state leggendo, dalla home a questo articolo, passa da Sanity. Lo uso come CMS headless dietro un frontend in Next.js, e persino le immagini di anteprima che vedete quando condividete un link arrivano dal suo CDN.

L'ho scelto per motivi molto pratici: si integra benissimo con Next, il dataset si interroga in modo semplice ed è veloce. Ma negli ultimi mesi Sanity è cambiato parecchio, soprattutto lato AI. Oggi non lo vedo più solo come "un posto dove salvare i contenuti", e in questo articolo vi spiego perché.

Il cuore di Sanity è il Content Lake: un database in cloud pensato per i contenuti. Ogni articolo è un documento JSON con campi tipizzati, non un blob di HTML legato a un template.

Per leggerlo si usa GROQ, un linguaggio di query nato apposta. Con una sola query prendo l'articolo, risolvo le reference (autore, categoria) e scelgo esattamente i campi che mi servono:

import { client } from '@/sanity/client'

const POST_QUERY = `*[_type == "post" && slug.current == $slug][0]{
  title,
  publishedAt,
  "categoria": categoria->title,
  "cover": mainImage.asset->url,
  body
}`

export default async function Page({ params }) {
  const { slug } = await params
  const post = await client.fetch(POST_QUERY, { slug })
  // ...
}

Niente over-fetching, niente endpoint REST da mantenere: la forma della risposta la decido io dentro la query. Esiste anche un'API GraphQL, ma una volta presa la mano con GROQ difficilmente si torna indietro.

L'interfaccia di amministrazione, lo Studio, è un'app React configurata in TypeScript. Lo schema dei contenuti vive nel repository insieme al resto del progetto, versionato con Git:

import { defineField, defineType } from 'sanity'

export const post = defineType({
  name: 'post',
  title: 'Articolo',
  type: 'document',
  fields: [
    defineField({ name: 'title', type: 'string', validation: (r) => r.required() }),
    defineField({ name: 'slug', type: 'slug', options: { source: 'title' } }),
    defineField({ name: 'categoria', type: 'reference', to: [{ type: 'categoria' }] }),
    defineField({ name: 'body', type: 'array', of: [{ type: 'block' }, { type: 'image' }] }),
  ],
})

Tre cose che apprezzo ogni giorno:

• Portable Text: il testo ricco è salvato come dati strutturati, quindi decido io come renderizzare ogni blocco in React. Ad agosto 2026 sono arrivate anche le tabelle native, validabili e interrogabili con GROQ.
• TypeGen: genera i tipi TypeScript dallo schema e dalle query, così il risultato di client.fetch è tipizzato senza scrivere interfacce a mano.
• Collaborazione in tempo reale: più persone possono lavorare sullo stesso documento, con la cronologia di ogni campo.

Il limite storico dei CMS headless è che scrivi in un form e non vedi il risultato. Sanity offre diversi strumenti per superarlo, e vale la pena conoscerli anche se non li usate.

Visual Editing. Dentro lo Studio, il Presentation tool mostra il sito vero: clicchi su un titolo nella pagina e si apre il campo da modificare, con l'anteprima che si aggiorna mentre scrivi. È incluso in tutti i piani, anche quello gratuito, e ora esiste un pacchetto separato per usarlo anche su siti statici o non React.

Io, per esempio, di solito non lo uso: preferisco scrivere direttamente dal form dello Studio. È più veloce e nel frontend mi porto dietro meno codice e meno pacchetti da tenere aggiornati. Su un blog personale l'anteprima dal vivo non mi serve; su un sito con più redattori, o per un cliente poco tecnico, può fare la differenza.

Live Content API. Con next-sanity i contenuti pubblicati arrivano sul frontend in tempo reale, senza dover ricostruire il sito o gestire a mano la revalidation.

Content Releases. Puoi preparare un gruppo di modifiche (per esempio un restyling del portfolio più tre articoli nuovi) in una release separata, vederla in anteprima su tutto il sito e pubblicarla in un colpo solo, anche programmata. Nel frattempo le bozze normali continuano a funzionare senza conflitti.

Sul mio sito non uso l'AI integrata di Sanity, ma è la novità più importante degli ultimi mesi e vale la pena capirla. Un ChatGPT qualunque genera testo libero; l'AI di Sanity invece sa che un articolo ha un titolo, uno slug, una categoria che è una reference e un body in Portable Text. Quindi scrive contenuti che rispettano lo schema, invece di testo da copiare e incollare.

Gli strumenti sono quattro, pensati per persone diverse:

Qualche esempio concreto di come si possono usare:

• Alt text e SEO in automatico: un comando di AI Assist che, su ogni immagine, scrive l'alt text partendo dal contenuto dell'articolo.
• Traduzioni: con l'azione Translate si crea la versione inglese di un articolo come bozza, mantenendo struttura, link e reference.
• Modifiche in blocco: al Content Agent si può chiedere "trova gli articoli senza categoria e proponine una", e approvare le modifiche una per una.
• Sviluppo assistito: un agente come Claude Code, collegato tramite MCP, può aggiungere un campo allo schema e popolarlo sui documenti esistenti.

Alcuni dettagli che fanno la differenza:

• Le Agent Actions scrivono sulle bozze e non toccano mai i campi nascosti o in sola lettura. Generate può anche creare immagini e collegare reference.
• Il Content Agent mostra un'anteprima delle modifiche e non cambia nulla senza la mia approvazione. Rispetta anche i permessi dell'utente.
• Con l'MCP Server si può chiedere all'editor di codice di aggiungere un campo allo schema, migrare i documenti o lanciare una query GROQ, senza uscire dal flusso di lavoro.

Questa parte è opzionale: sul mio sito non uso né Functions né Blueprints, e un blog funziona benissimo senza. Ma se un giorno vi servisse automatizzare qualcosa, ecco come funziona.

Functions. Sono piccole funzioni serverless che partono da sole quando un documento viene creato, aggiornato o eliminato. Girano sull'infrastruttura di Sanity, quindi non serve mettere in piedi un webhook e una route API su Vercel solo per reagire a una pubblicazione.

Blueprints. Sono il modo in cui si dichiarano queste funzioni: un file di configurazione nel progetto che dice "quando succede questo evento, esegui questa funzione". È infrastruttura come codice, simile nello spirito a un vercel.json, e si pubblica sui server di Sanity con il comando sanity blueprints deploy.

Un esempio pratico: pubblico un articolo e una funzione, usando le Agent Actions viste sopra, genera la meta description e la traduzione inglese come bozza da rileggere. Da agosto 2026 le funzioni possono anche chiamarsi a vicenda, utile per spezzare la logica in pezzi riutilizzabili.

Nessun CMS è perfetto, ognuno è un compromesso. Ecco come vedo Sanity rispetto alle alternative che un web developer valuta più spesso.

Ho scelto Sanity per GROQ, per lo schema in codice e per l'integrazione con Next, e lo uso nel modo più semplice possibile: form dello Studio e query dal frontend. Oggi lo sceglierei di nuovo anche per la direzione che sta prendendo: avere i contenuti strutturati significa che sono già pronti per l'AI, se e quando deciderò di usarla.