Come sono fatti il sito e il blog di ICT Sviluppo: Sanity, Nuxt e Claude in un sistema solo

Dopo qualche anno abbiamo riportato il sito di ICT Sviluppo e il suo blog rispondono sullo stesso dominio, con gli articoli sotto /blog.
Le pagine dei servizi, le landing, i case study e quasi cinquecento articoli stanno in un solo progetto Sanity, il CMS che li conserva come dati strutturati; li impagina una sola applicazione scritta con Nuxt, che costruisce ogni pagina sul server prima di mandarla al browser; li serve Azure Static Web Apps. Sopra lavora Claude, l'assistente di Anthropic, che legge e modifica i contenuti attraverso il connettore di Sanity.

Prima erano due sistemi su due domini: il sito istituzionale su Hubspot CMS e il blog già su Sanity, dove gli articoli erano arrivati a giugno con una migrazione parziale, perché il sito istituzionale era rimasto dov'era.

Perché sito e blog stanno nello stesso progetto

Sul confronto fra sottodomini e sottocartelle la guida SEO di Google non dà una preferenza: dice di fare quello che ha senso per il proprio business.
Le ragioni dell'unione sono operative, e si vedono nel percorso di chi legge.
Ogni articolo porta una chiamata all'azione, e le destinazioni sono pagine dello stesso sito, la pagina di un servizio, la landing di una guida, il modulo per chiedere un appuntamento, con la sola eccezione di un invito che porta a un negozio online.
Chi clicca resta nella stessa navigazione e sotto lo stesso dominio, e la misura lo segue in una sola proprietà di Analytics e di Search Console, senza configurazioni per tenere insieme due host.
Anche la mappa del sito è una sola, ed elenca insieme le pagine dei servizi e tutti gli articoli pubblicati.

Un secondo vantaggio si è visto nel trasloco stesso.
Dentro gli articoli, su Sanity, i link interni sono scritti nella forma /post/slug, e sono quasi tremila; il front end li traduce nell'indirizzo pubblico nel momento in cui disegna la pagina.
Spostare il blog sotto /blog ha cambiato quella traduzione, che sta nel codice, e i documenti che descrivono i reindirizzamenti, riscritti con i percorsi nuovi. Il testo degli articoli è rimasto com'era.

Un cambio di indirizzo resta comunque una migrazione. I reindirizzamenti vanno verificati con richieste vere, la proprietà nuova di Search Console parte senza la storia di quella vecchia, la mappa del sito va inviata di nuovo perché Google la rilegga con gli articoli dentro, e i dati di prima restano sulle proprietà di prima. È la stessa disciplina che serve per cambiare piattaforma a un negozio online, su una scala più piccola.

Che cos'è un modulo, e perché una pagina si compone invece di programmarsi

Sanity è un CMS headless: conserva i contenuti e li espone via API, senza decidere come vengano mostrati. Su come è costruito il prodotto c'è un pezzo dedicato a che cos'è Sanity CMS, e uno che lo confronta con WordPress sui progetti enterprise. Per un sito la conseguenza è che la grafica deve stare da un'altra parte, e sul sito di ICT Sviluppo sta nei moduli.

Un modulo è una sezione di pagina che fa un lavoro solo: un'apertura con titolo e pulsante, una griglia con i loghi dei clienti, una serie di domande frequenti, un form di contatto, un elenco di testimonianze, un conto alla rovescia, il calcolatore del costo totale di Shopify Plus. Ogni modulo esiste in due posti nello stesso momento. Nel front end è un componente Nuxt, che decide come la sezione appare e come si comporta, dai caratteri alle spaziature a quello che succede su un telefono; nello schema di Sanity è un tipo di oggetto, che decide quali campi deve compilare chi scrive. Una pagina del sito, nel CMS, è un elenco ordinato di moduli, e il front end li mette in fila e li disegna.

