Headless WordPress separa il backend (dove gestisci contenuti) dal frontend (dove li mostri). Promette performance migliori, design più libero e architettura moderna. Ma non è la soluzione giusta per tutti. Vediamo i tre approcci principali e quando ciascuno ha senso.
Approccio 1: WordPress REST API + React/Next.js
Il più comune. WordPress serve i dati via REST API, un'applicazione React (solitamente con Next.js per il server-side rendering) li consuma e genera le pagine. Il risultato è un sito velocissimo con transizioni fluide e design completamente personalizzabile.
Quando funziona: team con competenze React, progetto con interfaccia complessa (dashboard, configuratori, applicazioni web), necessità di performance estrema (TTFB sotto 50ms con Vercel/Netlify).
Quando non funziona: team solo PHP, budget limitato (costa 2-3 volte un sito WordPress tradizionale), sito semplice che non giustifica la complessità, cliente che vuole editare il sito autonomamente (l'anteprima in tempo reale è complessa da implementare).
Approccio 2: WordPress + WPGraphQL + Gatsby/Astro
Variante del primo approccio che usa GraphQL invece di REST. WPGraphQL espone i dati WordPress come schema GraphQL, framework come Gatsby o Astro li consumano e generano pagine statiche al build time. Il sito risultante è un insieme di file HTML statici — velocissimo e sicuro perché non c'è nessun server da attaccare.
Quando funziona: siti con contenuto che cambia raramente (corporate, portfolio, blog), quando la sicurezza è priorità assoluta, per progetti con budget per la fase iniziale ma che vogliono costi hosting vicini allo zero (deploy su CDN gratuita).
Quando non funziona: e-commerce (troppe pagine dinamiche), siti con contenuto in tempo reale, necessità di aggiornamento frequente (ogni modifica richiede un rebuild che può durare minuti).
Approccio 3: WordPress tradizionale con Interactivity API
Il compromesso pragmatico. Mantieni WordPress tradizionale (tema, template, rendering server-side) ma usi l'Interactivity API di WordPress 6.5+ per aggiungere interattività dove serve: filtri dinamici, ricerca live, componenti reattivi. Non è tecnicamente headless, ma offre molti dei vantaggi senza la complessità.
Quando funziona: il 90% dei progetti. Team PHP, budget normale, cliente che vuole autonomia, sito che deve essere mantenuto per anni senza dipendere da framework JavaScript che cambiano ogni 18 mesi.
Quando non funziona: quando il progetto è genuinamente un'applicazione web che si appoggia a WordPress solo per i contenuti, quando il team vuole usare un framework JS specifico per motivi tecnici validi.
La domanda giusta: ti serve davvero headless?
Nel 90% dei casi la risposta è no. Headless WordPress è la soluzione giusta per problemi specifici: performance estrema, design non ottenibile con temi WordPress, integrazione con applicazioni web complesse. Per un sito aziendale, un e-commerce, un blog — WordPress tradizionale con un buon tema block e uno stack server ottimizzato (Nginx, Redis, PHP 8.3) offre performance eccellenti con un decimo della complessità e del costo.
LANGA Tools supporta entrambi gli approcci: funziona come plugin tradizionale e espone i suoi dati via REST API per chi sceglie headless. Ma la raccomandazione per la maggior parte dei progetti italiani è: investi nel tradizionale, fatto bene.
Headless costa di più da sviluppare?
Sì, significativamente. Un sito headless con Next.js costa 2-3 volte un equivalente tradizionale. Il motivo: servono competenze React + WordPress (invece di solo WordPress), l'integrazione richiede più tempo, l'anteprima live è complessa, il deploy necessita di infrastruttura aggiuntiva (Vercel, AWS, piattaforma hosting Node.js).
L'SEO funziona bene con headless WordPress?
Sì, ma solo con server-side rendering (Next.js con SSR) o static site generation (Gatsby, Astro). Un'applicazione React client-side pura è invisibile a Google. Il SSR aggiunge complessità e costo server. Con SSG il problema non esiste (i file sono HTML statico) ma perdi contenuto dinamico.
Posso migrare gradualmente da tradizionale a headless?
Sì, con l'approccio ibrido: mantieni WordPress tradizionale per la maggior parte del sito e usa headless solo per le sezioni che ne beneficiano (un configuratore prodotto, una dashboard, una sezione interattiva). WordPress REST API e WPGraphQL funzionano anche su installazioni tradizionali — non devi scegliere tutto o niente.
Per continuare a leggere,
accedi al tuo account.
Il tuo account LANGA ti connette a tutta la Galaxy.
Articoli completi su tutti i blog Galaxy.
Un solo login, accesso ovunque.
Guadagna Leghe e sblocca contenuti premium.