Checklist dopo il trasferimento di un sito a Xlogic

Dopo il trasferimento a Xlogic verifica il sito sul nuovo server prima di chiudere il vecchio hosting. Controlla file, database, URL WordPress, HTTPS, DNS, email, moduli, area riservata e procedure automatiche. Cambia i DNS soltanto quando le funzioni essenziali sono pronte e conserva una copia del sito precedente finché i controlli pubblici non sono conclusi.

Prima di modificare i DNS

Apri il sito sul nuovo server con il metodo di anteprima concordato durante il trasferimento. Non basarti soltanto sulla homepage: prova pagine interne, immagini, file scaricabili e accesso amministrativo.

1. Confronta la data e la dimensione dei file con la copia di origine.
2. Verifica che il database importato sia quello corretto e che wp-config.php utilizzi nome database, utente e password del nuovo account.
3. Controlla che non ci siano errori PHP nuovi nei log.
4. Assicurati che il sito non sia rimasto in modalità manutenzione o con l’indicizzazione bloccata da una configurazione temporanea.
5. Se il sito cambia spesso, pianifica una sincronizzazione finale di ordini, utenti o contenuti prima del cambio DNS.

Controlli WordPress e database

Se dominio e protocollo non cambiano, gli URL principali dovrebbero restare uguali. Se cambia il dominio, il percorso o il passaggio da HTTP a HTTPS, controlla Indirizzo WordPress (URL) e Indirizzo sito (URL) in Impostazioni → Generali.

Per sostituire URL nel database usa uno strumento compatibile con i dati serializzati, come wp search-replace, prima con --dry-run e dopo aver creato un backup. Una sostituzione SQL testuale eseguita senza questa protezione può danneggiare widget, opzioni e contenuti serializzati.

Apri Impostazioni → Permalink e salva soltanto se le pagine interne restituiscono 404 o se le regole di riscrittura devono essere rigenerate. Non cambiare struttura dei permalink durante il trasferimento senza una ragione precisa.

Pagine e funzioni da provare

• login e logout di WordPress;
• ricerca interna, menu, moduli e upload;
• invio email di prova e reset password;
• carrello, coupon, checkout e notifiche WooCommerce, se presenti;
• aree riservate, abbonamenti e integrazioni API;
• cron, backup e attività pianificate;
• cache LiteSpeed e pagine viste da utente non autenticato;
• versione mobile e almeno un browser diverso.

Per i test eCommerce usa modalità di prova e controlla gli invii email. L’anteprima tramite file hosts riguarda solo il computer usato: pagamenti, webhook e altri servizi esterni continuano a seguire i DNS pubblici. Pianifica la sincronizzazione finale e come evitare scritture divergenti sui due server durante la transizione. Non sovrascrivere il database di destinazione dopo i primi ordini reali senza una procedura controllata.

DNS, HTTPS ed email

Prima del cambio annota i record DNS attuali, in particolare MX, TXT, SPF, DKIM, DMARC e record di servizi esterni. Se trasferisci soltanto il sito Web, non modificare i record della posta senza necessità. Un dominio acquistato senza hosting può gestire i nameserver, ma non dispone necessariamente di una zona DNS nel pannello hosting.

Prepara e verifica il certificato sul nuovo ambiente prima di inviarvi il traffico, quando il metodo di validazione disponibile lo consente. Con HTTP-01 la richiesta di verifica deve raggiungere il percorso corretto; con DNS-01 si verifica un record TXT e non è necessario spostare prima i record A o AAAA del sito. Dopo il cambio controlla dominio, www, redirect HTTPS e contenuti misti.

Se usi Cloudflare o un’altra CDN, verifica l’origine con un metodo controllato che mantenga hostname e HTTPS corretti, per esempio un’associazione locale tramite file hosts. Non disattivare automaticamente il proxy pubblico: potresti cambiare l’esposizione dell’origine o le protezioni del sito. Confronta poi la risposta attraverso la CDN.

Dopo la pubblicazione del nuovo sito

1. Controlla con un resolver pubblico che dominio e www restituiscano gli indirizzi previsti.
2. Apri il sito da una rete differente, per esempio connessione mobile.
3. Verifica codice HTTP, redirect, certificato e pagine 404.
4. Svuota le cache solo dopo aver confermato che la destinazione è corretta.
5. Monitora log, moduli, email e ordini nelle ore successive.
6. Se usi strumenti di monitoraggio o Search Console, controlla che non compaiano nuovi errori di scansione o disponibilità.

La visibilità delle modifiche DNS dipende da TTL e cache dei resolver. Non indicare un tempo garantito: durante la transizione alcuni visitatori possono raggiungere il vecchio server e altri quello nuovo.

Quando chiudere il vecchio hosting

Mantieni operativo il vecchio servizio finché il traffico raggiunge stabilmente il nuovo server, le email seguono il percorso corretto e i dati dinamici sono stati verificati. Prima della chiusura crea una copia indipendente di file, database e configurazioni necessarie.

Non usare il vecchio hosting come unico backup. Conserva il pacchetto di migrazione in una posizione separata e protetta.

Quando contattare l’assistenza Xlogic

Apri un ticket se anteprima e sito pubblico mostrano contenuti diversi, compaiono errori 404/500, il certificato non viene emesso, il database non si collega o le email cambiano percorso. Indica dominio, vecchio e nuovo ambiente, URL interessati, data e ora, modifica DNS eseguita e testo completo dell’errore. Non inviare password.

Guide Xlogic correlate

• Trasferire WordPress a Xlogic senza downtime
• Visualizzare il sito sul nuovo server senza modificare i DNS
• Propagazione DNS: TTL e verifiche
• AutoSSL: controllare DNS, CAA e Cloudflare

Domande frequenti

Fonti

• WordPress: migrazione di un sito
• WP-CLI: search-replace e dati serializzati
• cPanel: Zone Editor