Per vent'anni la risposta alla domanda "come faccio un sito?" è stata quasi sempre la stessa: WordPress. Era lo standard di fatto, il punto di partenza ovvio per chiunque, dal freelance al grande editore. Oggi quella risposta non è più scontata. Non perché WordPress sia diventato brutto o inutile, ma perché è cambiato qualcosa a monte: l'intelligenza artificiale ha imparato a scrivere codice di qualità produttiva, e questo sposta il baricentro di cosa conviene fare e a chi conviene affidarsi.

La domanda interessante non è "WordPress è morto?" — è una provocazione che si legge ovunque ma che semplifica troppo. La domanda vera è più sottile: se un assistente come Claude può costruirti un sito su misura in poche ore, cosa diventa il CMS? E soprattutto, chi gestirà quel sito dopo il lancio? Perché è lì, nella gestione quotidiana, che si gioca davvero la partita.

In questo articolo proviamo a mettere ordine. Guardiamo i numeri reali, mettiamo a confronto tre approcci concreti e poi mettiamo le carte in tavola: diciamo apertamente qual è l'approccio che oggi scegliamo per i nostri progetti, e perché. Non è un confronto neutro travestito da oggettività — è la nostra posizione, argomentata. La domanda che ci sta più a cuore, perché è quella che ci fa ogni cliente, è duplice: una persona senza competenze tecniche riesce davvero a gestire un setup moderno senza rompere tutto? E chi tiene in piedi il sito quando l'agenzia non c'è più a seguirlo? Useremo come esempi a supporto anche due progetti che abbiamo realizzato direttamente — il nuovo bryan.it e iainazienda.it — perché parlare di cose fatte vale più di mille schemi teorici.

Lo scenario reale: WordPress domina ancora, ma per la prima volta scricchiola

Partiamo dai fatti, perché è facile farsi travolgere dalla narrativa del "tutto sta cambiando". WordPress, a metà 2026, alimenta ancora circa il 41-43% di tutti i siti web del mondo e detiene quasi il 60% del mercato dei CMS: una posizione dominante che nessun concorrente si avvicina a insidiare (w3techs, Barn2). Chi dice che WordPress è finito sta esagerando, e di parecchio.

Però — e questo è il dato nuovo — per la prima volta dopo anni di crescita ininterrotta la quota ha smesso di salire. Si è passati dal 43,2% di dicembre 2025 al 41,9% di fine maggio 2026, un calo piccolo ma significativo proprio perché inverte una tendenza che durava dal 2017 (Sketchweb). Non è un crollo: è il segnale che il monopolio mentale del "tanto si fa con WordPress" si sta incrinando. E si incrina proprio mentre emergono due alternative che fino a poco fa erano riservate a team con sviluppatori interni: i CMS headless e i siti generati con l'AI.

Tre approcci sul tavolo (non due)

Il dibattito viene spesso raccontato come uno scontro a due, vecchio contro nuovo. In realtà oggi le strade praticabili sono tre, e fanno cose diverse.

1. L'approccio tradizionale — WordPress (o Wix, Squarespace). Un sistema "monolitico": la gestione dei contenuti e la presentazione grafica vivono nello stesso posto, strettamente accoppiate. Installi temi e plugin, e il sito è pronto. È il modello che conosciamo tutti.

2. L'approccio moderno headless — un CMS come Sanity + un frontend su Vercel. Qui il backend dei contenuti viene completamente separato dal frontend. Sanity conserva i contenuti come "dati puri" in un repository centrale, e il frontend (costruito con framework come Next.js e pubblicato su Vercel) li recupera via API e li mostra come vuole (Pagepro). I contenuti diventano riutilizzabili su più canali (sito, app, newsletter) perché non sono "incollati" a una grafica.

3. L'approccio AI-native — un sito costruito da zero con un assistente come Claude. Qui non parti da un tema preconfezionato: descrivi cosa vuoi e l'AI scrive il codice del sito su misura, pulito e senza la zavorra di decine di plugin. È l'approccio più recente, ed è quello che sta facendo più rumore.

Vale la pena chiarire subito un equivoco di fondo, perché è il cuore della tua domanda.

Claude può essere "il CMS"? Distinguere tra costruire e gestire

