Migrazione WordPress: come gestire DNS, SSL ed email senza interruzioni

Una migrazione WordPress non riguarda soltanto file e database. Il sito può essere copiato correttamente sul nuovo server e risultare comunque irraggiungibile, mostrare un errore sul certificato SSL oppure smettere di ricevere email dopo il cambio dei DNS.

Per limitare le interruzioni bisogna trattare sito, dominio, HTTPS e posta come parti dello stesso passaggio. La sequenza delle operazioni conta: prima si prepara e si verifica il nuovo ambiente, poi si modifica l’instradamento del dominio e infine si controlla che i servizi continuino a funzionare.

Questo approfondimento sviluppa gli aspetti infrastrutturali già introdotti nella guida alla migrazione WordPress senza downtime.

Cosa può interrompersi durante una migrazione WordPress

Trasferire WordPress significa spostare almeno il codice del sito, i file caricati e il database. In molti progetti, però, lo stesso dominio è collegato anche ad altri servizi che non risiedono necessariamente sul server web.

Prima di intervenire occorre distinguere:

• hosting del sito;
• gestione della zona DNS;
• registrar presso cui è registrato il dominio;
• servizio che emette o gestisce il certificato SSL;
• provider delle caselle email;
• servizi esterni che usano record DNS per verifiche o autenticazioni.

Questi ruoli possono appartenere allo stesso fornitore oppure essere distribuiti fra piattaforme diverse. Spostare il sito non implica sempre trasferire il dominio o la posta. Confondere i servizi porta facilmente a modificare più elementi del necessario.

Le conseguenze più comuni di una configurazione incompleta sono:

• il dominio continua a raggiungere il vecchio server;
• alcuni utenti vedono il nuovo sito e altri quello precedente;
• HTTPS restituisce un avviso di sicurezza;
• il sito carica risorse con URL non corretti;
• i messaggi inviati ai recapiti aziendali non arrivano;
• i moduli WordPress non consegnano le notifiche;
• record di verifica o autenticazione scompaiono dalla zona DNS.

Il primo controllo non deve quindi chiedere soltanto “dove si trova WordPress?”, ma “quali servizi dipendono dal dominio e chi li gestisce?”.

Come mappare i DNS prima di cambiare hosting WordPress

La zona DNS contiene i record che indicano dove devono essere indirizzati sito, posta e altri servizi. Prima della migrazione è utile esportare la configurazione, quando il provider lo consente, oppure documentare ogni record attivo.

L’inventario dovrebbe comprendere almeno:

• record A e AAAA associati al dominio e ai sottodomini;
• eventuali record CNAME;
• record MX utilizzati dalla posta;
• record TXT per verifiche e autenticazioni;
• configurazioni SPF, DKIM e DMARC già presenti;
• sottodomini usati da applicazioni, aree riservate o servizi esterni.

Non tutti questi record devono cambiare. Se viene spostato soltanto il sito, può essere sufficiente aggiornare l’indirizzo del server web lasciando invariato il percorso della posta. Se invece si cambiano i nameserver, la nuova zona deve essere predisposta con tutti i record necessari prima del passaggio.

La differenza è sostanziale. Modificare un record A agisce su una destinazione specifica; sostituire i nameserver delega l’intera gestione DNS a un nuovo sistema. Una zona ricreata copiando soltanto i record del sito può rendere irraggiungibili servizi che fino a quel momento funzionavano.

TTL e propagazione DNS durante la migrazione

Il TTL indica per quanto tempo una risposta DNS può essere conservata in cache. Ridurlo prima del cambio può aiutare i resolver a richiedere più rapidamente un dato aggiornato, ma non rende istantanea la propagazione e non sostituisce la preparazione del nuovo server.

La modifica del TTL deve avvenire con sufficiente anticipo perché anche il valore precedente abbia il tempo di scadere nelle cache. Inoltre, provider e resolver possono applicare comportamenti propri. Per questo non è professionale promettere un momento identico nel quale tutti gli utenti inizieranno a vedere il nuovo server.

Durante la transizione è possibile che richieste diverse raggiungano ambienti differenti. Il vecchio hosting dovrebbe restare operativo finché il passaggio non è stato verificato e le cache precedenti non rappresentano più un rischio concreto.

