Dopo 20 anni abbandona WordPress: il nuovo CMS che vuole sostituirlo

Dopo oltre 20 anni di esperienza con WordPress e più di 1.500 siti commerciali realizzati dalla sua agenzia, Ajay Chavda ha deciso di non consigliare più il CMS che ha accompagnato gran parte della sua carriera. La ragione non riguarda una singola vulnerabilità o una funzionalità mancante: secondo lo sviluppatore, WordPress avrebbe accumulato problemi architetturali che rendono sempre più costosa la gestione di siti Web professionali. Da questa convinzione nasce Hatamoto, un nuovo CMS open source scritto in Go, progettato per ridurre la dipendenza dai plugin, isolare il codice di terze parti e consentire anche agli agenti AI di amministrare i contenuti.

WordPress fu presentato nel 2003 come piattaforma per blog, prima di trasformarsi in uno dei sistemi di gestione dei contenuti più diffusi al mondo. L’introduzione della REST API nel core del CMS, completata con WordPress 4.7 nel dicembre 2016, e l’arrivo dell’editor Gutenberg nel 2018 hanno progressivamente ampliato le possibilità della piattaforma. La sua principale forza, tuttavia, rimane la disponibilità di migliaia di temi e plugin: un vantaggio che introduce anche dipendenze, problemi di compatibilità e un’estesa superficie di attacco.

Secondo il rapporto Patchstack pubblicato a febbraio 2026, durante il 2025 sono emerse 11.334 nuove vulnerabilità nei componenti WordPress, il 42% in più rispetto al 2024. Il 91% riguardava plugin, il 9% temi; soltanto 6 interessavano direttamente i componenti core.

Il vero problema di WordPress non è il core, ma quello che ci gira intorno

Una normale installazione WordPress può utilizzare decine di estensioni per gestire SEO, moduli di contatto, cache, reindirizzamenti, sicurezza, integrazioni commerciali e funzionalità editoriali. Ciascun componente aggiunge codice PHP che opera all’interno dell’applicazione, spesso con accesso alle stesse risorse del CMS.

WordPress non dispone di un isolamento nativo dei plugin a livello di processo: un’estensione PHP eseguita dal server eredita sostanzialmente i privilegi dell’applicazione e può interagire con filesystem, database e servizi esterni, nei limiti imposti dall’ambiente PHP e dal sistema operativo.

Per come è concepito WordPress, il CMS consente di verificare i privilegi degli utenti, ma non offre un sistema di autorizzazioni che impedisca a un plugin di accedere direttamente a determinate tabelle o risorse. Un componente vulnerabile può quindi compromettere informazioni che non dovrebbe neppure utilizzare.

La situazione diventa particolarmente delicata quando un’agenzia deve mantenere centinaia di installazioni: una ricerca CloudLinux e WebPros del 2026, condotta su 210 agenzie e professionisti, indica che il 65% dei soggetti considera gli aggiornamenti di plugin e temi una delle maggiori difficoltà operative. La percentuale sale al 75% tra chi gestisce oltre 100 siti. L’affidabilità complessiva dipende insomma da molti componenti sviluppati e aggiornati indipendentemente: per questo, in tanti, cercano di ridurre al minimo l’uso di codice di terze parti con WordPress. In molti casi, però, non è possibile proprio astenersi, a meno di non sviluppare funzionalità in autonomia e occuparsi quotidianamente della loro manutenzione.

La ricetta di Hatamoto per aggiornamenti e rollback: perché correggere un errore non basta

WordPress ha introdotto meccanismi di ripristino automatico per alcune situazioni: dalla versione 6.6, per esempio, il CMS può annullare l’aggiornamento automatico di un plugin quando rileva specifici errori fatali PHP.

Un componente aggiuntivo, tuttavia, può aggiornarsi senza generare errori fatali e interrompere un processo: un modulo non invia più email, un checkout non completa gli ordini oppure un tema altera il layout. Dal punto di vista del server, la pagina continua a rispondere regolarmente ma una funzionalità aggiunta a WordPress è di fatto andata persa.