Qui serve una distinzione netta, perché si confondono due cose diverse.

Un CMS — Content Management System — è prima di tutto un'interfaccia di editing: un pannello dove una persona, magari non tecnica, scrive un articolo, cambia un prezzo, aggiunge una pagina senza toccare il codice. La domanda, allora, non è davvero "Claude è un CMS?" — è "qual è l'interfaccia di editing migliore, un pannello a moduli o le istruzioni in linguaggio naturale?".

E qui va corretto un equivoco comune, perché è il punto che cambia tutto. Si tende a dire che Claude "serve a costruire, non a gestire". Falso, o almeno troppo riduttivo. Se dici a Claude "creami una nuova pagina con questi contenuti", oppure "modifica questa pagina, sposta questo blocco più in alto, quello più in basso, e aggiungi una sezione con questo testo", il risultato lo ottieni — e spesso più in fretta di quanto impiegheresti a cercare il campo giusto in un pannello CMS. Claude non è solo lo sviluppatore che costruisce il sito: è anche un'interfaccia di editing in linguaggio naturale, e su tutto ciò che è strutturale o di layout — proprio le cose dove i CMS sono più macchinosi — è quasi imbattibile.

La distinzione onesta quindi non è "pannello sì, AI no". È quale modello conviene, in base a tre variabili: quante persone editano, quanto spesso, e che tipo di modifiche fanno.

- Il pannello tradizionale (CMS) vince quando hai molti editor non tecnici che lavorano in parallelo, micro-modifiche ad altissima frequenza, bisogno di anteprima self-service istantanea e gestione fine dei permessi. È il caso della redazione, del team marketing numeroso, del catalogo che cambia ogni ora. - L'editing via Claude vince quando sei un owner-operator o un team piccolo, le modifiche hanno frequenza medio-bassa, e spesso sono strutturali. Il caveat onesto: esiste un ciclo di pubblicazione (versioni, anteprima, deploy) e serve qualcuno a suo agio nel dirigere l'AI — ma "saper descrivere cosa vuoi" è un'asticella molto più bassa che "imparare un CMS".

Da qui le due strategie pratiche, entrambe valide:

- AI per costruire + CMS leggero per gestire. Claude costruisce il sito e collega un CMS headless (come Sanity) come pannello quotidiano per chi pubblica. È l'approccio ibrido di bryan.it, adatto quando ci sono più persone a metter mano ai contenuti. - AI per costruire e per modificare direttamente. Si fa a meno del CMS tradizionale e si torna da Claude per ogni aggiornamento, anche pagine intere. Funziona benissimo per progetti più "a prodotto" che "a redazione", dove chi gestisce è una o due persone.

Una nota di realismo sull'headless "multipiattaforma", visto che è il suo argomento di vendita principale. La promessa — scrivi una volta, distribuisci ovunque: web, app, smartwatch, IoT — è reale ma per una minoranza di casi: grandi brand con davvero più canali da alimentare. Per la stragrande maggioranza dei progetti, headless significa un sito solo, e quindi è di fatto "un CMS diverso e migliore" — non l'omnichannel da brochure. Non solo: appena un editor vuole controllo sul layout, si finisce per aggiungere campi che sono presentazione travestita da contenuto (spaziatura, "mostra solo su mobile", variante di sfondo, ordine dei blocchi). Sono campi che hanno senso solo per quello specifico frontend e che inquinano la purezza del "contenuto strutturato e riutilizzabile". Tant'è che l'industria ha dovuto inventare i visual editor proprio per tappare questo buco, segno che il problema è reale (Prismic, dotCMS). Quando il modello dati non ha previsto il drag-and-drop, devi rifare gli schemi e aggiungere metadati di presentazione — e lì la teoria della "separazione netta" si sgretola. Morale: l'headless ha vantaggi veri, ma vanno cercati nella performance e nella sicurezza, non nel mito del multicanale che la maggior parte dei siti non userà mai.

Interessante notare che lo stesso mondo WordPress si sta muovendo verso l'editing conversazionale: WordPress.com ha rilasciato a febbraio 2026 un plugin che trasforma una conversazione con Claude in un sito WordPress completo, generando temi a blocchi e pubblicandoli (WordPress.com). Segno che la frattura non è "AI contro WordPress", ma "AI che riscrive le regole di tutti".