Prima di cambiare i DNS, il nuovo sito può essere controllato tramite un indirizzo temporaneo, un sottodominio di staging o una modifica locale del file hosts. Quest’ultima soluzione consente di associare il dominio al nuovo indirizzo soltanto sul computer usato per il test, senza modificare la risoluzione pubblica.

Preparare il certificato SSL sul nuovo server

Il certificato SSL del vecchio hosting non viene trasferito automaticamente solo perché sono stati copiati i file di WordPress. Il nuovo server deve essere configurato per rispondere al dominio tramite HTTPS con un certificato valido.

Il momento nel quale il certificato può essere emesso dipende dal provider e dal metodo di validazione. Alcuni ambienti permettono di predisporlo prima del cambio pubblico; altri richiedono che il dominio punti già al nuovo server. Questa dipendenza deve essere verificata sul servizio effettivamente utilizzato.

I controlli da eseguire comprendono:

• copertura del dominio principale e della variante con www, se usata;
• copertura degli eventuali sottodomini interessati;
• corretto reindirizzamento da HTTP a HTTPS;
• catena del certificato servita dal nuovo hosting;
• rinnovo automatico, quando previsto dalla piattaforma;
• assenza di loop fra regole HTTPS del server, CDN e WordPress.

Un certificato valido non risolve automaticamente il mixed content. Se pagine o risorse continuano a richiamare immagini, script o fogli di stile tramite HTTP, il browser può segnalarli o bloccarli. In quel caso occorre verificare URL nel database, configurazione di WordPress, cache e riferimenti inseriti nel tema o nei plugin.

Come evitare problemi alle email cambiando i DNS

Il trasferimento del sito e quello della posta sono attività separate. Se le caselle devono rimanere presso il provider attuale, i record MX e le configurazioni collegate non devono essere sostituiti con valori del nuovo hosting soltanto perché WordPress viene spostato.

Il rischio aumenta quando il cambio coinvolge i nameserver. Una nuova zona DNS creata automaticamente dall’hosting può contenere impostazioni predefinite che non corrispondono al servizio email realmente utilizzato.

Prima del passaggio bisogna sapere:

• quale provider gestisce le caselle;
• quali record MX richiede;
• quali record SPF, DKIM e DMARC sono attivi;
• se esistono alias, inoltri o sottodomini dedicati;
• se WordPress invia direttamente dal server oppure usa un servizio SMTP o transazionale esterno.

I valori non devono essere ricostruiti per intuizione. Vanno recuperati dalla configurazione esistente e confrontati con la documentazione del provider della posta.

Dopo il cambio è opportuno verificare sia la ricezione sia l’invio. Un test dal modulo di contatto controlla soltanto una parte del flusso: bisogna accertare anche che le caselle aziendali ricevano dall’esterno e possano inviare senza errori o problemi di autenticazione.

Se WordPress non consegna le notifiche, la causa può essere distinta dalla migrazione DNS. Configurazione SMTP, mittente, autenticazione e policy del provider richiedono una diagnosi specifica, come descritto nella guida ai problemi di invio email in WordPress.

Testare WordPress prima del cambio DNS

Il nuovo ambiente dovrebbe essere verificato usando il dominio reale in modo controllato. Testare il sito soltanto con un URL temporaneo può nascondere problemi legati a cookie, redirect, callback, licenze o configurazioni che dipendono dal nome host.

La verifica pre-migrazione può includere:

• home page e pagine principali;
• accesso al backoffice;
• immagini, allegati e file scaricabili;
• moduli di contatto e notifiche;
• login, aree riservate e recupero password;
• ricerca interna;
• redirect e pagina 404;
• funzioni offerte da plugin e integrazioni esterne;
• operazioni dinamiche rilevanti per il sito.

Un e-commerce, un portale con iscrizioni o un sito che riceve dati continuamente richiede anche una strategia per sincronizzare le modifiche avvenute dopo la prima copia del database. In base al progetto può essere necessario programmare una finestra operativa, limitare temporaneamente alcune funzioni oppure eseguire una sincronizzazione finale.

L’obiettivo non è dichiarare un’interruzione impossibile in ogni scenario. È evitare che utenti diversi lavorino su due database divergenti e che ordini, richieste o aggiornamenti rimangano soltanto sul vecchio server.

Sequenza operativa per migrare WordPress con continuità

Una sequenza ragionata riduce il numero di variabili durante il passaggio:

1. mappare hosting, dominio, DNS, SSL, email e servizi esterni;
2. creare backup verificabili di file, database e configurazioni rilevanti;
3. predisporre il nuovo ambiente con versioni compatibili;
4. copiare WordPress e configurare il sito;
5. testare il nuovo server con il dominio reale in modalità controllata;
6. predisporre certificato SSL e regole HTTPS secondo le possibilità del provider;
7. ricreare o verificare la zona DNS completa, se cambia il gestore;
8. pianificare la sincronizzazione finale dei dati dinamici;
9. modificare soltanto i record necessari;
10. controllare sito, HTTPS, posta e integrazioni da reti e strumenti differenti;
11. mantenere disponibile il vecchio ambiente durante la fase di verifica;
12. dismetterlo soltanto quando il nuovo flusso è stabile e recuperabile.

La procedura concreta varia in base a hosting, CDN, proxy, provider DNS e modalità di gestione della posta. Una checklist unica non può sostituire la lettura della configurazione reale.

Piano di rollback per DNS, sito ed email

Un rollback non consiste soltanto nel ricaricare un backup. Deve indicare quali record ripristinare, quale database considerare autorevole e come gestire eventuali dati creati durante la transizione.

Prima del cambio è utile conservare:

• valori DNS precedenti;
• accessi al vecchio e al nuovo hosting;
• copia dei file e del database;
• orario delle ultime sincronizzazioni;
• elenco delle operazioni effettuate;
• condizioni che richiedono il ritorno temporaneo al vecchio ambiente.

Ripristinare immediatamente il vecchio indirizzo DNS può non riportare tutti gli utenti nello stesso momento sul server precedente, perché anche la nuova risposta può essere presente nelle cache. Per questo entrambi gli ambienti devono essere gestiti con cautela durante la transizione.

Il rollback diventa particolarmente delicato quando il sito raccoglie ordini, registrazioni o contenuti. Tornare a un database precedente senza una strategia per i dati ricevuti nel frattempo può risolvere la raggiungibilità e creare un problema informativo più serio.

Controlli SEO dopo la migrazione WordPress

Se dominio e struttura degli URL non cambiano, la migrazione dovrebbe mantenere invariati gli indirizzi pubblici. Questo non elimina la necessità di verificare la risposta del nuovo server.

Dopo il passaggio vanno controllati almeno:

• codici HTTP delle pagine principali;
• redirect già esistenti;
• canonical;
• direttive robots e file robots.txt;
• sitemap XML;
• collegamenti interni e risorse statiche;
• eventuali blocchi lasciati dall’ambiente di staging;
• tracciamenti e strumenti di analisi autorizzati.

Un sito di test può essere protetto o escluso dall’indicizzazione durante la preparazione, ma tali limitazioni non devono restare attive sul sito pubblico. Anche cache, CDN e firewall devono essere verificati, perché possono continuare a servire risposte precedenti o bloccare richieste legittime.

Per migrazioni che comprendono server, zona DNS e posta può essere utile coordinare lo sviluppo WordPress con un intervento di assistenza sistemistica per hosting e DNS.

Quando affidare la migrazione WordPress a un professionista

Una migrazione semplice può essere gestita manualmente quando il sito è poco dinamico, il dominio non cambia, la posta resta separata e il nuovo hosting offre strumenti compatibili. Anche in questo caso sono necessari backup e test.

L’intervento professionale diventa più opportuno quando:

• sito ed email condividono una zona DNS poco documentata;
• sono presenti CDN, proxy o sottodomini;
• il sito raccoglie ordini, lead o dati continuamente;
• occorre sincronizzare il database vicino al cambio;
• hosting vecchio e nuovo usano configurazioni differenti;
• esistono integrazioni con API o servizi esterni;
• un’interruzione avrebbe conseguenze operative rilevanti.

Il compito non è soltanto copiare WordPress. Bisogna stabilire dipendenze, ordine delle modifiche, test e condizioni di rollback.

Se devi trasferire un sito WordPress e vuoi coordinare correttamente DNS, certificato SSL ed email, posso analizzare la configurazione esistente e preparare una procedura adatta ai servizi realmente coinvolti. Puoi descrivere il progetto nella pagina dedicata all’assistenza WordPress.

Ti auguro buona lettura e mi raccomando, se dopo aver letto questo articolo hai bisogno di aiuto non esitare a contattarmi.

Autore: Graziano De Maio | Titolare di Gdmtech