Guida completa alla migrazione di un sito WordPress senza downtime

Migrare un sito WordPress significa spostarlo su un altro hosting, su un altro dominio o su entrambi, e farlo in modo che chi lo visita non se ne accorga. Il downtime zero non è un dettaglio da perfezionisti: un sito irraggiungibile anche solo per venti minuti perde ordini, contatti e — se la finestra capita mentre Googlebot sta scansionando — anche fiducia lato indicizzazione.

Questa guida è la procedura completa che uso sui progetti dei clienti: cosa preparare prima, come si sposta il sito a mano e come si sposta con un plugin, che cosa si rompe sempre subito dopo, e soprattutto come si gestisce il cutover in modo che il sito non risulti mai offline. È scritta per il caso più comune — un sito WordPress autonomo che cambia server, dominio o tutti e due.

Una precisazione sul perimetro, perché i due casi si confondono spesso. Se il sito da spostare è uno dei siti di una rete multisito, prima del trasloco c’è un lavoro diverso e più delicato — separare le sue tabelle da quelle della rete, ricostruire i ruoli, rimettere a posto i percorsi dei media — che ho raccolto nella guida dedicata all’estrazione di un sottosito. Fatta quella, il passaggio in produzione è esattamente quello descritto qui.

Una nota sulle fonti. I nomi dei plugin, i comandi WP-CLI, le costanti di configurazione e gli avvertimenti sul database citati qui li ho verificati uno per uno il 1º settembre 2026 sulla documentazione ufficiale di WordPress, su quella di WP-CLI e sulle schede dei singoli plugin nel repository. Dove un’affermazione dipende da una versione o da un prodotto, accanto trovi il link alla fonte.

Una versione precedente di questo articolo conteneva alcune indicazioni non più corrette, tutte sistemate qui sotto. Il link al sito di Duplicator puntava per errore a un indirizzo diverso da quello mostrato; gli strumenti di monitoraggio «Better Uptime» e «Logtail» sono confluiti nel 2023 in Better Stack e non esistono più con quei nomi; «BackupBuddy» oggi si chiama Solid Backups ed è in transizione verso il marchio Kadence; il plugin gratuito di WP Engine indicato come «WP Migrate DB» si chiama oggi WP Migrate Lite; «WP Maintenance Mode» è stato rinominato LightStart, e il link puntava per giunta a un plugin omonimo ma diverso. Era inoltre attribuito ad All-in-One WP Migration un limite di 512 MB che in realtà dipende dalla configurazione del server, non dal plugin.

Perché si migra un sito WordPress

Le ragioni sono poche e vale la pena riconoscere la propria, perché determinano quanto lavoro serve davvero. Una migrazione che cambia solo server è un’operazione diversa da una che cambia anche dominio: la prima non tocca gli URL, la seconda li tocca tutti.

• Cambio di hosting, stesso dominio. Il caso più frequente e il più semplice: gli URL restano identici, il database non va riscritto, l’unica cosa che cambia è dove punta il DNS. Il rischio si concentra tutto nel cutover.
• Cambio di dominio, stesso server. Qui non si sposta un solo file, ma va riscritto ogni riferimento all’indirizzo vecchio dentro il database — ed è la parte in cui i siti si rompono. Serve anche una mappa completa dei redirect 301.
• Cambio di entrambi. È la somma dei due, e conviene affrontarla in due tempi: prima si sposta il sito lasciando il dominio invariato, si verifica che funzioni, poi si cambia dominio. Un problema alla volta è molto più veloce da diagnosticare di due insieme.
• Passaggio da HTTP a HTTPS. Tecnicamente è un cambio di dominio, perché http:// e https:// sono due origini diverse per il browser e per Google. Vale tutto quello che si legge più avanti sugli URL nel database.
• Riorganizzazione infrastrutturale. Da condiviso a VPS, introduzione di una CDN, containerizzazione. Se stai anche cambiando il tipo di hosting, la parte di configurazione la trovo spiegata in dettaglio nella guida su hosting condiviso, VPS e primo setup.

