Migrazioni dei siti

In breve — Una migrazione del sito è qualsiasi grande modifica al sito web che può spostare gli URL o cambiare il modo in cui Google li interpreta: un nuovo dominio, il passaggio a HTTPS, una nuova piattaforma, la riorganizzazione delle cartelle o persino un redesign. Il modo per proteggere il traffico è sempre lo stesso: invia ogni vecchia pagina alla nuova pagina equivalente più vicina con un redirect 301 e mantieni i redirect a lungo. Un calo temporaneo del traffico è normale; se non recupera mai, qualcosa si è rotto.

Che cos’è una migrazione del sito

“Migrazione” suona drammatico e a volte lo è. Significa però soltanto una modifica significativa al sito che può influire sul modo in cui i motori di ricerca trovano, interpretano e posizionano le pagine. Spostarsi su un nuovo dominio è una migrazione. Passare da http:// a https:// è una migrazione. Spostare il blog da blog.example.com a example.com/blog/ è una migrazione. Anche un redesign che conserva tutti gli URL conta, perché cambiano contenuti e template che Google posiziona.

Questi interventi vengono raggruppati perché condividono lo stesso rischio e lo stesso metodo.

L’unica regola che conta davvero

Quando un URL cambia, devi dire ai browser e ai motori di ricerca dove si è spostata la pagina. Lo fai con un redirect, in particolare un redirect 301 permanente, che comunica «questa pagina si è trasferita qui in modo definitivo». Sono i redirect a trasferire davvero i ranking dai vecchi URL ai nuovi. Google afferma che i 301 e gli altri redirect permanenti non causano una perdita di PageRank.

La parte più importante: associa ogni vecchia pagina all’unica nuova pagina più pertinente. Non scaricare tutto sulla home page. Se una vecchia pagina prodotto non ha un vero equivalente, inviala alla categoria più vicina, non alla porta d’ingresso. Google tratta un insieme di vecchie pagine tutte reindirizzate alla home page come errori 404 — pagina non trovata —, quindi non ne ricavi alcun vantaggio.

Gli errori più comuni

• “I redirect mi fanno perdere il valore dei link.” No. I redirect permanenti non costano PageRank. Questo mito è morto da anni.
• “Lo strumento Cambio di indirizzo sposta il sito al posto mio.” No. Quello strumento di Google Search Console si limita a comunicare a Google il passaggio a un nuovo dominio: il lavoro concreto lo svolgono i redirect. Inoltre funziona soltanto per trasferimenti di un intero dominio, non per il passaggio a HTTPS o la riorganizzazione delle cartelle.
• “Il traffico è calato, quindi la migrazione è fallita.” Di solito non è così. Una temporanea oscillazione mentre Google rielabora il sito è normale. Concedigli qualche settimana. Prova a sostegno di questa affermazione Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Ambito: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Site move with URL changes
• “Posso rimuovere i redirect dopo pochi mesi.” Mantienili molto più a lungo: idealmente per anni e, dove possibile, di fatto per sempre.

Cambia una cosa alla volta

Il rischio maggiore di qualsiasi migrazione è cambiare troppe cose insieme. Un nuovo dominio, una nuova piattaforma e una nuova struttura degli URL nello stesso giorno sono tre migrazioni sovrapposte, e i rischi si moltiplicano. Se puoi suddividere un grande cambiamento in fasi, fallo.

Vuoi il processo completo — le sette fasi, la strategia dei redirect e una checklist specifica per ogni tipo di migrazione? Passa alla scheda Avanzato.

In breve — Il rischio di una migrazione è dato da quantità di cambiamento × quanto realizzi contemporaneamente. I redirect 301/308 sono la spina dorsale: trasferiscono i ranking e non perdono PageRank; tutto il resto — strumento Cambio di indirizzo, sitemap, link interni e canonical — è un segnale di supporto. Associa vecchio→nuovo in rapporto 1:1, non reindirizzare in massa verso la home page — sarebbe un soft 404 —, evita le catene e conserva i redirect ben oltre l’indicazione dei “12 mesi”. Aspettati un’oscillazione temporanea seguita da un recupero; un calo permanente significa che qualcosa si è rotto: di solito un blocco dello staging rimasto attivo, hreflang o canonical rimossi, un noindex fuori posto oppure redirect verso le pagine sbagliate. Di seguito trovi il processo universale in 7 fasi e poi ciascuno dei 7 tipi di migrazione con le relative insidie.

Questo hub tratta classificazione, principi, modello di rischio, decisioni per tipo di migrazione e diagnosi del recupero. Usa la Checklist per la migrazione di un sito web per la sequenza operativa delle attività, i responsabili nominati, i gate di rilascio e i criteri di accettazione.

Che cos’è davvero una migrazione — e i 7 tipi

Una migrazione del sito è qualsiasi modifica significativa a struttura degli URL, dominio, piattaforma, protocollo o hosting che possa influire sul modo in cui i motori di ricerca eseguono scansione, indicizzazione e ranking. L’etichetta comprende tutto: da un passaggio a HTTPS in una sola riga fino al rebranding completo che sposta centinaia di migliaia di URL su un nuovo dominio e un nuovo CMS.

La cosa più utile da fare prima di scrivere un solo redirect è classificare la migrazione e riconoscere che la maggior parte delle migrazioni reali comprende più tipi insieme. Ecco i sette tipi, ordinati approssimativamente per rischio:

I numeri corrispondono all’ordine delle sezioni nell’analisi per tipo più avanti; la tabella è ordinata per rischio, così puoi individuare dove si colloca il tuo caso. Rischio = quanto cambi × quanto cambi contemporaneamente. Un redesign sugli stessi URL comporta un rischio basso. Un cambio di dominio insieme a ristrutturazione degli URL e cambio di piattaforma somma tre tipi ad alto rischio: Google stesso consiglia di cambiare una cosa alla volta.

Il processo universale di migrazione

Questo processo si applica a ogni tipo di migrazione, prima di aggiungere i passaggi specifici descritti sotto. Ne ho gestite molte e il filo comune di tutte quelle riuscite è lo stesso: perché una migrazione abbia successo, una checklist non basta. La checklist evita che tu dimentichi dei passaggi; sono il processo e il coinvolgimento della SEO in ogni fase a farla funzionare davvero.

Fase 1 — Pianificazione

• Classifica ogni tipo coinvolto. Un cambio di piattaforma che ristruttura anche gli URL e passa a un nuovo dominio rappresenta tre migrazioni insieme. Nominale tutte in anticipo per definire il rischio reale.
• Definisci le aspettative con la dirigenza prima del lancio, non dopo. Quasi certamente il traffico oscillerà. Spiega agli stakeholder che un calo temporaneo è normale e previsto, affinché un’oscillazione ordinaria non scateni un rollback dettato dal panico.
• Prepara sempre un piano di rollback. Devi sempre poter tornare allo stato originale, anche se prevedi di farlo soltanto in circostanze estreme.
• Programma il lancio in un periodo di poco traffico. Google stesso consiglia, se possibile, di far coincidere il trasferimento con un traffico ridotto. In pratica: da lunedì a giovedì, non il venerdì né durante il picco stagionale delle vendite, così ci sono persone disponibili per correggere i problemi e meno ricavi a rischio durante la stabilizzazione.
• Assegna un project manager SEO e usa un sistema di gestione dei progetti. Le migrazioni coinvolgono sviluppo, contenuti, analytics e SEO; qualcuno deve possedere la mappa delle dipendenze.

Fase 2 — Crea il benchmark ed esegui la scansione del vecchio sito

Non puoi svolgere il QA di una migrazione senza un’immagine del “prima”. Acquisiscila mentre il vecchio sito è ancora attivo:

