Da WordPress a Nuxt, GitHub e Netlify: perché ci sto passando e come si migra un sito

Lo dico subito: amo WordPress. Ci lavoro da anni, ci ho costruito siti di cui vado fiero e per molti progetti resta la scelta più sensata. Ma negli ultimi anni il modo in cui viene usato è cambiato, e non in meglio. Temi che fanno tutto, plugin per ogni esigenza, siti in cui tutto dipende da tutto. Nel frattempo gli attacchi automatici sono diventati una costante. Per questo, sempre più spesso, propongo un'architettura diversa: Nuxt per il sito, GitHub per codice e contenuti, Netlify per la pubblicazione. Il sito che stai leggendo è fatto così.

Il problema strutturale, non estetico

WordPress è un'applicazione PHP che, a ogni richiesta non servita dalla cache, carica il core, il tema, tutti i plugin attivi, legge le opzioni in autoload dal database ed esegue la catena di hook prima di produrre una pagina. È un modello potente, e per un sito con poche dipendenze funziona bene.

Il guaio è l'accumulo. Un sito medio che vedo oggi ha un tema multiuso con page builder, venti o trenta plugin, add-on che dipendono da altri plugin e una cache messa sopra per nascondere i tempi di risposta. In questa situazione:

• ogni aggiornamento è una scommessa, perché le versioni di tema, builder, plugin e PHP devono essere compatibili tra loro;
• la superficie d'attacco cresce con ogni componente: la grande maggioranza delle vulnerabilità di WordPress sta nei plugin, non nel core;
• la velocità diventa un lavoro a sé, fatto di cache, ottimizzatori e plugin che sistemano i problemi di altri plugin.

È questo che intendo quando dico che tutto è troppo legato: non si può toccare un pezzo senza temere per gli altri.

Cosa cambia con Nuxt, GitHub e Netlify

L'idea è separare ciò che WordPress tiene insieme.

• Nuxt genera le pagine in fase di build (o le renderizza sul server solo dove serve). Non c'è un database interrogato a ogni visita né un pannello pubblico da proteggere. Il codice è solo quello del progetto: componenti Vue, TypeScript, Tailwind.
• GitHub contiene codice e, spesso, contenuti in Markdown. Ogni modifica è un commit, quindi ha un autore, una data e si può annullare.
• Netlify costruisce e pubblica il sito su una CDN. Ogni proposta di modifica genera un'anteprima online da controllare prima della messa in linea, e il rilascio è atomico: o è online tutta la nuova versione, o resta la vecchia.

Il risultato pratico: pagine statiche servite dalla CDN, pochissime dipendenze runtime, nessun wp-login.php da martellare e una cronologia completa di ogni cambiamento. Ne parlo anche in Pubblicare un sito con GitHub e Netlify.

Dove vanno i contenuti

È la decisione che determina come lavorerà chi aggiorna il sito.

• Markdown nel repository, con Nuxt Content: i testi sono file versionati insieme al codice, con frontmatter tipizzato e validato da uno schema. È la soluzione di questo sito, ideale quando chi scrive è a suo agio con un editor e con Git.
• CMS headless: i redattori lavorano in un pannello e il sito si ricostruisce a ogni pubblicazione. Può essere un CMS pensato per questo uso o anche lo stesso WordPress, usato solo come archivio contenuti via API.

Se a scrivere sono persone non tecniche e frequenti, il pannello serve. Fingere il contrario è il modo più rapido per far fallire una migrazione.

Quando WordPress resta la scelta giusta

Non migro tutto, e non consiglio di farlo.

• E-commerce articolati con WooCommerce, abbonamenti, listini per gruppi di clienti: ricostruirli ha un costo che raramente si ripaga.
• Redazioni numerose che pubblicano ogni giorno e usano a fondo ruoli, revisioni e flussi di approvazione.
• Siti che dipendono da plugin senza equivalente semplice, come prenotazioni o membership complesse.
• Budget minimi su siti che funzionano: se il sito è veloce, sicuro e aggiornato, non c'è motivo di toccarlo.

In questi casi la strada è un WordPress asciutto: tema su misura, pochi plugin scelti con cura, codice proprio dove conta. Ne parlo in Tema e plugin WordPress su misura o pronti. Su Altura Vela, per esempio, il sito della scuola è rimasto in WordPress, mentre il gestionale l'ho sviluppato da zero in Nuxt: due strumenti diversi per due esigenze diverse.

Come si fa la migrazione

1. Inventario: URL, tipi di contenuto, tassonomie, campi personalizzati, moduli, funzioni che dipendono da plugin.
2. Modello dei contenuti: si decide lo schema (collezioni, campi, relazioni) prima di scrivere una riga di codice.
3. Esportazione: i contenuti escono via REST API o WXR, vengono convertiti in Markdown o importati nel CMS, ripuliti da shortcode e markup del page builder.
4. Componenti: il design diventa componenti Nuxt, con attenzione a LCP, CLS e accessibilità fin dall'inizio.
5. Funzioni: moduli, ricerca, lingue, mappe, feed RSS, sitemap. Ciascuna diventa un piccolo pezzo di codice invece di un plugin.
6. SEO: titoli, description, canonical, hreflang, dati strutturati e una mappa di redirect 301 uno a uno.
7. Prove sull'anteprima: ogni template, ogni redirect, ogni modulo, da mobile e da desktop.
8. Lancio e monitoraggio: cambio DNS in un momento tranquillo, poi Search Console, log dei 404 e dati reali di velocità per alcune settimane.

La checklist SEO completa è in Rifare il sito senza perdere il posizionamento.

Come la vedo io

Non è una questione di moda. Con WordPress ho passato troppe ore ad aggiornare componenti che non avevo scritto, a ripulire siti compromessi da plugin abbandonati e a ottimizzare pagine appesantite da funzioni che nessuno usava. Con Nuxt passo quelle ore a costruire: il codice è quello che serve, ogni modifica ha un'anteprima e una cronologia, e la sicurezza non dipende da quanto in fretta aggiorno trenta plugin.

Continuo a fare WordPress quando è lo strumento giusto. Ma se mi chiedi un sito nuovo e non hai bisogno di un pannello complesso, oggi ti proporrò quasi sempre di partire da qui.

Perché affidarlo a me

Programmo dal 1999, ho consegnato più di 300 progetti e collaboro con circa 30 agenzie come sviluppatore esterno. Conosco WordPress dall'interno, e proprio per questo so dire quando conviene restare e quando conviene uscirne. Lavoro con Nuxt, Vue, TypeScript e Tailwind, e pubblico con GitHub e Netlify, da Roma e da remoto.

Se stai valutando una migrazione, scrivimi: in una chiacchierata di circa 20 minuti analizziamo il sito attuale e ti dico, senza giri di parole, se ha senso spostarsi. Il servizio è in Creazione siti web.