Migrare un sito WordPress: checklist per ridurre il fermo

Una migrazione WordPress fatta bene è una sequenza di passaggi verificabili, ordinati in modo che il cambio DNS diventi quasi una formalità. Nessuna migrazione è del tutto priva di interruzione, ma con l'ordine giusto la finestra critica si accorcia e, soprattutto, resta reversibile. La checklist vale per un sito vetrina come per un WooCommerce.

Inventario: cosa stai spostando davvero

Quasi tutti i problemi dopo una migrazione nascono da qualcosa che nessuno aveva annotato. Prima di copiare un solo file, metti per iscritto:

• Versioni di WordPress, PHP (con le estensioni usate) e MySQL/MariaDB. Oggi WordPress raccomanda PHP 8.3 o superiore e MySQL 8.0 o MariaDB 10.11 o superiori.
• Dimensioni: spazio dei file, peso del database e numero di file (inode), limitato su alcuni piani condivisi.
• Regole in .htaccess e php.ini o .user.ini personalizzati. Passando a Nginx, le regole di .htaccess vanno riscritte, perché Nginx non le legge.
• Operazioni pianificate: cron di sistema, WP-Cron, script di backup ed esportazioni verso gestionali.
• Zona DNS completa: A/AAAA, CNAME, MX, TXT di SPF, DKIM e DMARC, verifiche di servizi esterni.
• Posta: caselle, inoltri e tutto ciò che invia email dal sito (moduli, notifiche d'ordine).
• Integrazioni che autorizzano per indirizzo IP: gateway di pagamento, API dei corrieri, relay SMTP.
• Accessi a registrar, DNS, vecchio e nuovo hosting, e data di rinnovo del vecchio piano: non deve scadere a metà lavoro.

Abbassare il TTL DNS con anticipo

Il TTL (time to live) è il numero di secondi per cui un resolver può tenere in cache un record prima di richiederlo (RFC 1035, chiarito dalla RFC 2181). Se il record A del sito ha TTL 86400, dopo il cambio una parte dei visitatori può continuare a raggiungere il vecchio server per un giorno intero.

Abbassa il TTL dei record che cambierai (A, AAAA, www) a un valore breve, per esempio 300 secondi, con un anticipo almeno pari al TTL attuale: il valore vecchio deve prima scadere dalle cache. Google, nella guida al cambio di hosting senza modifica degli URL, suggerisce di farlo almeno una settimana prima. A migrazione stabile, riportalo a un valore normale. Non tutte le cache rispettano il TTL alla lettera: qualche visitatore può restare sul vecchio server un po' più a lungo.

Copiare file e database

Le strade principali sono tre; la scelta dipende da dimensioni del sito, accessi disponibili e controllo desiderato.

Con l'approccio manuale, dal vecchio server:

# Dump coerente del database (tabelle InnoDB)
mysqldump --single-transaction -u utente_db -p nome_db > ~/migrazione/sito.sql

# Copia dei file verso il nuovo server
rsync -avz ~/public_html/ utente@203.0.113.10:public_html/

Secondo la documentazione di MySQL, --single-transaction produce un'istantanea coerente solo delle tabelle InnoDB: eventuali tabelle MyISAM vanno convertite prima, oppure il sito va messo in sola lettura durante il dump. Sul nuovo server importa il file e aggiorna wp-config.php con le credenziali del nuovo database.

Search-replace degli URL senza rompere i dati serializzati

Se il dominio resta lo stesso, il database non va toccato. Il search-replace serve quando cambia l'indirizzo: da staging al dominio definitivo, da http a https, da www a senza www. Mai un trova-e-sostituisci testuale sul file SQL: WordPress e i plugin salvano molte opzioni in formato PHP serializzato, che registra la lunghezza delle stringhe. Se la lunghezza non torna, il valore non viene più letto e widget o impostazioni spariscono.

WP-CLI gestisce i dati serializzati. Fai sempre prima una prova a vuoto:

wp search-replace 'https://staging.esempio.it' 'https://www.esempio.it' \
  --skip-columns=guid --dry-run
# se il report è quello atteso, ripeti senza --dry-run
wp cache flush

Testare il nuovo server prima del cambio DNS

Il test più affidabile è vedere il sito vero, sul dominio vero, servito dal nuovo server mentre il resto del mondo vede ancora quello vecchio. Basta il file hosts del tuo computer (C:\Windows\System32\drivers\etc\hosts su Windows, /etc/hosts su macOS e Linux, con permessi di amministratore): aggiungi l'IP del nuovo server e il dominio, poi svuota la cache DNS o riavvia il browser.

203.0.113.10  esempio.it www.esempio.it

Da terminale, curl forza la risoluzione senza toccare il sistema; finché manca un certificato valido, -k ignora l'errore TLS, solo in questo test:

curl -skI --resolve www.esempio.it:443:203.0.113.10 https://www.esempio.it/

• Home, pagine chiave, articoli e ricerca interna.
• Accesso all'amministrazione e salvataggio di una bozza.
• Moduli di contatto: l'email arriva davvero?
• Carrello e checkout con il gateway di pagamento in modalità test.
• Permalink: se le pagine interne danno 404, salva di nuovo le impostazioni dei permalink o esegui wp rewrite flush.
• Log degli errori PHP del nuovo server, durante e dopo la navigazione.

Se lo staging aveva attiva l'opzione “Scoraggia i motori di ricerca dall'effettuare l'indicizzazione di questo sito”, disattivala: anche Google raccomanda di rimuovere disallow in robots.txt e noindex prima di aggiornare i DNS.

Posta e certificati: dove si inciampa

Posta e record MX

Se la posta è su un servizio esterno (Google Workspace, Microsoft 365) non c'è niente da spostare: se cambi provider DNS, ricopia identici MX, SPF, DKIM e DMARC. Se le caselle stanno sul vecchio hosting, sono una migrazione a sé. Attenzione: in molti hosting condivisi mail.esempio.it punta allo stesso IP del sito, e cambiando quel record sposti anche la posta.

Se il server di destinazione è irraggiungibile per un po', la posta non si perde subito: secondo la RFC 5321 chi invia ritenta a intervalli di almeno 30 minuti e, di norma, insiste almeno 4-5 giorni. Il rischio vero sono i messaggi consegnati al vecchio server dopo la copia delle caselle: tienile attive qualche giorno e fai una seconda sincronizzazione IMAP dopo il cambio.

Se il sito invia email, aggiungi il nuovo IP al record SPF oppure fai spedire WordPress tramite un relay SMTP autenticato: altrimenti le notifiche finiscono in spam o vengono rifiutate da chi applica DMARC.

Certificati SSL

Let's Encrypt e molti altri sistemi automatici convalidano il dominio con la sfida HTTP-01, sulla porta 80 del server a cui il dominio punta in quel momento: prima del cambio DNS il nuovo server non può superarla. Le alternative: la sfida DNS-01 (un record TXT su _acme-challenge), copiare certificato e chiave privata dal vecchio server, oppure accettare qualche minuto senza certificato valido dopo il cambio.

Cutover e piano di ritorno

Se il lavoro preparatorio è fatto, il giorno del cambio è breve. In ordine:

1. Verifica che il TTL basso sia attivo da almeno quanto valeva il vecchio TTL.
2. Se il sito scrive dati, metti il vecchio in manutenzione e fai l'ultima copia del database e dei file caricati nel frattempo.
3. Togli la riga dal file hosts, così vedi quello che vedono tutti.
4. Aggiorna i record A/AAAA verso il nuovo server (e gli MX, se sposti anche la posta).
5. Interroga i nameserver autoritativi e qualche resolver pubblico; tieni d'occhio i log di entrambi i server.
6. Ripeti il giro di test della sezione precedente sul dominio pubblico.

Il piano di ritorno si decide prima, non durante. Se un problema grave non si risolve in tempi accettabili, riporti il record A sul vecchio server: con il TTL ancora basso l'effetto è rapido. Per questo il vecchio hosting resta attivo e intatto, e non si disdice il giorno stesso. Fissa una soglia (per esempio: checkout bloccato dopo 30 minuti di tentativi) e chi decide. I dati scritti nel frattempo sul nuovo server, come gli ordini, andranno riportati a mano.

Verifiche dopo la migrazione

• HTTPS valido su tutte le varianti (con e senza www) e redirect da http a https.
• Nessun contenuto misto: immagini o script caricati ancora in http o da un vecchio indirizzo.
• Cron: WP-Cron funziona oppure, se usi DISABLE_WP_CRON, il cron di sistema è stato ricreato.
• Backup automatici attivi sul nuovo server, con un primo ripristino di prova già fatto.
• Email inviate da moduli e ordini: arrivano e superano SPF, DKIM e DMARC.
• Search Console senza picchi di errori di scansione; secondo Google un calo temporaneo della frequenza di scansione subito dopo il cambio è normale.
• Log del vecchio server: quando il traffico arriva a zero, puoi dismetterlo.
• TTL riportato a un valore normale.

Se preferisci affidare questi passaggi a qualcun altro, la nostra migrazione assistita segue questa stessa checklist, con prova su staging e piano di ritorno concordato.