Cosa salvare prima della migrazione di un sito: l'elenco completo

Prima di una migrazione si pensa a fare il backup del database. È necessario, ma non basta: una migrazione riuscita deve poter tornare indietro se la messa online va male, confrontare il nuovo sito con il vecchio e sapere con precisione cosa conteneva il vecchio sito, compreso ciò che nessuno guarda più.

Questa pagina è la lista di controllo di ciò che va messo da parte, durante la fase di preparazione della migrazione. Ogni voce rimanda, quando esiste, alla procedura dettagliata.

Un backup prima della migrazione serve a tre cose:

• tornare indietro: se la nuova versione ha un problema grave il giorno della messa online, bisogna poter rimettere in servizio la vecchia, con i suoi file, il suo database e la sua configurazione;
• confrontare: i dati di traffico e di visibilità precedenti alla migrazione sono il riferimento che dirà, tra tre mesi, se la migrazione è costata visite;
• non dimenticare nulla: le vecchie URL, i redirect già attivi e i metadati di ogni pagina sono la materia prima del piano di redirect. Una volta spento il vecchio sito, non si possono più raccogliere.

Il codice, il tema, i plugin o moduli e soprattutto i media: immagini, video, documenti scaricabili (in WordPress, la cartella wp-content). Copiateli con un client SFTP o chiedete al vostro hosting un archivio completo. I media contano doppio: sono spesso indicizzati in Google Immagini e citati da altri siti, e i loro indirizzi andranno reindirizzati se cambiano (vedi il redirect delle immagini).

Pagine, articoli, prodotti, account, ordini, impostazioni: in un sito dinamico quasi tutto è nel database. Un'esportazione SQL (con phpMyAdmin o mysqldump) contiene solo il database: va conservata insieme alla copia dei file, e le due formano il backup completo. I metodi (manuale, pannello di amministrazione, cloud, rsync, servizi automatizzati) sono descritti nel nostro articolo sul backup del database.

Ciò che non si trova né nei file del CMS né nel database, e di cui ci si accorge dopo:

• il file .htaccess o la configurazione nginx, con i redirect già attivi. Vanno ripresi nel nuovo piano e aggiornati perché puntino direttamente ai nuovi indirizzi: altrimenti una vecchia URL reindirizzata nel 2019 si ritrova in fondo a una catena di due o tre redirect;
• i redirect gestiti da un plugin (come Redirection su WordPress) o nell'amministrazione del CMS, che vivono nel database e scompaiono con esso;
• il robots.txt e le sitemap XML, per confrontare ciò che veniva proposto a Google prima e dopo;
• le attività pianificate (cron), le regole di cache e la zona DNS del dominio (record A, CNAME, MX della posta, TXT di verifica), da annotare prima di qualsiasi cambio di hosting.

Il database contiene i testi, ma è utile conservare anche una fotografia di ciò che è davvero online: un crawl completo del vecchio sito, con per ogni URL il codice di risposta, il title, la meta description, il tag canonical e i link interni. Questo rilievo permette di verificare, dopo la migrazione, che nessun metadato sia andato perso. È il tema del nostro articolo sulla migrazione dei contenuti editoriali.

Lo storico di Google Analytics 4 e di Google Search Console non si migra: si conserva e si esporta. Search Console conserva solo 16 mesi di dati, e Google Analytics 4 cancella il dettaglio degli eventi oltre il periodo di conservazione scelto. Le esportazioni da fare, e le impostazioni da verificare, sono nel nostro articolo per salvare i dati di Google Analytics 4 e Search Console.

Una migrazione si blocca più spesso per un accesso perso che per una difficoltà tecnica. Fate l'elenco, con il loro titolare, degli accessi all'hosting, al registrar del dominio e alla zona DNS, all'amministrazione del CMS, a Search Console, a Google Analytics, a Google Tag Manager e ai servizi collegati al sito (pagamento, corrieri, CRM, strumento di invio email). Verificate che ogni account appartenga all'azienda e non a un ex fornitore o dipendente. Conservate questi accessi in un gestore di password, mai in un documento condiviso in chiaro.

Un backup conservato sul server che si sta per lasciare non è un backup. Applicate la regola 3-2-1: tre copie, su due supporti diversi, di cui una fuori dal server e dalla sede. Datate ogni backup e annotatelo nel registro della migrazione.

Conservateli oltre la messa online, finché il nuovo sito non si è stabilizzato e il traffico non è tornato al suo livello: diversi mesi, non pochi giorni. Serviranno anche a ritrovare una pagina o un redirect dimenticato.

Un backup mai ripristinato è una scommessa. Prima della migrazione, ripristinatelo almeno una volta in un ambiente di test: il sito deve essere visualizzato, il database deve rispondere e i media devono esserci. È anche il modo migliore per cronometrare un eventuale ritorno indietro, e quindi per decidere fino a quando resta possibile il giorno del passaggio.

• Il backup del database
• Salvare i dati di Google Analytics 4 e Search Console
• La migrazione dei dati in un restyling
• La checklist di una migrazione SEO
• Il piano di redirect