E se il sito fosse semplicemente HTML statico? La sicurezza che sparisce

C'è un corollario tecnico che merita un paragrafo a sé, perché risolve d'un colpo una montagna di problemi: ragionare a pagine HTML statiche. La maggior parte delle vulnerabilità di un sito tradizionale nasce da tre cose: un database da interrogare, codice eseguito sul server a ogni richiesta, e un pannello di login da proteggere. Un sito statico non ha nessuna delle tre. Non c'è database da violare con una SQL injection, non c'è PHP che gira sul server da exploitare, non c'è una pagina /wp-admin da bombardare con tentativi di accesso. La superficie d'attacco si riduce drasticamente perché, banalmente, non c'è quasi nulla da attaccare: ci sono solo file serviti da una CDN.

È esattamente la logica dell'architettura Jamstack: file pre-renderizzati e serviti da una rete di distribuzione globale, senza query né esecuzione server-side a ogni pagina (Naturaily). Il vantaggio è doppio — sicurezza e velocità — e si sposa perfettamente con l'approccio AI: Claude genera le pagine, queste vengono pubblicate come statiche, e ciò che resta da "proteggere" è ridotto al minimo. Le funzioni dinamiche che servono davvero (un form, un pagamento, una ricerca) si delegano a servizi esterni specializzati e già blindati, invece di tenere in casa un intero stack vulnerabile. Per moltissimi siti vetrina, portfolio, landing e blog, questo è semplicemente l'assetto più sicuro possibile — e il più economico da mantenere, perché non c'è un server da aggiornare ogni settimana per chiudere falle. Il limite, ovviamente, c'è: quando la logica applicativa diventa davvero complessa e ricca di stato (aree riservate, e-commerce articolati, gestionali), il "puro statico" non basta più e servono parti dinamiche — ma anche lì l'approccio resta "statico dove puoi, dinamico solo dove devi".

I pro e i contro (e da che parte stiamo)

Mettiamo subito le carte in tavola: per la maggior parte dei progetti che ci arrivano oggi scegliamo l'approccio AI — da solo, o in coppia con un headless leggero. Non perché sia di moda, ma per le ragioni concrete che spieghiamo qui sotto. Detto questo, WordPress resta la scelta giusta in alcuni scenari, e lo diciamo con la stessa franchezza. Ecco i tre approcci con pregi e difetti reali, e dove ci schieriamo noi.

L'approccio tradizionale (WordPress)

I vantaggi restano enormi e spiegano perché domina ancora. L'ecosistema di plugin è sterminato: un non-sviluppatore può aggiungere e-commerce, SEO, form e funzioni complesse senza scrivere una riga (Cinute). C'è una community immensa, trovi chiunque sappia metterci mano, e per certi scenari — grandi siti editoriali con migliaia di pagine e molti redattori, oppure store WooCommerce con cataloghi complessi e integrazioni già rodate — il flusso di lavoro è difficile da battere (Recursion).

I contro sono il rovescio della stessa medaglia. L'architettura monolitica esegue codice PHP e interroga il database a ogni caricamento, con possibili problemi di performance. Soprattutto, i plugin che danno tutta quella comodità portano con sé bloat tecnico, conflitti, e una superficie d'attacco ampia che impone aggiornamenti continui per ragioni di sicurezza (Pagepro). In pratica: parti veloce, ma la manutenzione diventa un costo permanente.

L'approccio moderno headless (Sanity + Vercel)

I vantaggi sono performance e sicurezza. I file pre-renderizzati serviti da una CDN globale caricano quasi istantaneamente, senza query al database a ogni pagina (Naturaily). La sicurezza è centralizzata e la superficie d'attacco si riduce, perché il CMS non serve direttamente il sito. La gestione dei contenuti è pensata per il lavoro di squadra: collaborazione in tempo reale, cronologia delle versioni, contenuti strutturati e riutilizzabili su più canali (Sanity). Il carico di manutenzione del backend è molto più basso, perché se ne occupa il fornitore.

