Guide

Spostare un sito WordPress senza perdere posizioni: checklist DNS, redirect e Search Console

Checklist passo per passo per cambiare hosting o dominio a un sito WordPress: TTL, backup, redirect 301 e strumento Cambio di indirizzo di Search Console.

Redazione UptimeMag · 21 ottobre 2026 · 5 minuti di lettura

Spostare un sito WordPress senza perdere posizioni: checklist DNS, redirect e Search Console

Cambiare hosting o dominio a un sito WordPress è un'operazione che si fa in poche ore di lavoro tecnico, ma gli effetti su traffico e posizionamento si vedono nelle settimane successive. La differenza fra un trasloco pulito e uno che costa posizioni su Google sta quasi sempre in tre cose: la preparazione del DNS, i redirect e l'uso corretto di Search Console. Ecco la sequenza, nell'ordine in cui va eseguita.

Prima regola: distinguere i due casi

Il procedimento cambia a seconda di cosa si sposta:

  • Stesso dominio, nuovo hosting: gli URL non cambiano. Non serve nessun redirect 301 e non si usa lo strumento Cambio di indirizzo di Search Console. Basta copiare i dati e aggiornare il DNS.
  • Nuovo dominio (con o senza cambio di hosting): qui servono sia i redirect 301 sia, dopo il trasloco, lo strumento Cambio di indirizzo. Questo vale anche per i passaggi da HTTP a HTTPS o fra www e non-www? No: per questi casi specifici Google indica di usare canonical tagging e/o redirect senza usare lo strumento Cambio di indirizzo, perché restano variazioni dello stesso dominio.

Il DNS: abbassare il TTL prima, non dopo

Il passo più spesso dimenticato è il primo. Se il record A ha un TTL alto (24 ore, cioè 86400 secondi) e lo si cambia il giorno del trasloco, parte dei visitatori continuerà a vedere il vecchio server per ore. La prassi, confermata da più guide tecniche di settore, è:

  1. 24-48 ore prima del cutover, abbassare il TTL dei record A/AAAA (e MX se cambia anche la posta) a un valore fra 300 e 600 secondi.
  2. Aspettare che il vecchio TTL sia scaduto ovunque: se prima era 86400, bisogna aspettare almeno 24 ore dopo l'abbassamento prima di procedere al cambio vero e proprio.
  3. Il giorno del cutover, cambiare il record con il nuovo IP: con TTL basso la propagazione effettiva richiede in genere da pochi minuti a qualche ora, invece delle 24-48 ore tipiche di un TTL alto.
  4. Tenere il vecchio server raggiungibile per 48-72 ore dopo il cambio, come rete di sicurezza: se qualcosa non funziona sul nuovo hosting, si può tornare indietro in pochi minuti rimettendo il vecchio IP.
  5. Una volta verificato che tutto gira sul nuovo hosting, riportare il TTL al valore normale (in genere 3600 o 14400 secondi), per non sovraccaricare inutilmente i resolver con query continue.

Cosa copiare, nell'ordine

Prima di toccare il DNS, il sito nuovo deve essere già pronto e testato, raggiungibile con un URL temporaneo o via file hosts:

  1. Backup completo di file e database sul vecchio hosting, e verifica che il backup sia davvero ripristinabile (non solo che esista).
  2. File: cartella wp-content (temi, plugin, upload), più eventuali file di configurazione (wp-config.php adattato alle credenziali del nuovo database).
  3. Database: esportazione e importazione sul nuovo server, con le stesse versioni di PHP e MySQL/MariaDB o superiori.
  4. Aggiornamento degli URL nel database, se cambia il dominio. Con WP-CLI il comando è:
wp search-replace 'http://vecchiodominio.it' 'https://nuovodominio.it' --skip-columns=guid

