Perché WordPress non è adatto a un sito professionale (e con l'AI lo è ancora meno)

Voglio partire da un riconoscimento, perché è dovuto: WordPress ha fatto una cosa che nessun altro software ha fatto. Ha messo un editor di testo davanti a milioni di persone che non avevano nessun motivo di imparare l’FTP, e le ha convinte che pubblicare fosse una cosa che potevano fare anche loro. Il web amatoriale degli anni Duemila esiste in gran parte grazie a lui. Anche io ho iniziato lì.

Il problema è che quello strumento, nato per far pubblicare un appassionato di fotografia dal salotto di casa, è diventato per default la fondazione di asset commerciali. Il sito su cui un’azienda costruisce metà della sua acquisizione clienti gira sullo stesso motore del blog di ricette di vent’anni fa. E quel motore, per quel lavoro, non è stato progettato.

L’autonomia promessa che nessuno usa davvero

L’argomento numero uno a favore di WordPress è sempre lo stesso: “così il cliente è autonomo”.

Nella mia esperienza è la promessa meno mantenuta del settore. Il caso tipico che mi arriva è un’azienda dove il responsabile marketing non tocca il sito da due anni, perché l’ultima volta ha provato a cambiare un prezzo e ha rotto il layout della sezione. L’autonomia c’è sulla carta e non nella testa di chi dovrebbe esercitarla.

Quello che resta al cliente non è la libertà di modificare, è la responsabilità di mantenere. Che è esattamente il contrario.

Il costo di tenere accesa un’applicazione per servire contenuti fermi

La maggior parte dei siti aziendali è fatta di pagine che cambiano tre o quattro volte l’anno. Servirle con WordPress significa, a ogni singola visita, far partire il bootstrap del CMS, risolvere il filesystem a runtime, eseguire la catena di hook, interrogare il database e costruire la pagina in memoria. Tutto questo per restituire un testo che era identico ieri e sarà identico domani.

Ho misurato la differenza su progetti veri: spostando una pagina semplice dal runtime PHP a uno stack moderno, il tempo di risposta migliora facilmente di dieci volte. Ne ho scritto nel dettaglio in Da WordPress a uno stack moderno (senza buttare tutto).

Ogni plugin è una serratura in più da mantenere

Un WordPress professionale medio monta tra i quindici e i trenta plugin, scritti da autori diversi, con cicli di rilascio diversi, che eseguono codice a ogni visita. Nessuno di quegli autori risponde del tuo sito. La somma però sì.

Ad agosto uno dei siti che gestisco è stato attaccato proprio attraverso l’istanza WordPress che avevo lasciato accesa dietro il proxy. L’ho spenta e ricostruita come build statica: il racconto dell’intervento è qui. La lezione operativa è banale e la ripeto spesso: un’applicazione viva esposta al pubblico è una casa con dieci porte, e ogni porta ha una serratura che qualcuno deve mantenere per sempre.

Il pezzo nuovo: il database è un muro tra i tuoi contenuti e l’AI

Questa parte l’ho capita lavorando, non leggendola.

Da quando uso strumenti agentici per lavorare sui siti dei clienti, il criterio con cui giudico uno stack è cambiato. Gli agenti sono bravissimi a fare una cosa: leggere e scrivere file dentro una repository. È il loro terreno naturale, è il formato su cui sono stati addestrati, ed è lì che danno il meglio.

Ora prova a chiedere a un agente di lavorare su un sito WordPress.

I contenuti stanno in MySQL. Il layout sta nel tema PHP. La configurazione sta in una tabella di opzioni serializzate. E se c’è un page builder, la struttura della pagina è un blob JSON annidato dentro i post meta, illeggibile per un essere umano e poco più leggibile per una macchina. Esiste la REST API, certo, ma è un ponte: ti dà accesso ai dati, non ti restituisce il sito come oggetto unico e comprensibile.

Il risultato pratico è che una richiesta semplice diventa complicata. “Abbiamo cambiato il nome del servizio, aggiornalo ovunque compaia e sistema i titoli di conseguenza.” Su una repo l’agente cerca in tutto il progetto, tocca ventitré file, e io apro un diff che mi dice riga per riga cosa cambia prima che vada online. Su WordPress le opzioni sono due: farlo a mano pagina per pagina, oppure dare a uno script accesso al database e sperare bene. In nessuno dei due casi esiste un momento in cui vedo tutto insieme e decido.

E poi c’è la parte che conta di più quando le modifiche sono tante: l’annullamento. Con i contenuti in git, un intervento sbagliato su quaranta pagine si annulla con un comando. Con i contenuti in un database, si annulla ripristinando un backup, cioè buttando via anche tutto quello che nel frattempo era giusto.

Quando il contenuto e il codice vivono nello stesso posto, l’agente vede il sito intero: testi, struttura, componenti, link interni, redirect. Può ragionare su tutto insieme, e ogni sua proposta passa da una revisione tracciata. Non è una comodità da sviluppatori: è la differenza tra usare l’AI sul serio su un sito di produzione e non usarla.

Cosa uso al posto di WordPress

Quello che uso davvero sui progetti dei clienti è Brixter. L’ho scritto io, quindi il conflitto di interessi lo dichiaro subito e prendete quello che segue con la cautela che merita.

Nasce da un’insoddisfazione precisa: volevo l’editing visuale per il cliente, i contenuti dentro la repository e nessuna dipendenza da un servizio esterno per pubblicare. Una pagina è un file messo esattamente dove sta la rotta: un elenco dichiarativo di sezioni riutilizzabili con i loro contenuti e i metadati SEO già dentro. Non esiste un archivio separato da tenere sincronizzato né un’API da chiamare a runtime. Quello che committi è quello che pubblichi.

La parte agentica l’ho aggiunta perché ne avevo bisogno io: il pacchetto contiene le guide per gli agenti e un comando le traduce nel formato dello strumento che usi, che siano skill per Claude Code, regole per Cursor, istruzioni per Copilot o un AGENTS.md. L’agente non deve indovinare come è fatto il sito, glielo dice il progetto stesso.

È giovane e si muove in fretta, le API non sono ancora stabili. Se ti serve qualcosa di maturo, con una comunità dietro e anni di casi d’uso alle spalle, le due alternative sensate sono queste.

Astro è la più facile da difendere quando il sito è prevalentemente editoriale. I contenuti sono file markdown organizzati in content collections, la build è statica, il risultato è un insieme di file su disco leggibili da un umano e da una macchina senza intermediari.

TinaCMS risolve il problema del cliente non tecnico, che è il vero motivo per cui la maggior parte delle agenzie resta su WordPress. È un CMS git-backed con editing visuale: chi scrive apre la pagina, modifica il testo dove lo vede, e senza saperlo produce un commit.

Se stai valutando cosa fare del tuo

Se hai un sito WordPress e ti stai chiedendo se abbia senso continuare così, raccontamelo. Scrivimi il dominio e cosa ti dà fastidio oggi: ti dico quale parte del tuo sito ha davvero bisogno di essere un’applicazione viva, quale può diventare un file, e da dove partirei.