Il modulo dei pulsanti chiede un'etichetta, una destinazione e una variante fra quelle previste, e la destinazione può essere un punto della stessa pagina, un documento di chiamata all'azione o un indirizzo esterno. Quello delle domande frequenti chiede le domande, le risposte in testo strutturato e il livello di titolo da dare alle domande, che serve alla gerarchia della pagina. Quello del form chiede soltanto l'identificativo del form HubSpot, che consegna i contatti al CRM di HubSpot. Quando un modulo lascia una scelta grafica, è una scelta fra opzioni decise da chi lo ha progettato, come lo schema di colori di un banner: il resto sta nel componente, e il contenuto non lo può rompere.

Per questo una landing nuova, se i moduli che le servono esistono, non richiede uno sviluppatore. La pagina del Voucher Piemonte 2026 è composta per intero da moduli della libreria comune: etichette, testo, il conto alla rovescia sulla scadenza del bando, pulsanti, box con immagini, una fascia di contenuto, colonne e le domande frequenti. I case study nascono da una stessa ossatura, un'apertura fatta di immagine e testo o di un video, banner fotografici, colonne di racconto e il form in fondo, e per questo si leggono e si confrontano allo stesso modo.

Lo sviluppatore serve quando diventa necessaria una sezione che non c'è. Si disegna, si scrive il componente, si registra il tipo nello schema, e da quel momento il modulo è disponibile su ogni pagina del sito. La libreria cresce così, un modulo alla volta, quando un'esigenza nata dal lavoro non trova posto in quelli che ci sono già.

Il blog nello stesso archivio: ogni articolo è un documento

Gli articoli seguono un'altra logica, perché un testo lungo ha bisogno di una struttura diversa da quella di una pagina di servizio. Un post ha un titolo, uno slug che ne determina l'indirizzo, un excerpt che fa da sottotitolo e resta sotto i duecento caratteri, un autore scelto fra quelli della redazione, una categoria fra ecommerce e digital, una data, un blocco seo con titolo e descrizione per i motori di ricerca, un'immagine di copertina con il suo testo alternativo, e un corpo.

Il corpo è scritto in Portable Text, una specifica aperta nata in Sanity per il testo strutturato: un array di blocchi in cui ogni paragrafo, ogni titoletto e ogni voce di elenco è un oggetto con un suo identificativo, e i link sono annotazioni separate, agganciate al pezzo di frase che le porta. Se un link è un dato, i link si contano: quanti articoli linkano una certa pagina dal corpo del testo, e quali, è una query, e la ricerca dei link rotti diventa un controllo che si esegue su tutto l'archivio invece di una caccia pagina per pagina.

La redazione lavora in Sanity Studio, l'interfaccia di scrittura del CMS, con componenti sviluppati sul modello di contenuto del blog: chi scrive vede i campi che servono, nell'ordine in cui vanno compilati.
Accanto ai campi che descrivono il testo ce ne sono altri che ne descrivono il posto nell'archivio: i tag, che portano l'argomento e le etichette tecniche, la famiglia, il ruolo, la persona a cui il pezzo parla e il punto del percorso d'acquisto in cui la intercetta, e sei correlati, che sono riferimenti ad altri documenti e non indirizzi scritti a mano, quindi restano validi se un articolo viene rinominato o accorpato.

Argomenti, famiglie e ruoli (sì, per la SEO)

Il blog ha tredici argomenti, e ognuno ha un contenuto canonico. Il campo del ruolo ha quattro valori, uno per ogni lavoro che un pezzo può fare nell'archivio.

• Pillar: il contenuto canonico di un argomento, la pagina che vuole essere la risposta di riferimento su quel tema; ce n'è uno per argomento.
• Hub: il capofila di una famiglia, cioè di un gruppo di pezzi che dentro un argomento rispondono alla stessa domanda, alla quale l'hub risponde per intero.
• Spoke: l'approfondimento, il pezzo che scava una porzione della materia e rimanda al suo hub; è giusto che siano la maggioranza.
• Storia: il racconto, l'intervista, la puntata del podcast, che non risponde a una domanda di ricerca e non finge di farlo.

