"Facciamolo Headless!" Lo sento sempre più spesso nei brief tecnici delle agenzie. Ma nella maggior parte dei casi, Headless WordPress introduce costi, complessità e fragilità senza un ritorno reale. Ecco perché.
1. Cos'è Headless WordPress (in breve)
In un'architettura Headless, WordPress viene usato solo come backend: gestisce i contenuti tramite la dashboard, ma non genera le pagine HTML. Il frontend è delegato a un framework JavaScript separato — di solito Next.js, Nuxt, Astro o Gatsby — che consuma i contenuti tramite REST API o WPGraphQL.
L'idea è affascinante: "usi WordPress per ciò che sa fare meglio (gestire contenuti) e un framework moderno per il rendering". In teoria suona perfetto. In pratica, stai costruendo due applicazioni invece di una.
2. Il doppio stack: doppia complessità
Un WordPress tradizionale è un singolo deploy: PHP, MySQL, un tema che genera HTML. Un Headless WordPress è almeno due progetti separati: il backend WordPress (hosting, database, plugin, API) e il frontend JavaScript (Node.js, framework, build pipeline, hosting separato).
Due stack significano:
- Due ambienti di hosting da configurare, monitorare e pagare.
- Due pipeline di deploy con i rispettivi CI/CD.
- Due set di competenze necessarie nel team (PHP + JavaScript avanzato).
- Due punti di failure. Se il backend va giù, il frontend non ha contenuti. Se il frontend si rompe, il sito è offline anche se WordPress funziona.
Per un sito aziendale o un magazine, questa complessità non è giustificata. Stai letteralmente raddoppiando la superficie di attacco e i costi operativi per ottenere... cosa esattamente?
3. Il mito della performance
"Headless è più veloce!" È l'argomento che sento più spesso, ed è il più fuorviante. Sì, un frontend in React/Next.js può essere velocissimo. Ma anche un WordPress tradizionale con buon caching è velocissimo.
Un WordPress monolitico con una strategia di cache ben configurata (page cache, object cache Redis, CDN) serve pagine statiche in 50-100ms di TTFB. Non c'è differenza percepibile dall'utente.
L'ironia è che molti setup Headless sono più lenti di un WordPress cachato. Perché? Perché il frontend deve fare chiamate API al backend per ogni richiesta (o al build time con SSG), introducendo latenza di rete. E se usi ISR (Incremental Static Regeneration) con Next.js, hai un layer di complessità che spesso degrada le performance nelle richieste non cachate (stale content).
I Core Web Vitals non migliorano per magia con Headless. Migliorano con una buona architettura frontend, ottimizzazione delle immagini e configurazione server — tutte cose che si fanno benissimo anche su un WordPress tradizionale.
4. Costi di manutenzione: il conto nascosto
Quando presenti il preventivo iniziale di un progetto Headless, il cliente vede un costo. Quello che non vede è il costo di manutenzione a lungo termine, che è dove il Headless fa davvero male.
- Aggiornamenti WordPress: Ogni major update di WordPress può rompere le API. I custom field cambiano struttura, le REST API evolvono, i plugin aggiornano i loro endpoint. Ogni update richiede test sul frontend.
- Aggiornamenti frontend: Next.js esce con una major quasi ogni anno. Ogni upgrade può richiedere refactoring. Le dipendenze npm scadono, le vulnerability si accumulano.
- Due hosting da mantenere: Il backend WordPress ha bisogno di PHP, MySQL, certificati SSL. Il frontend ha bisogno di Node.js, build server, edge functions. Doppio costo, doppio monitoraggio.
In un WordPress tradizionale, paghi un hosting, aggiorni i plugin, e il tema funziona. In un Headless, ogni aggiornamento è potenzialmente un progetto a sé.
5. Workflow editoriale: il vero disastro
Qui il Headless fallisce clamorosamente, e questo è il punto che le agenzie sottovalutano sempre. WordPress è amato dai clienti per una ragione: l'editor è intuitivo. Gutenberg, con i suoi blocchi, permette di costruire pagine visualmente. Il cliente vede cosa sta facendo.
In un setup Headless, il cliente apre WordPress e vede... campi custom. ACF, Meta Box o custom field senza contesto visuale. Scrive il testo, salva, e poi... non sa come appare. Non c'è anteprima reale. Non c'è il "vedi come viene" di Gutenberg.
Il workflow diventa:
- Il cliente inserisce contenuti nei campi custom.
- Salva come bozza.
- Deve andare su un URL separato per vedere l'anteprima (se funziona).
- Se qualcosa non va, torna alla dashboard e indovina quale campo modificare.
Questo è un passo indietro di 10 anni rispetto all'esperienza editoriale che WordPress offre nativamente. E il cliente lo nota, eccome.
6. Preview e bozze: il tallone d'Achille
L'anteprima dei contenuti è il problema tecnico più sottovalutato del Headless. In WordPress tradizionale, clicchi "Anteprima" e vedi la pagina esattamente come apparirà. Funziona e basta.
In Headless, l'anteprima richiede:
- Un endpoint API dedicato per i contenuti in bozza (non pubblicati).
- Un sistema di autenticazione tra WordPress e il frontend per le preview protette.
- Draft mode / Preview mode nel framework frontend (es. Next.js Draft Mode) da configurare e mantenere.
- Gestione dei token JWT o cookie per autenticare le richieste di preview.
Nella pratica, l'anteprima Headless è lenta, spesso rotta, e il primo punto dove i costi di manutenzione esplodono. Ho visto progetti dove l'anteprima semplicemente "non funziona più" dopo un aggiornamento di WordPress o del framework, e nessuno sa perché.
7. L'ecosistema plugin: addio
WordPress ha 60.000+ plugin. La maggior parte funziona perché assume di essere su un frontend WordPress. Form, SEO, analytics, cookie consent, popup, membership: tutto è costruito per integrarsi con il tema WordPress.
In Headless, perdi quasi tutto l'ecosistema:
- Contact Form 7 / Gravity Forms: Non funzionano. Devi ricostruire i form nel frontend e creare endpoint API custom.
- Yoast / Rank Math: I meta SEO li devi leggere via API e iniettarli manualmente nel frontend. Le funzionalità come il sitemap XML? Da rifare.
- WooCommerce: Funziona via API, ma perdi il checkout, il carrello, l'intera esperienza utente. Ricostruire un checkout in React è un progetto a sé.
- WPML / Polylang: La gestione multilingua va completamente reimplementata nel frontend.
In pratica, ogni plugin che usavi nel WordPress tradizionale diventa un componente frontend da sviluppare da zero. Il vantaggio di velocità di WordPress evapora.
8. "WordPress come backend" - un'illusione
L'argomento forte del Headless è: "Usi WordPress per quello che sa fare meglio: gestire contenuti". Ma è davvero così?
Se usi WordPress solo come backend API, stai usando forse il 20% delle sue funzionalità. Il tema? Inutile. I template? Non servono. I blocchi Gutenberg visivi? Non si vedono. Le shortcodes? Non funzionano. Il Customizer? Eliminato.
A quel punto, WordPress diventa un CMS headless mediocre rispetto a soluzioni native come Strapi, Sanity, Contentful o Directus, che sono nate per quello scopo e offrono:
- API più pulite e documentate.
- Modelli di contenuto flessibili senza plugin aggiuntivi.
- Webhook nativi per trigger di rebuild.
- Nessun bagaglio legacy di PHP e template engine.
Se vuoi davvero andare Headless, usare WordPress come backend è spesso la scelta peggiore. È come comprare una Ferrari e usarla solo per portare i sacchi della spesa: funziona, ma stai pagando per cose che non usi e rinunciando a cose che ti servono.
9. CV-driven development
Qui arriviamo al punto centrale, quello scomodo. Perché così tanti sviluppatori spingono per il Headless?
Nella maggior parte dei casi, non è perché il progetto lo richiede. È perché lo sviluppatore vuole lavorare con React/Next.js. È più interessante tecnicamente, sta meglio sul curriculum, e il mercato paga di più gli sviluppatori JavaScript "moderni".
Questo è CV-driven development: scegliere la tecnologia in base a ciò che fa bene alla carriera dello sviluppatore, non a ciò che serve al progetto del cliente.
Riconoscere il pattern è semplice:
- "È più moderno" — ma il cliente non paga per la modernità.
- "Le performance saranno migliori" — senza benchmark concreti a supporto.
- "Così siamo pronti per il futuro" — il futuro di quale esigenza, esattamente?
- "È lo standard dell'industria" — no, è lo standard di un segmento specifico (SaaS e grandi editori).
Un buon consulente propone la soluzione migliore per il problema del cliente, non quella che più gli conviene professionalmente. Se un sito aziendale o editoriale può essere costruito e gestito perfettamente con WordPress tradizionale, proporre Headless è un disservizio.
10. Quando Headless ha davvero senso
Non sono anti-Headless. Sono anti-Headless dove non serve. Ci sono scenari reali dove l'architettura Headless è la scelta giusta:
- Multi-channel publishing: Se lo stesso contenuto deve alimentare un sito web, un'app mobile nativa, un totem in-store e una newsletter, allora un backend API-first ha senso. Ma servono davvero tutti questi canali?
- Applicazioni web complesse: Se il frontend ha logica interattiva pesante (dashboard real-time, configuratori 3D, applicazioni SPA con stato complesso), un framework JS è giustificato — ma a quel punto forse non serve WordPress.
- Team enterprise con risorse dedicate: Se hai un team frontend dedicato, un team backend dedicato, DevOps interni e budget per la manutenzione continua, il Headless diventa gestibile. Ma stiamo parlando di organizzazioni con 10+ sviluppatori, non di agenzie con 3-5 persone.
- Contenuti che non cambiano spesso: Un sito documentale con migliaia di pagine statiche e aggiornamenti rari può beneficiare di un build SSG. Ma anche qui, un buon page cache su WordPress fa lo stesso lavoro.
La domanda chiave è: il vantaggio architetturale del Headless giustifica il costo aggiuntivo di sviluppo, manutenzione e la perdita di usabilità per il cliente? Nella mia esperienza, per l'80% dei progetti la risposta è no.
Verdetto: potenza vs. pragmatismo
Headless WordPress è una tecnologia potente. Ma "potente" non significa "necessaria". Per la stragrande maggioranza dei siti aziendali, magazine, e-commerce e portali editoriali, un WordPress tradizionale ben costruito offre:
- Performance eccellenti (con caching adeguato).
- Costi di sviluppo e manutenzione dimezzati.
- Workflow editoriale intuitivo per il cliente.
- Accesso completo all'ecosistema plugin.
- Un singolo stack da monitorare e mantenere.
Prima di proporre Headless a un'agenzia, chiedetevi: state risolvendo un problema del cliente o un problema del vostro curriculum? La risposta onesta fa la differenza tra un progetto sostenibile e un debito tecnico mascherato da innovazione.