Migrazione sito WordPress senza perdere posizionamento

Una migrazione WordPress finisce male quasi sempre per gli stessi motivi: DNS propagati troppo presto, redirect dimenticati, permalink cambiati senza avvisare Google, database importato con URL vecchi ancora dentro. Il sito torna online, ma nel giro di due settimane il traffico organico crolla e nessuno capisce perché.

Questa guida serve a evitarlo. Che tu debba cambiare hosting per un server più veloce, spostare il sito su un dominio nuovo dopo un rebranding, o portare via un WordPress da un fornitore che non ti convince più, i passaggi sono quelli sotto. Copia-incolla dove serve, spunta man mano.

Cosa si rompe davvero durante una migrazione

Prima di aprire cPanel o installare plugin, vale la pena capire quali sono i punti di rottura reali. Sono quattro, e vanno gestiti tutti, non solo il primo.

• URL hardcoded nel database: WordPress salva URL assoluti in decine di tabelle (post_content, options, postmeta, widget serializzati). Se cambi dominio e non li riscrivi tutti, mezzo sito punta al vecchio indirizzo.
• Redirect mancanti: se cambi struttura permalink o dominio, ogni URL indicizzato da Google deve avere un 301 verso il nuovo. Senza redirect, perdi le posizioni acquisite in mesi o anni.
• Downtime durante la propagazione DNS: se cambi hosting e sposti i DNS “a occhio”, tra la propagazione (fino a 48 ore) e la cache dei resolver, il sito può alternarsi tra vecchio e nuovo server. Ordini persi, form che non arrivano, email di reset dimenticate.
• Indicizzazione: robots.txt lasciato in modalità “disallow all” (tipico di ambiente di staging), sitemap non aggiornata, Search Console non notificata del cambio dominio. Il sito nuovo non viene scansionato per giorni.

Il resto (email, certificati SSL, cron job, chiavi API) è contorno. Va gestito, ma è prevedibile. I quattro punti sopra sono quelli che costano posizionamento.

Preparazione: cosa fare prima di toccare qualsiasi cosa

Una migrazione ben preparata è per il 70% lavoro fatto prima del “vai”. Ecco cosa serve pronto.

1. Inventario URL indicizzati

Vai su Google Search Console, sezione Pagine → Indicizzate, ed esporta l’elenco completo delle URL che Google ha in indice. Salvalo in un file urls-indicizzate.csv. Questo è il punto di partenza per la mappa di redirect. Se hai anche accesso a Screaming Frog o a un crawler, esegui una scansione completa del sito attuale ed esporta la lista URL in formato CSV.

2. Backup completo (file + database)

Non fidarti mai del backup automatico dell’hosting. Fai un backup manuale con un plugin affidabile: Duplicator Pro, All-in-One WP Migration o UpdraftPlus. In alternativa via SSH:

# Backup file
tar -czf backup-files.tar.gz /var/www/html/

# Backup database
mysqldump -u UTENTE -p NOMEDB > backup-db.sql

Scarica entrambi i file in locale. Un backup che sta solo sul server che stai migrando non è un backup.

3. Snapshot delle impostazioni chiave

Prendi screenshot o annota:

• Struttura permalink attuale (Impostazioni → Permalink)
• Elenco plugin attivi con versione
• Tema attivo e tema child
• Utente admin principale (per verificarlo dopo la migrazione)
• Chiavi API di Stripe, Brevo, Google Maps, reCAPTCHA se presenti

4. Ambiente di destinazione pronto

Se cambi hosting, il nuovo server deve avere PHP alla stessa versione o superiore (mai inferiore), MySQL/MariaDB compatibile, moduli PHP richiesti dai plugin installati. Prepara un database vuoto e un utente MySQL con permessi pieni sul DB.

Migrazione hosting senza downtime: il metodo hosts file

Il modo più sicuro per migrare senza tempi di sito offline è testare il sito sul nuovo server prima di spostare i DNS. Si fa con il file hosts locale.

