WordPress muove ancora più del 40% del web, ma nel 2026 sembra la scelta meno "cool" quando si parla di stack moderni. Eppure continuo a usarlo — non come sito finito, ma come puro content layer dietro un frontend costruito da zero. La domanda giusta non è se WordPress sia superato, ma cosa succede quando lo stacchi dal suo frontend tradizionale e lo tratti solo come backend.
L'architettura reale
Nel mio caso il frontend è completamente separato: Astro v6 con Vue 3 per i componenti interattivi, Tailwind v4 e shadcn/ui per lo styling. WordPress resta chiuso nel suo angolo, esposto solo tramite REST API (o GraphQL, con il plugin giusto), e il frontend consuma quei dati come farebbe con qualsiasi altro CMS headless.
Il vantaggio immediato è che il client (o io stesso) continua a editare i contenuti nell'admin che conosce da anni, mentre il sito pubblico non porta nessuno dei pesi tradizionali di WordPress: niente PHP renderizzato lato server, niente plugin di frontend che si accumulano, niente temi da mantenere. Solo dati puliti che arrivano via API.
Dove mi ha creato grattacapi
Il primo attrito è la REST API di default: pensata per l'admin di WordPress, non per un frontend esterno. Servono quasi sempre custom endpoint o l'aggiunta di ACF/plugin dedicati per esporre i campi nel formato che serve davvero, e ogni campo extra è una decisione da prendere consapevolmente.
Il secondo è il caching. Un sito headless perde gratis tutta la cache HTML tradizionale di WordPress: la invalidazione va ripensata da capo, di solito con webhook che notificano il frontend quando un contenuto cambia, oppure con una build a richiesta se il sito è statico.
Il terzo, più subdolo, è che buona parte dell'ecosistema plugin di WordPress assume ancora un frontend PHP classico. Plugin SEO, form builder, certi blocchi Gutenberg: molti "funzionano" solo se qualcuno legge il loro output HTML, cosa che in un'architettura headless non succede mai. Vanno scelti con più attenzione, verificando che espongano davvero dati via API e non solo markup.
Infine, l'admin di WordPress resta un bersaglio esposto pubblicamente anche se il frontend è altrove: va comunque protetto (hardening, aggiornamenti costanti, accesso limitato) con la stessa cura di un WordPress tradizionale, solo che ora è più facile dimenticarselo perché "il sito vero" sembra vivere altrove.
Perché comunque vince, in certi casi
Nonostante l'attrito, resta la scelta giusta quando il cliente (o io) deve editare contenuti in autonomia senza formazione, e quando servono plugin maturi per SEO, e-commerce o form che nessun CMS headless più giovane replica ancora con la stessa profondità. L'ecosistema enorme di WordPress è un vantaggio reale che pesa più della sua età, soprattutto su progetti dove il content editing quotidiano conta più dell'eleganza dello stack.
La domanda da farsi prima
Prima di scegliere WordPress headless invece di un CMS nativo per JS, la domanda utile è: chi editerà i contenuti, e con che frequenza? Se la risposta è "un cliente non tecnico, spesso", WordPress headless resta difficile da battere. Se invece i contenuti li gestisci solo tu (o un piccolo team dev), un CMS pensato per framework moderni parte già un passo avanti — ed è il tema del prossimo pezzo della serie.
