Da WordPress a headless: guida alla migrazione con Next.js

Portare WordPress su architettura headless significa mantenere WordPress come luogo in cui la redazione scrive e gestisce i contenuti, sostituendo il tema con un frontend separato, nella maggior parte dei casi realizzato in Next.js, che recupera i contenuti tramite un'API. Chi pubblica continua a lavorare in un pannello che conosce. Chi sviluppa ottiene uno stack moderno. In cambio ti ritrovi con due sistemi invece di uno, e alcune cose che WordPress faceva gratis ora vanno costruite.

Questa guida spiega che cosa cambia, quando il passaggio vale la pena, come si svolge una migrazione fatta bene e che cosa mettere a budget per il dopo. È scritta per fondatori e proprietari di siti che oggi usano WordPress e stanno valutando il cambio, non per sviluppatori in cerca di uno snippet di codice.

In breve

• WordPress headless mantiene l'editor e il database, ma le pagine pubbliche vengono generate da un'applicazione Next.js separata. WordPress non produce più l'HTML del tuo sito.
• Conviene per frontend molto personalizzati, contenuti riutilizzati tra web e app, o team che devono rilasciare modifiche al design in autonomia. Per un sito vetrina o un blog standard, di solito costa più di quanto renda.
• I due sistemi si collegano tramite REST API o WPGraphQL; poi tocca a te ricostruire routing, anteprime, moduli, metadati SEO e redirect.
• Migra in parallelo: costruisci il nuovo frontend mentre il vecchio sito è online, validalo e solo allora fai il passaggio. Mai cambiare alla cieca.
• Metti in conto due ambienti di hosting, due basi di codice e manutenzione continua su entrambi.

Che cosa cambia davvero con «headless»

In un sito WordPress tradizionale un solo sistema fa tutto. Arriva una richiesta, WordPress carica impostazioni, plugin e tema attivo, interroga il database, percorre la gerarchia dei template PHP e restituisce al browser l'HTML finito. WordPress.com’s explainer descrive esattamente questo flusso per l'architettura accoppiata.

In un'architettura headless WordPress smette di generare le pagine pubbliche. Come scrive WP Engine’s support documentation, resta soprattutto il backend dei contenuti ed espone i dati tramite un'API a un frontend costruito a parte. La «testa», cioè quello che vedono i visitatori, è ora un'applicazione a sé, con codice, hosting e processo di rilascio propri.

Ne derivano tre conseguenze pratiche:

1. Il tema sparisce. Template, page builder e widget legati al tema non si portano dietro. Il design va ricostruito nel nuovo frontend.
2. I plugin si dividono in due gruppi. Quelli che gestiscono contenuti (campi personalizzati, dati SEO, traduzioni) continuano a funzionare nel pannello. Quelli che producono qualcosa sulla pagina pubblica (moduli, slider, sezioni commenti, molte funzioni SEO) vanno sostituiti nel frontend. WordPress.com osserva che molti temi, pattern, commenti, moduli e plugin familiari WordPress.com’s explainer senza un lavoro aggiuntivo di realizzazione.
3. Chi scrive non se ne accorge quasi, se non per il fatto che anteprime e alcune funzioni di modifica visuale si comportano diversamente finché non le ricostruisci.

Headless ti serve davvero?

È la domanda da chiarire prima di scrivere una riga di codice. Headless è un compromesso, e la risposta onesta spesso è «non ancora».

Quando ha senso

Pantheon’s overview elenca i casi in cui headless ripaga: frontend fortemente personalizzati, contenuti distribuiti su più canali e cicli di rilascio del frontend che devono essere indipendenti dal CMS. In pratica significa:

• Un sito che somiglia a un prodotto, con funzioni interattive, dashboard o ricerca complessa, dove i template PHP sono diventati un vincolo.
• Una sola fonte di contenuti, più canali in uscita. Automattic notes che una singola istanza WordPress può alimentare sia siti web sia app mobili.
• Pagine in cui le prestazioni sono critiche. Framework come Next.js supportano generazione statica e rendering lato server, che Pantheon cites come strade verso prestazioni migliori. Attenzione però: un sito WordPress lento non si risolve automaticamente con headless. Spesso un tema ripulito, un hosting migliore e una buona cache ti portano quasi al traguardo.
• Un'esposizione alla sicurezza che vuoi ridurre. Togliere lo strato di rendering del tema può ridurre la superficie d'attacco dell'istanza WordPress, secondo WP Engine’s support documentation. Il pannello di amministrazione va comunque protetto, e puoi tenerlo fuori dalla rete pubblica o dietro controlli d'accesso.
• Sviluppatori frontend che vogliono strumenti moderni. Per React e Next.js è molto più facile trovare persone e scrivere test che per un tema PHP pesantemente personalizzato.