Dite che il parere è di parte, però Chavda ha proprio reagito ai vari punti interrogativi e ai problemi di WordPress sviluppando un nuovo CMS: Hatamoto (questo il nome del progetto) conserva la versione precedente accanto alla nuova e controlla il comportamento dell’applicazione dopo ogni aggiornamento: la nuova release dispone di 2 minuti per avviarsi; successivamente, per un minuto, il sistema verifica homepage, sitemap, pagina pubblicata e accesso amministrativo.

Se emergono errori, risorse precedentemente funzionanti non rispondono oppure si verificano tre crash entro 2 minuti, interviene il rollback automatico, che ripristina l’applicazione nella configurazione precedente.

Plugin WebAssembly: la differenza più importante rispetto a WordPress

Il cambiamento più interessante introdotto da Hatamoto riguarda il modello di esecuzione delle estensioni. Invece di caricare codice PHP con gli stessi privilegi dell’applicazione, Hatamoto utilizza WebAssembly (WASM), attraverso il framework Extism e il runtime wazero.

Ogni plugin funziona in un ambiente isolato, con limiti di memoria e tempo di esecuzione: le operazioni consentite dipendono dalle autorizzazioni dichiarate e approvate durante l’installazione.

Per esempio, un plugin incaricato di visualizzare informazioni meteorologiche può ricevere il permesso di leggere determinati contenuti e contattare un servizio esterno specifico, senza ottenere accesso alle credenziali degli utenti o alle altre tabelle del database.

Il modello segue il principio del minimo privilegio: un’estensione dispone soltanto delle capacità necessarie al proprio funzionamento. Se supera i limiti o genera un errore, Hatamoto può interromperla e continuare a produrre la pagina senza il relativo contributo.

Va detto però che WebAssembly non rappresenta una garanzia assoluta di sicurezza: l’efficacia dell’isolamento dipende dal runtime, dalle funzioni che l’applicazione espone ai moduli e dalla corretta verifica dei permessi.

Un CMS scritto in Go, senza PHP e senza Node.js

Dal punto di vista infrastrutturale, Hatamoto (repository GitHub) adotta una soluzione relativamente semplice: un singolo eseguibile Go che gestisce le funzionalità applicative, affiancato da PostgreSQL per la persistenza dei dati.

Non occorre configurare PHP-FPM né predisporre un processo Node.js per il rendering delle pagine: il server genera direttamente HTML completo, utilizzando template differenti per articoli, archivi, pagine e risposte 404.

Per gli sviluppatori abituati ai temi WordPress, l’organizzazione rimane riconoscibile: layout dedicati alle diverse tipologie di contenuto e componenti riutilizzabili per intestazione, piè di pagina e altre sezioni.

Chavda dichiara che il sito hatamoto.dev utilizza circa 280 MB di memoria per il processo principale e ulteriori 27 MB per il supervisore, mentre l’eseguibile occupa circa 49 MB. La cache delle pagine è integrata nel CMS, con possibilità di configurare durata, memoria massima e precaricamento degli URL presenti nella sitemap. Le modifiche ai contenuti provocano l’invalidazione della cache interessata, senza richiedere necessariamente Redis, Varnish o un plugin dedicato.

Una soluzione integrata semplifica l’amministrazione, anche se non elimina l’utilità di una CDN o di sistemi di caching distribuiti quando il traffico e l’architettura richidessero più server.

Hatamoto integra MCP per far lavorare gli agenti AI sui siti Web

Un’altra differenza sostanziale riguarda il rapporto con l’intelligenza artificiale. WordPress dispone già di REST API, application password e strumenti con cui sviluppare integrazioni automatizzate; di recente WordPress si è aperto ad assistenti e agenti AI con MCP (Model Context Protocol). Hatamoto sceglie però di incorporare direttamente un server MCP.

Il protocollo permette a client e agenti AI compatibili di interagire con strumenti e risorse esposti dal CMS: un agente potrebbe, per esempio, preparare un articolo, aggiornare una scheda prodotto, correggere un collegamento o intervenire su determinati metadati.

La particolarità sta nella gestione delle autorizzazioni: ogni agente possiede una chiave API con permessi circoscritti. Un agente autorizzato a modificare gli articoli non ottiene automaticamente il diritto di modificare menu, media o redirect.

