Migrare WordPress a un nuovo hosting significa spostare i file del sito, il database e la configurazione dal vecchio al nuovo server, senza perdere dati né tempi di attività. Se stai leggendo questa guida, quasi sicuramente hai un motivo concreto: il sito carica lento, il prezzo dell'hosting è salito, il supporto non risponde. Cambiare host è una mossa necessaria, e non serve essere sviluppatori: serve seguire la sequenza giusta, che è sempre la stessa.
Cosa stai spostando davvero
Perché conviene cambiare hosting? Due motivi, quasi sempre: il rinnovo che rincara (il primo anno costa meno del secondo) o un hosting incluso che non regge quando il sito cresce. Il movente decide cosa cercare nel nuovo piano.
Perché si cambia hosting? Quasi mai per capriccio: nel caso più frequente (il primo su due query) è il rinnovo che rincara — il prezzo del primo anno non è il prezzo del secondo — oppure un hosting «incluso» che non regge quando il sito cresce. Capire il movente serve: dice anche cosa cercare nel nuovo piano.
Prima della tecnica, la domanda che quasi nessuno si fa: perché stai migrando? Le due risposte più comuni sono diverse e portano a scelte diverse. La prima è economica: il rinnovo costa due o tre volte il primo anno, e a quel punto conviene guardarsi intorno (i numeri di questo effetto sono nella guida su quanto costa un sito web). La seconda è tecnica: il sito è cresciuto, il piano condiviso non basta più, e il sintomo è la lentezza (gli errori di hosting più comuni sono elencati qui).
Il movente conta perché cambia il piano: se il problema è il prezzo, cerchi lo stesso tipo di hosting a condizioni migliori; se è la lentezza, cambiare tipo di piano (condiviso → risorse isolate) è l’unico intervento che sposta i numeri. In entrambi i casi la migrazione la fai una volta, e farla bene è più importante di farla in fretta.
Cosa serve per migrare WordPress? Tre cose: i file del sito (tema, plugin, immagini), il database (articoli, pagine, impostazioni) e il file wp-config.php che li collega. Mancano una, il sito non parte.
WordPress vive in due mondi separati: i file su disco (tema, plugin, uploads, file di sistema) e il database (articoli, pagine, utenti, impostazioni). Il punto di contatto è il file wp-config.php, che dice a WordPress dove trovare il database e come chiamarlo. Una migrazione fatta bene copia tutti e tre gli elementi; una fatta a metà copia solo i file e poi si chiede perché il sito dà errore di connessione al database.
Il percorso in sintesi: backup, nuovo hosting, copia file, importa database, aggiorna wp-config, punti il DNS, verifica, svuota la cache. Otto passi, nessuno dei quali richiede competenze da sysadmin. La mappa completa è qui sotto: tienila aperta mentre procedi.
Un esempio concreto per capire il quadro: il sito di un artigiano con 300 prodotti, un blog con articoli e una galleria di foto. La parte "pesante" sono le immagini in uploads (anche 2-3 GB), la parte "invisibile" è il database (le schede prodotto, gli ordini, gli utenti). Se la migrazione porta tutto, il sito nuovo è identico in poche ore. Se dimentica il database, il risultato è una pagina con l'errore "Error establishing a database connection", un messaggio frequente di WordPress. La sequenza che segue evita esattamente questo.
Backup completo: file e database
Cosa serve davvero per il backup?
Cosa serve davvero per il backup? Una copia dei file e una del database, entrambe scaricate sul tuo computer o su un cloud tuo. Solo i file non bastano mai: senza database, WordPress mostra un errore di connessione.
Il backup è un passaggio che influenza l'esito di tutta l'operazione. Due pezzi, entrambi obbligatori. File: tema, plugin, la cartella wp-content/uploads con le immagini e il resto. Database: articoli, pagine, commenti, impostazioni, utenti. Per il database, da phpMyAdmin si esporta tutto in un file .sql; se hai accesso a WP-CLI, wp db export fa lo stesso lavoro in un comando. Se sul pannello del vecchio hosting c'è una funzionalità di backup automatico, usala comunque, ma scarica le copie anche fuori dal server: un backup che resta sullo stesso disco del sito è un backup a metà.
Se il tuo sito fa già backup automatici regolari (e dovrebbe: qui trovi la guida completa ai backup di WordPress), puoi riusare l'ultima copia: controllo che sia recente, scaricala e vai avanti. Se invece arrivi da WordPress.com e vuoi passare a un hosting tuo, il percorso è leggermente diverso, e in questa guida dedicata trovi le differenze passo per passo.
Prepara il nuovo hosting
Cosa devo preparare sul nuovo hosting? Lo spazio web, un database nuovo con utente e password, un certificato SSL e un ambiente testabile. Meglio settare tutto prima di copiare un solo file.
Sul nuovo hosting crei da zero l'ambiente: database (con utente e password dedicate), spazio web per i file e SSL. Molti pannelli moderni (cPanel, Plesk, i pannelli proprietari) offrono l'installazione di WordPress in un click: se la usi, fai attenzione a quello che installa, perché poi andrai a sovrascriverlo con i tuoi file. L'alternativa pulita è preparare solo il database e caricare i file a mano. Prima di procedere, verifica anche che il piano scelto rispetti almeno le basi: PHP aggiornato, risorse dedicate e cache lato server. I requisiti ufficiali di WordPress, aggiornati a ogni release, sono elencati nella documentazione ufficiale: una cosa da controllare prima di firmare, non dopo. Se stai ancora valutando dove andare, ti conviene partire dalla guida su come scegliere l'hosting WordPress e dal confronto dei migliori hosting italiani.
Copia i file e importa il database
Cosa cambio nel file wp-config?
Cosa cambio nel file wp-config? Tre righe: il nome del database, l'utente e la password del nuovo hosting. Tutto il resto del file resta com'è.
Copi i file con FTP o con un file manager: tema, plugin, uploads e tutto il contenuto della root di WordPress. Poi importi il .sql del database nel database nuovo (phpMyAdmin: importa; WP-CLI: wp db import). Infine apri wp-config.php e aggiorni queste tre righe con i dati del nuovo database:
define( 'DB_NAME', 'nuovo_nome_database' );
define( 'DB_USER', 'nuovo_utente' );
define( 'DB_PASSWORD', 'nuova_password' );
Se il dominio resta lo stesso, non devi toccare gli URL nel database: gli indirizzi nel wp_options restano validi. Cambi anche dominio? Allora serve una ricerca-e-sostituisci degli indirizzi (la fanno i plugin di migrazione o WP-CLI con wp search-replace), da fare con attenzione sulle tabelle giuste.
Un dettaglio che dimenticano quasi tutti: i permessi dei file. Dopo la copia, le directory devono avere lettura ed esecuzione per chi serve le pagine (tipicamente 755) e i file 644; molti archivi divisi copiano i file con permessi sbagliati e il sito risponde con errori che non c'entrano niente con la migrazione. Pannelli come cPanel hanno un pulsante per riparare i permessi in un click; da terminale si risolve con un comando ricorsivo. Controllalo come parte della verifica.
Il DNS: la parte che richiede pazienza
Quanto dura la propagazione DNS?
Quanto dura la propagazione DNS? Da poche ore fino a 48 ore: durante questo intervallo il sito può rispondere dal vecchio o dal nuovo server. È normale, non è un errore.
Il DNS collega il nome del dominio all'indirizzo del server. Quando lo cambi, l'aggiornamento si propaga per il mondo e può servire fino a due giorni: alcuni visitatori vedono il nuovo server, altri ancora il vecchio. Due accorgimenti per farlo in modo pulito. Prima, abbassa il TTL (il tempo di vita delle risposte DNS) a 300 secondi: le modifiche viaggiano più in fretta (la documentazione di Cloudflare sul TTL spiega bene il meccanismo). Durante, non toccare il vecchio hosting: lascialo in piedi finché il sito non risponde in modo stabile dal nuovo (il piano gratuito di Cloudflare, se lo usi, gestisce la parte CDN senza costi extra). Dopo, verifica da fuori, da un telefono o da una rete diversa, non dal computer con cui lavori. E se hai il controllo dei nameserver, controlla anche i record NS: alcuni hosting gestiti richiedono di puntare direttamente i loro nameserver, altri funzionano solo con i record che punti tu. Sapere dov'è il confine (registrar, DNS, hosting) evita il giro a vuoto del supporto tecnico.
Verifica dopo la migrazione
Cosa controllo subito dopo?
Cosa controllo subito dopo? HTTPS e SSL, le immagini, i link, le email, la velocità e la cache del nuovo server. Se qualcosa non torna, il problema è quasi sempre la cache o un permalink da rigenerare.
La verifica si fa in ordine. HTTPS: il sito deve rispondere con il lucchetto; se il certificato non è attivo, anche questa è una cosa da fare prima del DNS. Contenuti: apri qualche articolo, controlla che le immagini si vedano e che i link funzionino. Permalink: se le pagine danno 404, vai su Impostazioni e salvi di nuovo la struttura dei permalink; WordPress rigenera le regole da solo. Email: invia e ricevi una prova; se i record MX restano nello stesso DNS, di solito non cambia nulla. Velocità: un test con PageSpeed Insights dopo una settimana ti dice se il nuovo host mantiene le promesse. E per ultimo, svuota la cache del nuovo server: a migrazione finita, non deve restare traccia del vecchio sito. Un trucco da professionisti: prima di puntare il DNS, puoi testare il sito sul nuovo server con un sottodominio temporaneo (o l'host file locale), così la verifica vera la fai senza fretta e senza toccare il sito in produzione.
Se qualcosa non torna, niente panico: prima di tutto svuota la cache del server e del plugin cache, poi rigenera i permalink, e solo dopo inizia a cercare. La stragrande maggioranza dei "siti rotti dopo la migrazione" sono cache da svuotare. E se proprio non trovi la causa, sul forum di supporto italiano di WordPress trovi una comunità attiva che le migrazioni le vede ogni giorno.
Gli errori che rovinano la migrazione
Cosa si rompe in una migrazione WordPress? Tre cose su tutte: il database (se cambi dominio senza gestire le stringhe serializzate), le email (i record MX spostati troppo presto) e i link interni che restano puntati al vecchio indirizzo. Tutte e tre si prevengono, se si conoscono prima.
Il search-replace e le stringhe serializzate
È l’errore che si scopre dopo: il sito si apre, ma i link interni puntano al vecchio dominio, oppure una pagina perde i widget e le impostazioni. Il motivo è che cambiare dominio non è un semplice «trova e sostituisci»: il database di WordPress contiene valori «serializzati», cioè stringhe che dichiarano la propria lunghezza. Se sostituisci il vecchio indirizzo con uno più corto o più lungo senza correggere quel numero, il valore diventa illeggibile e WordPress lo scarta.
Come si fa bene: si usa uno strumento che gestisce la serializzazione — WP-CLI con wp search-replace (la sezione qui sopra), o lo strumento incluso nei plugin di migrazione — e mai una sostituzione fatta a mano in phpMyAdmin. Due regole pratiche: fai la sostituzione dopo l’importazione del database e prima di aprire il sito al pubblico, e controlla sempre tre cose dopo: i link interni di un articolo, il logo e le immagini in home, e le impostazioni di un plugin qualsiasi (è lì che si vedono i valori serializzati rotti).
Le email: l’unico danno irreversibile
È il punto in cui una migrazione può fare un danno che non si ripara con un backup, ed è la domanda che nessuna delle tredici guide di hosting in prima pagina affronta. Mentre il sito cambia server, la posta elettronica collegata al dominio continua a puntare dove dicono i record MX: se li sposti prima che la nuova casella sia pronta, i messaggi in arrivo si perdono (e non tornano). La sequenza sicura è questa: prima si creano le caselle sul nuovo provider e si verificano, poi si testano invio e ricezione, e solo alla fine si cambiano i record MX. Se il dominio ha email che usi per lavoro, tenere le due configurazioni attive per qualche giorno è la scelta prudente: la posta non ha la tolleranza che ha un sito web.
Migrare senza fermare il sito: come si fa
«Zero downtime» è una promessa commerciale: la tecnica esiste, e vale la pena conoscerla. Il metodo è non cambiare il DNS finché il nuovo server non è pronto e verificato, e nel frattempo controllare il sito nuovo tramite una corrispondenza locale: si modifica il file hosts del proprio computer (o si usa il DNS locale del pannello) per far puntare il dominio al nuovo IP solo per te. Navighi il sito nuovo come se fosse online, clicchi, verifichi i form, e quando è tutto a posto sposti il DNS per tutti. Se preferisci non toccare nulla, la variante è una breve finestra di manutenzione — dieci minuti in una notte — che è più sicura di una migrazione fatta «a sito aperto» senza controllo.
Qual è l'errore più grave in una migrazione? Dimenticare uno dei tre elementi (file, database, wp-config) oppure cambiare TTL alto e testare di fretta. La migrazione si rompe quasi sempre per il poco, non per il molto.
Gli errori si ripetono con una costanza impressionante. Copiare solo i file e scoprire che il database non c'è. Dimenticare che wp-config.php contiene i dati del vecchio hosting e lasciarlo così com'è. Fare il cambio DNS con TTL alto, condannandosi a ore di attesa inutili. Testare di fretta, guardando il sito dal computer di lavoro, che magari ha già la copia in cache e mostra il vecchio server. Dimenticare le email, che se vivono sul vecchio hosting smettono di arrivare. E migrare in pieno traffico, nel giorno sbagliato, senza margine per correggere.
Molti di questi errori sono gli stessi che vediamo ogni giorno nei siti nuovi: se vuoi riconoscerli a colpo d'occhio, la nostra raccolta degli errori comuni con l'hosting WordPress li elenca tutti con il rimedio. La regola pratica resta una: mai migrare di venerdì pomeriggio, mai senza backup fresco, mai la settimana dei saldi se sei un negozio. La migrazione si fa quando si ha il tempo di verificare.
WP-CLI: la via per chi ama il terminale
Come si cambia il dominio nel database di WordPress? Con wp search-replace da WP-CLI, che gestisce i valori serializzati, o con lo strumento incluso nel plugin di migrazione. Mai con una sostituzione fatta a mano in phpMyAdmin.
Posso migrare con i comandi? Se il nuovo hosting dà accesso SSH, sì, ed è anche più veloce: backup, copia e import si fanno con WP-CLI in pochi comandi.
Per chi ha accesso SSH (molti hosting gestiti lo danno), WP-CLI comprime l'intera procedura. Sul vecchio server: wp db export per il database e un archivio della cartella (per esempio con tar). Sul nuovo: ripristini database con wp db import, scompatti i file e aggiorni wp-config.php. Un esempio di sequenza, da adattare ai tuoi percorsi:
# sul vecchio server
wp db export sito.sql
tar czf sito-files.tar.gz wp-content
# sul nuovo server
wp db import sito.sql
tar xzf sito-files.tar.gz
La versione di PHP installata fa la differenza: la pagina ufficiale delle versioni supportate è il riferimento quando confronti vecchio e nuovo ambiente. Se non hai mai usato il terminale, non partire da qui: la via grafica descritta sopra funziona benissimo.
I plugin che migrano al posto tuo
Tre scenari diversi (e i nomi che si cercano)
La procedura di questa guida vale per il caso più comune — da un hosting all’altro, stesso dominio. Due varianti cambiano i passaggi, e sono quelle che la gente cerca per nome:
- Da WordPress locale a un hosting remoto: il caso di chi ha sviluppato in locale (Local, DevKinsta, Studio) e ora pubblica. Qui il database è già tuo e non c’è DNS da cambiare: serve esportare file e database, importarli, aggiornare l’URL nel database (dal dominio locale a quello vero) e sistemare i permessi dei file.
-
Su un dominio diverso: oltre alla migrazione c’è il cambio di indirizzo. Oltre al
search-replace, serve decidere cosa fare del vecchio dominio: un redirect 301 verso il nuovo è la scelta che conserva il posizionamento, e va tenuto attivo a lungo — non qualche settimana. - Con un plugin: tra i più usati c’è Duplicator — 1 milione di installazioni, 98/100, aggiornato il 18 settembre 2026 — che esporta un pacchetto completo da importare sul nuovo server. Resta vero quello che dicevamo sopra: qualunque strumento usi, la verifica finale è sempre la stessa. E se il nuovo hosting è un provider italiano molto diffuso, come Aruba, la sua procedura di importazione è documentata nel pannello: quello che conta è che tu faccia il backup prima di usarla.
Esiste un plugin per migrare? Sì: All-in-One WP Migration e Duplicator copiano sito e database con pochi click. Ottimi per siti piccoli, vanno verificati con attenzione sui siti grandi o con molto traffico.
Se la via manuale ti sembra troppa, i plugin di migrazione esistono e funzionano: All-in-One WP Migration esporta il sito intero (file e database insieme) in un unico archivio da importare sul nuovo host; Duplicator fa lo stesso con pacchetti separati. Il limite è la dimensione: gli hosting impongono tetti all'upload e i siti con molte immagini superano presto i limiti del piano gratuito. La logica resta identica alla via manuale: backup, copia, configurazione, test. L'unica differenza è che il plugin fa i passi 3 e 4 al posto tuo.
Quanto dura e quanto costa
Quanto tempo richiede una migrazione WordPress? Da una a tre ore di lavoro tecnico, più il tempo di propagazione del DNS: da qualche ora a 24-48 ore, secondo il TTL impostato. Il sito resta raggiungibile, se il DNS si sposta per ultimo.
I tempi reali, per farti un'idea concreta prima di partire.
FaseTempo tipicoDove si sbaglia di piùBackup file + database20-40 minDimenticare il databaseSetup nuovo hosting30-60 minSSL non attiva prima del DNSCopia file + import DB30-90 minwp-config non aggiornatoDNS e propagazione1-48 oreTTL alto e test troppo prestoVerifica finale30 minDimenticare email e cache
Domande frequenti
In pratica: il piano d'azione in 8 mosse
Ricapitoliamo: questa è la sequenza completa da seguire, nell'ordine. Se la rispetti, la probabilità di problemi si riduce.
- Fai il backup completo (file + database) e tienilo fuori dal server
- Prepara il nuovo hosting: database, utente, SSL
- Copia i file e importa il database
- Aggiorna wp-config.php con i dati del nuovo database
- Abbassa il TTL nel DNS, poi punta il dominio al nuovo server
- Verifica HTTPS, link, email, permalink e velocità
- Svuota la cache del nuovo hosting
- Non spegnere il vecchio server finché il sito non è stabile
Se durante la migrazione vuoi un punto di riferimento sulla sicurezza (i permessi dei file, per esempio, sono un classico da sistemare dopo il trasferimento), la guida completa alla sicurezza WordPress ti copre. E quando il sito è sul nuovo server, il lavoro successivo comincia: la guida alle performance WordPress ti mostra come sfruttarlo al massimo.
Un’ultima cosa, che viene da chi lo ha scritto dopo averlo fatto: «e poi la migrazione su un hosting migliore, perché quello incluso non reggeva». È la frase che riassume la migrazione più comune, quella in cui il sito è cresciuto e l’hosting incluso nell’offerta ha smesso di bastare. Non è un fallimento: è il momento in cui il progetto ha superato i limiti del piano che aveva. Se stai leggendo questa guida, sei esattamente lì.
Se preferisci farti seguire da chi queste migrazioni le fa di mestiere, su madweb.it ci occupiamo di hosting WordPress: ti trasferiamo il sito, verifichiamo ogni dettaglio e la prima settimana la passiamo insieme al monitoraggio.
Top comments (0)