I contro: richiede più impostazione iniziale e, storicamente, competenze di sviluppo. La frase ricorrente nei confronti tra i due mondi è proprio questa: WordPress vince quando vuoi funzionalità avanzate, facilità d'uso e costi ragionevoli; Sanity vince quando hai sviluppatori forti e ti serve controllo profondo su contenuti strutturati e multicanale (Pagepro). Il prezzo, inoltre, scala con l'uso delle API e il numero di utenti. È proprio su questo "richiede sviluppatori" che l'AI cambia le carte in tavola.

L'approccio AI-native (sito costruito da Claude)

I vantaggi sono seducenti: design su misura per il tuo brand, codice pulito senza bloat, SEO e markup strutturato curati fin dall'inizio, e l'eliminazione di tutto il fardello classico — login da proteggere, plugin da aggiornare, vulnerabilità da rincorrere (Recursion). Una società di consulenza ha raccontato di aver sostituito il proprio sito WordPress con una versione AI in 48 ore (innFactory). E lato frontend l'ecosistema accelera: Vercel ha spinto molto su v0, il suo strumento di generative UI (Naturaily).

I contro vanno presi sul serio, perché sono quelli di cui si parla meno nei post entusiasti. Il rischio principale è la manutenibilità: l'AI tende a privilegiare "funziona" rispetto a "è mantenibile", e nel tempo si può perdere traccia della logica di business, con debito tecnico che si accumula se nessuno governa il processo (Jellyfish). C'è poi il tema del lock-in e della dipendenza da una piattaforma: vale per qualsiasi servizio, ma va messo in conto. La regola pratica è semplice: un sito generato dall'AI non è "fai e dimentica", ha bisogno di qualcuno — umano o AI ben indirizzata — che ne resti responsabile.

La domanda che conta davvero: una persona non tecnica ce la fa?

È la domanda giusta, perché la maggior parte di chi possiede un sito non scrive codice e non vuole impararlo. La risposta è incoraggiante ma ha delle condizioni.

