Una migrazione SEO non è solo “spostare un sito”. È un progetto in cui URL, dominio, CMS, design, hosting o architettura possono cambiare mentre devi preservare discovery, indicizzazione, segnali, contenuti, link e misurazione.
Il rischio maggiore non è il cambiamento in sé. È lanciare senza sapere quali pagine generano traffico e backlink, dove devono essere reindirizzate, quali segnali devono essere aggiornati e come verificare rapidamente gli errori dopo il go-live.
Google raccomanda, quando possibile, di cambiare una cosa alla volta. Se vuoi cambiare dominio, CMS e layout, separare le fasi riduce il numero di variabili quando qualcosa non funziona.
Per migrazioni complesse, il servizio di audit SEO tecnico può essere usato come base pre-lancio e post-lancio. Questa guida, invece, ti dà il processo operativo completo.
Scarica SEO Migration Checklist.xlsx
Ho strutturato il lead magnet in cinque aree operative: URL Mapping, Pre-launch QA, Launch QA, Post-launch Monitoring e Redirect Validation. Il file può essere usato da SEO, developer, project manager e content team come documento condiviso di go-live.
Risposta breve: come fare una migrazione SEO senza perdere traffico?
| Devi sapere cosa stai cambiando, creare una baseline, mappare ogni vecchia URL verso una destinazione equivalente e testare il nuovo sito prima del lancio. Al go-live attiva redirect permanenti, rimuovi blocchi temporanei, aggiorna canonical, internal link, hreflang, sitemap e tracking, quindi ricrawla vecchio e nuovo inventario. Dopo il lancio monitora Search Console, analytics, ranking, server log, 404 e redirect. Fluttuazioni temporanee possono essere normali; errori sistemici no. |
1. Cosa conta come migrazione SEO
Parliamo di migrazione SEO quando un cambiamento può alterare gli URL, il modo in cui Google accede alle pagine, la struttura interna, il contenuto o i segnali che descrivono la versione preferita.
- Cambio dominio.
- HTTP → HTTPS.
- Cambio CMS.
- Ristrutturazione URL.
- Redesign importante.
- Cambio piattaforma e-commerce.
- Cambio hosting o CDN.
- Fusione di più siti.
- Separazione di un sito in più domini o sottodomini.
2. Migrazione di dominio
Esempio: `example.it` → `nuovodominio.it`. Qui cambia l’intero hostname e ogni URL deve essere considerata nel mapping.
- Verifica vecchio e nuovo dominio in Search Console.
- Controlla storia e manual action dell’eventuale dominio acquistato.
- Mappa tutte le varianti importanti.
- Configura redirect permanenti old → new.
- Per un vero cambio dominio/subdominio usa anche Change of Address in Search Console.
Il Change of Address non serve per ogni migrazione. Google lo indica per cambi di dominio o sottodominio, non per HTTP→HTTPS, www/non-www sullo stesso dominio o semplici cambi di path.
3. HTTP → HTTPS
Il passaggio a HTTPS è un site move con cambio URL perché cambia il protocollo.
- Certificato TLS valido.
- Redirect HTTP → HTTPS.
- Canonical HTTPS.
- Internal link HTTPS.
- Sitemap HTTPS.
- Asset e risorse senza mixed content.
4. Migrazione CMS
WordPress → headless, CMS custom → WordPress, Magento → Shopify o un altro cambio CMS può modificare URL, HTML, rendering, schema, navigazione e performance.
Se puoi, non aggiungere nello stesso giorno anche un cambio dominio e un redesign radicale. Separare i cambi rende la diagnosi molto più semplice.
5. Ristrutturazione URL
Cambiare `/categoria/pagina/` in `/pagina/`, tradurre slug, rimuovere date o modificare la struttura delle categorie richiede un mapping completo.
Non cambiare URL solo perché una nuova struttura “sembra più SEO”. Il beneficio deve giustificare il rischio e il costo operativo del passaggio.
6. Redesign del sito
Un redesign può essere una migrazione SEO anche se gli URL restano identici, perché può rimuovere contenuto, link interni, breadcrumb, schema, heading, navigation path o componenti crawlable.
- Confronta contenuto principale old vs new.
- Confronta link interni.
- Confronta meta e heading.
- Confronta structured data.
- Verifica rendering mobile e desktop.
7. Migrazione di piattaforma
In e-commerce, cambiare piattaforma spesso modifica collection/category URL, product variants, pagination, faceted navigation e parametri.
Non limitare il mapping alle pagine prodotto. Categorie, filtri indicizzabili, immagini, PDF e asset che ricevono traffico possono essere parte dell’inventario.
8. Migrazione hosting
Se cambia solo l’infrastruttura e gli URL rimangono identici, Google tratta il caso separatamente dalle migrazioni con cambio URL.
- Copia e testa il sito sulla nuova infrastruttura.
- Usa un ambiente di test con accesso controllato.
- Verifica che Googlebot possa raggiungere l’infrastruttura quando previsto.
- Controlla firewall/CDN/WAF.
- Valuta di abbassare il DNS TTL prima dello switch.
- Monitora log su vecchio e nuovo hosting durante la propagazione.
Dopo un cambio hosting è normale vedere una variazione temporanea del crawl rate. Il segnale critico è se Googlebot incontra errori, timeout o rallentamenti persistenti.
9. Fusione di più siti
Unire più domini in uno solo è una migrazione ad alta complessità.
- Evita mapping many-to-one indiscriminato.
- Consolida solo contenuti realmente equivalenti.
- Preserva sezioni con domanda e backlink.
- Gestisci conflitti di intent e cannibalizzazione.
- Mantieni un inventario per ogni dominio sorgente.
10. Separare domini o sezioni
Il percorso inverso — spostare una directory su un nuovo dominio o separare un sito per mercato — richiede un mapping altrettanto rigoroso.
Non assumere che la struttura nuova erediti automaticamente tutti i segnali. Ogni URL deve essere raggiunta, canonica, coerente e collegata al nuovo contesto.
Principio critico: cambia una cosa alla volta quando possibile
Google raccomanda esplicitamente di sequenziare i grandi cambiamenti invece di eseguirli tutti insieme.
| Esempio più sicuro: 1. Cambio dominio 2. Stabilizzazione 3. Cambio CMS 4. Stabilizzazione 5. Redesign Esempio più rischioso: Dominio + CMS + URL + design + contenuti nello stesso rilascio |
Non è sempre possibile separare tutto. Se il progetto impone un unico lancio, aumenta il livello di QA, documentazione, monitoraggio e rollback planning.
11. Crea una baseline pre-migrazione
Prima di toccare il sito salva una fotografia dello stato attuale. Senza baseline non puoi distinguere un problema nuovo da uno che esisteva già.
- Traffico organico.
- Clic e impressioni.
- Ranking principali.
- Conversioni e revenue.
- URL indicizzate.
- Backlink.
- Status code.
- Canonical.
- Internal link.
12. Crawla il vecchio sito
Esegui un crawl completo e salvalo. È il tuo inventario tecnico di riferimento.
- URL.
- Status code.
- Title e meta description.
- H1.
- Canonical.
- Meta robots.
- Hreflang.
- Structured data.
- Inlinks e outlinks.
- Click depth.
- Immagini e asset importanti.
13. Esporta i ranking
Salva un set di query prioritarie e relative landing page.
- Branded.
- Non-branded.
- Transactional.
- Informational.
- Local/market-specific.
Il ranking export non deve diventare l’unico KPI. Serve soprattutto per capire quali query e URL sono sensibili alla migrazione.
14. Esporta i backlink
Recupera le pagine che ricevono link esterni, in particolare quelle con referring domains forti o traffico referral.
Una URL con poco traffico ma backlink importanti non deve sparire dal mapping.
15. Esporta traffico e conversioni
Usa GA4 e, se presente, CRM/e-commerce per capire quali URL generano valore.
- Landing page organiche.
- Lead.
- Revenue.
- Qualified leads.
- Assisted conversions.
16. Identifica le top page
Crea una lista di pagine critiche che devono essere controllate manualmente prima e dopo il lancio.
- Top traffic.
- Top conversion.
- Top backlink.
- Top revenue.
- Top ranking.
- Pagine strategiche BOFU.
17. Costruisci la URL map
La redirect map è il cuore della migrazione con cambio URL.
| Old URL | New URL | Action | Reason | Priority |
| /vecchio-servizio/ | /nuovo-servizio/ | 301 | Equivalente diretto | Alta |
| /old-guide/ | /guida-aggiornata/ | 301 | Content merge | Alta |
| /vecchia-campagna/ | — | 404/410 | Nessuna sostituzione | Bassa |
| /prodotto-a/ | /prodotto-b/ | 301 | Sostituzione equivalente | Alta |
Una riga per ogni URL importante è preferibile a regole generiche non validate. Wildcard e regex possono accelerare il lavoro, ma vanno testate contro eccezioni reali.
18. Crawla lo staging
Non aspettare il launch day per scoprire che title, canonical o internal link sono spariti.
- Crawlability.
- Indexability.
- Canonical.
- Meta robots.
- Hreflang.
- Structured data.
- Internal links.
- Status code.
- Content parity.
19. Proteggi correttamente lo staging
Per un ambiente realmente privato, accesso IP/password è la scelta più robusta.
Se devi testare pubblicamente con un hostname temporaneo, Google documenta l’uso di noindex per evitare indicizzazione accidentale. Qualunque blocco temporaneo usi deve essere rimosso prima del go-live.
Uno dei peggiori errori di migrazione è lanciare il sito con noindex o robots.txt di staging ancora attivi.
20. Canonical
Le nuove pagine dovrebbero puntare con canonical alla versione finale corretta, normalmente self-referencing quando quella URL è la principale.
Aggiorna canonical da vecchi URL a nuovi URL e verifica che non puntino ancora al dominio staging o al vecchio dominio. Approfondisci nella guida al tag canonical SEO.
21. Hreflang
Se il sito è internazionale, aggiorna ogni annotazione hreflang con le nuove URL.
- URL nuove per ogni lingua/mercato.
- Return links coerenti.
- Canonical coerente con la propria variante.
- Nessun riferimento a staging o vecchi hostname.
22. Structured data
Un cambio template o CMS può far sparire o rompere dati strutturati che prima erano validi.
- Confronta i tipi di schema old vs new.
- Aggiorna URL e @id quando cambiano dominio o path.
- Aggiorna BreadcrumbList.
- Controlla immagini e riferimenti assoluti.
- Valida campioni con Rich Results Test e URL Inspection.
23. Title e meta description
Il redesign non dovrebbe riscrivere automaticamente title e meta di tutte le pagine senza una ragione.
Preserva ciò che funziona. Se vuoi ottimizzare snippet e migrare contemporaneamente, documenta quali pagine cambiano e perché.
24. Internal links
Dopo la migrazione i link interni dovrebbero puntare direttamente alle nuove URL, non affidarsi ai redirect.
- Menu.
- Breadcrumb.
- Body links.
- Related content.
- Footer.
- Sitemap HTML.
La guida sull’internal linking SEO ti aiuta a ricostruire cluster e gerarchia dopo il cambio di struttura.
25. Content parity
Una migrazione non è un semplice confronto di word count. Devi preservare il valore informativo e il ruolo dell’URL.
- Informazioni che generavano ranking.
- FAQ realmente utili.
- Dati e prove.
- Recensioni.
- Specifiche.
- Call to action.
- Contenuti localizzati.
Se il redesign elimina metà del contenuto utile, non puoi attribuire l’eventuale calo solo alla migrazione tecnica.
26. Analytics
Il tracking deve essere testato prima del lancio e ricontrollato subito dopo.
- GA4 tag.
- Key events.
- E-commerce events.
- Form.
- Call tracking.
- Cross-domain tracking quando necessario.
- Consent setup.
27. Search Console
Verifica le proprietà necessarie prima del lancio, non dopo.
- Vecchio dominio.
- Nuovo dominio.
- Varianti importanti.
- Sitemap.
- URL Inspection.
- Page Indexing.
Per cambi di dominio o sottodominio, usa Change of Address dove applicabile. Google ha aggiornato nel 2026 la guida per ricordare di gestire anche le varianti del dominio coinvolte.
28. Redirect 301/308
Google raccomanda redirect permanenti server-side quando gli URL cambiano.
301 e 308 non causano intrinsecamente una perdita di PageRank. Il rischio reale è mapping sbagliato, destinazioni irrilevanti, catene, loop, pagine finali deboli o segnali contraddittori.
Per implementazione e miti, consulta la guida sui redirect 301 SEO.
Mito: un 301 perde automaticamente “SEO”
No. Google dice esplicitamente che i redirect permanenti non causano perdita di PageRank. Questo non significa però che qualunque redirect preservi qualunque performance: la nuova pagina deve essere una destinazione valida e pertinente.
29. Gestione dei 404
Non tutte le vecchie URL devono avere un redirect.
- Pagina spostata → 301.
- Contenuto consolidato → 301 verso la pagina equivalente.
- Pagina eliminata senza sostituzione → 404/410.
- URL casuale/spam → 404.
La guida sugli errori 404 SEO spiega come distinguere URL normali da errori che hanno perso traffico o backlink.
30. Sitemap XML
Genera una sitemap con le URL finali e canoniche del nuovo sito e inviala in Search Console.
- Niente vecchi URL.
- Niente redirect.
- Niente 404.
- Niente URL noindex.
- Niente canonical verso altre pagine.
La guida alla sitemap XML SEO approfondisce questi controlli.
31. Robots.txt
Controlla il file del nuovo sito prima del go-live.
- Nessun Disallow globale rimasto dallo staging.
- Asset necessari non bloccati.
- Pattern aggiornati al nuovo CMS.
- Sitemap declaration corretta.
Ricorda: robots.txt gestisce il crawling, non è una direttiva di deindicizzazione. Vedi la guida robots.txt SEO.
32. Launch-day checks
- Homepage e top page rispondono 200.
- Vecchie top URL rispondono 301/308 verso la destinazione corretta.
- Nuove URL finali rispondono 200.
- robots.txt corretto.
- noindex di staging rimosso.
- canonical finale.
- hreflang aggiornato.
- analytics attivo.
- Search Console verificata.
- sitemap nuova disponibile.
- form e checkout funzionanti.
Criteri di go/no-go per il lancio
Prepara un elenco di percorsi critici: homepage, principali categorie, prodotti rappresentativi, servizi, form e varianti linguistiche. Per ciascuno documenta URL attesa, status, canonical, contenuto essenziale e azione commerciale. Un test superato su una sola pagina non approva un template intero.
Blocca il rilascio se questi percorsi ereditano noindex dallo staging, falliscono l’acquisto o rimandano a destinazioni non equivalenti. Le anomalie secondarie possono avere una correzione pianificata con responsabile e scadenza. Il verbale di lancio deve indicare versione distribuita, controlli completati, eccezioni e modalità di ripristino. Nella guida Google alle migrazioni con cambio URL trovi i passaggi per aggiornare i segnali del sito e monitorare il trasferimento.
33. Crawl post-lancio
Esegui almeno due crawl distinti.
Crawl del nuovo sito
- 200.
- Canonical.
- Indexability.
- Internal link.
- Hreflang.
- Structured data.
- Meta.
Crawl del vecchio inventario
- 301/308 previsti.
- 404/410 intenzionali.
- Nessun 5xx.
- Nessun loop.
- Nessuna destinazione staging.
34. Redirect validation
Il redirect test deve confrontare la URL prevista nella map con la URL finale realmente raggiunta.
- Status iniziale.
- Final status.
- Final URL.
- Numero di hop.
- Relevance check.
Googlebot può seguire catene, ma Google raccomanda di puntare direttamente alla destinazione finale e mantenere gli hop bassi.
35. Monitoring dell’indicizzazione
Controlla se Google sta sostituendo progressivamente vecchie URL con nuove URL.
- Page Indexing.
- Sitemap status.
- URL Inspection per pagine critiche.
- Canonical selected by Google.
- 404 e soft 404 inattesi.
36. Monitoring ranking e traffico
Confronta i trend con la baseline.
- Clic e impressioni.
- Ranking per cluster.
- Landing page.
- Non-branded traffic.
- Conversioni.
- Revenue.
Evita di reagire a ogni oscillazione giornaliera. Cerca pattern: directory, template, query o device che si comportano in modo anomalo.
37. Log monitoring
I log aiutano a vedere come Googlebot sta attraversando la migrazione.
- Richieste al vecchio sito.
- Richieste al nuovo sito.
- Crawl di redirect.
- 404 inattesi.
- 5xx.
- Crawl rate.
- URL non presenti nel mapping.
38. Rollback planning
Un rollback non deve essere improvvisato dopo il lancio.
- Backup verificato.
- Versione del codice precedente.
- Database snapshot.
- DNS/hosting rollback plan.
- Lista dei cambi reversibili.
- Owner e canale decisionale.
- Soglie severe che giustificano rollback.
Non rollbackare solo perché il ranking oscilla nei primi giorni. Un rollback è per errori tecnici seri, indisponibilità, mapping catastrofico o problemi che compromettono utenti e crawling.
39. Quanto dura il recupero dopo una migrazione?
Non esiste una timeline garantita.
Google indica che, per siti piccoli o medi, il passaggio delle nuove URL può richiedere alcune settimane; siti più grandi possono richiedere più tempo. La velocità dipende dal numero di URL, dalla capacità del server e da quanto rapidamente Googlebot riesce a ricrawlare vecchie e nuove URL.
Fluttuazioni temporanee non significano automaticamente che la migrazione sia fallita. Ma errori tecnici sistemici vanno corretti subito.
40. Errori di migrazione più comuni
- Lancio con noindex attivo.
- robots.txt che blocca sezioni importanti.
- Redirect verso URL inesistenti.
- Redirect massivi alla homepage.
- Catene e loop.
- Canonical verso vecchio dominio.
- Hreflang ancora sul vecchio hostname.
- Sitemap con vecchie URL.
- Internal link che passano dai redirect.
- Tracking rotto.
- Content parity non verificata.
- Pagine con backlink dimenticate.
- Capacità server insufficiente.
- Domain + CMS + redesign + content rewrite nello stesso rilascio senza QA adeguata.
Checklist pre-launch
- Crawl completo del vecchio sito salvato.
- Inventory CMS completato.
- Top page identificate.
- Backlink export salvato.
- Search Console baseline salvata.
- GA4/conversion baseline salvata.
- Ranking baseline salvato.
- URL map approvata.
- Staging crawl completato.
- Content parity verificata.
- Canonical/hreflang/schema verificati.
- Internal link aggiornati.
- Tracking testato.
- Rollback plan documentato.
Checklist launch
- 301/308 attivi.
- noindex staging rimosso.
- robots.txt corretto.
- Canonical finali.
- Hreflang finali.
- Structured data valido.
- Analytics live.
- Search Console pronta.
- Nuova sitemap live e inviata.
- Top redirect testati manualmente.
Checklist post-launch
- Crawl old URLs.
- Crawl new URLs.
- 404/410 review.
- Redirect validation.
- Indexation comparison.
- Traffic/ranking comparison.
- Log monitoring.
- External high-value links update.
- Ads/profile links update.
- Recurring monitoring dashboard.
SEO Migration Support: quando coinvolgere uno specialista
La migrazione è uno dei casi in cui il costo di prevenzione è normalmente più basso del costo di recupero.
- Cambio dominio.
- E-commerce con migliaia di URL.
- CMS/platform change.
- Fusione di siti.
- Sito internazionale con hreflang.
- Redesign che cambia navigation e content.
- Sito con forte dipendenza dall’organico.
SEO Migration Support può includere baseline, crawl, redirect map, staging QA, launch validation, Search Console, post-launch monitoring e prioritizzazione degli errori.
Per una revisione completa pre-lancio puoi partire da un audit SEO tecnico e usare la checklist SEO tecnica come controllo complementare.
Domande frequenti sulla migrazione SEO
Una migrazione SEO fa sempre perdere traffico?
No. Una migrazione ben preparata può mantenere gran parte della performance, ma fluttuazioni temporanee sono normali mentre Google ricrawla e reindicizza. Il rischio aumenta con errori di redirect, indexing, content parity e architettura.
Un redirect 301 perde PageRank?
Google afferma che 301 e altri redirect permanenti non causano intrinsecamente perdita di PageRank. La destinazione deve però essere corretta, pertinente e tecnicamente raggiungibile.
Quanto tempo dura una migrazione SEO?
Non c’è una durata fissa. Google indica alcune settimane o più per molti siti piccoli/medi e tempi maggiori per siti grandi, in base a volume di URL e capacità del server.
Devo usare Change of Address in Search Console?
Solo per un vero cambio di dominio o sottodominio. Non è richiesto per HTTP→HTTPS, www/non-www sullo stesso dominio o cambi di path interni.
Quanto tempo devo mantenere i redirect?
Google raccomanda di mantenerli il più a lungo possibile, in genere almeno un anno. Dal punto di vista utenti può avere senso mantenerli ancora più a lungo.
Posso cambiare dominio, CMS e design insieme?
Puoi, ma aumenta il rischio diagnostico. Google raccomanda di cambiare una cosa alla volta quando è possibile.
Devo bloccare lo staging con robots.txt?
Per staging privato è preferibile un controllo accessi. Se usi noindex o blocchi temporanei durante lo sviluppo, devi avere un controllo esplicito per rimuoverli prima del go-live.
Cosa faccio con vecchie URL senza una nuova pagina equivalente?
Se il contenuto è stato rimosso e non esiste una sostituzione pertinente, restituisci 404 o 410 invece di reindirizzare automaticamente tutto alla homepage.
Coinvolgi la SEO prima del lancio
Se stai cambiando dominio, CMS, struttura URL o design, coinvolgi la SEO prima del lancio. La maggior parte dei problemi di migrazione è molto più semplice da prevenire che da recuperare.
La migrazione dovrebbe avere owner, checklist, redirect map, baseline, piano di monitoraggio e responsabilità tecniche definite prima che il nuovo sito diventi pubblico.