• Scansione completa del vecchio sito — Screaming Frog, Ahrefs Site Audit o equivalente. Salvala: sarà il confronto di riferimento dopo il lancio.
• Acquisisci tutto per ogni URL: codici di stato, titoli, meta description, tag canonical, hreflang, struttura dei titoli, struttura dei link interni e Core Web Vitals.
• Fotografa i ranking di tutte le pagine principali prima del lancio.
• Esporta i benchmark del traffico: dati sulle prestazioni di Search Console — ultimi 3/6/12 mesi — e GA4 a livello di pagina e sessione.
• Esporta le pagine principali per backlink — Ahrefs più il report Link di GSC. Sono gli URL che devono assolutamente reindirizzare correttamente, perché trasportano il valore dei link.
• Raccogli ogni redirect esistente da tutte le fonti: CMS, CDN, configurazione .htaccess o del server, report Pagina con redirect di Search Console e analytics. Se dimentichi una fonte, dopo il lancio creerai catene di redirect.
• Controlla i problemi preesistenti prima di trasferirli. Un nuovo dominio o CMS non è una scusa per importare vecchi errori di canonical, eccesso di indice o blocchi di scansione.

Fase 3 — Mappatura degli URL

Crea un foglio uno a uno: ogni vecchio URL → il suo unico nuovo URL più pertinente. Nessuna eccezione: per ogni URL deve essere presa una decisione.

• Pagine rimosse con un equivalente vicino: reindirizzale alla pagina attiva più pertinente per argomento. Google è esplicito: non reindirizzare molti vecchi URL verso una singola destinazione irrilevante, come la home page. Prova a sostegno di questa affermazione Google advises against redirecting many old URLs to one irrelevant destination such as the home page and says that can be treated as a soft 404. Ambito: Google Search guidance for site moves with changed URLs; relevant replacements remain appropriate. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Site move with URL changes
• Pagine senza alcun equivalente: restituisci un vero 410 — non più disponibile — o 404. Non reindirizzarle alla home page: verrebbe trattato come soft 404.
• Seguire i singoli URL è la parte più importante, perché offre una mappa chiara di ciò che ogni URL era e di ciò che deve diventare. Questa mappa è la migrazione.

Fase 4 — Strategia dei redirect

Questa è la spina dorsale dell’intero progetto.

• Usa 301 — Spostato definitivamente — o 308 per i trasferimenti permanenti. Google consiglia redirect permanenti lato server, come 301 e 308.
• I 301 trasferiscono PageRank, punto. La documentazione di Google afferma che i redirect permanenti non causano una perdita di PageRank e Gary Illyes ha confermato anni fa che i redirect 30x non perdono più PageRank. Qualsiasi guida sostenga che i redirect permanenti disperdono il valore dei link è obsoleta. Prova a sostegno di questa affermazione Google says 301 and other permanent redirects do not cause a loss in PageRank. Ambito: Google Search handling of permanent redirects during site moves; this does not guarantee unchanged rankings after a migration. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Site move with URL changes
• Evita le catene di redirect. Collega direttamente vecchio → nuovo. Google dice di mantenere corte le catene: idealmente non più di 3 e meno di 5. Googlebot segue fino a circa 10 passaggi, quindi le catene brevi non sono fatali, ma ogni passaggio può rompersi e ritarda il consolidamento dei segnali. Una causa silenziosa frequente è l’incoerenza della barra finale — /page rispetto a /page/: scegli una forma canonica e reindirizza l’altra.
• Reindirizza anche le risorse: immagini, PDF e altri file non HTML, non soltanto le pagine.
• Soltanto lato server. I redirect JavaScript sono l’ultima risorsa; Google potrebbe non elaborarli mai se il rendering fallisce.
• Non confondere temporaneo e permanente. Un 302/307 non comunica alla pipeline di indicizzazione che la destinazione debba diventare canonica: il vecchio URL rimane indicizzato e i segnali restano perlopiù fermi. Usa redirect temporanei soltanto per situazioni davvero temporanee.
• Conserva i redirect ben oltre “un anno”. La soglia minima indicata da Google è “at least 1 year” (traduzione) «almeno 1 anno», ma Illyes ha chiarito che il valore di circa 12 mesi serve soprattutto a Google: gli utenti apprezzeranno se manterrai i redirect di fatto per sempre. Bing propende per un minimo di 1–2 anni. La mia regola è conservarli finché i vecchi URL ricevono traffico o link, che in pratica significa a tempo indeterminato. Prova a sostegno di questa affermazione Google recommends keeping site-move redirects as long as possible, generally for at least one year. Ambito: Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Site move with URL changes

Fase 5 — Staging e test prima del lancio

• Impedisci l’indicizzazione dello staging: noindex e/o una regola Disallow in robots.txt sull’host di staging. Limita l’accesso al sito di staging o sviluppo per evitare che venga indicizzato fin dall’inizio. Annota questo blocco per la Fase 6: al lancio deve essere rimosso.
• Usa un hostname temporaneo — per esempio beta.example.com — per i test pubblici.
• Prova ogni redirect da vecchio a nuovo. Spesso si reindirizza verso URL sbagliati e inesistenti: scansiona l’elenco completo dei vecchi URL nello staging e verifica che ciascuno raggiunga la pagina attiva prevista in un solo passaggio.
• Confronta la scansione dello staging con il benchmark della Fase 2: titoli, meta description, tag canonical, hreflang, dati strutturati, meta robots, link interni e velocità.
• Conferma che i canonical puntino al sito attivo, non agli URL di staging.
• Verifica che gli strumenti analytics si attivino — GA4, verifica GSC e tag manager — e prova moduli, checkout e altri percorsi di conversione.
• Assicurati che Googlebot non sia bloccato da firewall o protezione DoS: conferma che possa raggiungere DNS e host.

Fase 6 — Lancio

• Rimuovi subito ogni blocco di scansione: elimina il noindex e le regole di robots.txt dello staging usate soltanto durante la preparazione. È il disastro di migrazione più comune: pubblicare mantenendo attivo il blocco dello staging. Non dimenticare di eliminare ogni blocco noindex o robots.txt necessario soltanto per la migrazione.
• Attiva contemporaneamente tutti i redirect 301.
• Aggiorna e invia di nuovo la sitemap XML di produzione attuale, contenente soltanto i nuovi URL canonici. Se una sitemap dei vecchi URL fosse utile per scoprire o monitorare i redirect, inviala come sitemap separata e chiaramente temporanea; non mescolare mai inventari vecchi e nuovi e rimuovila quando non fornisce più informazioni utili. Consulta la guida di Google al trasferimento del sito.
• Controlla un campione di redirect con lo strumento Controllo URL di GSC.
• Invia lo strumento Cambio di indirizzo, soltanto per trasferimenti a livello di dominio — consulta il Tipo 1.
• Per Bing, invia tramite IndexNow, il meccanismo attuale. Il vecchio strumento Site Move di Bing è stato ritirato intorno al 2021: ignora le guide che consigliano ancora di usarlo. IndexNow permette di inviare in una volta tutti gli URL migrati dopo una migrazione.
• Garantisci capacità al server. Subito dopo il trasferimento Google eseguirà sul nuovo sito una scansione più intensa del solito.

Fase 7 — Monitoraggio dopo il lancio

• Aspettati un’oscillazione temporanea. Google dice di attendersi oscillazioni temporanee nel ranking del sito durante il trasferimento. Un calo non dimostra che la migrazione sia fallita. Martin Splitt ha sottolineato che, se copi letteralmente l’intera struttura degli URL e i contenuti su un nuovo dominio, potresti anche non osservare alcun calo.
• Conosci le tempistiche. Google afferma che per spostare nell’indice la maggior parte delle pagine di un sito medio possono servire alcune settimane; i siti più grandi richiedono più tempo. La stabilizzazione completa spesso richiede un paio di mesi.
• Diagnostica i cali che non recuperano. Quasi mai dipendono dal semplice “trasferimento”. L’indicazione più utile di Gary Illyes sulle migrazioni è che i cali dopo il trasferimento sono di solito causati da tag o direttive mancanti o anomali sul nuovo sito: hreflang rimossi, un noindex in più, canonical rotti. Controlla prima questo elenco.
• Esegui in blocco il QA dei redirect: ripeti la scansione del vecchio elenco di URL e conferma che ciascuno restituisca un 301 verso la pagina attiva corretta, senza catena né 404 finale.
• Controlla la selezione canonica. Se molti link esterni — e link interni dimenticati — puntano ancora al vecchio URL, Google può continuare a indicizzare il vecchio URL anziché il nuovo. Per questo aggiornare i link interni è importante quanto i redirect e conviene contattare chi gestisce i link più importanti: i nuovi link diretti battono quelli reindirizzati.
• Monitora in GSC: report Indicizzazione delle pagine, Prestazioni — clic e impression per pagina —, Statistiche di scansione ed eventuali nuove azioni manuali. Registra i ranking ogni settimana per il primo mese. Bing consiglia di controllare i log del server per almeno tre mesi dopo la migrazione.