Sul fronte della gestione dei contenuti, i CMS headless moderni non sono più territorio esclusivo degli sviluppatori. Una volta che lo sviluppatore (o l'AI) ha impostato la struttura, l'editor di un CMS come Sanity è pensato proprio perché chi crea contenuti possa generare quante landing page vuole da solo, in autonomia, senza aspettare la coda dello sviluppo (Naturaily). Il punto delicato non è scrivere un articolo — quello è facile — ma fare modifiche strutturali senza combinare guai.

Non a caso, in questo ambito si osserva come l'introduzione dell'AI nei design system, abbinata a token strutturati, riduca drasticamente il lavoro manuale di manutenzione e il cosiddetto “design drift”: UXPin riferisce una riduzione fino all'82% del debito tecnico legato al design (UXPin).UXPinParallelUXPin

La condizione, però, c'è: questa tranquillità non è automatica, è progettata. Qualcuno deve aver impostato bene il design system, separato ciò che l'editor può toccare da ciò che è bloccato, e definito un minimo di governance. Fatto questo lavoro a monte — ed è esattamente il tipo di lavoro in cui l'AI oggi eccelle — la gestione quotidiana diventa alla portata di chiunque sappia usare un pannello web.

Due casi concreti: come abbiamo lavorato noi

La teoria si capisce meglio con esempi reali, e ne abbiamo due che illustrano i due modelli di cui sopra.

bryan.it — il modello ibrido (Vercel + Sanity, AI come collaboratore). Per il nuovo sito siamo partiti dai layout di frontend disegnati con Gemini, poi abbiamo chiesto a Claude di gestire i blocchi CMS e tutto il resto dell'implementazione, su uno stack Vercel + Sanity. È esattamente l'architettura headless "manuale" descritta sopra — frontend veloce su Vercel, contenuti strutturati su Sanity — ma con una differenza sostanziale: la parte che storicamente richiedeva sviluppatori senior (collegare i blocchi, strutturare lo schema dei contenuti, far parlare frontend e CMS) è stata orchestrata con l'AI. Il risultato è un sito con i vantaggi dell'headless — performance, sicurezza, contenuti riutilizzabili — ma realizzato senza il costo e i tempi di un team di sviluppo tradizionale. E, una volta in piedi, i contenuti si gestiscono dal pannello di Sanity senza toccare codice.

C'è poi un aspetto che in fase di lavoro si è rivelato decisivo, ed è forse il vantaggio meno raccontato di tutti: abbiamo usato Claude anche per popolare il CMS. Invece di sederci a fare data entry blocco per blocco — inserire a mano decine di pagine, sezioni e campi, un lavoraccio meccanico che divora ore — abbiamo chiesto a Claude di fare gli import e creare i blocchi direttamente. Questo capovolge un'obiezione classica all'headless: "sì, ma poi qualcuno deve riempirlo, e riempirlo è una noia mortale". Con l'AI quel collo di bottiglia in gran parte sparisce. Non è solo che Claude costruisce il contenitore: lo riempie, trasformando il data entry da lavoro umano ripetitivo a operazione che descrivi una volta e deleghi. È un punto che vale per qualsiasi CMS — tradizionale o headless — perché la fatica del popolamento iniziale (e delle migrazioni di contenuti da un vecchio sito) è universale, ed è esattamente il tipo di compito in cui l'AI dà il meglio.

iainazienda.it — il modello AI-native completo. Qui siamo andati oltre: tutto sviluppato da zero con Claude, incluse due parti notoriamente complesse come l'elearning e l'e-commerce dei corsi. Sono proprio gli scenari che secondo la vulgata "servono per forza WordPress + WooCommerce + plugin LMS": catalogo prodotti, gestione acquisti, erogazione dei contenuti formativi. Averli costruiti su misura significa nessun plugin da aggiornare, nessuna vulnerabilità ereditata, e funzionalità che fanno esattamente ciò che serve invece di adattarsi a ciò che un plugin generico permette. È il caso che dimostra concretamente la tesi di chi sostiene che l'AI può sostituire stack complessi — con l'avvertenza, vera per tutti, che un sistema del genere va presidiato nel tempo.

I due progetti, messi insieme, raccontano bene il ventaglio: bryan.it mostra che l'AI può abbassare la barriera dell'headless professionale; iainazienda.it mostra che può sostituire stack tradizionali anche su funzioni complesse.

Chi mantiene il sito quando l'agenzia non c'è?

È la domanda che ogni cliente fa, prima o poi, e di solito a mezza voce: “se mi costruite un sito su misura, poi resto legato a voi per sempre?”. È una preoccupazione legittima, e la risposta onesta cambia parecchio a seconda dell'approccio.

Partiamo da un equivoco da sfatare: la manutenzione non sparisce mai del tutto, per nessun sito. Con WordPress, anzi, è un costo permanente e spesso sottovalutato — aggiornamenti del core, dei temi e di decine di plugin, patch di sicurezza da applicare in fretta quando esce una falla, conflitti dopo ogni update. Se non lo fai tu, paghi qualcuno che lo faccia; se non lo fa nessuno, il sito prima o poi viene bucato. La “libertà” del fai-da-te è in buona parte apparente, perché il carico resta lì, ogni mese.

Con il modello ibrido di bryan.it (Vercel + Sanity) la gestione quotidiana è in mano al cliente, senza di noi e senza codice: si pubblica e si modificano i contenuti dal pannello di Sanity come da qualsiasi CMS. Gli aggiornamenti tecnici veri e propri sono molto più rari e leggeri che su WordPress, perché non c'è la giostra dei plugin e la superficie d'attacco è ridotta. E soprattutto: lo stack è standard e diffuso (Next.js, Sanity, Vercel), non una scatola nera proprietaria. Il codice è del cliente; qualsiasi sviluppatore può riprenderlo in mano. Non si è ostaggi di noi.

Con il modello AI-native di iainazienda.it vale lo stesso principio, rafforzato da un dettaglio che cambia le regole: il codice è pulito, documentato e standard, quindi lo può mantenere qualunque sviluppatore — ma anche la stessa AI che lo ha costruito. Per molte modifiche non serve neppure un tecnico: si descrive a Claude la modifica (“cambia questo prezzo”, “aggiungi una pagina”, “sposta questa sezione”) e la si ottiene. In altre parole, il cliente non sceglie più tra “dipendo dall'agenzia” e “imparo a programmare”: può dirigere l'AI, oppure affidarsi a chiunque preferisca per farlo. L'agenzia diventa una scelta, non una catena.

C'è poi un vantaggio strutturale che riduce a monte il problema: un sito statico servito da CDN non ha un server da aggiornare ogni settimana né un pannello di login da difendere. Continua a funzionare anche se per mesi nessuno lo tocca. Quello che facciamo concretamente, alla consegna, è proprio questo: trasferiamo repository e accessi, lasciamo il progetto documentato, e ci assicuriamo che il sito stia in piedi da solo. Se poi il cliente vuole continuare con noi, è perché conviene — non perché non può farne a meno.

L'unica avvertenza, valida per qualunque approccio: il “fai e dimentica” non esiste. Qualcuno deve restarne responsabile nel tempo. La differenza è che, con l'approccio AI, l'asticella per essere quel qualcuno è molto più bassa di prima.

Chi ne sta parlando online

Non è un dibattito di nicchia: se ne discute parecchio, ed è materiale citabile. La provocazione "WordPress è morto" è ormai un genere a sé — Recursion la usa per argomentare perché l'AI sta sostituendo i CMS tradizionali nel 2026 (Recursion), mentre innFactory ha documentato la propria migrazione in 48 ore (innFactory). Sul fronte opposto, sviluppatori dell'ecosistema WordPress come Jonathan Bossenger raccontano come hanno costruito temi a blocchi personalizzati usando proprio Claude (Bossenger) — a riprova che la linea non è "AI contro il vecchio mondo", ma AI che entra in tutti i flussi. Il confronto Sanity vs WordPress, tradizionale vs headless, è ormai un classico con guide approfondite (Pagepro, Kevin Saffer). E lo stesso WordPress.com che pubblica un plugin per costruire siti con Claude è forse il segnale più eloquente di tutti (WordPress.com).

Allora cosa scegliere?

Niente verità assolute, ma una bussola pratica.

Se hai un grande sito editoriale con molti redattori e migliaia di pagine, o un e-commerce molto standard dove WooCommerce e i suoi plugin fanno già tutto, WordPress resta una scelta sensata: la sua forza è l'ecosistema e il flusso redazionale collaudato.

Se ti serve un sito veloce, sicuro e con contenuti riutilizzabili su più canali, e vuoi i vantaggi dell'headless senza pagare un team di sviluppo intero, il modello AI + headless (Vercel + Sanity) di bryan.it è probabilmente il punto di equilibrio migliore oggi: barriera tecnica abbattuta, gestione quotidiana alla portata di chi non scrive codice.

Se hai un progetto su misura con funzioni specifiche — un'app web, una piattaforma di formazione, un e-commerce con logiche particolari — e nessun plugin off-the-shelf ti convince, il modello AI-native di iainazienda.it ti dà esattamente ciò che serve, a patto di mettere in conto che qualcuno (o un'AI ben indirizzata) ne resti responsabile nel tempo.