C’è un caso in cui conviene fermarsi prima di partire: se stai migrando perché il sito è lento, cambiare server risolve il problema solo se il collo di bottiglia è davvero il server. Nella maggior parte dei siti che ho visto non lo è, ed è molto più economico verificare prima da cosa dipende la lentezza che pagare un hosting migliore per scoprire che il problema si è trasferito insieme al sito.

Preparazione: backup e ambiente di staging

È la fase che decide se la migrazione sarà noiosa o drammatica. Saltarla non fa risparmiare tempo: sposta soltanto il tempo più avanti, nel punto in cui costa di più.

1. Un backup che sia davvero completo

Un backup utile a una migrazione contiene due cose, e devono essere coerenti fra loro, cioè fotografate nello stesso momento:

• I file. L’intera directory di installazione: wp-content con temi, plugin e soprattutto uploads, più wp-config.php, .htaccess e i file di core. La cartella uploads è quella che non si può ricostruire: temi e plugin si reinstallano, i media caricati in cinque anni no.
• Il database. È dove stanno contenuti, utenti, impostazioni e opzioni. Un dump parziale produce un sito che si apre e che ha perso qualcosa, ed è la situazione peggiore perché non è evidente subito.

Se hai accesso SSH, il modo più affidabile di prendere il database è WP-CLI, perché esporta l’installazione così com’è vista da WordPress e non dipende dai timeout dell’interfaccia web:

# Dump del database nella cartella corrente
wp db export backup-pre-migrazione.sql

# Archivio dei file, escludendo la cache che non serve a destinazione
tar --exclude='wp-content/cache' -czf backup-pre-migrazione.tar.gz .

Se invece lavori dal pannello, i plugin che uso più spesso sono UpdraftPlus, che archivia su storage esterni ed è quello con la barriera d’ingresso più bassa, e BlogVault, che fa backup incrementali e include lo staging — utile proprio quando si sta per migrare. Nota sui nomi: il vecchio BackupBuddy esiste ancora ma si chiama Solid Backups, è passato sotto Nexcess e sta migrando al marchio Kadence; la versione storica è oggi etichettata come legacy, quindi se lo trovi consigliato con il nome vecchio stai leggendo una guida datata.

Un backup automatizzato e depositato fuori dal server è comunque la cosa giusta da avere anche fuori dalle migrazioni: la procedura completa, con ripristino verificato, è nella guida su come automatizzare il backup WordPress su S3 con WP-CLI.

La regola che vale più di tutte: un backup non provato non è un backup. Prima di toccare qualsiasi cosa, ripristinalo da qualche parte e apri il sito. È l’unico modo di sapere che funziona, e si scopre in dieci minuti invece che nel momento peggiore.

2. Alleggerire prima di spostare

Migrare è l’occasione naturale per non portarsi dietro la zavorra: revisioni dei post accumulate per anni, transient scaduti, tabelle lasciate da plugin disinstallati, media mai usati. Su un sito trascurato questa roba può valere metà del peso del database, e il peso del database è esattamente ciò che fa fallire le migrazioni con plugin e allunga il cutover. Il modo sicuro di farlo — cioè senza rompere niente — è quello che ho descritto in come ripulire un sito WordPress senza romperlo.

Stesso discorso per gli aggiornamenti: conviene arrivare alla migrazione con core, temi e plugin già allineati, perché un sito aggiornato è più probabile che funzioni su uno stack più recente. Ma vanno fatti prima e su staging, mai insieme allo spostamento: se qualcosa si rompe, devi poter sapere quale delle due operazioni l’ha rotto. La sequenza sicura è in cosa fare prima e dopo ogni aggiornamento importante.

3. L’ambiente di staging

Lo staging è una copia funzionante del sito sul nuovo server, raggiungibile a un indirizzo temporaneo. Serve a fare tutta la migrazione, verificarla con calma e solo alla fine spostare il traffico. È il motivo per cui il downtime può essere zero: quando cambi il DNS, il sito nuovo è già in piedi e già collaudato.

• Con hosting che lo offre. Provider come Kinsta, SiteGround o WP Engine creano uno staging con un clic. È la strada più rapida quando la destinazione è uno di loro.
• A mano. Un sottodominio dedicato (staging.tuosito.it) sul nuovo server, oppure l’accesso al nuovo server tramite il file hosts del tuo computer — la tecnica migliore, perché ti permette di vedere il sito nuovo al dominio definitivo mentre per tutti gli altri è ancora online il vecchio. Ne parlo più avanti, nella sezione sul cutover.