Il redirect ha funzionato? Misura l’impatto senza ingannarti

Non giudicare una migrazione da uno screenshot del giorno del lancio. Definisci vecchi e nuovi URL, gruppi di query e pagine e metriche prima del lancio, quindi analizza le stesse coorti in quattro momenti di controllo:

Per ogni controllo confronta il periodo successivo al cambiamento con un periodo precedente equivalente ed escludi il giorno del cambiamento. Il giorno del lancio mescola vecchio e nuovo stato, distribuzioni parziali, modifiche alla cache, traffico di QA e discontinuità nel tracciamento; assegnarlo a uno dei due lati contamina il confronto. Mantieni fisse le definizioni di coorti e metriche e segmenta per brand/non-brand, dispositivo, paese, template o tipo di migrazione soltanto se tali suddivisioni facevano parte del piano di misurazione.

Prima di attribuire un guadagno o una perdita, annota gli altri cambiamenti avvenuti nella finestra: rilasci, aggiornamenti dei contenuti, modifiche al tracciamento, stagionalità, campagne e storico degli aggiornamenti di ranking confermati da Google. Un aggiornamento algoritmico sovrapposto non rende la migrazione innocente né colpevole: confonde l’attribuzione, quindi dichiara l’incertezza e affidati maggiormente a prove dirette dell’implementazione, come test delle risposte, copertura dell’indice, selezione canonica e log del server.

“Nessuna variazione” è un risultato valido. Il compito di un redirect è spesso preservare accesso, segnali e conversioni durante lo spostamento degli URL. Prestazioni stabili con risposte pulite in un solo passaggio possono indicare successo. Registra questo risultato, anziché cercare una storia di crescita che i dati non sostengono.

Il futuro Before/After Impact Checker appartiene a questo punto del flusso di lavoro: quando sarà disponibile, potrà standardizzare l’esclusione del giorno del cambiamento e i confronti a 7/14/30/90 giorni. Fino ad allora usa un foglio di calcolo o un livello di reporting e salva con ogni controllo intervalli di date, filtri, coorte e annotazioni esatti.

I 7 tipi di migrazione

Il processo universale descritto sopra rappresenta la maggior parte del lavoro. Di seguito trovi ciò che è specifico di ciascun tipo: le insidie e le attività indispensabili che spesso colgono i team impreparati.

Tipo 1 — Cambio di dominio / rebranding

Che cos’è: spostare tutte le pagine da oldbrand.com a newbrand.com: nuovo dominio, nuova proprietà GSC e, idealmente, nessun cambiamento simultaneo alla struttura degli URL.

Rischio: massimo. Ogni URL cambia, i link esterni devono essere aggiornati e lo storico di GSC viene diviso tra due proprietà.

Insidie e attività indispensabili:

• Non combinare il cambio di dominio con un redesign e una ristrutturazione degli URL. La documentazione di Google sul Cambio di indirizzo avverte che abbinare il trasferimento del dominio a un redesign dei contenuti e della struttura degli URL comporterà probabilmente una perdita di traffico. Sposta prima il dominio e ristruttura in seguito.
• Esamina lo storico del nuovo dominio prima di registrarlo. Controlla archive.org: un dominio già registrato e con precedenti azioni manuali può mettere subito il nuovo brand in difficoltà.
• Non lasciare scadere il vecchio dominio. Continua a rinnovarlo e mantieni attivi i redirect; se scade e qualcun altro lo registra, i redirect — e il valore dei link — spariscono.
• Non concatenare i cambi di dominio — A → B e subito dopo B → C. Lo strumento Cambio di indirizzo non può essere concatenato.

Lo strumento Cambio di indirizzo: che cosa fa e che cosa non fa. È qui che nasce la maggior parte della confusione. Lo strumento comunica a Google di dare priorità alla scansione e all’indicizzazione del nuovo sito, inoltra i segnali e privilegia i canonical del nuovo sito per 180 giorni. È fondamentale sapere che:

• Funziona per il trasferimento di un dominio o sottodominio senza ambito di percorso, non per spostare singole pagine o cartelle all’interno di un sito.
• Devi essere proprietario verificato di proprietà Search Console idonee sia vecchie sia nuove. È idonea una proprietà Dominio e può esserlo anche una proprietà Prefisso URL radice; una proprietà Prefisso URL limitata a un percorso non lo è. Consulta i requisiti del Cambio di indirizzo e la guida di Google sull’idoneità delle proprietà.
• È un trasferimento rigorosamente 1:1: non può essere usato per fusioni o spostamenti parziali.
• È facoltativo, non obbligatorio. È un segnale in più; se i redirect sono configurati correttamente, puoi farne a meno. Il vero lavoro è svolto dai 301: lo strumento si limita ad accelerare e chiarire il messaggio. Nel cluster Strumenti per i motori di ricerca trovi un approfondimento dedicato al Cambio di indirizzo.

La finestra di 180 giorni non è una scadenza per i redirect. Dopo 180 giorni Google non riconosce più tramite lo strumento la relazione tra vecchio e nuovo sito e considera il vecchio sito non correlato. Proprio per questo i redirect devono sopravvivere allo strumento. Mantienili per almeno un anno — il minimo indicato da Google — e, realisticamente, molto più a lungo.

Tipo 2 — HTTP → HTTPS

Che cos’è: passare da HTTP non cifrato a HTTPS — TLS/SSL. Ogni URL cambia da http:// a https://. HTTPS è un segnale di ranking, seppur leggero, dal 2014; oggi restare su HTTP costituisce uno svantaggio concreto.

Rischio: basso–medio se eseguito correttamente; alto se emergono problemi con il certificato o contenuti misti.

Insidie e attività indispensabili:

• NON usare lo strumento Cambio di indirizzo. Google dice esplicitamente di seguire le linee guida per il trasferimento del sito nel passaggio HTTP → HTTPS.
• Usa redirect 301 per ogni URL, non una regola generale che invii tutto alla home page HTTPS. Quanto più chiaramente comunichi che si tratta soltanto di un cambio generico di protocollo, tanto più agevolmente Google completerà il passaggio.
• Correggi i contenuti misti. Qualsiasi risorsa — immagine, script o foglio di stile — ancora caricata via HTTP dopo il passaggio genera avvisi di contenuto misto e segnali contrastanti. Usa URL relativi al protocollo o relativi; una Content Security Policy upgrade-insecure-requests è un modo rapido per intercettare gli elementi rimasti.
• Google preferisce automaticamente HTTPS come canonical, tranne in presenza di certificato non valido, dipendenze non sicure — contenuti misti —, redirect di ritorno a HTTP o altri segnali contrastanti. Un certificato mal configurato non produce soltanto una brutta impressione: può mantenere canonica la versione HTTP.
• Fai attenzione a HSTS. HSTS impone ai browser di connettersi soltanto tramite HTTPS per un periodo stabilito. Se lo abiliti prima che TLS sia solidissimo, un errore del certificato diventa un blocco totale per i visitatori di ritorno. Aggiungilo dopo aver raggiunto la sicurezza necessaria, partendo da un valore max-age basso e aumentandolo nel tempo.
• Usa un certificato robusto — RSA a 2048 bit o EC; punta ad A/A+ nel test SSL di Qualys — e imposta il flag Secure sui cookie.

Tipo 3 — Cambio di piattaforma / CMS

Che cos’è: passare a un nuovo CMS o stack tecnologico — per esempio WordPress → headless oppure Magento → Shopify. Spesso trascina con sé modifiche a URL, template, link interni e rendering.