Il livello intermedio, la famiglia, esiste per una ragione pratica: con tredici argomenti soltanto, un pillar si sarebbe trovato a distribuire link verso venti o trenta approfondimenti, e una pagina che manda il lettore in trenta direzioni lo smista invece di guidarlo.
Argomenti e famiglie sono documenti come gli altri, etichette con un campo che ne dichiara il tipo, e quindi nascono, si rinominano e si riorganizzano via API senza toccare il codice.
Ruolo, persona e fase del percorso sono invece liste chiuse nello schema, perché non cambiano quasi mai e una lista chiusa impedisce a chi scrive di inventarsi un valore nuovo.
Le famiglie oggi sono una cinquantina: se ognuna fosse stata una voce dello schema, ognuna sarebbe stata un intervento di sviluppo.

Le relazioni fra i vari pezzi del progetto

Un archivio su tre livelli ha bisogno di regole su chi linka chi, altrimenti i link interni diventano una maglia in cui tutto punta a tutto e nessuna pagina emerge. Le relazioni sono quattro, ciascuna con il suo verso.

1. Lo spoke linka l'hub della sua famiglia, nel punto del corpo in cui il discorso lo chiede.
2. Lo spoke linka il pillar dell'argomento quando il tema affiora davvero, e non per riempire una casella.
3. Il pillar linka gli hub delle famiglie che gli stanno sotto.
4. L'hub linka i suoi spoke, cedendo a ciascuno la porzione di materia che quel pezzo tratta meglio di lui.

La regola che le tiene insieme riguarda l'onestà del link: la frase che lo introduce promette qualcosa a chi legge, e la pagina di destinazione la deve mantenere. Un link rotto lo trova uno script; un link che porta a una pagina che non contiene quello che la frase annunciava lo trova solo chi apre la destinazione e rilegge la frase intera. Il resto si verifica con una query: quanti spoke non linkano il proprio hub, quali articoli non ricevono un link dal corpo di nessun altro, quali hub sono più magri dei pezzi che dovrebbero riassumere.

Chiamate all'azione e reindirizzamenti sono documenti

Gli inviti all'azione sono documenti a sé, ognuno con il suo titolo e la sua destinazione.
Dentro un articolo c'è un blocco che fa riferimento a uno di loro, al posto di un pulsante con un indirizzo scritto dentro, e il giorno in cui una landing cambia indirizzo si cambia il documento e cambiano insieme tutti gli articoli che lo citano.
Oggi ogni articolo pubblicato ne porta uno, scelto in base alla famiglia a cui appartiene, e la destinazione è quasi sempre una pagina a moduli dello stesso sito: questo articolo, per esempio, porta alla pagina sui progetti headless con Sanity, composta nello stesso CMS che conserva il testo che si sta leggendo.

I reindirizzamenti seguono lo stesso principio.
Quando due articoli si accorpano, o uno viene ritirato perché non ha più ragione di esistere, il suo indirizzo deve portare al pezzo che ne ha preso il posto, e nel modello questo si fa con un documento che dichiara il percorso di partenza, quello di arrivo, se il reindirizzamento è permanente e se è attivo. Il front end li legge e serve il 301 senza una riga di codice scritta per l'occasione, con qualche minuto di ritardo fra la pubblicazione del documento e il momento in cui l'indirizzo vecchio comincia a reindirizzare. Saperlo evita l'errore di chi verifica troppo presto, vede ancora la pagina vecchia e conclude che il meccanismo è guasto; la regola che ne è nata è verificare il 301 con una richiesta vera prima di ritirare la pagina di partenza, sempre.

Claude sui contenuti: il connettore di Sanity e le richieste in italiano

Claude si collega al CMS attraverso il server MCP di Sanity, che l'azienda ospita sulla propria infrastruttura e che segue il Model Context Protocol, lo standard aperto pubblicato da Anthropic per collegare gli assistenti ai servizi esterni.
Il connettore espone le operazioni del CMS: leggere lo schema, interrogare i documenti con GROQ, il linguaggio di query di Sanity, creare e modificare documenti, pubblicarli. Le modifiche finiscono sempre in una bozza e mai direttamente sul contenuto pubblicato, e la pubblicazione è un'operazione a parte.
Claude lavora quindi sui campi veri dei documenti, con le loro regole, invece che su un testo copiato in una chat e incollato a mano nel CMS.

