← Tutti gli articoli

WordPress headless: pro, contro e quando ha davvero senso

22 August 20232 min di lettura

Disaccoppiare il backend di WordPress dal frontend è di moda, ma non è la soluzione universale. Ecco quando vale la pena, quando no, e cosa abbiamo imparato sul campo.

"Facciamo WordPress headless." È una frase che sentiamo sempre più spesso da clienti che hanno letto un articolo, visto un talk a una conferenza o ricevuto una proposta da un'altra agenzia. Funziona davvero? La risposta onesta è: dipende. E nella maggior parte dei casi che incontriamo, non è la scelta migliore.

Cosa significa headless

WordPress nasce come monolite: il backend gestisce contenuti e il tema PHP genera l'HTML. Headless vuol dire spaccare in due: WordPress resta come CMS e si espone via REST API o GraphQL (con plugin come WPGraphQL), mentre il frontend è un'altra applicazione, tipicamente Next.js, Astro o Nuxt.

Quando ha senso

  • Contenuti consumati da più canali: web, mobile app, totem, schermi in negozio. Un'unica fonte di contenuti che alimenta touchpoint diversi.
  • Performance e Core Web Vitals critici: un frontend statico generato con Next.js o Astro è quasi sempre più veloce di un tema PHP con dieci plugin caricati.
  • Team frontend separato: se chi cura il design lavora in React e non vuole toccare PHP, headless elimina l'attrito.
  • Personalizzazioni interattive complesse: configuratori di prodotto, calcolatori, aree riservate con logica corposa.

Quando è uno spreco

  • Il sito è un sito istituzionale con dieci pagine, una sezione blog e qualche form. Headless aggiunge complessità senza ritorno.
  • Il cliente vuole pieno controllo del backend con plugin di SEO, form, e-commerce: spesso quei plugin assumono di stare in un tema PHP e non funzionano altrettanto bene esposti via API.
  • Budget di manutenzione ridotto: due sistemi vogliono dire due deploy, due monitoraggi, due punti di rottura.

I costi nascosti

Il primo costo è la preview. In WordPress classico vedi l'anteprima cliccando un pulsante. Headless richiede una pipeline ad hoc, con token, route protette e revalidazione. Il secondo costo è il versioning: il frontend e il backend si evolvono separatamente, e una breaking change al CMS può rompere le pagine senza che nessuno se ne accorga finché un editor non pubblica. Il terzo è la SEO: meta tag, sitemap, redirect — tutto gestito da plugin nel mondo classico — vanno reimplementati.

Il nostro consiglio

Per la maggior parte dei siti aziendali italiani, WordPress monolitico ben fatto resta la scelta più economica e robusta. Headless lo proponiamo quando ci sono almeno due dei seguenti tre fattori: traffico significativo (oltre 100k pageview/mese), contenuti distribuiti su più canali, o un team frontend interno. Negli altri casi, l'overhead non si ripaga.