Passo 1: carica il sito sul nuovo hosting

Con Duplicator crei un pacchetto (installer.php + archivio .zip), lo carichi sul nuovo hosting via FTP o pannello, poi vai su https://IP-NUOVO-SERVER/installer.php ed esegui la procedura guidata. Se il nuovo hosting non permette accesso via IP, chiedi al provider un URL temporaneo (tipo tuosito.serverprovider.com).

Passo 2: modifica il file hosts locale

Sul tuo computer, punta manualmente il dominio al nuovo IP. Solo per te, non per il resto del mondo.

Su macOS/Linux: apri terminale e digita sudo nano /etc/hosts. Aggiungi in fondo:

123.45.67.89   tuosito.it
123.45.67.89   www.tuosito.it

Su Windows: apri come amministratore C:\Windows\System32\drivers\etc\hosts e aggiungi le stesse righe.

Sostituisci 123.45.67.89 con l’IP del nuovo hosting. Salva, poi svuota la cache DNS locale (sudo dscacheutil -flushcache su Mac, ipconfig /flushdns su Windows).

Passo 3: testa tutto sul nuovo server

Ora quando visiti tuosito.it dal tuo browser, stai vedendo il nuovo hosting mentre tutti gli altri vedono ancora il vecchio. Verifica: homepage, 5-10 pagine chiave, login admin, pagina carrello e checkout se hai WooCommerce, form di contatto (invia una email di prova), certificato SSL valido. Se qualcosa non funziona, hai tempo per sistemarlo senza che nessuno se ne accorga.

Passo 4: cambia i DNS e riduci il TTL prima

Almeno 24 ore prima del cambio DNS, riduci il TTL del record A da 3600 (o quello che è) a 300 secondi. Così quando cambi l’IP, la propagazione è molto più rapida. Il giorno del cambio: aggiorna il record A puntando al nuovo IP, e imposta il sito in modalità sola lettura per un’ora (niente ordini, niente commenti) per evitare che entrino dati sul vecchio server durante la propagazione.

Passata la propagazione, rimuovi le righe dal tuo file hosts e verifica che il sito risponda dal nuovo server anche per te.

Cambio dominio: la gestione dei redirect è tutto

Se oltre all’hosting stai cambiando dominio (o passi da http:// a https://, o da tuosito.it a www.tuosito.it), la partita si gioca sui redirect 301.

Riscrittura URL nel database

Dopo aver importato il database sul nuovo dominio, tutti i vecchi URL sono ancora dentro. Usa WP-CLI per riscriverli correttamente (gestisce anche i dati serializzati, cosa che un semplice search&replace SQL non fa):

wp search-replace 'https://vecchiodominio.it' 'https://nuovodominio.it' --all-tables --skip-columns=guid --dry-run

Se il dry-run mostra numeri sensati (centinaia o migliaia di occorrenze, non zero), lancia il comando vero rimuovendo --dry-run. Il flag --skip-columns=guid serve: i GUID dei post non vanno mai modificati, sono identificatori univoci storici.

Se non hai WP-CLI, il plugin Better Search Replace fa lo stesso lavoro dall’interfaccia, con opzione “dry run” attivabile.

Mappa dei redirect 301

Ogni URL del vecchio dominio deve rispondere con un 301 verso l’URL corrispondente del nuovo. Se la struttura permalink è identica, basta un redirect globale nel file .htaccess del vecchio dominio (che devi tenere attivo almeno 6-12 mesi):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?vecchiodominio\.it$ [NC]
RewriteRule ^(.*)$ https://nuovodominio.it/$1 [R=301,L]

Se la struttura permalink cambia, o se alcune URL non hanno corrispondenza 1:1, serve una mappatura manuale. Prendi il CSV delle URL indicizzate, aggiungi una colonna nuovo_url, compila riga per riga, poi importa le regole con il plugin Redirection (sezione Strumenti → Redirection → Import, formato CSV supportato nativamente).

Su Nginx invece di Apache

Se il vecchio hosting è su Nginx, il redirect equivalente va nel file di configurazione del server:

server {
    listen 80;
    server_name vecchiodominio.it www.vecchiodominio.it;
    return 301 https://nuovodominio.it$request_uri;
}

Search Console, sitemap e indicizzazione

Il lavoro tecnico è fatto, ma se non lo comunichi a Google possono servire settimane prima che il nuovo dominio venga scansionato completamente.

1. Verifica il nuovo dominio in Search Console. Aggiungi la nuova property, verifica proprietà via DNS TXT o file HTML.
2. Usa lo strumento “Cambio di indirizzo” (solo se cambi dominio, non solo hosting). Nella property del vecchio dominio, vai su Impostazioni → Cambio di indirizzo e seleziona la nuova property. Google usa questo segnale per accelerare il trasferimento del ranking.
3. Invia la nuova sitemap. Genera la sitemap con Yoast SEO Premium o Rank Math, poi in Search Console vai su Sitemap e inserisci l’URL (di solito https://nuovodominio.it/sitemap_index.xml).
4. Controlla robots.txt. Assicurati che NON contenga Disallow: /. Se il sito veniva da staging, questa è la trappola più comune. Il robots.txt corretto per un sito pubblico è:

   User-agent: *
   Allow: /
   
   Sitemap: https://nuovodominio.it/sitemap_index.xml

5. Richiedi la reindicizzazione delle pagine chiave. In Search Console, sezione Controllo URL, incolla la URL, premi “Richiedi indicizzazione”. Fallo per homepage e le 10-20 pagine più importanti per traffico.

Nei giorni successivi, monitora la copertura in Search Console e i log del server per vedere che Googlebot stia scansionando davvero il nuovo dominio.

Errori comuni da evitare (visti troppe volte)

• Dimenticare di aggiornare siteurl e home nel database. Se dopo la migrazione il sito ti reindirizza al vecchio dominio, è quasi sempre questo. Correggi via WP-CLI: wp option update siteurl 'https://nuovodominio.it' e wp option update home 'https://nuovodominio.it'.
• Non testare il checkout su un e-commerce prima del go-live. Un plugin di pagamento con URL callback hardcoded può bloccare tutti gli ordini. Fai un ordine di prova in modalità sandbox prima di aprire al pubblico.
• Lasciare attivi due WordPress. Se il vecchio hosting resta online con lo stesso database, i due siti possono divergere. Dopo il cambio DNS, disattiva WordPress sul vecchio server (basta rinominare la cartella wp-content o mettere il sito in maintenance) tenendo solo l’.htaccess con i redirect.
• Ignorare la velocità del nuovo server. Migrare per andare su un hosting peggiore capita più spesso di quanto si pensi. Prima di firmare, controlla che il nuovo hosting regga i tempi di risposta attuali. Su questo ho già scritto una guida dedicata alle strategie per velocizzare un sito WordPress.
• Sottovalutare i costi ricorrenti post-migrazione. Il nuovo hosting è solo una voce. Backup, monitoraggio, SSL, plugin premium: tutto va rimesso in ordine. Sui costi nascosti della manutenzione di un sito vedo confusione praticamente ogni volta che si affronta una migrazione.

Checklist finale prima e dopo il go-live

Prima del cambio DNS:

• Backup completo file + database scaricato in locale
• Sito replicato sul nuovo server e testato via hosts file
• Certificato SSL attivo e valido sul nuovo dominio/hosting
• WP-CLI o Better Search Replace eseguito per riscrivere URL nel database
• Redirect 301 configurati nel .htaccess o Nginx del vecchio dominio
• Mappa redirect manuale importata in Redirection (se struttura permalink cambiata)
• TTL DNS ridotto a 300 secondi almeno 24 ore prima
• robots.txt verificato (nessun Disallow globale)
• Plugin di caching svuotato (WP Rocket → Impostazioni → WP Rocket → Dashboard → Svuota cache)

Dopo il go-live:

• Homepage e 10 pagine chiave caricate correttamente dal nuovo server
• Login admin funzionante
• Ordine di prova completato (se WooCommerce)
• Form di contatto inviato e email ricevuta
• Sitemap XML raggiungibile e inviata a Search Console
• Cambio di indirizzo notificato in Search Console (se cambio dominio)
• Redirect testati: apri 5 vecchie URL, verifica che rispondano 301 al nuovo dominio (usa curl -I https://vecchiodominio.it/pagina/)
• Google Analytics e Tag Manager configurati sul nuovo dominio (aggiorna eventuali filtri di dominio)
• Chiavi API aggiornate (Stripe webhook, Brevo, reCAPTCHA con nuovo dominio autorizzato)
• Monitoraggio uptime attivo per le prime 72 ore

Domande frequenti

Quanto tempo serve per una migrazione WordPress fatta bene?

Per un sito vetrina standard servono alcune ore di lavoro effettivo, distribuite su due giornate (preparazione + go-live). Per un e-commerce con centinaia di prodotti e integrazioni si arriva a qualche giornata piena. Il tempo non è nel “copiare file”, quello lo fa un plugin, ma nel testare tutto sul nuovo ambiente prima di spostare i DNS. Chi promette migrazioni “in un’ora chiavi in mano” sta saltando i test, e sono le stesse promesse che si vedono nella logica del sito web a basso costo.

Cambiare hosting fa perdere posizionamento su Google?

No, se URL e struttura restano identici. Google guarda i contenuti e gli URL, non l’IP del server. L’unica cosa che può influire è la velocità: se il nuovo hosting è più lento, i Core Web Vitals peggiorano e nel medio periodo il ranking può risentirne. Se il nuovo è più veloce, capita l’opposto. Il ranking cala solo se sbagli i redirect o se il sito resta offline a lungo durante la propagazione.

Serve mantenere attivo il vecchio dominio dopo il cambio?

Sì, per almeno 12 mesi, idealmente permanentemente se il budget lo consente. Il vecchio dominio deve continuare a rispondere con redirect 301 verso il nuovo. Se lasci scadere il dominio, perdi tutto il valore SEO trasferito e i link esterni che puntavano al vecchio indirizzo diventano 404. Il costo di rinnovo annuo è trascurabile rispetto al danno potenziale.

Posso migrare un sito WordPress manualmente senza plugin?

Sì, ed è il metodo più pulito quando il sito è grande (oltre 2GB) o quando i plugin di migrazione danno errori di timeout. Il procedimento: backup file via SSH/FTP, export database via phpMyAdmin o mysqldump, import sul nuovo server, modifica di wp-config.php con le nuove credenziali DB, riscrittura URL via WP-CLI. Richiede più competenza tecnica ma evita i limiti dei plugin su hosting con risorse ridotte.

Cosa succede alle email se cambio hosting?

Se l’email è ospitata sullo stesso hosting del sito (record MX puntati al server web), spostando i DNS sposti anche le email, e rischi di perderle. Prima della migrazione, decidi: o sposti anche le caselle sul nuovo hosting (con backup IMAP di tutti i messaggi), o separi il servizio email su un provider dedicato (Google Workspace, Microsoft 365, servizio email del provider precedente) modificando solo il record A del dominio e lasciando i record MX invariati. Questa seconda opzione è quasi sempre la scelta migliore.

La migrazione non è un’emergenza, è un progetto

Le migrazioni che vanno male hanno tutte in comune una cosa: sono state trattate come un’operazione tecnica veloce, non come un progetto con fasi, test e verifiche. Il metodo hosts file per testare prima del go-live, la mappa dei redirect scritta a mano quando serve, la Search Console notificata: sono i passaggi che separano una migrazione pulita da un mese di traffico perso.

Se hai una migrazione in programma e il sito genera fatturato reale, vale la pena pianificarla con almeno 2-3 settimane di anticipo. Il costo del tempo speso a farla bene è sempre inferiore al costo di doverla rifare dopo aver perso posizionamento.