Le regole che applica sul blog stanno scritte in un repository che ogni sessione legge prima di toccare un articolo: la voce di chi firma e le formule da evitare, le misure dei campi SEO, la tassonomia, e una procedura di controllo da eseguire dopo ogni modifica, fatta di query che dicono se il documento è integro e se ogni link porta a una pagina pubblicata, e di una rilettura che chiede la fonte di ogni cifra.
Quasi tutte quelle regole sono nate da un errore trovato su un pezzo pubblicato.
Claude sbaglia come sbaglia chiunque scriva, e un errore che non diventa una regola scritta torna alla sessione successiva, che non ricorda niente di quelle prima.

Le richieste si scrivono in italiano, come a un collega.
Qualche esempio, con quello che Claude fa dopo:

• Trova le copertine con il testo alternativo vuoto o che è un nome di file. Claude interroga le immagini di tutti gli articoli, isola i testi alternativi che descrivono un file invece di una scena, come «disorganizzazione aziendale.jpg», e per ciascuno scrive in bozza una descrizione di quello che la foto mostra.
• Controlla title e meta description di tutti gli articoli e riscrivi quelli fuori misura. Una query misura le lunghezze sull'intero archivio, e la riscrittura tocca soltanto i campi fuori regola, con la parola chiave in testa e senza tono promozionale.
• Questo articolo è stato accorpato a quello sui piani di Shopify: crea il reindirizzamento. Claude crea il documento, aspetta che il 301 risponda a una richiesta vera sulla pagina vecchia e solo dopo ritira l'articolo di partenza.
• Metti su ogni articolo la chiamata all'azione giusta per la sua famiglia. Claude legge la famiglia di ogni articolo, sceglie l'invito corrispondente e inserisce nel corpo il blocco che lo cita: è il lavoro che ha portato una chiamata all'azione su tutti gli articoli pubblicati.
• Dimmi quali articoli hanno i titoletti senza una gerarchia pulita. L'analisi passa la struttura di ogni corpo e restituisce l'elenco articolo per articolo; è con una richiesta così che sono stati censiti gli articoli importati con uno stile di titolo diverso da quello di tutti gli altri.
• Nella pagina Shopify Plus sposta le testimonianze sopra le domande frequenti. Su una pagina a moduli è un cambio d'ordine in un elenco: la grafica non si tocca, e la modifica resta in bozza finché qualcuno non la pubblica.
• Quanto traffico arriva da ChatGPT e dagli altri assistenti, pagina per pagina? Qui Claude passa dalle API di Google Analytics, con un accesso in sola lettura, e restituisce le visite divise per pagina di atterraggio.

Chi non vuole passare da Claude apre Sanity Studio e compila gli stessi campi a mano. Il sito non ha bisogno di Claude per funzionare: Claude lavora sopra lo stesso CMS che usa la redazione.

Claude sul codice, e chi ne risponde

Sul front end vale la stessa divisione dei compiti, un piano più in basso.
Lo spieghiamo anche sulla pagina di ProvaGenerale, il nostro sistema di prototipazione: nel lavoro quotidiano, la scrittura del codice è delegata all'intelligenza artificiale, con controlli rigidi e la supervisione di chi sviluppa, che definisce l'architettura del prodotto, verifica quello che l'AI produce e risponde del risultato. Claude Code, lo strumento di Anthropic per il lavoro sul codice, legge il repository, modifica i file ed esegue i comandi; la decisione su come vanno fatte le cose resta a una persona.

Su un sito a moduli quel lavoro ha confini netti: un modulo nuovo è un componente nel front end e un tipo nello schema di Sanity, e i due devono dire la stessa cosa: i campi che lo schema chiede sono quelli che il componente mostra.
Il controllo di chi sviluppa si fa dove si vede, sulla pagina che il componente disegna e sullo schema che chi scrive si troverà davanti nello Studio.

La progettazione segue lo stesso filo: con ProvaGenerale il prototipo si costruisce in HTML con Claude Design, a partire dalle decisioni di chi progetta l'esperienza, e un HTML in cui spazi, dimensioni, stati e comportamenti sono già dichiarati è un punto di partenza che chi scrive il codice continua, senza dover interpretare un disegno.

