Dietro le quinte

Da WordPress a Nuxt

Il sito che stai leggendo girava su WordPress. Oggi gira su Nuxt, e non è stata una scelta di moda: dopo anni passati ad aggiornare plugin, rincorrere punteggi PageSpeed e spiegare perché una modifica banale richiedeva mezz'ora, abbiamo ricostruito tutto. Cosa è cambiato davvero, senza esagerazioni e con i limiti dichiarati.

Blog ContatPubblicato il 9 min di lettura
0
plugin di terzi da aggiornare
0
database da mantenere
1
file JSON per pagina
~60s
dalla modifica alla pubblicazione

Sei cose che sono migliorate

Non è solo "il sito è più veloce". Cambiando fondamenta cambiano anche i costi di gestione, il rischio di sicurezza e il modo in cui il sito viene letto dalle macchine.

La cache non è un plugin

Anche WordPress genera HTML lato server, ma lo ricostruisce dal database a ogni richiesta salvo aggiungere un layer di cache. Qui la pagina è resa una volta, servita dalla cache e rigenerata in background: è il comportamento predefinito, non un componente da configurare.

Niente stack di plugin

Cache, SEO, form, sitemap, immagini: erano plugin di autori diversi, con calendari e qualità diversi. Ora sono funzioni del sito, scritte una volta e testate insieme al resto.

Superficie d'attacco ridotta

Nessun pannello /wp-admin esposto, nessun tema con codice di terzi, nessun aggiornamento urgente di venerdì sera.

SEO verificata dal codice

Title, description e canonical sono validati al salvataggio: una pagina con meta sbagliati non si pubblica proprio.

Immagini servite su misura

AVIF, WebP o PNG scelti in base al browser, larghezza adatta allo schermo e dimensioni dichiarate in HTML: il layout non salta durante il caricamento.

Leggibile dalle AI

I contenuti sono dati strutturati, non HTML da spulciare: motori di ricerca, modelli linguistici e agenti li leggono senza interpretazioni.

WordPress vs Nuxt

Due strumenti diversi, non un vincitore assoluto. WordPress resta la scelta giusta per molti progetti: quello che segue è il confronto sul nostro caso d'uso.

Una pagina ricostruita a ogni visita
Una pagina ricostruita a ogni visita

Perché abbiamo lasciato WordPress

Il nostro vecchio sito non era messo male: hosting decente, plugin di cache, tema ottimizzato. Il problema era strutturale, e si vedeva in tre punti.

Ogni visita ricostruiva la pagina. WordPress è PHP: a ogni richiesta interroga il database, monta il tema, esegue gli hook dei plugin e solo alla fine consegna l'HTML. La cache nasconde il problema finché regge; appena la si svuota — un aggiornamento, una modifica, un picco di traffico — il tempo di prima risposta torna a farsi sentire.

Ogni funzione era un plugin di qualcun altro. Cache, SEO, form di contatto, sitemap, ottimizzazione immagini, sicurezza: sei autori diversi, sei calendari di aggiornamento diversi, sei fogli di stile e script caricati su ogni pagina anche dove non servivano. E i plugin obsoleti restano la prima causa di siti WordPress compromessi — lo raccontiamo anche nella pagina di assistenza sito web, perché è il lavoro che facciamo tutti i giorni sui siti dei clienti.

Ogni modifica costava troppo. Aggiungere una sezione voleva dire aprire un page builder, combattere con i margini e sperare che l'aggiornamento successivo non spostasse tutto. Non è un difetto morale di WordPress: è il prezzo di un sistema che deve andare bene per chiunque.

Come è andata la migrazione

Cinque fasi, nessun big bang: il vecchio sito è rimasto online fino all'ultimo giorno.

1

Inventario dei contenuti e degli URL

Abbiamo estratto pagine, articoli, media e — soprattutto — la lista completa degli URL indicizzati. È il passaggio che salva il posizionamento: nessuna migrazione può permettersi di perdere indirizzi che Google conosce già.

2

Un modello di contenuto, non un tema