Qualunque strada scegli, lo staging va tenuto fuori dagli indici: protezione con password a livello di server, che è l’unico metodo che funziona davvero. Il flag «Scoraggia i motori di ricerca» di WordPress è solo una richiesta, e una copia del sito indicizzata in parallelo è un problema di contenuti duplicati che poi va risolto a mano.

Manuale o con un plugin: come scegliere

Non c’è una risposta valida sempre. C’è un criterio: la dimensione del sito e quanto è raggiungibile il server di partenza.

La differenza sostanziale è dove avviene il lavoro. Un plugin di migrazione deve comprimere l’intero sito dentro PHP, e quindi sbatte contro i limiti di memoria e di tempo di esecuzione del server: è il motivo per cui su siti grandi falliscono a metà. La via manuale non ha questo vincolo perché usa strumenti di sistema, ma richiede di sapere cosa si sta facendo con FTP, database e configurazione.

Migrazione manuale: la procedura completa

1. Portare via i file

Con un client FTP come FileZilla, o dal file manager del pannello, scarica l’intera directory di installazione. Se hai SSH, rsync è molto più veloce e soprattutto riprende da dove si è interrotto, cosa che su una cartella uploads da qualche gigabyte fa la differenza fra un pomeriggio e cinque minuti:

# Da eseguire COLLEGATI AL VECCHIO SERVER:
# rsync non trasferisce fra due host remoti, uno dei due capi deve essere locale.
rsync -avz --progress \
  --exclude 'wp-content/cache' \
  /percorso/del/sito/ \
  utente@nuovo-server:/percorso/di/destinazione/

Mantieni intatta la struttura delle cartelle. I permessi corretti a destinazione sono 755 per le directory e 644 per i file; wp-config.php può stare a 640 o anche 600, perché deve leggerlo solo il processo web.

2. Esportare il database

Da phpMyAdmin: seleziona il database, scheda Esporta, metodo rapido, formato SQL. Da riga di comando è più affidabile perché non passa dal browser:

# Con WP-CLI (legge le credenziali da wp-config.php)
wp db export dump.sql

# Oppure direttamente con mysqldump
mysqldump -u UTENTE -p --default-character-set=utf8mb4 NOME_DB > dump.sql

L’opzione --default-character-set=utf8mb4 non è un vezzo: è la codifica che WordPress usa dalla versione 4.2 e che serve a far sopravvivere emoji e caratteri speciali. Un dump preso in utf8 semplice li corrompe silenziosamente, e te ne accorgi settimane dopo guardando un vecchio articolo.

3. Caricare tutto sul nuovo server

Carica i file nella document root del nuovo hosting (public_html, httpdocs o quello che usa il tuo pannello), poi crea il database e importa il dump:

# Creazione del database con la collation corretta
mysql -u root -p -e "CREATE DATABASE nuovo_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

# Import del dump
mysql -u UTENTE -p --default-character-set=utf8mb4 nuovo_db < dump.sql

4. Aggiornare wp-config.php

Le quattro righe da allineare ai dati del nuovo database sono queste:

define( 'DB_NAME', 'nuovo_nome_database' );
define( 'DB_USER', 'nuovo_utente' );
define( 'DB_PASSWORD', 'nuova_password' );
define( 'DB_HOST', 'localhost' ); // o l'host indicato dal provider

Se stai cambiando server è il momento buono per rileggere il resto del file invece di fermarti al database: chiavi di sicurezza, prefisso delle tabelle, WP_DEBUG e l’editor di file dal backend sono tutti configurati lì, e su un’installazione ereditata sono spesso rimasti ai valori di partenza. Ho messo in fila cosa controllare in wp-config.php e le righe che contano.

Una scorciatoia utile mentre collaudi, che però va conosciuta per quello che è. Le costanti WP_HOME e WP_SITEURL forzano l’indirizzo del sito senza toccare il database:

define( 'WP_HOME', 'https://staging.tuosito.it' );
define( 'WP_SITEURL', 'https://staging.tuosito.it' );