I vantaggi della combinazione, per chi sviluppa e per chi gestisce

Sanity tiene i contenuti, Nuxt li disegna, Claude ci lavora sopra.

• Autonomia sui contenuti: pagine, landing e articoli si compongono con i moduli che esistono, e lo sviluppatore entra quando serve un modulo nuovo, non per spostare un banner.
• Coerenza grafica: la grafica sta nei componenti, quindi resta la stessa su tutte le pagine che usano lo stesso modulo, e una pagina nuova la eredita senza ridisegnarla.
• Un archivio solo: articoli, pagine, chiamate all'azione, autori e reindirizzamenti stanno nello stesso progetto, e un articolo porta il lettore a una pagina di servizio dello stesso sito.
• Indirizzi che cambiano senza toccare i testi: il passaggio del blog sotto /blog ha cambiato il modo in cui il front end scrive i link, e i link scritti negli articoli sono rimasti dov'erano.
• Controllo su tutto l'archivio: campi SEO, testi alternativi, link interni e reindirizzamenti si verificano con una query su centinaia di documenti, invece che pagina per pagina.
• Claude sui dati veri: le modifiche passano dai campi del CMS, in bozza, e ogni documento conserva la cronologia delle versioni; chi non vuole usarlo lavora nello Studio.
• Pagine servite già costruite: il rendering universale, che è la modalità predefinita di Nuxt, manda al browser, ai motori di ricerca e agli assistenti un HTML completo, che non aspetta il JavaScript per riempirsi.
• Niente tema e niente plugin di terzi: il front end è codice versionato di ICT Sviluppo e Sanity è un servizio gestito, quindi non c'è un tema o un plugin da aggiornare, e il codice che disegna le pagine cambia solo con un rilascio; restano esterni gli script che le pagine caricano da altri servizi, come il form di HubSpot o il gestore dei consensi.
• Contenuti riusabili: gli stessi documenti si leggono via API da qualunque canale, un'app, un negozio, una newsletter, perché non sono incollati a una pagina.

Un test di stamattina (il 14 ottobre 2026) con Lighthouse su profilo desktop, questa pagina segna 98 su 100 di prestazioni, 96 di accessibilità, 100 di buone pratiche e 100 di SEO tecnica, con il contenuto principale disegnato in 0,92 secondi.
La pagina dei servizi Shopify Plus, una delle più lunghe del sito, lo stesso giorno segna 96 di prestazioni, 99 di accessibilità e 100 di SEO tecnica, e scende a 77 nelle buone pratiche: delle due è l'unica che carica anche gli script di HubSpot per il form, che sono il primo indiziato e non ancora la causa accertata. Sono rilevamenti singoli e non medie su settimane.

Sull'accessibilità il punteggio automatico misura solo una parte dei criteri: nessuno strumento può dire se un testo alternativo descrive davvero l'immagine o se un contrasto è comodo per chi legge, e per il resto servono scelte prese a mano. Che cosa chiede la norma a chi pubblica, e come si lavora sui criteri, è nel pezzo sull'accessibilità web.

Che cosa chiede in cambio

Il front end è un'applicazione di ICT Sviluppo, e come tale va mantenuto: gli aggiornamenti, i componenti nuovi e le funzioni che su un CMS tradizionale si attivano con una spunta qui sono codice da scrivere e da controllare.

Che lo scriva una persona o un assistente, qualcuno lo deve rileggere, perché un front end scritto in buona parte da un'AI vale quanto il controllo di chi lo rilegge: per questo, nella dichiarazione di ICT Sviluppo, chi sviluppa risponde del risultato.

I fornitori sono tre, Sanity per i contenuti, Microsoft per l'hosting su Azure e Anthropic per Claude, e ognuno si può cambiare senza toccare gli altri due; il rovescio è che sono tre contratti, tre pannelli e tre posti dove un problema può nascere. Sanity si paga per utente che accede allo Studio: secondo il listino di Sanity, letto il 14 ottobre 2026, il piano Growth costa 15 dollari al mese per utente, fino a 50 utenti, mentre il piano gratuito arriva a 20 utenti con funzioni ridotte.

Il terzo costo da mettere in conto è la disciplina.
Un articolo è finito quando ha l'argomento, la famiglia, il ruolo, la persona, la fase del percorso, i sei correlati, la chiamata all'azione e il link al suo hub, e una pagina del sito è finita quando ha il suo titolo e la sua descrizione per i motori di ricerca; ogni casella vuota è un contenuto che sta nell'archivio senza esserci dentro. Quasi ottanta articoli, i più vecchi arrivati con la migrazione, roba scritta anni fa e oggi fuori focus rispetto a quello che vene l’azienda, non hanno ancora un ruolo, e si stanno lavorando uno per uno (lo fa Claude ovviamente, ma andiamo a rilento perchè poi ci vuole la supervisione umana…)

ICT Sviluppo costruisce progetti con Sanity anche per i clienti, quindi su questa scelta non è un osservatore neutrale.
Per un sito di poche pagine che cambia due volte l'anno, un CMS tradizionale fa lo stesso lavoro con meno pezzi.
La combinazione conviene quando i contenuti sono tanti, devono essere descritti da campi propri e interrogabili e servono anche fuori dal sito.
Chi valuta la stessa architettura per il proprio negozio online trova il ragionamento completo nel pezzo su cos'è un ecommerce headless, dove i vantaggi stanno accanto ai costi, e in quello su quando serve un CMS headless per l'ecommerce, con la domanda su chi deve possedere la pagina; lo stesso schema applicato a un negozio, con Sanity accanto al motore di vendita, è nel pezzo su Sanity e Shopify Plus.

Domande frequenti

Che cos'è un modulo in un sito fatto con Sanity?

È una sezione di pagina riusabile, come un'apertura, una griglia di loghi, una serie di domande frequenti o un form, che esiste come componente nel front end e come tipo di oggetto nello schema del CMS. Chi scrive sceglie i moduli, li mette in ordine e ne compila i campi; l'aspetto lo decide il componente, ed è lo stesso su tutte le pagine che lo usano.

Serve un CMS headless per fare un sito aziendale?

No, e per molti siti non conviene: un CMS tradizionale fa il lavoro con meno pezzi e meno manutenzione. Conviene quando i contenuti sono tanti, quando devono essere descritti da campi propri e interrogabili, quando servono anche fuori dal sito, e quando chi li gestisce vuole comporre pagine nuove senza aprire una richiesta allo sviluppo ogni volta.

Il sito funziona anche senza Claude?

Sì. Sanity Studio è un'interfaccia completa che si usa dal browser, e Claude lavora sullo stesso CMS attraverso il connettore. Se il connettore non c'è, i contenuti si gestiscono a mano come su qualunque CMS, e il front end non se ne accorge.

Claude può pubblicare un errore?

Sì, come chiunque scriva. Per questo le modifiche partono in bozza e ogni documento conserva la cronologia delle versioni, per un periodo che secondo la documentazione di Sanity va dai 3 giorni del piano gratuito ai 90 del piano Growth e ai 365 di Enterprise. Sul blog di ICT Sviluppo ogni intervento passa anche da una procedura di controllo scritta, con query che verificano il documento prima della pubblicazione e i conteggi dopo. Quanta autonomia dare all'assistente lo decide chi gestisce il sito, e la decisione si scrive nelle regole che ogni sessione legge.

Che differenza c'è fra pillar, hub e spoke?

Il pillar è il contenuto canonico di un argomento, e ce n'è uno solo per argomento. L'hub è il capofila di una famiglia dentro quell'argomento, e risponde per intero alla domanda comune dei pezzi che la compongono. Lo spoke approfondisce una porzione della materia e rimanda all'hub. La gerarchia serve a impedire che una sola pagina debba smistare i lettori in trenta direzioni.

Se un giorno si cambia front end, i contenuti restano?

Sì, perché stanno fuori dalle pagine. Un dataset di Sanity si esporta dalla riga di comando in un archivio compresso che contiene un documento JSON per riga, insieme a immagini e file, e un front end nuovo legge i contenuti dalle stesse API di quello vecchio. Si rifanno i componenti, e i testi restano dove sono.