Rischio: alto, perché cambiano più elementi contemporaneamente.

Insidie e attività indispensabili:

• Prevedi cambiamenti agli URL: piattaforme diverse generano strutture degli slug, gerarchie di categorie e paginazione diverse. Pianifica la mappa degli URL prima di impegnarti con una piattaforma, non dopo.
• I redirect non vengono trasferiti automaticamente. Un errore classico è non copiare sul nuovo host i vecchi redirect presenti nei file .htaccess. Raccogli le regole da tutte le fonti — CMS, CDN, configurazione del server e report Pagina con redirect di GSC — prima di costruire il nuovo livello di redirect.
• Reimplementa i dati strutturati: non presumere che il markup schema venga trasferito. Convalidalo dopo il lancio.
• Prova il rendering JavaScript se passi a un front end headless o SPA: il rendering cambia il modo in cui Googlebot elabora le pagine. Il rendering dei contenuti, soprattutto JavaScript, è uno degli aspetti che verifico più attentamente nel QA dopo la migrazione.
• Crea un benchmark di velocità e mobile. I nuovi temi sono spesso più pesanti; Google indicizza la versione mobile, quindi conferma che la nuova piattaforma non sia più lenta né difettosa sui dispositivi mobili.
• Imponi coerenza alla barra finale: piattaforme diverse la gestiscono in modo diverso e l’incoerenza crea silenziosamente catene di redirect.
• Distribuisci di nuovo i tag analytics e di verifica — GA4, GSC e tag manager — sulla nuova piattaforma prima del lancio.
• Una ristrutturazione seria in cui URL, link interni e template cambiano tutti insieme impedisce a Google di conservare semplicemente la precedente comprensione del sito: aspettati una stabilizzazione più lunga rispetto a un trasferimento equivalente.

Tipo 4 — Struttura degli URL / ristrutturazione del sito

Che cos’è: cambiare i percorsi degli URL sullo stesso dominio, per esempio /category/post/ → /post/. Il dominio resta invariato; i contenuti possono cambiare o no.

Rischio: medio. L’autorevolezza del dominio resta intatta, ma ogni URL modificato richiede un redirect e il grafo dei link interni deve essere aggiornato.

Insidie e attività indispensabili:

• I link interni sono la parte che tutti dimenticano. Vedo continuamente lo stesso schema: si reindirizzano gli URL ma non si aggiornano rel=canonical, navigazione, footer o link nel corpo. Questi segnali obsoleti rendono molto più difficile per Google scegliere i nuovi URL come canonici, anche quando i redirect sono presenti.
• La canonicalizzazione può tardare. Se il vecchio URL ha più backlink e i link interni vi puntano ancora, Google potrebbe continuare a preferirlo come canonical dopo il 301. È fondamentale aggiornare i link interni direttamente ai nuovi URL.
• NON usare lo strumento Cambio di indirizzo per le ristrutturazioni sullo stesso dominio. L’indicazione di Google è semplice: aggiungi i redirect e aggiorna le sitemap.
• Aggiorna breadcrumb, navigazione e sitemap con i nuovi percorsi. Le sitemap devono elencare soltanto i nuovi URL.

Tipo 5 — Redesign del sito web — stessi URL

Che cos’è: un redesign in cui dominio e URL restano invariati, ma cambiano template, testi, navigazione, immagini o elementi SEO on-page. È il tipo a rischio più basso, ma il rischio non è zero.

Rischio: basso, ma i cambiamenti on-page possono comunque spostare i ranking.

Insidie e attività indispensabili:

• Gli elementi on-page si rompono in silenzio. I redesign rimuovono o alterano regolarmente tag <title>, meta description, struttura dei titoli e dati strutturati. Mappa e verifica ciascuno rispetto al benchmark del vecchio sito.
• Controlla i link interni. Un redesign della navigazione può rimuovere silenziosamente link interni di grande valore che trasmettevano autorevolezza alle pagine profonde.
• Crea un benchmark dei Core Web Vitals prima e dopo. Nuovi CSS, JS, font e immagini modificano quasi sempre la velocità delle pagine.
• Gestisci consapevolmente le modifiche ai contenuti. I redesign “con lo stesso URL” spesso assottigliano o consolidano i contenuti: non presumere che una pagina più povera renda allo stesso modo.
• La guida di Google al trasferimento del sito senza modifiche agli URL è il riferimento: tratta come ridurre l’impatto quando cambiano infrastruttura o presentazione, ma non gli URL.

Tipo 6 — Sottodominio ↔ sottocartella

Che cos’è: spostare contenuti tra un sottodominio e una sottocartella, più comunemente blog.example.com → example.com/blog/. Il consolidamento riunisce in un solo luogo l’autorevolezza prima divisa tra due host.

Rischio: medio–alto. Per molti scopi Google tratta sottodomini e dominio radice come entità separate, quindi il consolidamento provoca una reale instabilità durante la nuova indicizzazione.

Insidie e attività indispensabili:

• Per Google le due versioni sono entità separate: budget di scansione distinto e segnali in parte separati. Consolidare in una sottocartella è spesso positivo nel complesso, ma richiede tempo e si comporta come un vero trasferimento.
• NON usare lo strumento Cambio di indirizzo per spostamenti sottodominio → sottocartella sulla stessa radice; appartengono alla stessa categoria del caso www/non-www, che Google dice di gestire con canonical e redirect, non con lo strumento.
• Proprietà GSC: probabilmente hai proprietà separate per sottodominio e radice. Dopo il consolidamento, i dati confluiscono nella proprietà radice: osserva la copertura del sottodominio diminuire e quella della radice crescere.
• Reindirizza ogni URL del sottodominio al suo equivalente nella sottocartella e aggiorna i link interni affinché puntino direttamente ai nuovi URL, non attraverso il redirect. L’intero profilo backlink del sottodominio confluisce nel dominio principale tramite i 301; contattare i proprietari dei link principali resta utile.
• Riconcilia analytics: se il sottodominio usava un tracciamento proprio o cross-domain, riconfigura GA4 per non perdere continuità.

Tipo 7 — Consolidamento di domini / fusione di siti

Che cos’è: riunire due o più siti distinti in uno, per esempio integrando i contenuti di un concorrente acquisito nel dominio principale oppure fondendo i siti separati di un brand per paese o prodotto.

Rischio: molto alto. Non è affatto una migrazione standard: non esiste un trasferimento 1:1 da segnalare e, sotto molti aspetti, per Google l’entità risultante è di fatto un nuovo sito. Come ha spiegato Martin Splitt, combinare due siti non è più una migrazione, quanto piuttosto la creazione di un nuovo sito da una versione amalgamata.

Insidie e attività indispensabili:

• Non puoi usare lo strumento Cambio di indirizzo. Richiede un trasferimento 1:1 da un dominio a un altro; una fusione non lo è. Il lavoro va svolto URL per URL.
• Aspettati una certa perdita di traffico. Google avverte che spostare i siti A, B e C tutti verso una nuova destinazione D può creare confusione e perdita di traffico. Pianifica un periodo di stabilizzazione prolungato.
• Elimina prima i duplicati. Se i siti da fondere si sovrappongono per argomento, la fusione crea contenuti duplicati. Scegli la pagina canonica per ogni argomento sovrapposto prima di reindirizzare.
• Redirect per ogni URL verso la pagina più pertinente: non reindirizzare in blocco un intero dominio acquisito alla home page — sarebbe un soft 404 per tutto tranne la home page. Il valore dei link a livello di pagina si trasferisce meglio quando ciascuna pagina raggiunge il proprio vero equivalente.
• Mantieni una proprietà GSC per ogni sito coinvolto nella fusione e monitora la copertura di ciascuno — è prevista una diminuzione — insieme al dominio principale — è prevista una crescita.

Scegli la guida specializzata

Usa la guida corrispondente alla decisione o alla modalità di errore che devi risolvere:

• SEO per la migrazione dell’hosting — per modifiche a server, CDN, DNS o hosting che mantengono stabili gli URL.
• SEO per la migrazione del CMS — per cambi di piattaforma e CMS, compresi i rischi relativi a template, rendering e parità dei dati.
• Migrazione della struttura degli URL — per cambiamenti di percorso, tassonomia o cartella sullo stesso dominio.
• Migrazione SEO per la separazione o lo scorporo di un sito — per spostare una sezione definita di un sito in una proprietà separata.
• Integrazione SEO dopo un’acquisizione — per decidere come integrare siti, brand e contenuti acquisiti.
• Perdita di traffico dopo una migrazione — per diagnosticare visibilità o traffico che non recuperano dopo il lancio.

Il suo posto nel quadro generale

Una migrazione coinvolge molti argomenti adiacenti: i redirect che la trasferiscono, la canonicalizzazione che decide quale URL Google conserva, il protocollo HTTPS, hreflang sui siti internazionali e lo strumento Cambio di indirizzo che segnala un trasferimento di dominio. Ciascuno merita un approfondimento dedicato, ma la spina dorsale di ogni migrazione è la stessa: associa vecchio e nuovo 1:1, usa redirect permanenti, conservali e poi monitora i segnali giusti.

Riepilogo IA

Una sintesi della versione Avanzata:

• Una migrazione del sito è qualsiasi grande modifica a URL, dominio, piattaforma, protocollo o host che possa influire su scansione, indicizzazione e ranking. Rischio = quantità di cambiamento × quanto cambi contemporaneamente.
• I 7 tipi, per rischio: redesign — stessi URL, basso — → HTTP→HTTPS — basso–medio — → ristrutturazione degli URL — medio — → sottodominio↔sottocartella — medio–alto — → cambio di CMS — alto — → cambio di dominio/rebranding — massimo — → fusione/consolidamento di domini — molto alto.
• Processo universale in 7 fasi: pianifica e classifica → crea il benchmark ed esegui la scansione del vecchio sito → costruisci una mappa URL 1:1 → definisci la strategia dei redirect → testa staging e pre-lancio → lancia → monitora dopo il lancio.
• I redirect 301/308 sono la spina dorsale. Trasferiscono i ranking e non perdono PageRank. Tutto il resto — strumento Cambio di indirizzo, sitemap, link interni e canonical — è un segnale di supporto.
• Associa vecchio→nuovo in rapporto 1:1. Non reindirizzare mai in massa alla home page — sarebbe trattato come soft 404. Evita le catene — resta sotto circa 3–5 passaggi. Conserva i redirect ben oltre “12 mesi”, di fatto per sempre a beneficio degli utenti.
• Aspettati un’oscillazione temporanea e un recupero. Un calo persistente di solito indica che qualcosa si è rotto — blocco dello staging ancora attivo, hreflang o canonical rimossi, noindex fuori posto o redirect verso pagine sbagliate —, non il semplice trasferimento.
• Strumento Cambio di indirizzo: soltanto a livello di dominio, rigorosamente 1:1 e facoltativo. Non serve per HTTP→HTTPS, ristrutturazioni sullo stesso dominio o fusioni.
• Bing: il vecchio strumento Site Move è stato ritirato intorno al 2021; usa IndexNow per inviare gli URL migrati. Bing propende per mantenere i redirect almeno 1–2 anni.

Documentazione ufficiale

Documentazione delle fonti primarie dei motori di ricerca.

Google

• Trasferimento del sito con modifiche agli URL — il manuale principale per la migrazione: redirect, tempistiche, aspettative e conservazione dei redirect per circa 1 anno.
• Trasferimento del sito senza modifiche agli URL — cambiamenti di hosting, infrastruttura e redesign; hostname temporanei e precauzioni per DNS, firewall e DoS.
• Redirect e Ricerca Google — redirect permanenti rispetto a quelli temporanei e rischio dei redirect JavaScript.
• Strumento Cambio di indirizzo — Guida di Search Console — ambito di trasferimento supportato, prerequisiti delle proprietà, esclusioni e indicazioni sui redirect.
• Consolidare gli URL duplicati — preferenza canonica per HTTPS e motivo per cui un 301 è un segnale canonico più forte di un redirect temporaneo.
• Canonicalizzazione — come Google seleziona un URL canonico: un suggerimento, non una direttiva.
• Abilitare HTTPS sui server — web.dev — certificati TLS, contenuti misti e indicazioni HSTS; la vecchia documentazione HTTPS di Google ora reindirizza qui.

Bing / Microsoft

• Migrazione di un sito web con Bing — il modello di migrazione di Bing, la durata dei redirect e il monitoraggio dei log dopo la migrazione.
• IndexNow — il meccanismo attuale per inviare a Bing gli URL migrati; il vecchio strumento Site Move è stato ritirato.

Citazioni dalle fonti

Dichiarazioni ufficiali di Google. Ogni collegamento è un deep link che porta al passaggio citato nella pagina di origine.

Google — redirect e PageRank

• “301 and other permanent redirects don’t cause a loss in PageRank.” (traduzione) «I 301 e gli altri redirect permanenti non causano una perdita di PageRank.» — Search Central, trasferimento del sito con modifiche agli URL. Vai alla citazione
• “keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5” (traduzione) «Mantieni basso il numero di redirect nella catena, idealmente non più di 3 e meno di 5.» — Search Central, trasferimento del sito con modifiche agli URL. Vai alla citazione
• “Keep the redirects for as long as possible, generally at least 1 year.” (traduzione) «Mantieni i redirect il più a lungo possibile, generalmente per almeno 1 anno.» — Search Central, trasferimento del sito con modifiche agli URL. Vai alla citazione
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page” (traduzione) «Non reindirizzare molti vecchi URL verso un’unica destinazione URL irrilevante, come la home page.» — Search Central, trasferimento del sito con modifiche agli URL. Vai alla citazione

Google — aspettative e tempistiche

• “Expect temporary fluctuation in site ranking during the move.” (traduzione) «Aspettati un’oscillazione temporanea del ranking del sito durante il trasferimento.» — Search Central, trasferimento del sito con modifiche agli URL. Vai alla citazione
• “a medium-sized website can take a few weeks for most pages to move in our index” (traduzione) «Per un sito web di medie dimensioni possono servire alcune settimane affinché la maggior parte delle pagine si sposti nel nostro indice.» — Search Central, trasferimento del sito con modifiche agli URL. Vai alla citazione
• “Check your redirects from the old site to the new one. We frequently see people redirecting to the wrong (non-existent) URLs.” (traduzione) «Controlla i redirect dal vecchio sito a quello nuovo. Vediamo spesso persone reindirizzare verso URL sbagliati e inesistenti.» — Search Central, trasferimento del sito con modifiche agli URL. Vai alla citazione

Google — strumento Cambio di indirizzo — finestra di 180 giorni

• “Maintain the redirects for at least 180 days—longer if you still see any traffic to them from Google Search.” (traduzione) «Mantieni i redirect per almeno 180 giorni, più a lungo se ricevono ancora traffico dalla Ricerca Google.» — Guida di Search Console, Cambio di indirizzo. Leggi la fonte
• “After the 180 day period, Google does not recognize any relationship between the old and new sites, and treats the old site as an unrelated site.” (traduzione) «Dopo il periodo di 180 giorni, Google non riconosce alcuna relazione tra il vecchio e il nuovo sito e considera il vecchio sito non correlato.» — Guida di Search Console, Cambio di indirizzo. Leggi la fonte

Google — canonical HTTPS e segnali dei redirect

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” (traduzione) «Google preferisce come canoniche le pagine HTTPS rispetto alle equivalenti HTTP, tranne quando esistono problemi o segnali contrastanti.» — Search Central, consolidare gli URL duplicati. Vai alla citazione
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (traduzione) «Googlebot segue il redirect, ma la pipeline di indicizzazione non usa il redirect come segnale che la destinazione debba essere canonica.» (a proposito dei redirect temporanei) — Search Central, redirect e Ricerca Google. Vai alla citazione

Google — precauzioni per lancio e infrastruttura