La documentazione ufficiale è esplicita sul limite: impostare WP_SITEURL «sovrascrive il valore della tabella wp_options ma non lo modifica nel database», e l’indirizzo torna quello vecchio non appena togli la riga. Vanno benissimo per collaudare lo staging, non sono un modo di cambiare dominio: quello si fa nel database, ed è il punto successivo.

5. Aggiornare gli URL: la parte che rompe i siti

Questo passaggio serve solo se stai cambiando dominio (o passando da HTTP a HTTPS). Se il dominio resta lo stesso, saltalo: non c’è niente da riscrivere. Ed è bene saperlo, perché è di gran lunga il punto in cui si fanno più danni.

Il motivo è che WordPress non salva soltanto stringhe semplici. Molti temi, plugin e widget salvano le proprie impostazioni come array PHP serializzati, e in un dato serializzato ogni stringa è preceduta dalla sua lunghezza in byte: s:29:"https://vecchiodominio.it/logo". Se sostituisci il dominio con uno più lungo o più corto senza aggiornare quel numero, il valore diventa illeggibile e WordPress lo scarta in silenzio: sparisce la configurazione del tema, si svuotano i widget, i campi personalizzati smettono di restituire valori. Il sito si apre, ed è mezzo vuoto.

È un rischio documentato da WordPress stesso, che avverte: «se fai una ricerca e sostituzione sull’intero database per cambiare gli URL, puoi causare problemi con la serializzazione dei dati», proprio perché alcuni temi e widget memorizzano i valori insieme alla lunghezza dell’URL.

Da qui discende la regola pratica: non si cambia dominio con un UPDATE ... REPLACE() sull’intero database. Servono strumenti che deserializzano il dato, sostituiscono e riserializzano ricalcolando le lunghezze.

Il migliore è WP-CLI, che gestisce in modo intelligente i dati serializzati e permette di simulare tutto prima di scrivere:

# 1. Simulazione: mostra cosa cambierebbe, senza toccare nulla
wp search-replace 'https://vecchiodominio.it' 'https://nuovodominio.it' \
  --all-tables --precise --skip-columns=guid --dry-run

# 2. Se il report è quello atteso, si esegue davvero
wp search-replace 'https://vecchiodominio.it' 'https://nuovodominio.it' \
  --all-tables --precise --skip-columns=guid --report-changed-only

Le opzioni contano tutte. --dry-run «esegue l’intera operazione e mostra il report, ma non salva le modifiche»: si lancia sempre per primo. --precise forza l’uso di PHP invece di SQL, «più accurato ma più lento» — ed è quello che garantisce il trattamento corretto dei dati serializzati. --all-tables estende la sostituzione anche alle tabelle create dai plugin, che altrimenti resterebbero indietro.

--skip-columns=guid merita una riga a parte. Il campo guid è l’identificatore che i lettori di feed usano per capire se un post l’hanno già visto. La documentazione di WordPress su questo non lascia margini: «non modificare mai, in nessuna circostanza, il contenuto della colonna GUID». Riscriverlo durante una migrazione fa ricomparire l’intero archivio come nuovo nei feed reader e nelle integrazioni che si appoggiano a quel valore. Non è un URL da aggiornare: è un identificatore che somiglia a un URL.

Se non hai accesso SSH, l’equivalente dal pannello è Better Search Replace, che fa lo stesso lavoro sui dati serializzati e ha una modalità di prova. Anche lì escludi la colonna guid e fai prima il giro a vuoto. WP Engine offre WP Migrate Lite, la versione gratuita di WP Migrate (il prodotto che fino a qualche anno fa si chiamava WP Migrate DB Pro), che esporta un dump con gli URL già sostituiti.

L’unico caso in cui una query SQL diretta è sicura è quello delle due opzioni che contengono l’URL del sito come stringa semplice, non serializzata — utile per rimettere in piedi l’accesso al backend quando il sito non si apre più:

UPDATE wp_options
SET option_value = REPLACE(option_value, 'vecchiodominio.it', 'nuovodominio.it')
WHERE option_name IN ('home', 'siteurl');