Il vero cambiamento non è che WordPress stia morendo — non sta morendo. È che, per la prima volta, le alternative più potenti non sono più appannaggio esclusivo di chi ha sviluppatori in casa. L'AI non ha tanto inventato un nuovo modo di fare siti: ha tolto la barriera che teneva la maggior parte delle persone lontane dai modi migliori che già esistevano. E questa, per chiunque debba decidere come costruire la propria presenza online, è una notizia che vale la pena raccontare.

Fonti

- w3techs — Usage Statistics of WordPress, June 2026 - Barn2 — 2026 WordPress Market Share Report - Sketchweb — WordPress Market Share Decline - Recursion — Is WordPress Dead? Why AI Is Replacing CMS Tools in 2026 - innFactory — How AI Replaced Our Website in 48h - WordPress.com — New Plugin and Skills for Claude Cowork - Jonathan Bossenger — Custom WordPress block theme with Claude - Pagepro — Best CMS in 2026: Sanity vs WordPress - Sanity — Sanity vs WordPress - Cinute Infomedia — Headless Sanity vs WordPress 2026 - Kevin Saffer — The Great CMS Debate: WordPress vs Sanity - Naturaily — What Is Jamstack in 2026? - Prismic — Best Headless CMS with Visual Editing (2026) - dotCMS — Visual Headless CMS vs Traditional Headless CMS - UXPin — AI in Design Systems: Consistency Made Simple - Parallel — Automating Design Systems with AI: 2026 Workflow Guide - Jellyfish — The Risks of Using Generative AI in Software Development