Invece di replicare il tema, abbiamo definito i blocchi di cui il sito ha davvero bisogno: hero, confronto, passi, FAQ, testo con immagine. Ogni pagina è diventata un file JSON che descrive quali blocchi mostrare e con quali contenuti.

3

Ricostruzione dei blocchi in Nuxt

Ogni blocco è un componente Vue riusabile, con il proprio comportamento responsive e accessibile. Un blocco corretto una volta si corregge su tutte le pagine che lo usano — il contrario di quello che succede in un page builder.

4

Redirect 301 e controlli SEO

Ogni vecchio URL è stato mappato al nuovo. Un controllo automatico verifica meta tag, canonical, link interni rotti e immagini mancanti: se qualcosa non torna, la build non passa.

5

Pubblicazione e osservazione

Cambio DNS, sitemap inviata, e poi settimane di osservazione su Search Console e log del server: redirect che rispondono, pagine scansionate, errori 404 residui. È la fase in cui si vede se la mappa degli URL era completa.

Dal testo dentro il tema al contenuto strutturato
Dal testo dentro il tema al contenuto strutturato

Il pezzo che non ci aspettavamo: il contenuto come dato

La decisione più utile della migrazione non riguarda le prestazioni, ma il formato del contenuto. In WordPress il testo di una pagina vive dentro l'HTML generato dal page builder: leggibile da un browser, scomodo per chiunque altro. Da noi ogni pagina è un file JSON con la sua struttura esplicita — meta, blocchi, proprietà.

Da quella scelta discendono cose che prima erano progetti a sé: la sitemap si costruisce da sola, i dati strutturati per Google rispecchiano sempre ciò che è visibile, l'anteprima social si genera automaticamente, e una nuova pagina è semplicemente un file in più — senza rimettere online il sito. È lo stesso principio che spieghiamo quando parliamo di API: se i dati hanno una forma dichiarata, chiunque può usarli senza indovinare.

Il contenuto è diventato riusabile anche fuori dal sito: la stessa fonte alimenta un'app mobile o un'integrazione senza duplicare nulla — il percorso che descriviamo in creare un'app dal sito web.

Pagina già pronta contro pagina costruita al momento
Pagina già pronta contro pagina costruita al momento

La velocità, spiegata bene

"Il sito è più veloce" non vuol dire niente se non si dice dove, e va detto subito: un WordPress con una buona cache e un hosting serio è veloce anche lui. La differenza sta in cosa devi fare per ottenerlo e in cosa succede quando la cache non c'è. Quattro punti misurabili:

  • Prima risposta (TTFB): l'HTML è già reso e tenuto in cache dal server, che lo consegna subito e lo rigenera in background. Nessuna richiesta paga il conto della ricostruzione.
  • Peso del JavaScript: senza plugin di terzi spariscono gli script caricati su ogni pagina anche dove non servono. JavaScript ce n'è comunque — è pur sempre un framework — ma è quello che abbiamo scritto noi, suddiviso per pagina.
  • Immagini: ogni immagine viene ridimensionata e convertita in AVIF o WebP in base al browser, con larghezza e altezza dichiarate in HTML. Il layout non salta mentre carica — è metà del punteggio CLS.
  • Stabilità sotto carico: servire un file già pronto costa una frazione di CPU rispetto a costruirlo. Un picco di traffico non si traduce in un sito lento.

Il risultato pratico non è un numero da sbandierare — quello dipende da hosting, rete e pagina, e va misurato sul singolo sito con Lighthouse e dati di campo. È che le Core Web Vitals smettono di essere una rincorsa mensile: partono già in regola perché lo è l'architettura. Se vuoi capire cosa entra davvero in un progetto fatto così, ne parliamo in creare un sito web professionale.

Su WordPress la velocità era un livello da aggiungere e da mantenere. Su Nuxt è il comportamento predefinito: se non tocchi niente, resta veloce.

Migrazione contat.eu

SEO: da plugin a regola di progetto

Su WordPress la SEO tecnica era delegata a un plugin: utile, ma pur sempre un consiglio che qualcuno deve ricordarsi di seguire. Nel sito nuovo è diventata una regola che il codice fa rispettare.

  • Meta obbligatori: title, description e canonical sono validati quando la pagina viene salvata. Se mancano o sono nel formato sbagliato, il salvataggio viene rifiutato.
  • Sitemap e llms.txt dinamici: si generano dai contenuti reali, quindi non possono restare indietro. Una pagina programmata compare nell'istante esatto della pubblicazione.
  • Dati strutturati coerenti: il markup FAQ è generato dalle FAQ visibili in pagina, mai scritto a mano. Google vede esattamente quello che vede il lettore.
  • Data di aggiornamento onesta: viene marcata solo quando il contenuto cambia davvero. Niente freschezza finta per compiacere un crawler.
  • Link interni controllati: un collegamento a una pagina che non esiste fa fallire il controllo automatico prima della pubblicazione.

Sono le stesse fondamenta che mettiamo nei progetti di posizionamento SEO: la parte tecnica smette di essere un intervento periodico e diventa una proprietà del sito.

Contenuti indicizzabili da motori e modelli
Contenuti indicizzabili da motori e modelli

Un sito che le AI sanno leggere (e usare)

Nel 2026 una parte crescente delle visite non arriva più da un elenco di link blu: arriva da una risposta scritta da un assistente AI che ha letto il web al posto tuo. Un sito costruito su contenuti strutturati parte avvantaggiato — non per magia, e non perché il CMS sia scritto in JavaScript invece che in PHP:

  • HTML completo dal server: chi legge la pagina — crawler classico o modello linguistico — trova il testo già presente, senza dover eseguire JavaScript. Su questo WordPress non è messo peggio: il confronto vero è con le applicazioni a pagina singola, che a un lettore automatico consegnano una pagina vuota.
  • Un indice pensato per i modelli: pubblichiamo un file llms.txt che elenca le pagine e cosa contengono, l'equivalente della sitemap per chi legge in linguaggio naturale.
  • Contenuti come dati: essendo JSON, le stesse pagine possono essere interrogate da un'integrazione o esposte come strumenti a un agente AI tramite MCP, senza scraping.
  • Redazione assistita: modificare una pagina significa modificare un file strutturato, quindi anche un assistente può preparare una bozza corretta — con la revisione umana prima della pubblicazione, sempre.

È il vantaggio che con un page builder non si ottiene: lì il contenuto e la sua presentazione sono lo stesso groviglio di HTML, e ogni riuso è un lavoro di archeologia.

Il costo che non ti mettono a preventivo

WordPress costa poco all'inizio, ed è un vantaggio reale: per un progetto piccolo o medio è spesso la scelta giusta. Il punto è un altro — il preventivo iniziale non è il costo del sito.

Un WordPress che deve funzionare in modo serio richiede attenzione quotidiana: aggiornamenti di core, tema e plugin da provare prima di applicarli, backup verificati (non solo pianificati), monitoraggio dell'uptime e soprattutto sorveglianza sulla sicurezza. Essendo open source e installato su una quota enorme dei siti del mondo, WordPress è il bersaglio più conveniente che esista: quando esce una vulnerabilità in un plugin diffuso, i bot automatici la provano su ogni sito che lo usa nel giro di poche ore. Non è un difetto morale del progetto, è la conseguenza matematica della sua diffusione.

Quel lavoro ha un costo operativo ricorrente che molte agenzie non mettono nero su bianco al momento della firma. Si scopre dopo — oppure non si scopre affatto finché il sito non viene compromesso, e allora il ripristino costa più di un anno intero di manutenzione. Preferiamo dirlo prima: se un sito WordPress deve reggere lavoro vero, il canone di assistenza non è un extra facoltativo, è parte del prezzo del sito.

Con Nuxt la voce non sparisce del tutto — server e dipendenze vanno comunque tenuti aggiornati — ma si riduce parecchio: nessun plugin di terzi con permessi ampi, nessun pannello di amministrazione pubblico da difendere, poche dipendenze scelte e controllate da noi. Il tempo che prima serviva a tenere in piedi il sito torna disponibile per farlo crescere.

Quando WordPress resta la scelta giusta

Sarebbe disonesto trasformare questo articolo in una condanna. WordPress fa girare una fetta enorme del web perché per i progetti piccoli e medi è spesso la risposta giusta: quando serve pubblicare tanto e subito con più autori, quando il budget iniziale è il vincolo principale, quando esiste già un plugin che risolve esattamente il tuo problema verticale, o quando chi gestisce il sito conosce quel pannello e non vuole cambiarlo.

Esiste anche una via di mezzo che usiamo spesso: WordPress headless, cioè WordPress come archivio dei contenuti e Nuxt come sito pubblico. Si tiene la redazione familiare e si guadagna la velocità del frontend moderno.

Quello che consigliamo di non fare è la terza opzione: restare su un WordPress pieno di plugin, pagando ogni mese in manutenzione e prestazioni un sito che nessuno ha più il coraggio di toccare. Se è la tua situazione, un check-up del sito chiarisce se serve una ristrutturazione o una migrazione vera.

Cosa consigliamo oggi ai nostri clienti

Per i progetti nuovi partiamo da Nuxt salvo motivi contrari espliciti. Non perché sia di moda, ma perché mette d'accordo tre esigenze che di solito litigano: un sito veloce, una base tecnica SEO solida e contenuti riusabili da app, integrazioni e sistemi AI. Sopra le stesse fondamenta costruiamo anche le web app, quindi un sito vetrina può crescere in area riservata o gestionale senza ricominciare da capo.

Se stai valutando un rifacimento, due strade rapide: chiedi un'anteprima visiva del tuo sito per vedere la direzione prima di decidere, oppure un preventivo chiaro con tempi e costi scritti. In entrambi i casi ti diciamo anche quando non conviene migrare.

Domande su WordPress e Nuxt

Nuxt è un framework per costruire siti e applicazioni web basato su Vue. Non è un CMS da installare e riempire: è la base su cui uno sviluppatore costruisce il sito, con rendering delle pagine sul server, gestione delle rotte, delle immagini e dei metadati già integrata. Il pannello per i contenuti va progettato a parte — nel nostro caso è un editor che scrive i file JSON delle pagine.
Non se la migrazione è fatta bene, ma il rischio è reale e va gestito. Le condizioni sono tre: ogni vecchio URL deve avere un redirect 301 verso il nuovo, i contenuti devono restare equivalenti per profondità e intento, e i dati strutturati vanno ricostruiti. Nelle settimane successive si tengono d'occhio Search Console e log per intercettare 404 e pagine non scansionate. Chi ti promette "zero rischi" senza guardare la mappa degli URL non l'ha guardata.
Sì. Il nostro sito ha un editor riservato: le pagine sono file strutturati e si modificano da interfaccia, con le modifiche online in circa un minuto senza ripubblicare il sito. La differenza rispetto a WordPress è che il pannello viene progettato attorno ai blocchi che usi davvero, invece di esporre mille opzioni che non servono.
Ha una superficie d'attacco più piccola: nessun pannello di amministrazione pubblico noto a tutti i bot, nessun plugin di terzi con permessi ampi, nessun tema con codice non revisionato. La sicurezza dipende comunque dal server e dalle scelte di sviluppo, ma sparisce la categoria di problemi più comune: il plugin obsoleto.
Perché una quota crescente di traffico nasce da risposte generate da assistenti AI che leggono il web. Un sito che serve HTML completo dal server, pubblica un indice llms.txt e conserva i contenuti come dati strutturati viene compreso e citato più facilmente, e può essere collegato ad agenti tramite protocolli come MCP senza scraping.

Il tuo sito WordPress ti sta costando troppo?

Analizziamo il sito attuale, ti diciamo se conviene ottimizzarlo o rifarlo, e in caso di migrazione ci occupiamo anche di redirect, SEO tecnica e contenuti.

Ultimo aggiornamento: