10 controlli prima di disattivare il vecchio hosting dopo una migrazione

Il sito è stato spostato, il nuovo hosting risponde, e ora arriva la domanda che nessuno vuole sbagliare: quando si può spegnere il vecchio server senza lasciare qualcuno fuori — un cliente, un motore di ricerca, un cron job dimenticato. Spegnere troppo presto costa email perse e pagine 404 per mesi. Tenere acceso troppo a lungo costa solo canone mensile, ma prima o poi va chiuso. Ecco la checklist da seguire in ordine, oggi 1 novembre 2026.

1. DNS: non guardare solo se risolve, guarda il TTL

Non basta che dig dominio.it +short restituisca il nuovo IP sulla propria macchina: bisogna sapere quanto tempo resta prima che tutti i resolver del mondo abbiano scartato il vecchio. Per controllare il TTL di un record esistente si usa dig: dig dominio.it A +noall +answer, dove il numero restituito è il TTL residuo in secondi. Su Windows la stessa informazione si ottiene con nslookup usando l'opzione -debug per vedere l'output verboso che contiene i valori di TTL. Finché quel numero non è sceso al valore basso impostato prima del trasloco (idealmente 300 secondi o meno, abbassato qualche giorno prima della migrazione), qualche resolver nel mondo sta ancora servendo il vecchio IP.

2. Email: controlla i log del vecchio MX, non solo la casella

Se i record MX puntano ancora al vecchio server, le email arrivano lì. Verificare con dig dominio.it MX +short e confrontare l'IP di destinazione.

3. Certificato SSL valido sul nuovo server

Controllare scadenza e catena con openssl s_client -connect dominio.it:443 -servername dominio.it.

4. Redirect 301 attivi e funzionanti

Testare con curl -I https://dominio.it/pagina e verificare lo status code e l'header Location.

5. Search Console senza errori di scansione nuovi

Nella sezione Pagine della proprietà nuova vanno controllati gli errori 404, 5xx e di reindirizzamento: le informazioni sugli errori di scansione e gli avvisi si trovano nella sezione Pagine di Google Search Console, e in alcuni casi, come un errore 404 o 5xx, Google non è stato in grado di eseguire la scansione e probabilmente rimuoverà la pagina dai risultati.

6. Cron job e backup riattivati sul nuovo ambiente

Verificare con crontab -l che i job non girino ancora sul vecchio server in parallelo, generando dati su due database diversi.

7. Form di contatto testati end-to-end

Non basta l'invio: va verificato che la mail arrivi davvero, non finisca in spam per via dell'SPF non aggiornato.

8. CDN ripuntata al nuovo origin

Controllare la configurazione dell'origin server nel pannello della CDN, non solo il CNAME pubblico.

9. Sitemap aggiornata e inviata

File sitemap.xml rigenerato con gli URL correnti e reinviato da Search Console.

10. Log del vecchio server: l'ultimo controllo prima di spegnere

È il punto che decide davvero. Analizzare gli access log del vecchio hosting per 7-14 giorni consecutivi: se compaiono ancora richieste con user-agent reali (non solo bot), il DNS non è ancora completamente propagato per qualcuno.

Un'opzione in più per i cambi di dominio

Se la migrazione ha comportato anche un cambio di dominio, lo strumento Cambio di indirizzo in Search Console indica a Google di accentuare la scansione del nuovo sito abbandonando il vecchio, inoltra i segnali e suggerisce il nuovo sito come canonico, azioni eseguite nei 180 giorni successivi all'avvio della migrazione. Attenzione a non disattivare troppo presto i redirect: rimuovere le istruzioni di reindirizzamento 301 dal server prima del tempo fa sì che, alla scansione successiva, Google possa continuare a reindirizzare secondo le vecchie istruzioni, oppure perdere il collegamento tra i due siti. Solo quando tutti e dieci i punti sono verificati, e i log del vecchio hosting non mostrano più traffico umano, lo spegnimento è sicuro.