• “Make sure it does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers.” (traduzione) «Assicurati che non blocchi la capacità di Googlebot di raggiungere il DNS o i server del provider di hosting.» (firewall / protezione DoS) — Search Central, trasferimento del sito senza modifiche agli URL. Vai alla citazione
• “it’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days.” (traduzione) «È normale osservare un calo temporaneo della frequenza di scansione di Googlebot subito dopo il lancio, seguito da un aumento costante nei giorni successivi.» (trasferimenti di server o hosting) — Search Central, trasferimento del sito senza modifiche agli URL. Vai alla citazione

Checklist principale per la migrazione

Eseguila per ogni migrazione, indipendentemente dal tipo, quindi aggiungi sotto l’elenco specifico.

Prima del lancio

• Classificato ogni tipo di migrazione coinvolto ed evitato di sovrapporre tipi ad alto rischio.
• Stakeholder informati che un calo temporaneo è normale; lancio programmato in un periodo di poco traffico.
• Piano di rollback documentato e collaudato.
• Scansione completa del vecchio sito salvata come benchmark per il QA.
• Esportati ranking, prestazioni GSC — 3/6/12 mesi —, GA4 e pagine con più backlink.
• Raccolto ogni redirect esistente da CMS, CDN, configurazione del server e report Pagina con redirect di GSC.
• Costruita una mappa URL vecchio→nuovo uno a uno — decisione per ogni URL; pagine rimosse → 410/404, non home page.
• Piano dei redirect basato su 301/308, un solo passaggio e nessuna catena, incluse immagini e PDF.
• Staging bloccato dall’indicizzazione — noindex e/o robots.txt — e blocco annotato per la rimozione al lancio.
• Scansione dello staging confrontata con il benchmark: titoli, meta, canonical, hreflang, dati strutturati, meta robots, link interni e velocità.
• Canonical sullo staging diretti agli URL attivi, non agli URL di staging.
• Provato ogni redirect vecchio→nuovo, con arrivo alla pagina prevista in un solo passaggio.
• Tag analytics e di verifica presenti; moduli e percorsi di conversione collaudati.
• Confermato che la protezione firewall/DoS non blocchi Googlebot.

Giorno del lancio

• Rimossi tutti i blocchi di scansione dello staging — noindex e robots.txt — e verificata la versione attiva.
• Attivati tutti i redirect 301.
• Sitemap XML di produzione attuali aggiornate con i soli nuovi URL canonici e inviate di nuovo in GSC.
• Se utile, inviata una sitemap separata e temporanea dei vecchi URL per scoprire o monitorare i redirect, con responsabile e condizione di rimozione.
• Controllato un campione di redirect con Controllo URL di GSC.
• Inviato lo strumento Cambio di indirizzo — soltanto per trasferimenti a livello di dominio.
• URL migrati inviati a Bing tramite IndexNow.
• Confermata la capacità del server per la maggiore scansione successiva al lancio.

Dopo il lancio

• Ripetuta in blocco la scansione del vecchio elenco di URL; ogni URL restituisce un 301 verso la pagina attiva corretta.
• Link interni aggiornati per puntare direttamente ai nuovi URL, senza link obsoleti ai vecchi.
• Monitorati in GSC Indicizzazione delle pagine, Prestazioni per pagina, Statistiche di scansione e azioni manuali.
• Ranking registrati ogni settimana per il primo mese.
• Contattati i proprietari dei principali link esterni per farli aggiornare.
• Pianificato di mantenere attivi i redirect per anni, non soltanto per i 180 giorni dello strumento.
• Se il traffico cala e non recupera, controllati prima hreflang rimossi, noindex fuori posto, canonical rotti e redirect errati.

Checklist specifiche per tipo

Tipo 1 — Cambio di dominio / rebranding

• Controllato lo storico del nuovo dominio — archive.org — e garantiti i rinnovi del vecchio dominio.
• Confermata la proprietà verificata delle proprietà GSC idonee, vecchie e nuove, senza ambito di percorso: proprietà Dominio o Prefisso URL radice, non Prefisso URL limitato a un percorso.
• Presente un 301 dalla vecchia home page alla nuova, obbligatorio per lo strumento.
• Canonical, link interni e sitemap aggiornati in tutto il sito con il nuovo dominio.
• Cambio di indirizzo inviato per ogni sottodominio e variante www/non-www.
• File disavow trasferito alla nuova proprietà; intervento non combinato con redesign o ristrutturazione.

Tipo 2 — HTTP → HTTPS

• Certificato valido — RSA/EC a 2048 bit —, Qualys A/A+; 301 per ogni URL da http→https, non redirect generale alla home page.
• Contenuti misti individuati e corretti — URL relativi o relativi al protocollo; CSP upgrade-insecure-requests.
• Canonical, sitemap, robots.txt e hreflang tutti aggiornati a HTTPS; flag Secure sui cookie.
• HSTS aggiunto soltanto dopo aver confermato la stabilità di TLS, iniziando da un max-age basso.
• Strumento Cambio di indirizzo non usato; applicate invece le linee guida per il trasferimento del sito.

Tipo 3 — Cambio di piattaforma / CMS

• Mappa vecchio→nuovo costruita prima di rendere definitiva la piattaforma.
• Regole di redirect raccolte da CMS, CDN, configurazione del server e GSC, senza perdere le regole .htaccess.
• Convenzione della barra finale imposta; dati strutturati ricostruiti e convalidati.
• Rendering JavaScript collaudato — se headless/SPA —; rendering mobile e velocità delle pagine confrontati con il benchmark.
• GA4, GSC e tag manager distribuiti di nuovo sulla nuova piattaforma.

Tipo 4 — Struttura degli URL / ristrutturazione

• Mappa completa vecchio→nuovo costruita; 301 implementati per ogni URL.
• Aggiornati TUTTI i link interni — navigazione, breadcrumb, footer, corpo e widget dei post correlati.
• rel=canonical aggiornato ai nuovi URL; sitemap contenenti soltanto i nuovi URL.
• Strumento Cambio di indirizzo non usato — sullo stesso dominio basta reindirizzare e aggiornare le sitemap.
• Nuovo sito sottoposto a scansione per confermare che nessun link interno punti ancora a vecchi URL con redirect.

Tipo 5 — Redesign del sito web — stessi URL

• Elementi on-page — titoli, descrizioni, H1, canonical e dati strutturati — salvati dal vecchio sito e confrontati dopo il lancio.
• Link interni di grande valore conservati durante il redesign della navigazione.
• Core Web Vitals confrontati con il benchmark prima e dopo.
• Modifiche ai contenuti consapevoli, senza assottigliamento accidentale; analytics ancora attivi.

Tipo 6 — Sottodominio ↔ sottocartella

• Sottodominio sottoposto a scansione; costruita la mappa completa blog.example.com/post/ → example.com/blog/post/.
• 301 da ogni URL del sottodominio al suo equivalente nella sottocartella; link interni aggiornati per puntare direttamente ai nuovi URL.
• Strumento Cambio di indirizzo non usato per spostamenti sulla stessa radice.
• Monitorate entrambe le proprietà GSC — copertura del sottodominio in calo e della radice in crescita —; analytics riconfigurati.

Tipo 7 — Consolidamento / fusione di domini

• Controllato ogni sito da fondere — scansione, ranking, backlink e GSC.
• Contenuti sovrapposti deduplicati; pagina canonica scelta per ogni argomento prima dei redirect.
• 301 per ogni URL verso la pagina più pertinente, mai un redirect generale alla home page.
• Strumento Cambio di indirizzo non usato — non esiste un trasferimento 1:1 da segnalare —; pianificata una stabilizzazione prolungata.
• Mantenuta una proprietà GSC per ciascun sito da fondere; copertura monitorata su ognuno e sul dominio principale.

I modelli mentali

1. Rischio = quantità di cambiamento × quanto cambi contemporaneamente. Prima di tutto, classifica i tipi coinvolti. Un redesign sugli stessi URL è un singolo cambiamento a basso rischio; cambio di dominio, ristrutturazione degli URL e nuova piattaforma insieme sono tre tipi ad alto rischio che si sommano. Se puoi introdurre il cambiamento per fasi, fallo: cambia una cosa alla volta.

