WordPress headless: quando e perché separare frontend e backend

WordPress headless: usare WordPress come motore di contenuti senza il suo frontend

WordPress "tradizionale" gestisce sia i contenuti (backend) sia la loro presentazione (frontend tramite temi PHP). WordPress "headless" mantiene il backend (editor, custom post types, tassonomie, media library, utenti) ma elimina il frontend PHP. I contenuti vengono serviti tramite REST API o WPGraphQL, e il frontend è costruito con tecnologie moderne: React, Next.js, Vue, Nuxt, o qualsiasi framework JavaScript. Il risultato: la potenza editoriale di WordPress combinata con la velocità e la flessibilità di un frontend custom.

Quando ha senso il WordPress headless

Ha senso quando il frontend deve fare cose che i temi WP non possono

Applicazioni web interattive (dashboard, configuratori, calcolatori), siti con animazioni complesse, multi-piattaforma (stesso contenuto su web, app mobile, totem, digital signage), prestazioni estreme (siti statici generati con Next.js che caricano in meno di un secondo). Se il sito è un blog, un portfolio, un ecommerce standard, o un sito aziendale classico: WordPress tradizionale è più efficiente. Il headless aggiunge complessità di sviluppo e costi di manutenzione che si giustificano solo quando il frontend tradizionale non basta.

Non ha senso per la maggior parte dei siti

Il 90% dei siti WordPress non ha bisogno di headless. Un tema ben costruito con LANGA Tools carica in meno di 2 secondi, è SEO-friendly, e costa una frazione dello sviluppo headless. Il headless richiede: sviluppatore frontend specializzato, hosting separato per il frontend, gestione di due deployment, complessità SEO (SSR o SSG necessari per l'indicizzazione). Se il motivo per cui consideri headless è "il sito è lento", la soluzione è ottimizzare il tema e il server, non ricostruire l'architettura.

Come funziona tecnicamente

WordPress espone tutti i contenuti tramite REST API: /wp-json/wp/v2/posts, /wp-json/wp/v2/pages, /wp-json/wp/v2/media. I custom post types registrati con show_in_rest=true appaiono automaticamente. ACF (o campi personalizzati) vengono esposti tramite il plugin ACF to REST API o registrando meta fields con show_in_rest. Il frontend fa fetch dei dati e li renderizza. Next.js con getStaticProps è la combinazione più comune: genera pagine statiche a build time, le rigenera con ISR (Incremental Static Regeneration), e ottiene performance quasi perfette.

Domande frequenti

WordPress headless è più sicuro?

Il frontend headless non esegue PHP pubblicamente, quindi la superficie di attacco si riduce. Ma il backend WordPress resta esposto (almeno l'area admin e le API). La sicurezza va comunque gestita: autenticazione API, rate limiting, CORS configurato correttamente, e aggiornamenti regolari. Il headless non è una soluzione di sicurezza: è una scelta architetturale.

Posso usare WooCommerce in modalità headless?

Sì, WooCommerce ha una REST API completa per prodotti, ordini, carrello, e checkout. Ma il checkout headless è complesso: gestione pagamenti, calcolo tasse, coupon, spedizioni. Librerie come CoCart semplificano il carrello headless. Per un ecommerce standard, WooCommerce tradizionale è più pratico. Il headless WooCommerce ha senso per: marketplace custom, app mobile con catalogo WooCommerce, o integrazioni multi-canale.

Per continuare a leggere,
accedi al tuo account.

Il tuo account LANGA ti connette a tutta la Galaxy.