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 è Sandy, un editor che ho scritto io. Il conflitto di interessi lo dichiaro subito, quindi prendete quello che segue con la cautela che merita.

Nasce da un’insoddisfazione precisa: volevo un’interfaccia comoda per il cliente, i contenuti dentro la repository e nessun formato inventato. Sandy si collega alla repository del sito e lavora sui file che ci sono già, markdown con i metadati in testa, gli stessi che Astro, SvelteKit o Jekyll leggono senza bisogno d’altro. Il cliente vede i suoi articoli in griglia con copertina e data, scrive nel testo come in un normale editor e compila il resto in un pannello di campi. Ogni salvataggio è un commit a suo nome su una bozza tutta sua, che va online solo quando la pubblica. Se domani Sandy sparisse, il sito resterebbe esattamente com’è.

Per le pagine che non sono un articolo, come la home o una pagina di vendita, c’è un agente. Il cliente apre la pagina e scrive “accorcia il titolo”: l’agente trova i file che la disegnano, li modifica in una copia isolata del sito, controlla il risultato su telefono, tablet e desktop e salva tutto nella stessa bozza. Prima di pubblicare si vede l’anteprima di ogni pagina cambiata.

È molto giovane, ma è già stabile, perché costruisce sopra quello che esiste (file markdown, git, il sito stesso) invece di inventarsi un linguaggio nuovo. 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.