Per molto tempo, in Ctrl Studio, "fare un sito" ha significato quasi sempre "farlo su Webflow". Prima ancora, come per quasi tutta l'industria, voleva dire WordPress. Funzionavano entrambi, e Webflow continua a funzionare benissimo per la maggior parte dei nostri clienti. Ma da qualche mese stiamo aggiungendo un terzo binario tecnico, Astro più Sanity come CMS, e non perché Webflow abbia smesso di andarci bene. Perché alcuni progetti chiedono qualcosa che né WordPress né Webflow sono stati costruiti per fare.
Questo articolo non è una guida su "quale CMS scegliere nel 2026". È il racconto di un ragionamento ancora in corso, con anche una parte più tecnica per chi vuole capire cosa significa davvero, sotto il cofano, mettere insieme Astro e Sanity.
WordPress ha democratizzato il web. Chiunque poteva avere un sito senza scrivere una riga di codice, e questo per anni è stato il suo punto di forza assoluto. Il problema arriva dopo: ogni funzionalità in più significa un plugin in più, ogni plugin in più significa un punto di fragilità in più. Aggiornamenti che rompono qualcosa, conflitti tra plugin scritti da team diversi che non si parlano tra loro, vulnerabilità di sicurezza che si accumulano, performance che peggiorano progressivamente man mano che il sito cresce.
Per l'agenzia, questo si traduce in manutenzione continua che pesa sul margine. Per il cliente finale, si traduce in un sito che con il tempo diventa sempre più lento e sempre più rischioso da aggiornare, al punto che molte aziende finiscono per avere paura di toccare il proprio sito per timore di romperlo. Non è colpa di WordPress in sé. È la conseguenza naturale di un'architettura pensata per essere infinitamente estendibile da migliaia di sviluppatori indipendenti, senza un controllo centrale sulla qualità di ciò che viene costruito sopra.
Webflow ci ha permesso di consegnare siti rapidamente, con un'esperienza visuale che i clienti capiscono e possono in parte gestire da soli, e con una qualità estetica difficile da replicare con la stessa velocità su altri stack. Risolve gran parte dei problemi di WordPress: niente plugin di terze parti che litigano tra loro, hosting e sicurezza gestiti dalla piattaforma, aggiornamenti che non rompono il sito da un giorno all'altro.
Il compromesso si vede su due fronti. Il primo è tecnico: l'integrazione con sistemi esterni, dati complessi o logiche personalizzate resta più rigida rispetto a un framework di sviluppo vero e proprio, perché Webflow è prima di tutto uno strumento di design visuale, e solo in seconda battuta una piattaforma di sviluppo. Il secondo è commerciale, e lo vediamo sempre più chiaramente: il modello di prezzo di Webflow si sta spostando verso clienti enterprise, con piani e funzionalità sempre più pensati per team grandi e budget consistenti, mentre i costi per chi gestisce più siti in piani separati, come fa tipicamente un'agenzia con tanti clienti PMI, tendono a salire in modo meno lineare di quanto vorremmo. Non significa che Webflow abbia smesso di avere senso. Significa che va scelto sapendo che quella direzione esiste, non per inerzia.
Astro è un framework pensato per generare siti molto leggeri e velocissimi, dando però la possibilità di aggiungere componenti interattivi solo dove servono davvero, invece di caricare un'intera applicazione JavaScript anche per una pagina che è essenzialmente testo e immagini. Sanity è un CMS headless: il contenuto vive separato dal layout, gestibile attraverso un'interfaccia che si può adattare esattamente alle esigenze di chi scriverà i contenuti, senza i vincoli visuali di un builder.
Questa combinazione richiede competenze più simili allo sviluppo software che al design visuale. Qualcuno deve scrivere e mantenere quel codice, non solo trascinare blocchi in un'interfaccia. È il prezzo da pagare per avere più controllo, più velocità, e una struttura dati pensata su misura per quel progetto specifico invece di adattarsi ai vincoli di un builder generico.
Per chi è curioso di capire cosa significa davvero collegare i due strumenti, ecco la logica di base, semplificata. Non serve essere sviluppatori per seguirla, basta capire il flusso.
Si parte creando un progetto Astro e aggiungendo l'integrazione ufficiale per Sanity, che si occupa di collegare le due piattaforme. In pratica si tratta di un comando da terminale che installa i pacchetti necessari e configura automaticamente il file principale del progetto, indicando l'identificativo del progetto Sanity e il nome del set di dati a cui collegarsi.
A quel punto si avvia Sanity Studio, l'interfaccia dove chi scrive i contenuti lavorerà ogni giorno. Qui si definisce lo schema, cioè la struttura dei contenuti: un articolo di blog avrà un titolo, uno slug per l'URL, un autore, un'immagine di copertina, delle categorie e il corpo del testo. Ogni campo è definito in un file di configurazione semplice, e Sanity costruisce automaticamente un'interfaccia di editing leggibile a partire da quella definizione.
Da lì, in Astro si creano le pagine che recuperano i contenuti da Sanity tramite query scritte in GROQ, il linguaggio di interrogazione di Sanity, concettualmente simile a come si interrogherebbe un database, ma pensato per essere leggibile anche da chi non scrive query tutti i giorni. Ogni articolo pubblicato genera automaticamente la propria pagina, senza che nessuno debba creare manualmente un file per ogni nuovo contenuto.
Il dettaglio che vale la pena conoscere anche se non si scrive codice: i contenuti formattati come testo, grassetti, link e immagini incluse, vengono salvati da Sanity in un formato chiamato Portable Text, pensato apposta per essere trasformato in HTML, PDF o qualsiasi altro formato senza dipendere da un singolo front-end. È uno dei motivi per cui questa combinazione si presta bene anche a progetti che in futuro potrebbero avere bisogno di mostrare lo stesso contenuto su più canali diversi, non solo sul sito.
Per chi vuole vedere la guida tecnica completa passo per passo, con tutto il codice necessario per costruire un blog funzionante da zero, il punto di riferimento più solido è la documentazione ufficiale di Sanity per l'integrazione con Astro.
Stiamo applicando questa combinazione su un progetto reale per un'azienda che lavora nel settore delle pratiche doganali, un ambito con contenuti tecnici specifici, terminologia di settore precisa, e necessità editoriali diverse da quelle di un'azienda che vende un prodotto o un servizio più immediato da raccontare.
È un pilota nel senso pieno della parola: lo stiamo costruendo per imparare cosa funziona davvero di questa combinazione tecnica quando viene applicata a un caso reale, non a un esercizio teorico. Lo schema dei contenuti in Sanity lo stiamo definendo pensando a come un team non tecnico dovrà poi usarlo ogni giorno, perché un CMS più potente che nessuno sa usare è peggio di un CMS più semplice che funziona davvero nella routine di chi ci lavora.
Quando avremo risultati misurabili, performance reali, tempo di gestione contenuti, feedback di chi lo usa lato cliente, ne scriveremo con i numeri veri, non prima.
Se sei un'azienda che si sta chiedendo che tecnologia dovrebbe usare per il proprio sito, la risposta onesta non è mai "quella più nuova" o "quella che usa l'agenzia più brava". È: dipende da cosa devi fare con quel sito, chi lo dovrà gestire dopo che è online, e quanto è probabile che le tue esigenze cambino nel tempo.
Un sito vetrina per un'attività locale con aggiornamenti occasionali ha bisogno di tutt'altro rispetto a un sito editoriale per un'azienda B2B che pubblica contenuti tecnici ogni settimana e ha un team che deve poterli gestire senza chiamare uno sviluppatore ogni volta. Non sono la stessa domanda, e non dovrebbero avere la stessa risposta solo perché chi te lo costruisce ha un solo strumento in tasca.
Se vuoi vedere più nel concreto come ragioniamo quando un sito deve davvero portare risultati e non solo essere online, ne parliamo più nel dettaglio in Sito web che converte: come progettare pagine, CTA e UX per trasformare visite in lead. Se il dubbio di fondo è più ampio, non quale tecnologia ma se hai davvero bisogno di un sito nuovo o di riorganizzare quello che hai già, il punto di partenza giusto è Hai un sito o un sistema? La differenza che blocca (o sblocca) la crescita. E se invece la domanda è più diretta, quanto costa realmente, l'abbiamo affrontata senza giri di parole in Quanto costa davvero un sito web professionale?
Ctrl Studio. Meno task. Più sistema.
