Migrazione SEO: come cambiare sito, CMS o dominio senza perdere controllo

4 Agosto 2026 · SEO

Una migrazione SEO non è un singolo intervento tecnico. È il trasferimento di segnali, contenuti, percorsi e misurazioni da una configurazione a un’altra. Il rischio non nasce soltanto dai redirect mancanti: nasce soprattutto dal fatto che, durante il progetto, cambiano contemporaneamente URL, template, testi, navigazione, codice, tracking e talvolta perfino dominio. Quando il traffico cala, diventa difficile capire quale cambiamento abbia prodotto il danno.

Per mantenere il controllo serve quindi un metodo che separi le decisioni, registri lo stato di partenza e renda verificabile ogni passaggio.

Prima distinzione: quale migrazione stai realmente facendo

Non tutte le migrazioni hanno lo stesso rischio. È utile elencare in modo esplicito le trasformazioni previste.

La prima decisione di qualità è limitare i cambiamenti simultanei. Se l’azienda deve cambiare dominio, CMS, architettura e testi, può essere necessario farlo in un unico rilascio per ragioni operative; in quel caso, però, ogni trasformazione deve avere un proprio inventario e un proprio controllo. Dire semplicemente “rifacciamo il sito” non è un perimetro sufficiente.

Costruire una baseline che permetta confronti reali

Prima di modificare il sito bisogna sapere che cosa funziona oggi. La baseline non è una schermata del traffico complessivo, ma un insieme di dati segmentabili.

Per ogni URL rilevante conviene registrare almeno:

• status code, URL canonico e indicizzabilità;
• titolo, H1, contenuto principale e template;
• click e impressioni organiche per query e paese;
• sessioni, eventi e conversioni attribuite;
• link interni in entrata e profondità di navigazione;
• backlink rilevanti;
• presenza in sitemap, hreflang e dati strutturati;
• valore commerciale o funzione della pagina.

Una pagina con poco traffico può essere essenziale perché intercetta richieste ad alto valore o perché sostiene un cluster di contenuti. Eliminare in base alle sole visite è una scorciatoia pericolosa.

La baseline deve inoltre includere un campione di query di marca, generiche, informative e commerciali. Se dopo il rilascio cala soltanto un gruppo, la diagnosi sarà più precisa rispetto a un generico “la SEO è scesa”.

La mappa old-to-new è una decisione editoriale, non un foglio automatico

Ogni vecchio URL deve avere un esito esplicito:

1. resta invariato;
2. viene spostato verso una pagina equivalente;
3. viene consolidato in una risorsa più completa;
4. viene rimosso senza sostituto perché non ha più valore;
5. richiede una nuova pagina ancora da produrre.

Un redirect permanente deve portare alla destinazione più equivalente possibile. Reindirizzare centinaia di pagine alla Home o a una categoria generica non conserva l’intento e può essere interpretato come un risultato non pertinente. Anche le catene di redirect vanno evitate: il vecchio URL dovrebbe puntare direttamente alla destinazione finale.

La mappa deve essere revisionata da SEO, contenuti e referenti di business. Un tecnico può verificare che il redirect funzioni; non può decidere da solo se due pagine rispondono davvero allo stesso bisogno.

Che cosa testare prima del go-live

Lo staging deve permettere controlli realistici senza diventare indicizzabile. Prima del rilascio serve un test su tutti i template e sui casi limite, non soltanto sulla Home.

La lista minima comprende:

• status code e redirect su un campione rappresentativo;
• canonical, meta robots, robots.txt e sitemap;
• link interni, breadcrumb, paginazioni e filtri;
• contenuto principale, H1, title e meta description;
• immagini, PDF e altri asset con URL modificati;
• hreflang e selettori lingua;
• rendering JavaScript e contenuto visibile ai crawler;
• dati strutturati senza errori concettuali;
• eventi analytics, moduli, telefonate e download;
• prestazioni dei template principali;
• pagine 404 e gestione degli URL non mappati.

Un test passa soltanto quando esiste un risultato atteso. “Il form funziona” è troppo vago; “l’invio genera l’evento generate_lead, conserva la landing page e crea il record nel CRM” è verificabile.

Il giorno del rilascio: una sequenza controllata

Il cutover deve avere una checklist temporale e responsabili reperibili. DNS, deployment, redirect, sitemap, cache, CDN, monitoraggio e tracking non possono dipendere da persone che non sanno quando intervenire.

Subito dopo la pubblicazione conviene verificare:

• Home, pagine principali e URL profondi;
• vecchi URL ad alto valore;
• sitemap e robots.txt pubblici;
• assenza di noindex o blocchi ereditati dallo staging;
• risposte server e tempi anomali;
• moduli e conversioni reali;
• log applicativi e server;
• proprietà e impostazioni degli strumenti di ricerca e analisi.

Per un cambio di dominio vanno inoltre aggiornati Search Console, profili aziendali, campagne, feed, link social, email transazionali e collegamenti esterni controllabili. La migrazione non termina quando il nuovo sito è online.

Come monitorare senza reagire in modo impulsivo

Nei giorni successivi sono normali oscillazioni, ma non ogni calo va atteso passivamente. Il monitoraggio deve distinguere:

• URL vecchi ancora richiesti;
• errori 404 inattesi;
• pagine nuove non scansionate o non indicizzate;
• query perse per sezione, intento o template;
• calo delle conversioni dovuto al tracking anziché al traffico;
• peggioramenti di performance o rendering;
• redirect errati o destinazioni non equivalenti.

Un issue log aiuta a non confondere sintomi e cause. Ogni voce dovrebbe contenere URL, evidenza, gravità, ipotesi, responsabile, intervento e verifica. Prima si correggono gli errori sistemici — per esempio un canonical sbagliato su un intero template — poi i casi isolati.

Un esempio di controllo utile

Un’azienda industriale cambia CMS e riorganizza 1.800 schede e pagine di lavorazione. Dopo il rilascio, il traffico organico cala del 18%. Il dato aggregato suggerisce un problema generale, ma la segmentazione mostra che:

• le pagine istituzionali sono stabili;
• le pagine di lavorazione mantengono le query;
• le schede con parametri nell’URL non ricevono più link interni;
• alcuni PDF tecnici restituiscono 404;
• il nuovo modulo non registra correttamente l’origine del lead.

La soluzione non è annullare il sito né “aspettare Google”. È correggere navigazione parametrica, asset e tracciamento, verificando separatamente il recupero di ogni area.

Criteri per considerare conclusa la migrazione

La chiusura non coincide con una data fissa. Il progetto può dirsi sotto controllo quando:

• gli URL prioritari hanno esito corretto;
• non esistono errori sistemici di scansione o indicizzazione;
• le principali query e sezioni sono state confrontate con la baseline;
• conversioni e integrazioni sono affidabili;
• le anomalie residue hanno owner e scadenza;
• la documentazione finale descrive struttura, redirect e decisioni prese.

Una buona migrazione non promette assenza assoluta di oscillazioni. Riduce l’incertezza, limita i cambiamenti non tracciati e consente di capire rapidamente dove intervenire.

Fonti operative

• Google Search Central, Site moves and migrations: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
• Google Search Central, Redirects and Google Search: https://developers.google.com/search/docs/crawling-indexing/301-redirects
• Google Search Central, Canonicalizzazione: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

Approfondisci il servizio: Recupero traffico organico.