Attenzione al prefisso wp_, che nel tuo database può essere diverso. E che sia chiaro: questa query rimette in piedi l’ingresso, non completa la migrazione. Tutto il resto — contenuti, media, impostazioni — va fatto con gli strumenti di sopra.

Migrazione con un plugin: le soluzioni che funzionano

Su un sito di dimensioni normali un plugin fa tutto il lavoro in pochi minuti, sostituzione degli URL compresa. Le tre soluzioni che uso e che tengo aggiornate sono queste.

Duplicator

Il più diffuso della categoria. Crea un pacchetto che contiene file e dump del database insieme a un installer, e a destinazione ti guida nella configurazione di database, URL e permessi. La versione gratuita nel repository si chiama semplicemente Duplicator ed è sufficiente per la maggior parte dei siti; Duplicator Pro è la versione a pagamento e aggiunge backup pianificati, storage esterni come Amazon S3, Google Drive e Dropbox, e il supporto multisito.

Un limite da conoscere: nessun plugin, Duplicator Pro compreso, gestisce da solo l’estrazione di un singolo sito da una rete multisito. La parte sui prefissi delle tabelle e sui ruoli degli utenti resta manuale, ed è quella che ho descritto nella guida sull’estrazione di un sottosito da una rete multisito.

Sito ufficiale: duplicator.com.

All-in-One WP Migration and Backup

Il più semplice da usare: esporta l’intero sito in un unico file .wpress e a destinazione lo si importa trascinandolo nella dashboard. Zero configurazione, ed è la scelta giusta quando la migrazione la deve fare qualcuno che non è un tecnico.

Sul limite di dimensione va fatta chiarezza, perché in giro si legge spesso un «limite di 512 MB del plugin» che non esiste. Il tetto all’importazione lo impone il server, con i parametri PHP upload_max_filesize e post_max_size: se il tuo hosting li tiene bassi, il plugin non può farci niente. La documentazione del plugin suggerisce infatti di alzare quei valori lato server, e vende un’estensione che rimuove le restrizioni imposte dall’host. Se hai accesso al php.ini, alzare i due parametri risolve senza comprare nulla.

WPvivid Backup & Migration

Unisce backup e migrazione anche nella versione gratuita, e ha una funzione che le altre due non hanno: la migrazione remota diretta fra due siti, senza scaricare e ricaricare niente. Si installa il plugin su entrambi, si incolla una chiave e il trasferimento avviene da server a server. Su connessioni domestiche lente è la differenza fra mezz’ora e un pomeriggio. Sito ufficiale: wpvivid.com.

I limiti del server che fanno fallire le migrazioni

Quando un plugin di migrazione si blocca a metà, nove volte su dieci la causa è una di queste tre e non il plugin:

• upload_max_filesize e post_max_size troppo bassi: l’archivio viene rifiutato in fase di caricamento.
• max_execution_time troppo basso: l’esportazione viene interrotta mentre comprime.
• memory_limit insufficiente: PHP si ferma su un database grande. Sotto i 256 MB su un sito medio si fa fatica.

Vanno verificati sul server di destinazione, non solo su quello di partenza. E se il nuovo hosting ha una versione di PHP o di MySQL diversa, è il caso di aprire il sito su staging e guardare i log prima di spostare il traffico: una funzione deprecata che non dava fastidio su PHP 8.1 può diventare un errore fatale su PHP 8.4.

Strategie per evitare il downtime

Qui sta il cuore della questione. Tutto quello di prima serve a portare il sito sul nuovo server; questo serve a spostare il traffico senza che nessuno veda una pagina di errore.

1. Abbassare il TTL del DNS, 24-48 ore prima

Il TTL dice ai resolver per quanto tempo tenere in cache l’indirizzo IP del tuo dominio. Se è impostato a 86400 secondi — 24 ore, un valore comunissimo — dopo il cambio di IP una parte dei visitatori continuerà a essere mandata sul vecchio server per un giorno intero.

Perciò, almeno 24 ore prima (meglio 48, per essere sicuri che il valore vecchio sia scaduto ovunque), porta il TTL del record A a 300 secondi. Al momento del cutover la propagazione sarà questione di minuti. Finita la migrazione, si rialza.

È il passaggio che viene dimenticato più spesso, ed è anche quello che non si può recuperare all’ultimo momento: se ci pensi il giorno stesso, il TTL vecchio è già stato distribuito e devi comunque aspettarlo.

2. Collaudare il sito nuovo al dominio definitivo

Questa è la tecnica che rende la migrazione davvero invisibile, ed è sottoutilizzata. Modificando il file hosts del tuo computer puoi far risolvere il dominio definitivo verso il nuovo IP solo per te, mentre per tutto il resto del mondo continua a rispondere il vecchio server.

# macOS e Linux: /etc/hosts
# Windows: C:\Windows\System32\drivers\etc\hosts

203.0.113.42    tuosito.it www.tuosito.it

Da quel momento navighi il sito nuovo all’indirizzo vero: puoi verificare permalink, certificato, form, checkout e redirect nelle condizioni definitive, senza URL di staging che falsano il comportamento di plugin e cache. Quando tutto funziona, il cambio di DNS è l’ultima cosa che resta da fare — e a quel punto è una formalità, perché quello che gli utenti vedranno lo hai già visto tu.

3. Il cutover, passo per passo

L’ordine delle operazioni è quello che minimizza la finestra in cui i due ambienti divergono:

1. Congela le scritture sul sito vecchio. Sospendi commenti, registrazioni e — se è un e-commerce — gli ordini. È la finestra in cui i dati non devono cambiare da due parti insieme.
2. Esporta il database aggiornato dal vecchio server e importalo sul nuovo, sovrascrivendo quello usato in staging. I file li hai già sincronizzati: qui si allinea solo il database, che è veloce.
3. Risincronizza i media caricati dopo l’ultima copia, con un rsync incrementale: passano solo i file nuovi.
4. Cambia il record A verso il nuovo IP.
5. Tieni acceso il vecchio server per almeno 48 ore. Chi ha ancora il DNS vecchio in cache continuerà ad arrivarci, e deve trovare un sito che funziona, non un errore.

Il punto 5 è quello che distingue una migrazione fatta bene. Spegnere il vecchio server subito dopo il cambio di DNS è la causa più comune di downtime percepito in una migrazione che, sulla carta, era stata fatta a regola d’arte.

4. Sincronizzare i contenuti dell’ultimo minuto

Sui siti che ricevono dati in continuazione — e-commerce, portali con commenti, form attivi — fra la creazione dello staging e il cutover si accumulano differenze. Le strade sono tre, in ordine di eleganza:

• Migrazione differenziale con WP Migrate (il prodotto che fino a qualche anno fa si chiamava WP Migrate DB Pro), che sincronizza solo ciò che è cambiato.
• Sincronizzazione incrementale via rsync per i media e dump del solo database a ridosso del passaggio: è l’approccio che uso più spesso, perché il database è quasi sempre la parte piccola.
• Finestra di congelamento di 15-30 minuti dichiarata, con pagina di manutenzione. Meno elegante, ma su un e-commerce con ordini frequenti è la sola che garantisce di non perdere nulla.

5. Se serve una pagina di manutenzione, falla rispondere 503

Nel caso in cui una finestra di fermo sia inevitabile, il dettaglio che quasi tutti sbagliano è il codice di stato HTTP. Una pagina di manutenzione che risponde 200 dice a Google che quello è il contenuto della pagina, e se la scansione capita in quel momento il rischio è di veder finire in indice la schermata di cortesia. Il codice giusto è 503 Service Unavailable, accompagnato da Retry-After:

# Apache, in .htaccess
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !=203.0.113.7
RewriteCond %{REQUEST_URI} !^/manutenzione\.html$
RewriteRule ^ - [R=503,L]

ErrorDocument 503 /manutenzione.html
Header always set Retry-After "3600"

La prima condizione esclude il tuo IP, così tu continui a vedere il sito mentre lavori. Se preferisci un plugin, quello che conoscevi come WP Maintenance Mode oggi si chiama LightStart ed è mantenuto da Themeisle — il nome è cambiato, lo slug del repository no, ed è il motivo per cui in giro si trovano ancora guide che lo chiamano al vecchio modo.

6. Monitorare il passaggio mentre avviene