L'approccio viene usato anche in contesti istituzionali seri. Una WordCamp Europe 2025 session descrive un portale svizzero di orientamento professionale del settore pubblico costruito su WordPress headless e REST API.

Quando conviene aspettare

Headless costa di più all'inizio e durante l'esercizio. Automattic dice chiaramente che Automattic notes perché l'architettura richiede più lavoro iniziale e continuativo, spesso da parte di specialisti sia di backend sia di frontend. Un relatore della comunità WordPress citato da HubSpot avvertiva che può essere un big investment e che potrebbe non adattarsi a un sito nuovo senza una grande campagna alle spalle.

Resta su WordPress tradizionale se:

• Il tuo sito è fatto soprattutto di pagine e di un blog, e un buon tema fa già il lavoro.
• Il marketing modifica i layout direttamente con un page builder e dipende da questa libertà.
• Non hai budget per sviluppo oltre alla realizzazione iniziale.
• Il tuo problema principale è un sito lento e appesantito, non un limite architetturale.

Un test semplice: scrivi le tre cose che oggi su WordPress non riesci a fare e che ti servono nei prossimi dodici mesi. Se un plugin o una modifica al tema le risolve, non ti serve headless. Se la risposta è «un'architettura frontend diversa», probabilmente sì.

Scegliere l'API: REST o WPGraphQL

La tua applicazione Next.js ha bisogno di un modo per leggere i contenuti. WordPress offre due strade principali e la Vercel’s guide conferma che entrambe funzionano con Next.js: la REST API oppure WPGraphQL.

	REST API	WPGraphQL
Disponibilità	Integrata in WordPress	Plugin gratuito da installare
Forma dei dati	Endpoint fissi per tipo di contenuto	Richiedi esattamente i campi che ti servono
Recupero di dati collegati	Spesso più richieste	Spesso una sola richiesta
Curva di apprendimento	Bassa, familiare a quasi tutti gli sviluppatori	Più ripida, richiede conoscenza di GraphQL
Adatta a	Siti semplici, pochi tipi di contenuto	Modelli di contenuto complessi, molte relazioni

La REST API espone articoli, pagine e tipi di contenuto personalizzati senza installare nulla. WPGraphQL è un plugin gratuito e open source che aggiunge a un sito WordPress uno schema e un'API GraphQL estendibili. Per un sito con pochi tipi di contenuto, REST basta e ha un pezzo in meno da gestire. Per un sito con campi personalizzati, tassonomie e relazioni annidate, GraphQL risparmia molte chiamate e tiene ordinato il codice del frontend.

Qualunque sia la scelta, decidi presto e mantienila. Mescolare entrambe in un unico frontend raddoppia la superficie da mantenere.

Come si svolge una migrazione da WordPress a Next.js

La sequenza qui sotto è il modo in cui la imposteremmo per un sito aziendale. I nomi degli strumenti cambiano, l'ordine quasi mai.

Passo 1: analizza che cosa fa davvero il sito attuale

Elenca ogni schema di URL, tipo di contenuto, modulo, plugin, redirect, integrazione e script di tracciamento. Molti siti dipendono in silenzio da un plugin per qualcosa che nessuno ricorda più: un'iscrizione alla newsletter, una mappa di redirect, un selettore di lingua, un blocco di dati strutturati. Tutto ciò che non finisce in questa lista si romperà il giorno del lancio.

Misura anche la base di partenza: traffico organico per pagina di destinazione, Core Web Vitals, tassi di conversione. Ti servirà un prima e un dopo.

Passo 2: pulisci e modella i contenuti

Headless mette a nudo i contenuti disordinati. Shortcode dentro il corpo degli articoli, markup dei page builder e stili scritti a mano non vengono resi in un nuovo frontend. Decidi come verrà archiviato ogni tipo di contenuto: campi personalizzati strutturati per i blocchi ricorrenti, contenuto pulito dell'editor a blocchi per gli articoli. È il passaggio che i team sottovalutano, e spesso richiede più tempo del frontend.

Passo 3: prepara WordPress come backend

Una realizzazione tipica comincia con la preparing WordPress API access: attivare l'API scelta, impostare l'autenticazione dove serve ed esporre i campi personalizzati. Metti il pannello di amministrazione su un sottodominio separato, limita chi può raggiungerlo e fai puntare il dominio pubblico solo al frontend.

Passo 4: costruisci il frontend Next.js

La stessa guida di Kinsta descrive lo schema di base: creare pagine e rotte dinamiche che recuperano gli articoli, poi mostrare il contenuto recuperato. Oltre a questo, dovrai ricostruire:

• Il routing. I tuoi URL attuali devono sopravvivere. Rotte dinamiche e catch-all possono associare i percorsi in entrata agli slug di WordPress, così /blog/my-post/ continua a funzionare.
• Le immagini. Decidi da dove vengono servite, come vengono ridimensionate e in quali formati. Next.js include un'ottimizzazione delle immagini che puoi sfruttare.
• I metadati SEO. Titoli, descrizioni, tag canonical, dati Open Graph, sitemap XML e dati strutturati devono essere generati dal frontend a partire dai dati forniti da WordPress. Automattic segnala che la Automattic notes come in un'installazione tradizionale.
• I moduli. I moduli di contatto e iscrizione hanno bisogno di una nuova gestione, con protezione antispam e recapito dove devono arrivare i contatti.
• Ricerca, paginazione, archivi e feed. Ognuno è una piccola funzione di cui ora rispondi tu.

Passo 5: ricostruisci le anteprime

Chi scrive si aspetta di cliccare «Anteprima» e vedere la propria bozza. Headless rompe questa abitudine per impostazione predefinita, e Pantheon elenca la perdita di funzioni integrate come le anteprime dal vivo tra gli Pantheon’s overview. Costruisci in Next.js una rotta di anteprima che accetta un token sicuro e recupera la bozza. Provala con chi scrive davvero, non solo con gli sviluppatori. Se le anteprime sono lente o inaffidabili, la redazione perde fiducia nell'intero sistema.

Passo 6: decidi come gli aggiornamenti arrivano al sito online

Se il frontend genera le pagine in anticipo, deve sapere quando i contenuti cambiano. La risposta abituale è un webhook: quando qualcuno pubblica, WordPress avvisa il frontend, che ricostruisce o rivalida solo le pagine interessate. Next.js supporta la rivalidazione su richiesta proprio per questo. Le alternative sono il rendering a ogni richiesta (sempre aggiornato, più carico sul server) o la rivalidazione a tempo (semplice, ma le modifiche compaiono in ritardo). Scegli per tipo di pagina: una pagina prezzi che deve aggiornarsi subito è diversa da un archivio che può restare indietro di qualche minuto.

Passo 7: tieni i due siti in parallelo, poi fai il passaggio

La migrazione più sicura affianca il nuovo frontend mentre il sito WordPress esistente resta in funzione, poi switches DNS or a reverse proxy una volta validato il nuovo frontend. Prima del passaggio:

1. Scansiona entrambe le versioni e confronta URL, titoli, intestazioni, tag canonical e dati strutturati.
2. Controlla ogni redirect, inclusi i vecchi URL delle campagne e il comportamento con la barra finale.
3. Prova i moduli dall'inizio alla fine e verifica che analytics e strumenti di consenso si attivino correttamente.
4. Esegui test di prestazione su template reali, da mobile.
5. Tieni il vecchio sito raggiungibile per una breve finestra di ritorno indietro.

Dove possibile, migra sezione per sezione invece che tutto in una volta. Spostare prima il blog, per esempio, ti dà una prova dal vivo del flusso con un rischio limitato per l'attività.

Che cosa mettere in conto dopo il lancio

La realizzazione è la parte più piccola della storia. Un sito headless è composto da due prodotti.

Come osserva Kamaan notes, un'architettura tipica comporta due ambienti di hosting: uno per il backend WordPress e uno per il frontend disaccoppiato. WordPress.com’s explainer che questo significa più manutenzione, perché frontend e backend sono basi di codice e tecnologie separate. In pratica, metti a budget:

• Aggiornamenti di WordPress per core, plugin e PHP, necessari anche se i visitatori non vedono mai il tema.
• Aggiornamenti delle dipendenze del frontend per Next.js, React e ogni pacchetto, comprese le patch di sicurezza.
• Monitoraggio di entrambi i lati, oltre al collegamento fra i due. Se l'API non risponde, il sito può servire pagine vecchie o smettere del tutto di funzionare.
• Supporto alla redazione, perché pubblicare ora coinvolge un flusso tecnico che può fallire.
• Sviluppatori che conoscono entrambi i mondi, oppure due interlocutori che comunicano bene. Dividere la responsabilità fra un'agenzia WordPress e un freelance frontend separato è il punto in cui molti progetti si arenano.

Chi mantiene che cosa va messo per iscritto prima del lancio, non scoperto al primo disservizio.

Errori frequenti

Migrare solo per la velocità. Un sito Next.js statico può essere velocissimo, ma lo può essere anche un sito WordPress fatto bene. Fai il confronto con misurazioni reali.

Dimenticare redirect e metadati. I cali di traffico dopo un cambio di piattaforma si spiegano quasi sempre con URL modificati, canonical mancanti o dati strutturati persi.

Lasciare i contenuti sporchi. Spostare articoli pieni di shortcode in un frontend pulito produce pagine rotte. Prima pulisci.

Sottovalutare chi scrive. Le persone che usano il sistema ogni giorno dovrebbero provarlo prima del lancio, e il loro giudizio sulle anteprime è il più prezioso che riceverai.

Affidarsi a un team che poi sparisce. I progetti headless hanno molte parti in movimento. Se chi ha definito il lavoro non è chi lo realizza, i requisiti vengono riscritti a metà strada.

Come lo affrontiamo in Ampersand

Siamo un piccolo studio di Zurigo e ogni progetto è seguito dall'inizio alla fine da ingegneri senior, dalla prima consulenza alla consegna. Per un passaggio da WordPress a headless significa che la persona che analizza il tuo sito e ti dice se headless è la scelta giusta è la stessa che lo realizza e te lo consegna. Se le tue esigenze sono servite meglio tenendo WordPress com'è, te lo diciamo.

Realizziamo siti web, applicazioni web e piattaforme, ci occupiamo di integrazioni fra sistemi e cambi di piattaforma, e offriamo audit e consulenza tecnica senior se vuoi un secondo parere prima di impegnarti in una ricostruzione. Il nostro obiettivo è che tu possa gestire il risultato in autonomia, senza dipendere da noi. La nostra pagina dei prezzi, pubblica elenca i servizi, e i progetti che abbiamo realizzato mostrano il tipo di lavoro che c'è dietro. Dopo il lancio, il nostro piano Run & monitor per il supporto tecnico continuativo costa CHF 750 al mese, mentre il piano Guidance per il supporto consulenziale costa CHF 799 al mese. I progetti di cambio piattaforma e di realizzazione vengono valutati caso per caso, quindi non hanno un prezzo pubblicato.

Un percorso decisionale realistico

Se sei ancora indeciso, segui questa sequenza:

1. Definisci il problema. Indica il limite preciso che hai incontrato, con numeri dove puoi.
2. Prova la soluzione più economica. Ottimizza tema, hosting, cache e immagini, poi misura di nuovo.
3. Fai un prototipo di una sezione. Costruisci un solo tipo di pagina in Next.js usando i tuoi dati WordPress reali. Due settimane di prototipo ti dicono più di qualsiasi articolo.
4. Calcola i costi di entrambi i sistemi. Includi la manutenzione del secondo anno, non solo la realizzazione.
5. Decidi insieme a chi pubblica. Se il nuovo flusso di lavoro rende il loro lavoro più difficile, l'architettura non fa per te, per quanto elegante sia.

Domande frequenti

Posso mantenere i contenuti WordPress esistenti passando a headless?

Sì. I contenuti restano in WordPress e vengono esposti tramite REST API o WPGraphQL. Di solito è il loro formato a richiedere lavoro: shortcode, markup dei page builder e stili legati al tema non vengono resi in un nuovo frontend, quindi prevedi una pulizia prima o durante la migrazione.

WordPress headless è meglio per la SEO?

Non automaticamente. Next.js può servire pagine veloci e completamente renderizzate, il che aiuta, ma titoli, tag canonical, sitemap, dati strutturati e redirect vanno tutti ricostruiti nel frontend. Una migrazione curata può mantenere o migliorare i posizionamenti; una fatta male li perde.

Serve WPGraphQL per collegare WordPress a Next.js?

No. La REST API integrata basta per molti siti. WPGraphQL diventa interessante quando hai molti campi personalizzati e relazioni e vuoi recuperarli con una sola richiesta, ma aggiunge un plugin e un linguaggio di interrogazione da mantenere.

Headless costa più di un normale sito WordPress?

Di solito sì. Mantieni due basi di codice e due ambienti di hosting, e ti servono sviluppatori a proprio agio con entrambi. Il costo in più si giustifica quando la flessibilità del frontend, la distribuzione su più canali o i guadagni di prestazione sono centrali per la tua attività, non quando basterebbe un tema standard.

Posso passare a headless per gradi?

Sì, ed è spesso la strada più sicura. Puoi costruire il frontend Next.js accanto al sito WordPress online, spostare una sezione alla volta e dirottare il traffico solo dopo aver validato il nuovo frontend.

Fonti

• WordPress.com’s explainer
• WP Engine’s support documentation
• Pantheon’s overview
• Pantheon cites
• Automattic notes
• big investment
• WordCamp Europe 2025 session
• Vercel’s guide
• WPGraphQL
• preparing WordPress API access
• switches DNS or a reverse proxy
• Kamaan notes