L'opzione --skip-columns=guid evita di toccare il campo GUID dei contenuti, che per convenzione WordPress non andrebbe modificato dopo la pubblicazione. Prima di lanciarlo sul sito vero, conviene fare una prova con --dry-run, che esegue l'operazione e mostra il report senza scrivere nulla nel database.

  1. Test del sito nuovo (via file hosts o URL temporaneo) prima di spostare il DNS: pagine, form, carrello se c'è un e-commerce, invio email.

I redirect 301: quando sono obbligatori

Se cambia il dominio, il redirect 301 dalla vecchia alla nuova home page è il minimo indispensabile, ma la pratica più solida è mappare uno a uno gli URL vecchi verso i corrispondenti nuovi, non solo la home. Senza redirect, chi arriva da un link vecchio o da una pagina indicizzata trova un errore 404 e il segnale di autorità di quella pagina va perso, non trasferito.

Se il cambio è solo di hosting a parità di dominio e di struttura URL, non serve alcun redirect: lato visitatori e motori di ricerca non cambia nulla, cambia solo il server che risponde.

Search Console: quando e come usare il Cambio di indirizzo

Lo strumento Cambio di indirizzo di Search Console serve esclusivamente per i trasferimenti fra domini o sottodomini diversi. Vanno usati solo dopo aver spostato e reindirizzato il sito.

Google indica quattro casi in cui lo strumento non va usato: passaggio da HTTP a HTTPS, spostamento di alcune pagine all'interno dello stesso sito, passaggio fra www e non-www sullo stesso dominio, e cambio di hosting o CDN a parità di URL visibili.

Prima di avviare la procedura, entrambe le proprietà (vecchio e nuovo dominio) devono essere verificate in Search Console con lo stesso account Google, a livello di dominio e non di singolo percorso. Google raccomanda inoltre di sottoporre la richiesta per tutte le varianti verificate del vecchio dominio: sottodomini e versioni www/non-www, anche quelle non attivamente usate, prima di inviare le richieste.

Una volta avviata la procedura, resta visibile in Search Console per 180 giorni, periodo durante il quale vanno mantenuti attivi i redirect: Google indica di mantenere i reindirizzamenti per almeno 180 giorni, o più a lungo se non si nota traffico in calo dai vecchi URL. Trascorso quel periodo, se il vecchio dominio è ancora raggiungibile, Google smette di considerarlo collegato al nuovo. Una conseguenza pratica: non va disattivato il vecchio dominio troppo presto, nemmeno se sembra "tutto a posto" dopo pochi giorni.

Un'altra indicazione utile per chi gestisce più domini: Google sconsiglia di concatenare più spostamenti in sequenza (dominio A verso B, poi subito B verso C), perché il sistema non permette di avviare una seconda richiesta di cambio di indirizzo dal sito B finché la prima non si è conclusa, e il traffico rischia di disperdersi lungo la catena.

Dopo il cutover: cosa controllare

  • Inviare la nuova sitemap XML da Search Console: questo aiuta Google a scoprire più in fretta gli URL nuovi, e a quel punto la vecchia sitemap può essere rimossa.
  • Controllare nel rapporto "Copertura" o "Pagine" di Search Console che il nuovo dominio venga effettivamente scansionato e indicizzato.
  • Monitorare per alcune settimane le impressioni e i clic sia sulla proprietà vecchia sia su quella nuova: un calo temporaneo nelle prime settimane è normale, Google stesso segnala che per siti di medie dimensioni possono servire alcune settimane prima che i nuovi URL sostituiscano gradualmente i vecchi nei risultati.
  • Verificare che il file o il meta tag di verifica della proprietà Search Console sia presente anche sul sito nuovo, altrimenti si perde la verifica della proprietà.

Fatto questo, il trasloco è concluso lato tecnico. Il resto è attesa: Google ha bisogno di tempo per ricrawlare ogni URL vecchio e nuovo almeno una volta prima di considerare la migrazione completata, e non esiste uno stato "completato" visibile da nessuna parte: l'unico segnale affidabile è il traffico che si stabilizza sul nuovo dominio.

Testo redatto con il supporto dell'intelligenza artificiale e verificato dalla redazione (AI Act, art. 50).