Il monitoraggio va attivato prima del cutover, non dopo: serve a sapere in tempo reale se qualcosa è andato storto, e a saperlo prima che te lo dica un cliente. Con UptimeRobot o Better Stack imposti un controllo ogni minuto sulle pagine chiave — home, una scheda prodotto, il checkout — e ricevi l’alert immediato.

Nota sui nomi, perché qui la confusione è frequente: gli strumenti che molti conoscono come Better Uptime e Logtail sono confluiti nel 2023 in un unico prodotto, Better Stack, dove sono diventati rispettivamente i moduli Uptime e Logs. Funzionano come prima, ma con quei nomi non li trovi più.

Lato applicativo, Query Monitor installato sul sito nuovo mostra subito query lente ed errori PHP introdotti dal cambio di ambiente, e i log del server (/var/log/nginx/error.log o /var/log/apache2/error.log) vanno guardati nelle prime ore, non alla prima segnalazione.

Verifiche post-migrazione

Il sito risponde al nuovo indirizzo: non vuol dire che sia finita. Questa è la lista che eseguo prima di considerare chiusa una migrazione.

• Contenuti e layout. Home, pagine principali, qualche articolo con gallerie e blocchi complessi. Le immagini rotte indicano media non arrivati o percorsi non aggiornati; un layout scomposto indica quasi sempre impostazioni del tema perse nella serializzazione.
• Menu, widget e link hardcoded. Gli URL scritti a mano nei menu, nei widget e nelle CTA non vengono aggiornati da nessuna procedura automatica. Vanno guardati uno per uno.
• Form e funzioni dinamiche. Invia un messaggio di prova da ogni form. Se il sito usa SMTP esterno, verifica che le credenziali siano valide anche dal nuovo IP: alcuni provider filtrano per indirizzo di provenienza.
• Login e ruoli. Entra come amministratore e come utente normale. Se il prefisso delle tabelle è cambiato, i permessi possono non essere riconosciuti.
• Ricerca interna. Una ricerca che non restituisce nulla è il sintomo di un import parziale del database.
• Permessi dei file. 755 per le directory, 644 per i file, proprietario corretto. Un caricamento media che fallisce è quasi sempre questo.
• Certificato HTTPS. Emesso per il dominio giusto, catena completa, nessun contenuto misto residuo.

Poi ci sono due controlli che conviene non rimandare. Il primo è la cache: sul nuovo server va riconfigurata e svuotata, e finché non lo fai stai guardando una versione che non corrisponde al sito. Se stai anche scegliendo che plugin usare, il confronto è in W3 Total Cache e WP Rocket a confronto. Il secondo è la sicurezza: un’installazione appena spostata ha spesso permessi larghi lasciati durante il trasferimento e nessuna protezione al login. La lista di quello che va rimesso a posto è nella checklist sicurezza WordPress.

Sulle prestazioni, infine, non fidarti dell’impressione: misura. PageSpeed Insights e GTmetrix danno un riferimento oggettivo da confrontare con i valori di prima, e se il nuovo server è più lento del vecchio è meglio scoprirlo subito, quando tornare indietro è ancora facile.

Considerazioni SEO durante la migrazione

Se cambia solo il server, la SEO non è a rischio: gli URL restano identici e Google non ha nulla da rielaborare. Tutto ciò che segue riguarda il cambio di dominio, dove invece il rischio è reale.

1. Non cambiare la struttura degli URL insieme al dominio

Cambiare dominio è già un’operazione che Google deve digerire. Cambiare nello stesso momento anche la struttura dei permalink significa moltiplicare le variabili e rendere impossibile capire, se il traffico cala, quale delle due cose l’ha causato.

La regola è: un cambiamento alla volta. Prima il dominio, con la struttura identica. Poi, a traffico stabilizzato, l’eventuale ristrutturazione. Quando arriva quel momento, quali parti della struttura si possono toccare e a che prezzo è una decisione da prendere prima di aprire le impostazioni, non dopo.

2. Redirect 301, uno per uno e in un salto solo

Ogni URL del vecchio dominio deve rispondere con un 301 verso il corrispondente URL nuovo. A livello di server è la soluzione più efficiente, perché non passa da PHP:

# Apache: redirect dell'intero dominio mantenendo il percorso
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?vecchiodominio\.it$ [NC]
RewriteRule ^(.*)$ https://www.nuovodominio.it/$1 [R=301,L]

# NGINX: stesso effetto
# Serve su entrambe le porte: il vecchio dominio va raggiunto
# anche in HTTPS, quindi il certificato va tenuto valido.
server {
    listen 80;
    listen 443 ssl;
    server_name vecchiodominio.it www.vecchiodominio.it;
    return 301 https://www.nuovodominio.it$request_uri;
}

Due errori da evitare. Il primo è il redirect di massa verso la home: mandare tutte le pagine vecchie sulla home del sito nuovo equivale a dichiarare che quei contenuti non esistono più, e Google le tratta come soft 404. Il secondo sono le catene: se il vecchio URL passa da HTTP a HTTPS e poi al nuovo dominio, sono due salti dove ne basta uno. Vanno scritti in modo che la destinazione sia raggiunta al primo colpo.

Se preferisci gestirli da WordPress, Redirection offre interfaccia e log dei 404, utile per intercettare gli URL dimenticati. I redirect vanno tenuti attivi almeno un anno: è il tempo che serve perché i link esterni e le cache dei motori si allineino. Come si scrive e si verifica un singolo redirect — con Rank Math, sul server o in PHP — è in come fare un redirect in WordPress.

3. Search Console: usa lo strumento Cambio di indirizzo

È il passaggio che accelera più di ogni altro il trasferimento dei segnali. In ordine: aggiungi e verifica la proprietà del nuovo dominio; assicurati che i 301 siano già attivi; poi, dalla proprietà vecchia, apri Impostazioni → Cambio di indirizzo e indica la nuova. Google userà quella dichiarazione per accelerare la sostituzione degli URL in indice.

Poi rigenera la sitemap XML dal plugin SEO e inviala sulla proprietà nuova, verificando che contenga solo URL del nuovo dominio.

4. Link interni, canonical e backlink

I link interni assoluti vengono sistemati dalla sostituzione nel database, ma vanno controllati a campione — insieme a menu, widget, campi ACF e shortcode, che sfuggono più spesso. I canonical devono puntare al nuovo dominio: se usi Rank Math o Yoast sono rigenerati in automatico, ma una scansione con Screaming Frog è il modo più rapido di averne conferma su tutto il sito. Il resto dei controlli tecnici che conviene rifare dopo un cambio di dominio è nella checklist SEO on-page.

Sui backlink, i 301 fanno già il lavoro di trasferire il valore. Vale però la pena estrarre la lista dei domini che linkano di più — da Search Console, o da strumenti come Ahrefs e Semrush — e chiedere l’aggiornamento ai più autorevoli: non risponderanno tutti, ma un link diretto vale comunque più di uno che passa da un redirect.

5. Cosa aspettarsi nelle settimane successive

Una flessione temporanea del traffico organico dopo un cambio di dominio è normale e non indica un errore: Google deve riscansionare e riassegnare i segnali. In genere il recupero avviene fra le due e le otto settimane, in funzione della dimensione del sito e della frequenza di scansione.

Il segnale a cui prestare attenzione non è il calo in sé, ma il calo accompagnato da errori: 404 in aumento nel rapporto di copertura, pagine escluse per redirect, URL nuovi che non vengono indicizzati. In quel caso c’è qualcosa da correggere e va corretto subito, non aspettando che «si sistemi da solo».

Domande frequenti

Vuoi migrare senza rischiare?

Una migrazione ben fatta è invisibile: nessuno se ne accorge, e questo è esattamente il punto. Le operazioni descritte qui sono tutte alla portata di chi ha dimestichezza con FTP, database e DNS — ma richiedono di eseguirle nell’ordine giusto e di sapere cosa controllare dopo, che è la parte in cui si concentrano quasi tutti i problemi.

Se preferisci non occupartene, o se il sito è un e-commerce dove ogni ora di disservizio ha un costo misurabile, me ne occupo io: analisi preliminare, migrazione completa senza interruzioni, verifica dei redirect e controllo delle prestazioni sul nuovo ambiente.

Guarda i servizi che possono fare al caso tuo »