Le operazioni passano dagli stessi servizi applicativi utilizzati dall’interfaccia amministrativa, rispettando validazioni e controlli. Hatamoto dichiara inoltre di registrare le chiamate in un audit log e di creare inizialmente come bozze i contenuti generati dagli agenti.

È un approccio interessante soprattutto per chi gestisce pubblicazioni automatizzate: l’AI non dovrebbe mai ricevere accesso amministrativo completo soltanto perché deve preparare un articolo. Restano ovviamente indispensabili controlli editoriali, protezioni contro la prompt injection e verifiche sulle azioni eseguite: i permessi limitano i danni potenziali, non garantiscono la correttezza del contenuto e soprattutto non escludono la responsabilità di un soggetto in carne ed ossa.

Dati strutturati, SEO e accesso dei crawler AI

Hatamoto prova anche a ridurre la distanza tra contenuti editoriali e informazioni comprensibili dalle macchine: ogni tipologia di contenuto può essere associata a uno schema che utilizza i vocabolari di Schema.org.

Da una rappresentazione comune, il CMS genera pagine HTML, JSON-LD, sitemap e altre informazioni strutturate; l’obiettivo è evitare incongruenze tra i dati pubblicati e quelli forniti ai motori di ricerca.

Il progetto prevede anche la generazione di llms.txt e statistiche dedicate ai crawler AI conosciuti, con registrazione delle richieste e delle visite eventualmente riconducibili agli assistenti. Va precisato, comunque, che llms.txt non costituisce uno standard universalmente adottato dai sistemi di intelligenza artificiale e non garantisce maggiore visibilità nelle risposte generative. Allo stesso modo, i dati strutturati aiutano a descrivere i contenuti ma non assicurano automaticamente posizionamenti migliori.

La possibilità di riconoscere un crawler dipende inoltre dall’affidabilità dei segnali disponibili: il solo User-Agent HTTP può essere falsificato e non consente sempre di stabilire se una visita appartenga realmente a un determinato servizio AI.

Moduli, webhook, backup e migrazioni senza decine di estensioni

Il progetto include nativamente moduli di contatto, campi personalizzati, menu, redirect e cronologia delle revisioni: i moduli consentono di definire controlli sui valori inseriti, memorizzare le richieste, esportarle in CSV e inviare notifiche.

Per comunicare con sistemi esterni è disponibile un plugin ufficiale per i webhook, con firme HMAC-SHA256 e tentativi successivi in caso di consegna fallita. Il destinatario può verificare l’autenticità del messaggio tramite un segreto condiviso; rimangono importanti anche la gestione dei replay e l’idempotenza delle operazioni.

Per i backup, Hatamoto propone i comandi hatamoto export e hatamoto import: il primo produce un archivio contenente dati del sito, contenuti, revisioni, file multimediali, utenti e configurazioni; il secondo permette di ricostruire l’installazione su un altro server.

Hatamoto può davvero sostituire WordPress?

Il codice di Hatamoto è disponibile su GitHub con licenza Apache 2.0. La piattaforma punta su installazioni autonome, distribuzione tramite eseguibili firmati o container Docker e minore dipendenza dai servizi centralizzati.

Esistono però differenze importanti tra una nuova architettura promettente e un’alternativa già collaudata su larga scala.

WordPress dispone di un’enorme disponibilità di sviluppatori, integrazioni commerciali, hosting specializzati e componenti consolidati. Migrare un sito complesso, soprattutto se utilizza WooCommerce, plugin personalizzati o processi articolati, richiede molto più che trasferire articoli e immagini.

Inoltre, alcune garanzie dichiarate da Hatamoto, tra cui isolamento dei plugin, ripristino automatico e affidabilità degli aggiornamenti, richiedono verifiche indipendenti e prove su installazioni reali.

Il dibattito aperto da Chavda è però cruciale: WordPress ha costruito il suo successo sulla flessibilità e sulle estensioni; Hatamoto tenta di spostare l’attenzione verso componenti integrati, permessi espliciti e automazione controllata.

Il nome Hatamoto deriva dal giapponese 旗本, letteralmente “alla base della bandiera“: nel Giappone feudale identificava i samurai direttamente al servizio dello shogun. Un richiamo alla lealtà e alla protezione che ben si presta alla filosofia del nuovo CMS, incentrata su sicurezza, controllo e indipendenza.