Pubblicato il
Un sito WordPress che resta irraggiungibile dopo il cambio hosting, immagini mancanti e moduli di contatto che non inviano email sono problemi quasi sempre evitabili. Capire come migrare WordPress su server significa pianificare il passaggio di file, database, dominio e configurazioni senza affidarsi al caso. Una migrazione ben eseguita riduce il downtime, protegge i dati e consente di sfruttare subito le risorse del nuovo ambiente.
La procedura cambia leggermente tra hosting condiviso, VPS, cloud server e server dedicato. Il principio, però, resta lo stesso: prima si replica il sito nel nuovo spazio, poi lo si testa e solo alla fine si indirizza il dominio verso il nuovo server.
Prima di migrare WordPress su server: cosa verificare
Non iniziare copiando la cartella di WordPress. Prima serve una verifica tecnica dell'ambiente di destinazione. Controlla la versione PHP supportata, i limiti di memoria, le estensioni richieste dal sito, la versione di MySQL o MariaDB e lo spazio disco disponibile. Un e-commerce con molti prodotti, immagini e ordini storici ha esigenze diverse rispetto a un sito vetrina di dieci pagine.
Verifica anche il web server e la gestione della cache. Un ambiente con storage NVMe, rete veloce e LiteSpeed Enterprise può offrire tempi di risposta più bassi rispetto a configurazioni tradizionali, ma eventuali plugin di cache vanno configurati correttamente dopo il trasferimento. Non copiare alla cieca impostazioni nate per Apache se il nuovo server usa regole o sistemi di cache diversi.
Fai poi un inventario di ciò che deve essere migrato. Oltre a file e database, possono essere presenti caselle email, record DNS personalizzati, certificati SSL, cron job, configurazioni SMTP, redirect e sottodomini. Se il dominio è gestito separatamente dall'hosting, annota con precisione dove intervenire per aggiornare la zona DNS al termine dei test.
Scegliere il momento giusto
Per un blog aggiornato raramente, la migrazione può essere effettuata in qualsiasi fascia con traffico ridotto. Per un e-commerce o un portale che riceve richieste e ordini ogni ora, serve maggiore attenzione: tra l'esportazione del database e il cambio DNS potrebbero essere registrati nuovi dati sul vecchio server.
In questi casi pianifica una finestra operativa, avvisa il team e limita le modifiche editoriali. Se il progetto è business-critical, prepara un ultimo export del database poco prima della messa online e valuta una modalità manutenzione breve. L'obiettivo non è azzerare il tempo tecnico, ma evitare perdite di ordini, utenti registrati o richieste inviate dai moduli.
Backup completo: il punto da cui partire
Un backup non è una formalità. È la possibilità concreta di tornare indietro se un plugin entra in conflitto, un'importazione si interrompe o un record DNS viene modificato in modo errato. Crea almeno una copia completa dei file e una copia separata del database, quindi conserva entrambi anche fuori dal server che stai lasciando.
I file WordPress comprendono la directory principale, le cartelle `wp-content`, `wp-includes` e `wp-admin`, oltre ai file nascosti come `.htaccess`. La cartella `wp-content` merita un controllo specifico perché contiene temi, plugin, upload e talvolta dati generati da estensioni di e-commerce o page builder.
Il database contiene invece pagine, articoli, utenti, impostazioni, commenti, prodotti e ordini. Esportalo in formato SQL con uno strumento di gestione database oppure tramite riga di comando. Prima di procedere, controlla che l'archivio sia leggibile e che la sua dimensione sia coerente con quella attesa. Un file SQL di pochi kilobyte per un sito attivo da anni è un segnale da indagare.
Se disponi di backup gestiti, come copie pianificate con R1Soft Backup, usali come ulteriore livello di protezione. Restano comunque utili un export manuale e una verifica puntuale prima della migrazione.
Copiare file e database nel nuovo ambiente
Nel nuovo hosting o server crea il database, l'utente associato e una password sicura. Assegna all'utente tutti i privilegi necessari sul database e annota nome database, username, password e host. In molti ambienti l'host è `localhost`, ma su architetture cloud o server separati può essere differente.
Carica quindi i file del sito nella directory web corretta, spesso `public_html`, `httpdocs` o nella document root definita per il dominio. Per siti di grandi dimensioni è preferibile comprimere i file in un archivio, trasferirlo via SFTP o SSH e decomprimerlo direttamente sul server. Così si riduce il numero di trasferimenti e si limita il rischio di file incompleti.
Importa il file SQL nel nuovo database. Al termine dell'importazione, verifica che le tabelle siano presenti e che il prefisso corrisponda a quello configurato nel sito. Il prefisso più comune è `wp_`, ma non è obbligatorio: molti progetti usano prefissi personalizzati per ragioni di organizzazione o sicurezza.
Apri il file `wp-config.php` e sostituisci i dati del vecchio database con quelli appena creati. Controlla anche il valore di `DB_CHARSET`, di norma `utf8mb4`, e non modificare le chiavi di autenticazione se non hai una ragione precisa. Cambiarle forza la disconnessione di tutti gli utenti, inclusi gli amministratori.
Dominio invariato o dominio nuovo
Se il dominio non cambia, il database può mantenere lo stesso indirizzo del sito. Per testare il progetto prima di aggiornare il DNS, puoi usare un dominio temporaneo, un sottodominio di prova o un file hosts configurato sul tuo computer. Quest'ultima soluzione è utile perché permette di visualizzare il sito sul nuovo server mantenendo il dominio pubblico ancora attivo sul vecchio.
Se invece cambia anche il dominio, devi sostituire gli URL nel database. Non usare una semplice ricerca e sostituzione su tutto il file SQL senza sapere cosa stai facendo: WordPress e molti plugin salvano dati serializzati, che possono rompersi se la lunghezza delle stringhe non viene aggiornata correttamente. Usa uno strumento compatibile con WordPress o una procedura che gestisca i dati serializzati.
Dopo la sostituzione, aggiorna in WordPress gli indirizzi "Indirizzo WordPress" e "Indirizzo sito", se necessario. Verifica anche URL inseriti manualmente nei page builder, nelle impostazioni del tema, nelle campagne email e nei servizi esterni collegati al sito.
Testare il sito prima del cambio DNS
Il test è la fase che separa un trasferimento ordinato da una migrazione fatta di correzioni urgenti. Accedi al pannello WordPress nel nuovo ambiente e controlla prima le pagine principali, poi le funzionalità meno visibili: ricerca interna, moduli, aree riservate, download, feed, redirect e sitemap.
Per un e-commerce, esegui un acquisto di prova fino alla pagina di conferma, senza trascurare carrello, checkout, coupon, metodi di pagamento, email transazionali e calcolo delle spedizioni. Per un sito multilingua, prova il cambio lingua e gli URL localizzati. Per un portale con membership, verifica registrazione, login, recupero password e ruoli utente.
Controlla anche i permalink. Se ottieni errori 404 sulle pagine interne mentre la home page funziona, salva nuovamente la struttura dei permalink dal pannello WordPress. Su server Apache verifica il file `.htaccess`; su Nginx devono essere presenti regole di riscrittura equivalenti nella configurazione del virtual host.
Infine, svuota la cache del plugin, del server e dell'eventuale CDN. Una cache vecchia può mostrare asset del vecchio hosting, pagine non aggiornate o errori ormai risolti. Attiva HTTPS sul nuovo server e verifica che non compaiano avvisi di contenuti misti per immagini, script o fogli di stile richiamati ancora in HTTP.
Aggiornare DNS e controllare la propagazione
Quando il sito replica funzionalità e contenuti del vecchio ambiente, aggiorna il record A del dominio verso il nuovo indirizzo IP oppure modifica i nameserver secondo la configurazione scelta. Se il dominio usa record MX esterni o servizi email dedicati, non sovrascrivere la zona DNS senza prima aver copiato tutti i record necessari.
La propagazione DNS può richiedere tempo. In pratica, alcuni visitatori potrebbero raggiungere il nuovo server subito, mentre altri continueranno temporaneamente a vedere quello precedente. Per questo il vecchio hosting non va disdetto il giorno stesso della migrazione. Mantienilo attivo per alcuni giorni, controlla log e richieste ricevute e verifica che non ci siano contenuti mancanti.
Se hai abbassato il TTL dei record DNS prima del passaggio, il cambio può risultare più rapido. Non è una garanzia assoluta, ma aiuta a ridurre la durata della cache presso molti resolver.
Gli errori più comuni da evitare
Il primo errore è cancellare il vecchio spazio prima dei controlli. Il secondo è dimenticare il database: copiare i file senza importare il SQL produce un sito apparentemente completo ma privo di contenuti e configurazioni. Il terzo è ignorare email e DNS, con il risultato di ricevere messaggi non consegnati anche se il sito è online.
Evita inoltre di aggiornare WordPress, tema e plugin durante la migrazione, salvo necessità. Spostamento e aggiornamento sono due interventi distinti: eseguirli insieme rende più difficile capire l'origine di un eventuale problema. Prima trasferisci una versione stabile, poi pianifica gli aggiornamenti con backup e test dedicati.
Un ambiente scalabile permette di iniziare con un hosting adeguato e passare a risorse cloud o dedicate quando traffico, database e processi applicativi lo richiedono. Con un'infrastruttura completa, come quella proposta da CoolNetwork, puoi mantenere dominio, hosting e protezione dei dati sotto un unico interlocutore, semplificando anche le prossime migrazioni.
La migrazione non termina quando il dominio risponde al nuovo IP: termina quando utenti, moduli, pagamenti, email e backup funzionano come previsto. Dedica qualche ora ai controlli finali: è il modo più semplice per trasformare un cambio server in un miglioramento reale del servizio.