2. I redirect svolgono il lavoro; tutto il resto si limita a inviare segnali. I 301 sono il meccanismo che trasferisce i ranking. Lo strumento Cambio di indirizzo, l’invio delle sitemap, l’aggiornamento dei link interni e i canonical sono tutti segnali di supporto che aiutano i motori di ricerca a elaborare il trasferimento più rapidamente e con maggiore chiarezza. Costruisci prima i redirect; considera il resto un acceleratore, non un sostituto.

3. La mappatura 1:1 batte il redirect di tutto alla home page. Ogni vecchio URL viene associato al suo unico nuovo URL più pertinente. Una massa di redirect verso la home page viene trattata come soft 404: nessun vantaggio e perdita del valore dei link a livello di pagina che cercavi di conservare. Nessun equivalente? Usa un vero 410/404, non la home page.

4. La finestra dello strumento non è la durata del redirect. Lo strumento Cambio di indirizzo inoltra i segnali per 180 giorni. I redirect devono sopravvivergli per anni: mantienili finché i vecchi URL ricevono traffico o link. Sono due tempistiche e quella più lunga — dei redirect — è ciò che rende stabile il trasferimento.

5. Un calo è normale; un calo bloccato è un errore. Aspettati un’oscillazione temporanea e un recupero nell’arco di qualche settimana o di un paio di mesi. Se il traffico non ritorna, non accusare “il trasferimento”: cerca i soliti responsabili, come un blocco dello staging rimasto attivo, hreflang rimossi, un noindex fuori posto, canonical rotti o redirect diretti alle pagine sbagliate.

6. Per la selezione canonica, i link interni contano quanto i redirect. Puoi reindirizzare tutto perfettamente e vedere comunque Google continuare a indicizzare il vecchio URL se navigazione, footer, link nel corpo e link esterni puntano ancora lì. Aggiorna i link interni affinché raggiungano direttamente i nuovi URL e contatta i proprietari dei link esterni più importanti.

Scheda di riferimento per le migrazioni

Quale tipo di redirect usare e quando

Quale strumento o segnale per quale migrazione

Equivalenti di Bing

Dati rapidi

• I 301 non perdono PageRank: il mito è morto intorno al 2016.
• Catene di redirect: resta sotto circa 3–5 passaggi — Googlebot ne segue circa 10.
• 180 giorni è la finestra del Cambio di indirizzo, non una scadenza per i redirect. Mantienili di fatto per sempre.
• Tempistica della nuova indicizzazione: “alcune settimane” per un sito medio, più a lungo per i siti grandi.
• Causa principale di un calo persistente: tag mancanti o anomali sul nuovo sito — hreflang, noindex e canonical —, non il trasferimento.

Qual è il tipo di migrazione e si applica il Cambio di indirizzo?

Percorri l’albero una volta per la modifica più grande, poi ripetilo per ogni cambiamento aggiuntivo incluso nello stesso rilascio. Un cambio di piattaforma che modifica anche percorsi e dominio rappresenta tre migrazioni, non una.

Playbook: il traffico è calato dopo il lancio e non recupera

Usalo quando l’oscillazione prevista dopo il lancio non si stabilizza. Procedi dai problemi di accesso che riguardano tutto il sito ai conflitti di segnale a livello di URL; non accusare “il trasferimento” finché non hai escluso errori di implementazione.

Passaggio 1 — Conferma che il calo sia reale e definiscine l’ambito. Confronta le stesse pagine, query, mercati e definizioni analytics acquisite nel benchmark prima del lancio. Se è scomparso soltanto il reporting, correggi prima la misurazione. Se i vecchi URL perdono visibilità mentre i nuovi equivalenti la guadagnano, continua a monitorare il normale passaggio. Se la perdono entrambi, passa al Passaggio 2.

Passaggio 2 — Cerca un blocco di scansione o indicizzazione esteso all’intero lancio. Recupera la produzione come crawler e controlla robots.txt, meta robots, X-Robots-Tag, autenticazione, risposte del firewall, DNS e codici di stato. Se sono arrivati in produzione un noindex dello staging, Disallow: /, un muro di autenticazione o un blocco dei bot, rimuovili e ripeti subito la scansione. Se la produzione è accessibile e indicizzabile, continua.

Passaggio 3 — Esegui di nuovo l’intera mappa di redirect dal vecchio al nuovo. Prova l’inventario completo dei vecchi URL, iniziando dalle pagine con più link e traffico. Se gli URL terminano in 404, destinazioni irrilevanti, loop o catene, correggi le associazioni e appiattisci ogni percorso verso l’URL equivalente finale. Se i redirect si risolvono correttamente in un solo passaggio, continua.

Passaggio 4 — Confronta le nuove pagine con il benchmark. Confronta canonical, hreflang, titoli, intestazioni, contenuto del corpo, dati strutturati, link interni e HTML visibile dopo il rendering. Se un tag comune a tutto il template è scomparso o punta allo staging o ai vecchi URL, correggi il template prima delle singole pagine. Se la parità è intatta, continua.

Passaggio 5 — Controlla i segnali di consolidamento. Conferma che i nuovi URL siano autocanonici, che link interni e navigazione vi puntino direttamente e che le sitemap di produzione attuali contengano soltanto i nuovi URL canonici. Se hai inviato una sitemap separata dei vecchi URL per il monitoraggio, conferma che sia ancora utile e rimuovila quando non lo è più. In Controllo URL esamina un campione dei canonical selezionati da Google. Se Google continua a scegliere URL vecchi o non correlati, elimina link, canonical e voci di sitemap in conflitto, quindi attendi una nuova scansione.

Passaggio 6 — Controlla capacità e dati del server. Leggi le statistiche di scansione e i log di accesso per verificare codici di risposta e attività di Googlebot sul nuovo host. Se errori, latenza, limiti di frequenza o controlli del firewall aumentano durante il picco di scansione successivo al trasferimento, ripristina capacità o accesso. Se la scansione è in salute, approfondisci i gruppi di pagine rimanenti per tipo di migrazione e template.

Passaggio 7 — Usa il piano di rollback soltanto per una regressione pubblicata e dimostrata. Torna indietro quando viene raggiunta la soglia concordata e il confronto delle scansioni collega il calo a un difetto reversibile di template, piattaforma o configurazione. Non eseguire il rollback soltanto per la volatilità del primo giorno: un secondo trasferimento imprevisto aggiunge un’altra migrazione che i motori di ricerca devono elaborare.

Miti sulle migrazioni che causano problemi reali

“I redirect permanenti perdono valore dei link.” Perché è falso: Google afferma che i redirect permanenti non perdono PageRank. Il rischio concreto è una destinazione sbagliata, una catena, un loop o un vicolo cieco, non il 301. Che cosa fare: associa direttamente ogni vecchio URL all’equivalente più vicino e verifica la risposta finale.

“Il Cambio di indirizzo sposta il sito al posto mio.” Perché è falso: lo strumento è un segnale facoltativo di supporto per il trasferimento rigoroso di un intero dominio. Non crea redirect e non supporta passaggi a HTTPS, ristrutturazioni dei percorsi, spostamenti parziali o fusioni di domini. Che cosa fare: costruisci prima la mappa dei redirect, poi usa lo strumento soltanto quando il suo ambito corrisponde.

“Qualsiasi calo del traffico dimostra che la migrazione è fallita.” Perché è falso: sono previste oscillazioni temporanee di ranking e scansione e, quando si usa una sitemap separata dei vecchi URL, del passaggio tra sitemap, mentre i motori di ricerca elaborano il trasferimento. Che cosa fare: concorda benchmark e criteri di rollback prima del lancio, poi diagnostica un calo persistente o spiegato da problemi strutturali invece di reagire al rumore ordinario.

“I redirect possono essere rimossi dopo pochi mesi.” Perché è falso: l’indicazione di un anno di Google è il minimo per l’elaborazione, non una data di scadenza per preferiti, backlink o utenti. Che cosa fare: conserva i redirect finché i vecchi URL ricevono traffico o link — in genere a tempo indeterminato — e mantieni il controllo del vecchio dominio.

Strumenti per mappare e verificare una migrazione

• Generatore della mappa dei redirect — incolla gli insiemi di vecchi e nuovi URL per creare una proposta di mappa 301 con livelli di confidenza, righe senza corrispondenza, elenco 410, appiattimento delle catene, modifiche manuali ed esportazioni per piattaforma. Ogni suggerimento richiede comunque una verifica editoriale dell’equivalenza prima del lancio.
• Mappatore delle catene di redirect — traccia ogni passaggio e osserva stato, cambi di host o percorso, meta refresh e regole di pulizia. Usalo su campioni dello staging e sugli errori dopo il lancio, dove possono sovrapporsi regole per barra, protocollo o dominio.
• Controllo dei redirect — conferma rapidamente stato finale, passaggi e destinazione per un singolo URL o un piccolo gruppo. Usa un crawler completo per l’intero inventario dei vecchi URL: i controlli a campione non possono dimostrare la validità di tutta la mappa.
• Un crawler dell’intero sito — salva il benchmark precedente alla migrazione, prova l’elenco completo dei redirect e confronta titoli, canonical, hreflang, direttive, link, schema e rendering.
• Google Search Console — usa Indicizzazione delle pagine, Prestazioni, Sitemap, Statistiche di scansione, Controllo URL e — soltanto per il trasferimento idoneo di un intero dominio — Cambio di indirizzo.
• Log di accesso al server — dimostrano se i bot di ricerca raggiungono il nuovo host, quali risposte ricevono e se i vecchi URL vengono ancora richiesti prima di ritirare l’infrastruttura.

Dimostra che la migrazione è stata pubblicata come previsto dalla mappa

Prova completa dei redirect dei vecchi URL

• Prova da eseguire: scansiona in produzione l’inventario completo dei vecchi URL della Fase 2 ed esamina gli errori con il Mappatore delle catene di redirect o il Controllo dei redirect.
• Risultato atteso: ogni URL spostato restituisce un solo passaggio 301 o 308 lato server verso l’equivalente previsto; gli URL rimossi intenzionalmente restituiscono il 404 o 410 pianificato.
• Interpretazione di un errore: una risposta 200 sul vecchio URL, una catena, un loop, una destinazione irrilevante o un 404 non pianificato indicano che la mappa dei redirect o l’ordine delle regole non sono stati pubblicati come approvato.
• Finestra di monitoraggio: subito dopo il lancio, poi ripeti mentre vengono distribuite le correzioni e durante la prima finestra di monitoraggio, quando i vecchi URL sono ancora sottoposti a scansione frequente.
• Soglia di rollback: una regola sistemica di mappatura invia una sezione protetta importante a destinazioni sbagliate o la rende irraggiungibile e non può essere corretta in sicurezza senza rollback.

Prova di indicizzabilità e canonical delle nuove pagine

• Prova da eseguire: scansiona il nuovo insieme di URL per stato, direttive robots e canonical, quindi usa Controllo URL su un campione di pagine di grande valore.
• Risultato atteso: le nuove pagine restituiscono 200, non sono bloccate né noindex e dichiarano il nuovo canonical previsto; dopo una nuova scansione, Google riporta il canonical previsto sui campioni.
• Interpretazione di un errore: una direttiva dello staging estesa all’intero sito, un canonical vecchio o di staging, una richiesta di autenticazione o un canonical diverso selezionato da Google segnalano una configurazione di lancio in conflitto.
• Finestra di monitoraggio: i segnali tecnici sono immediati; la selezione canonica di Google e il movimento nell’indice richiedono una nuova scansione e possono impiegare settimane su un sito medio, più a lungo su larga scala.
• Soglia di rollback: un blocco di scansione o indicizzazione esteso alla produzione oppure un difetto del canonical nel template riguarda l’insieme protetto e non può essere rimosso rapidamente senza annullare il rilascio.

Prova delle destinazioni di link e sitemap

• Prova da eseguire: scansiona i link interni e analizza le sitemap inviate, confrontando ogni destinazione con l’insieme approvato dei nuovi URL canonici.
• Risultato atteso: navigazione e link interni puntano direttamente ai nuovi URL e le sitemap di produzione attuali elencano soltanto nuovi URL canonici con risposte valide. L’eventuale sitemap dei vecchi URL è separata, temporanea e associata a una condizione di rimozione.
• Interpretazione di un errore: vecchi link interni, inventari misti di vecchi e nuovi URL nelle sitemap o una sitemap dei vecchi URL mantenuta dopo che smette di fornire informazioni utili possono rallentare o nascondere il passaggio dal vecchio al nuovo.
• Finestra di monitoraggio: immediata nel sito renderizzato e nei file sitemap; conferma che la sitemap inviata venga elaborata durante il monitoraggio dopo il lancio.
• Soglia di rollback: una regressione di navigazione o del generatore di sitemap estesa a tutto il template invia i crawler verso URL vecchi, di staging o non canonici e non può essere corretta rapidamente in sicurezza.

Risorse che meritano il tuo tempo

I miei articoli correlati

• Perché una migrazione del sito abbia successo, una checklist non basta — la mia guida completa alle migrazioni, con l’elenco degli errori comuni e la checklist di monitoraggio dopo il lancio.
• Redirect per la SEO: guida per principianti — tipi di redirect, catene e durata consigliata.
• È giusto rimuovere i redirect 301 dopo un anno? Lo abbiamo verificato — l’esperimento diretto alla base del consiglio di conservare i redirect a lungo.
• Canonicalizzazione: guida per principianti — come Google sceglie un canonical, importante quando vecchi e nuovi URL competono dopo un trasferimento.
• Guida per principianti alla SEO tecnica — il posto delle migrazioni nel quadro generale.

Fonti ufficiali

• Trasferimento del sito con modifiche agli URL — il manuale principale di Google per le migrazioni.
• Strumento Cambio di indirizzo — ambito di trasferimento supportato da Google, prerequisiti delle proprietà e indicazioni sui redirect.
• Migrazione di un sito web con Bing — il modello di Bing e le indicazioni sulla durata dei redirect.

Da altri autori

• r/TechSEO — dove vengono analizzati i casi limite delle migrazioni e i cali dopo il lancio.
• Mueller di Google sulle chiavi di una migrazione riuscita — Search Engine Journal; tratta mappatura degli URL, link interni e perché i soli redirect non bastano.
• Google: una migrazione pulita richiede tempo, una improvvisata molto di più — Search Engine Roundtable; i consigli di Mueller sulle fusioni di siti e il costo delle scorciatoie.
• Nel passaggio da HTTP a HTTPS, Google consiglia i redirect 301 — Search Engine Land; Mueller raccomanda 301 per ogni URL nei trasferimenti HTTPS anziché redirect generali.
• Migrazione di un sito web con Bing — Bing Webmaster Blog; il modello di migrazione in 8 passaggi, la durata dei redirect — 1–2 anni — e il monitoraggio dei log dopo la migrazione.
• Spostare i domini: evitare le insidie — Bing Webmaster Blog; indicazioni sul controllo dello storico del nuovo dominio e sull’errore di usare un canonical come sostituto del redirect.
• Abilitare HTTPS sui server — web.dev; riferimento principale per certificati TLS, contenuti misti e configurazione HSTS durante le migrazioni HTTP→HTTPS.

Google consiglia di conservare i redirect di trasferimento del sito il più a lungo possibile, in genere almeno un anno. Prova a sostegno di questa affermazione Google recommends keeping site-move redirects as long as possible, generally for at least one year. Ambito: Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Site move with URL changes Dice di aspettarsi oscillazioni temporanee dei ranking e che per spostare nell’indice la maggior parte delle pagine di un sito medio possono servire alcune settimane. Prova a sostegno di questa affermazione Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Ambito: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Site move with URL changes Quando possibile, Google consiglia di cambiare una sola cosa importante alla volta.

Mettiti alla prova: migrazioni dei siti

Cinque domande su tipi di migrazione, redirect e diagnosi dopo il lancio. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche