Migrare WordPress a un VPS senza perdere email o DNS

Come trasferire un sito WordPress da hosting condiviso a VPS senza perdere email o DNS

Spostare WordPress da un hosting condiviso a un server privato virtuale (VPS) può darti più controllo su PHP, risorse del server e configurazione. Tuttavia, il trasferimento può interrompere il servizio email o indirizzare i visitatori al posto sbagliato se lo consideri una semplice copia di file. Il segreto è separare il sito web dai servizi che già dipendono dal tuo dominio.

Se stai cercando come migrare WordPress da hosting condiviso a VPS, per prima cosa fai un elenco dei servizi effettivamente forniti dall’host attuale. Il dominio può essere registrato presso un’azienda, usare i DNS di un’altra, un servizio email di una terza e l’hosting WordPress di una quarta. Non è necessario spostare tutti questi servizi insieme.

1. Definisci l’ambito del trasferimento: separa il sito dai servizi che resteranno dove sono

Annota dove si trovano i file e il database di WordPress, poi individua il provider responsabile di ogni servizio correlato. Verifica chi gestisce il registrar del dominio, il DNS, l’email e gli eventuali servizi separati, come una CDN o l’archiviazione delle immagini. Il pannello di controllo dell’hosting potrebbe mostrare alcune di queste informazioni, ma sono i nameserver e i record DNS del dominio a indicare dove viene effettivamente indirizzato il traffico.

Per esempio, un sito può essere ospitato su un piano condiviso, mentre il DNS è gestito tramite Cloudflare e l’email del personale tramite Google Workspace. In questo caso, spostare WordPress su un VPS non richiede di trasferire né il dominio né gli account email. Di solito basta modificare i record che indirizzano il traffico web, lasciando invariati quelli della posta.

Prima di apportare modifiche, prepara un semplice inventario. Annota la destinazione web attuale, i nameserver e tutti i record email che conosci. Se non sai se un record è legato alla posta, chiedi al provider email o consulta le sue istruzioni di configurazione invece di eliminarlo. Un record email mancante può bloccare i messaggi in arrivo anche se il sito sembra funzionare normalmente.

2. Individua le dipendenze che una semplice copia del sito potrebbe non includere

Un backup di WordPress può contenere i file e il database del sito, ma non necessariamente tutti i servizi da cui dipende. Controlla le attività pianificate, le impostazioni per l’invio delle email, lo storage esterno, i reindirizzamenti, la configurazione SSL e tutte le impostazioni specifiche del server. Per esempio, un sito di iscrizioni potrebbe dipendere da un’attività pianificata per far scadere gli account, mentre un negozio potrebbe inviare le notifiche degli ordini tramite un servizio SMTP esterno.

Controlla le attività pianificate nel pannello dell’hosting e nei plugin di WordPress. Il sistema di pianificazione integrato in WordPress può attivarsi quando un visitatore carica una pagina; un cron job del server, invece, può eseguire uno script specifico secondo una pianificazione prestabilita. Annota il comando, la frequenza e il fuso orario di ogni attività. Se sul VPS non configuri un cron job equivalente, un’attività che sul vecchio host veniva eseguita ogni ora potrebbe interrompersi dopo il trasferimento.

Verifica come vengono inviate le email dal sito. Annota se utilizza il server di posta dell’hosting, un plugin SMTP o un servizio di email transazionali e controlla quale indirizzo mittente viene usato. Se il vecchio host forniva il server di posta, le stesse impostazioni potrebbero non funzionare dal VPS. Chiedi al provider email se limita le connessioni o richiede un metodo di autenticazione specifico.

Fai anche un elenco dello storage esterno e delle impostazioni del server. Un plugin per i file multimediali potrebbe archiviare i caricamenti su uno storage a oggetti anziché nella cartella uploads di WordPress. Il sito potrebbe dipendere da una versione specifica di PHP, da determinate estensioni PHP, da regole di riscrittura o da un’impostazione nel file .htaccess. Conserva una copia di questi dettagli: improvvisare dopo la pubblicazione può trasformare un piccolo problema di compatibilità in una lunga interruzione del servizio.

3. Configura il VPS in base alle reali esigenze del sito

Scegli una configurazione VPS adeguata alle esigenze effettive del sito e decidi come gestirà le richieste web. Tra le opzioni più comuni ci sono Apache e Nginx, ma la scelta giusta dipende dal sito attuale e dalle competenze di chi dovrà amministrarlo. Prima di installare lo stack di produzione, verifica che la versione di PHP e le estensioni necessarie siano compatibili con il codice, i plugin e il tema del sito.

Configura il database, il server web e l’interprete PHP, poi imposta proprietari e permessi dei file in modo che WordPress possa leggerli e scrivere solo dove necessario. Non rendere scrivibili tutti i file solo per far sparire un errore. Limita gli accessi amministrativi, attiva un firewall e imposta backup che includano sia il database sia i file del sito.

Prima di trasferire il sito attivo, testa il VPS. Verifica che il server web riesca a mostrare una pagina di base, che PHP funzioni correttamente e che il database accetti una connessione di prova. Prendi nota delle versioni installate e dei file di configurazione. Potrai confrontare queste informazioni se un plugin dovesse comportarsi diversamente sul nuovo server.

4. Trasferisci file e database senza modificare il sito attivo

Crea una copia completa dei file e del database di WordPress e lascia il sito originale disponibile ai visitatori mentre lavori. Un plugin di migrazione può creare un pacchetto del sito, mentre gli strumenti da riga di comando o un backup fornito dall’host possono offrire maggiore controllo. Qualunque metodo tu scelga, verifica che il backup includa database, caricamenti, temi, plugin ed eventuali file di configurazione personalizzati. Se devi trasferire un sito WordPress senza perdere le email, conserva anche le impostazioni dei servizi di posta e i relativi record DNS, senza confondere il backup del sito con quello della posta.

Se il sito viene aggiornato spesso, pianifica come gestire i nuovi ordini, commenti o articoli pubblicati dopo la prima copia. Una possibilità è creare una copia iniziale, testarla in privato e ripetere il trasferimento del database durante una breve finestra di manutenzione. Per un negozio, evita di accettare ordini su entrambe le copie: rimediare a dati degli ordini duplicati o mancanti è più complicato che sospendere brevemente le vendite, avvisando i clienti.

Sposta i file e il database sul VPS, poi aggiorna la configurazione di WordPress con il nuovo nome del database, utente, password e host, se necessario. Conserva in modo sicuro i valori originali e quelli nuovi. Se cambia il dominio o il percorso dei file, aggiorna attentamente le impostazioni del sito: una sostituzione globale di testo può danneggiare i dati serializzati nel database se non gestisce correttamente la serializzazione.

Per ora non indirizzare il DNS pubblico al VPS. Mentre controlli la copia privata, il vecchio host deve continuare a essere la destinazione pubblica. Inoltre, il nuovo server non dovrebbe ricevere attività reali dei clienti finché non sei pronto a completare il passaggio.

5. Esegui test in privato prima di modificare il DNS pubblico

Configura una modifica al file hosts sul tuo computer o usa un hostname temporaneo di staging per indirizzare il browser al VPS senza modificare il DNS pubblico. La modifica al file hosts riguarda solo il dispositivo su cui viene applicata, quindi è utile per controllare il nuovo sito prima che sia visibile agli altri visitatori. Al termine dei test, rimuovi la voce per non confondere il percorso privato con quello pubblico.

Prova sia il front-end sia la bacheca di WordPress. Controlla la pagina di accesso, un insieme rappresentativo delle pagine principali, la ricerca, i moduli, i caricamenti, i reindirizzamenti e le eventuali funzioni di pagamento o di iscrizione. Invia un modulo di prova e verifica dove arriva il messaggio. Se il sito invia email, controlla che vengano consegnate e che non finiscano nello spam: la conferma visualizzata dopo l’invio di un modulo non dimostra che l’email sia partita.

Controlla le attività pianificate e tutte le integrazioni che contattano il sito dall’esterno. Un servizio di pagamento, per esempio, potrebbe inviare una notifica a un URL specifico, mentre un servizio di monitoraggio potrebbe aspettarsi una determinata risposta. Verifica anche che HTTPS funzioni sul VPS. Un hostname di staging potrebbe non corrispondere al certificato di produzione, quindi prova la configurazione definitiva del certificato prima di indirizzare i visitatori al nuovo server.

Controlla i reindirizzamenti e gli URL canonici del dominio di produzione. Se il sito ha una frequenza di rimbalzo elevata, una pagina di destinazione o un reindirizzamento non funzionante possono peggiorare la situazione; questa guida spiega qual è una buona frequenza di rimbalzo per un sito web e come interpretare questo dato. Durante i test della migrazione, concentrati su problemi concreti, come un modulo che restituisce un errore o un file caricato che non compare.

6. Modifica il DNS con un piano per l’email e il ripristino

Prima di modificare il DNS, salva i record attuali e annota esattamente quali record web intendi aggiornare. Se il sito usa un record A, cambiane la destinazione con l’indirizzo del VPS. Se l’hostname web è gestito da un record CNAME, modificalo se necessario. Mantieni invariati i record email, compresi quelli MX e tutti i record TXT usati per l’autenticazione della posta, a meno che tu non stia cambiando deliberatamente provider email. Per configurare DNS e posta dopo la migrazione a un VPS, verifica i record web e quelli di posta separatamente, così da indirizzare il sito al nuovo server senza alterare la consegna delle email.

Ridurre il time to live (TTL) del DNS prima del trasferimento può aiutare alcuni resolver a rilevare più rapidamente la nuova destinazione, ma non garantisce che la modifica si propaghi subito ovunque. Prima di modificare i record, controlla la configurazione DNS attuale e le indicazioni del provider. Se usi un proxy o una CDN, verifica se l’indirizzo di origine deve puntare direttamente al VPS e se la modalità SSL del proxy è compatibile con il certificato installato sul server.

Scegli una finestra per il passaggio durante la quale puoi tenere d’occhio il sito e intervenire in caso di problemi. Modifica i record web previsti, poi controlla il dominio da più reti o usando diversi servizi di ricerca DNS. Prepara istruzioni scritte per tornare alla configurazione precedente: ripristina la vecchia destinazione web, annota chi può applicare la modifica e mantieni l’accesso al vecchio account di hosting. Non eliminare il vecchio sito finché le cache DNS potrebbero ancora indirizzarvi alcuni visitatori.

Durante il passaggio, controlla l’email separatamente. Invia un messaggio da un account esterno a un indirizzo del dominio e, se possibile, rispondi da quell’indirizzo. Se la posta non funziona, confronta i record DNS attuali con la copia salvata prima di apportare altre modifiche. Il trasferimento del server web non dovrebbe richiedere l’eliminazione dei record email.

7. Verifica la nuova configurazione dopo la pubblicazione

Quando il traffico pubblico raggiunge il VPS, controlla HTTPS, le pagine principali, i moduli, l’accesso e tutti i flussi di lavoro che generano entrate. Esamina i log di WordPress e del server per individuare errori PHP, accessi ai file negati, connessioni al database non riuscite o richieste ripetute a URL inesistenti. La home page potrebbe sembrare normale anche se un errore di un plugin ha bloccato il modulo di contatto.

Verifica che i backup sul VPS vengano eseguiti e che tu sappia come ripristinarli. Controlla la destinazione dei backup e assicurati che uno recente contenga sia il database sia i file. Configura il monitoraggio della disponibilità e della scadenza del certificato, poi verifica che le email continuino a essere inviate e ricevute. Completa questi controlli prima di disdire il vecchio piano di hosting.

Mantieni attivo il vecchio hosting finché il nuovo sito non supera i controlli che hai definito e le modifiche DNS non si sono propagate. Conserva una copia finale dei vecchi file e del database secondo la tua politica di conservazione. Quando il VPS ospita il sito, la posta funziona e le procedure di ripristino sono documentate, potrai decidere quando chiudere il vecchio account senza rischiare di rinunciare a servizi che sono ancora necessari.