Michele Eccher
In questa guida
Una migrazione SEO ben gestita conserva significato e reperibilità delle pagine di valore mentre il sito cambia. Prima del lancio, fotografa la situazione di partenza, censisci i vecchi URL, assegna a ciascuno una destinazione pertinente e verifica il nuovo sito. Al momento del rilascio, attiva redirect permanenti diretti e rendi coerenti canonical, link interni e sitemap. Dopo il lancio, monitora scansione, indicizzazione, visibilità e conversioni fino alla stabilizzazione del nuovo sistema, mantenendo i redirect per almeno un anno.
Una migrazione comprende qualsiasi intervento capace di modificare il modo in cui i motori di ricerca trovano, recuperano, comprendono o selezionano le pagine. Il cambio di dominio è il caso più evidente, ma presentano rischi simili anche il passaggio a un nuovo CMS, la riorganizzazione degli URL, l’espansione internazionale, la migrazione da HTTP a HTTPS, un redesign o il passaggio da HTML generato dal server a un’applicazione JavaScript. Anche con URL invariati, la rimozione di elementi di navigazione e le modifiche a template o contenuti renderizzati possono cambiare ciò che Google riceve.
L’obiettivo non è immobilizzare il vecchio sito, ma rendere ogni cambiamento intenzionale e misurabile. Anche un lancio riuscito può generare oscillazioni temporanee mentre i motori di ricerca scansionano e valutano i nuovi URL. Un processo controllato consente al team di distinguere questa fase fisiologica da un redirect errato, un contenuto mancante o un template bloccato.
Dati di partenza, inventario, mappatura URL e piano di verifica
Redirect, segnali, controlli di scansione e decisione sul rilascio
Monitora, diagnostica, correggi e mantieni attivi i redirect
Stabilisci che cosa deve cambiare e che cosa conviene mantenere stabile
Definisci per iscritto il perimetro delle modifiche. Elenca sistemi, template, URL, contenuti, percorsi di navigazione e mercati interessati dal rilascio, quindi individua ciò che non ha motivo di cambiare. Conservare l’intento di ricerca, i testi, i titoli e le relazioni interne delle pagine che già funzionano riduce le variabili da analizzare dopo il passaggio alla nuova piattaforma.
Cambio di dominio o sottodominio
Tutti gli URL cambiano host. Verifica di avere accesso alle vecchie e nuove proprietà di Search Console, mantieni i percorsi quando ha senso e pianifica certificato, DNS e capacità del server oltre ai redirect.
Cambio di piattaforma o CMS
L’URL visibile può rimanere invariato mentre cambiano rendering, metadati, dati strutturati, paginazione e codici di stato. Confronta ciò che il sistema produce, non il nome delle funzionalità del nuovo CMS.
Riorganizzazione dell’architettura o degli URL
Cambiano categorie, cartelle e relazioni tra le pagine. Verifica che la nuova gerarchia continui a rispondere alle esigenze del pubblico e che le destinazioni importanti restino raggiungibili attraverso link scansionabili.
Redesign o rifacimento del front-end
Cambiano template, componenti e navigazione, talvolta senza un’attività SEO dedicata. Controlla la completezza dei contenuti, il comportamento su mobile, l’HTML iniziale, il risultato dopo il rendering e tutti i percorsi gestiti dal codice eseguito nel browser.
Se il team deve ancora scegliere tra un restyling visivo, un rifacimento strutturale o un intervento circoscritto, consulta la guida su restyling o rifacimento del sito prima di definire il perimetro della migrazione. Una volta scelta la strada, un audit SEO tecnico fornisce la base per verificare template, rendering e indicizzazione.
Costruisci un quadro di partenza che permetta di capire che cosa è cambiato
Il quadro di partenza non è una presentazione sul traffico storico: è l’insieme dei dati necessari per analizzare il rilascio. Raccogli le informazioni per singolo URL e template, così un calo complessivo può essere ricondotto a una sezione, un mercato, un gruppo di query o una specifica condizione tecnica. Fotografa la situazione abbastanza vicino al lancio da rappresentare il sito attuale, ma conserva periodi più lunghi per leggere stagionalità e tendenze.
| Situazione di partenza | Che cosa rilevare | Perché serve dopo il lancio |
|---|---|---|
| Risultati organici | Clic, impressioni, query, pagine di destinazione, Paesi e dispositivi | Mostra dove sono cambiate domanda o visibilità , senza nascondere tutto in un unico dato aggregato. |
| Risultati commerciali | Lead, fatturato, eventi dei moduli, percorsi assistiti e pagine di maggior valore | Distingue la transizione nella ricerca da un problema nel percorso di conversione o nel tracciamento. |
| Stato di scansione e indicizzazione | Campioni di URL indicizzati, copertura della sitemap, statistiche di scansione e risposte del server | Offre un riferimento per valutare con quale velocità vengono elaborati vecchi e nuovi URL. |
| Inventario del sito | URL rilevabili, canonical, codici di stato, metadati e link interni | Evidenzia pagine scomparse, direttive modificate e URL generati in modo imprevisto. |
| Riferimenti esterni | URL con link importanti, destinazioni delle campagne, segnalibri e integrazioni | Aiuta a dare priorità ai redirect da mantenere e agli aggiornamenti necessari fuori dal sito. |
Combina più fonti invece di affidarti a un solo crawler. I dati di analytics possono far emergere pagine che ricevono visite ma non sono più collegate internamente. Search Console può mostrare pagine di destinazione assenti dalla sitemap attuale, mentre i log del server rivelano vecchi percorsi ancora richiesti da motori di ricerca o clienti. Dati sui backlink, campagne a pagamento, template email e documenti offline aggiungono URL che una scansione del sito non può scoprire.
Prima del rilascio in produzione, esegui un’ultima scansione del vecchio sito e conservane il risultato. Salva HTML, screenshot e dati strutturati di esempi rappresentativi dei template più importanti. Non serve creare un archivio completo: l’obiettivo è avere un riferimento funzionante quando la nuova pagina si comporta in modo diverso.
Assegna a ogni vecchio URL di valore una destinazione precisa
La mappa dei redirect è un registro di decisioni, non una formula automatica di sostituzione. Per ogni vecchio URL stabilisci se esiste una nuova pagina equivalente, se il contenuto è confluito in una pagina più ampia o se è stato realmente eliminato. Rispetta sempre l’intento originario: una pagina prodotto non dovrebbe portare alla home page soltanto perché entrambe appartengono alla stessa azienda.
Reindirizza direttamente alla nuova pagina più pertinente. Verifica che la destinazione contenga il contenuto previsto e restituisca un codice 200 senza ulteriori passaggi.
Usa il redirect soltanto se la nuova destinazione risponde davvero allo stesso bisogno. Documenta perché più pagine vengono accorpate e quali ricerche dovrà continuare a intercettare la pagina risultante.
Restituisci un codice 404 o 410 e rimuovi i link interni. Segnalare correttamente l’assenza della pagina è preferibile a un redirect fuorviante verso una destinazione non pertinente, che potrebbe essere interpretato come soft 404.
Controlla comunque codice di stato, canonical, indicizzabilità , contenuto e link. Dopo il rifacimento, un indirizzo rimasto uguale può mostrare una pagina molto diversa o incompleta.
Quando possibile, implementa i redirect permanenti sul server. Google raccomanda i codici 301 o 308 per gli spostamenti definitivi e sconsiglia le catene lunghe. Ogni richiesta dovrebbe passare dal vecchio URL alla destinazione finale pertinente in un solo salto, tenendo conto anche dei redirect precedenti al progetto. Verifica caratteri codificati, maiuscole, slash finali, parametri e varianti di protocollo o host, senza presumere che una sola regola copra ogni richiesta.
Le indicazioni di Google sui redirect spiegano che i redirect permanenti lato server sono il metodo migliore per modificare l’URL mostrato nei risultati di ricerca. Google può seguire più passaggi, ma i redirect diretti riducono latenza, punti di errore e complessità operativa.
Verifica il nuovo sistema nelle stesse condizioni in cui lo riceveranno utenti e motori di ricerca
Impedisci l’indicizzazione pubblica dell’ambiente di staging, ma non lasciare che questa protezione nasconda problemi destinati alla produzione. Controlli di accesso, tag noindex temporanei e regole di blocco nel robots.txt devono avere un responsabile e un controllo esplicito per la loro rimozione al lancio. Una sola direttiva dimenticata può rendere invisibile una migrazione altrimenti impeccabile.
Scansiona template rappresentativi
Verifica esempi prioritari e casi limite tra servizi, prodotti, categorie, articoli, paginazione, filtri, pagine locali e versioni linguistiche. Confronta il risultato con ciò che produce il vecchio sito online.
Controlla i segnali per i motori di ricerca
Controlla codici di stato, canonical autoreferenziali, direttive robots, title, titoli di pagina, dati strutturati, hreflang e idoneità alla sitemap XML. Tutti i segnali devono indicare lo stesso nuovo URL preferito.
Verifica rendering e navigazione
Confronta l’HTML iniziale con il DOM renderizzato. Assicurati che contenuti importanti e link scansionabili restino disponibili dopo l’esecuzione di JavaScript, nelle diverse visualizzazioni responsive, con gli strumenti di consenso attivi e in caso di richieste API non riuscite.
Verifica conversioni e misurazione
Invia i moduli, completa gli acquisti e controlla il tracciamento su più dispositivi. Una migrazione può conservare i posizionamenti e perdere comunque fatturato se un form, un evento o il checkout smette di funzionare.
Verifica l’intera mappatura dei redirect in un ambiente il più possibile simile alla produzione. Oltre al codice di stato, controlla che ogni destinazione sia pertinente. Scansiona poi le pagine di arrivo per accertarti che siano indicizzabili, canoniche rispetto a se stesse e collegate internamente. Un 301 tecnicamente corretto non rende riuscita la migrazione se porta a una pagina noindex, a un altro redirect o a un contenuto insufficiente.
Pubblica seguendo una sequenza che il team possa controllare e, se necessario, invertire
Scegli un momento in cui sviluppo, SEO, analytics e responsabili aziendali possano seguire il rilascio. Evita la fine della giornata o le ore che precedono un picco commerciale. Registra l’orario esatto della pubblicazione, così log, monitoraggio e dati sulle prestazioni potranno essere collegati con precisione al cambiamento.
Rendi disponibile il nuovo sito in produzione
Verifica DNS, TLS, varianti dell’host, capacità del server e accesso pubblico. Rimuovi le protezioni dello staging soltanto dall’ambiente di produzione previsto.
Attiva e verifica i redirect permanenti
Da un ambiente esterno al sistema di pubblicazione, verifica gli URL prioritari, le strutture ricorrenti e le regole preesistenti note. Cerca cicli, catene, risposte 5xx e destinazioni non pertinenti.
Scansiona subito il nuovo sito
Controlla direttive robots, URL canonici, indicizzabilità , link interni, contenuti renderizzati e codici di stato. Confronta il risultato con la scansione dello staging approvata prima del lancio.
Pubblica e invia la nuova sitemap
Inserisci soltanto i nuovi URL canonici che restituiscono un codice 200. Aggiorna i riferimenti alla sitemap nel robots.txt e invia il file nelle proprietà Search Console interessate.
Verifica percorsi e tracciamento
Verifica in produzione moduli e transazioni di maggior valore, consenso, analytics e tag pubblicitari. Accertati che i report riconoscano correttamente i nuovi URL di destinazione.
Registra i problemi e decidi se confermare il rilascio
Classifica i problemi per impatto ed estensione. Correggi rapidamente quelli che non comportano rischi, ma applica i criteri concordati quando un blocco diffuso rende più sicuro tornare indietro che intervenire sul sito online.
Usa gli strumenti adatti al tipo di spostamento
Prima della migrazione, verifica tutte le proprietà Search Console rilevanti del vecchio e del nuovo sito. In caso di cambio di dominio o sottodominio, assicurati di avere accesso a entrambe le parti e alle varianti di protocollo o host necessarie per l’analisi. Conserva l’accesso alla vecchia proprietà anche dopo il lancio: mostra richieste ancora attive, URL indicizzati ed errori che la nuova proprietà non può spiegare da sola.
Usa lo strumento Cambio di indirizzo soltanto per uno spostamento tra domini o sottodomini e dopo aver verificato il funzionamento dei redirect permanenti. La documentazione di Google sul Cambio di indirizzo esclude i passaggi da HTTP a HTTPS, tra www e non-www e le modifiche dei soli percorsi. Queste transizioni vengono gestite attraverso redirect, canonical, sitemap e nuove scansioni, non con lo strumento.
Ogni nuova pagina dovrebbe indicare se stessa come canonica, salvo i casi in cui sia stata decisa una precisa operazione di accorpamento. Aggiorna link interni, hreflang e URL nelle sitemap affinché puntino direttamente alle nuove versioni canoniche. L’obiettivo è presentare una destinazione coerente, non chiedere a Google di interpretare link precedenti, canonical reindirizzati e versioni linguistiche non allineate.
Le attuali indicazioni di Google sulle migrazioni dei siti raccomandano di verificare il nuovo sito, preparare la mappatura degli URL, avviare lo spostamento e poi monitorare il traffico. Google consiglia inoltre di mantenere i redirect per almeno un anno e avverte che i siti più grandi possono richiedere più tempo, perché la migrazione viene elaborata URL per URL.
Monitora la transizione per ipotesi precise, non attraverso un’unica curva di traffico
Prevedi controlli ravvicinati nel primo giorno e nella prima settimana, quindi riducine la frequenza man mano che il sistema si stabilizza. Non aspettare il report mensile. Un template difettoso scoperto entro poche ore può essere corretto prima di coinvolgere un’ampia parte del sito; lo stesso problema individuato dopo settimane può richiedere un recupero molto più lungo.
| Segnale | Evoluzione prevista | Da verificare subito |
|---|---|---|
| Vecchi URL | Le richieste continuano, ma raggiungono direttamente nuove pagine pertinenti. | Risposte 200, cicli, catene, errori 5xx o destinazioni non pertinenti. |
| Nuovi URL | Scansione e indicizzazione aumentano progressivamente sui template prioritari. | Scansione bloccata, noindex, canonical errati, soft 404 o contenuti renderizzati vuoti. |
| Risultati nella ricerca organica | Una certa variabilità mentre segnali e visibilità passano ai nuovi URL. | Calo circoscritto a un template, una lingua, una directory o un gruppo di query di valore. |
| Risultati commerciali | Variazioni normali, con misurazione valida e percorsi funzionanti. | Problemi a moduli, checkout, tracciamento o consenso nonostante una domanda organica stabile. |
| Comportamento del server | Aumento temporaneo della scansione su vecchi e nuovi host. | Latenza, errori di capacità o protezioni antibot che bloccano la normale scansione. |
Segmenta i risultati per gruppi di URL interessati dalla migrazione. Quando possibile, confronta le pagine modificate con campioni rimasti invariati e separa ricerche di marca e non, mobile e desktop, Paesi e template. Se una sezione perde visibilità mentre il resto del sito completa correttamente il passaggio, controlla i redirect, la completezza dei contenuti, i link interni e il comportamento tecnico di quella sezione prima di attribuire la causa all’intera migrazione o a un aggiornamento del motore di ricerca.
Mantieni un registro aggiornato dei problemi, indicando evidenze, portata, responsabile, decisione presa e stato della verifica. Ripeti la scansione delle aree corrette e controlla URL rappresentativi in Search Console. Mantieni attivi il vecchio dominio, i certificati, l’infrastruttura dei redirect e il monitoraggio. La migrazione non è conclusa soltanto perché la nuova home page è stata indicizzata.
Molte perdite durante una migrazione nascono da poche decisioni evitabili
Reindirizzare tutto verso la home page
Questa scelta abbandona l’intento originario e può essere interpretata come una soft 404. Individua la pagina equivalente più vicina oppure restituisci un codice 404 o 410 quando non esiste una sostituta.
Pubblicare mantenendo le protezioni dello staging
Password, tag noindex o regole di blocco finiscono in produzione. La loro rimozione deve essere un controllo esplicito del rilascio, non un presupposto.
Creare catene di redirect
Le nuove regole puntano a destinazioni intermedie precedenti. Risolvi le catene storiche affinché ogni vecchio URL noto raggiunga direttamente la destinazione finale.
Mantenere gli URL ma perdere i contenuti
La pagina restituisce ancora un codice 200, ma testi, link, contenuti multimediali o dati strutturati importanti sono scomparsi. Confronta risultato renderizzato e intento, non soltanto l’indirizzo.
Mescolare segnali vecchi e nuovi
Canonical, hreflang, link interni e sitemap indicano versioni diverse degli URL. Aggiorna tutti i segnali che puoi controllare affinché puntino alla destinazione canonica finale.
Rimuovere i redirect dopo il primo report
I vecchi URL possono ancora ricevere visite da link, segnalibri e risultati di ricerca. Mantieni i redirect per almeno un anno e, idealmente, finché gli indirizzi precedenti continuano a essere utilizzati.
La migrazione può dirsi stabile quando i vecchi URL di valore vengono reindirizzati correttamente, le nuove pagine canoniche sono raggiungibili e indicizzate, la visibilità sulle query più importanti e i risultati commerciali si sono stabilizzati, non restano problemi sistemici e il monitoraggio può tornare alla normale frequenza. Documenta la mappa finale dei redirect e le eccezioni accettate, così i rilasci futuri non annulleranno il lavoro svolto.
Una buona migrazione è prima di tutto una gestione rigorosa del cambiamento. Conserva ciò che utenti e motori di ricerca già comprendono, offre al team di sviluppo un risultato verificabile e permette di diagnosticare le perdite prima che vengano considerate normali. Questa checklist è importante perché il rilascio dura poche ore, mentre le decisioni sugli URL possono restare operative per anni.
Domande frequenti sulla migrazione SEO
Che cos’è una migrazione SEO?
Una migrazione SEO è un cambiamento controllato di URL, dominio, protocollo, piattaforma, architettura, template o contenuti renderizzati che può modificare il modo in cui i motori di ricerca scoprono, interpretano e indicizzano un sito. Il lavoro SEO tutela il valore già acquisito definendo una destinazione precisa per ogni URL importante, verificando il nuovo sistema e monitorando il passaggio dopo il lancio.
Quanto tempo richiede una migrazione SEO?
La preparazione può richiedere alcune settimane per un sito di piccole dimensioni e diversi mesi per un ecommerce o una piattaforma internazionale complessa. Dopo il lancio, i motori di ricerca elaborano lo spostamento URL per URL: la visibilità può quindi oscillare per settimane o più a lungo. I tempi effettivi dipendono dal numero di URL, dall’ampiezza delle modifiche, dalla frequenza di scansione, dall’affidabilità del server e dalla precisione con cui vengono implementati redirect e segnali interni.
I redirect 301 fanno perdere segnali di posizionamento?
Google dichiara che i redirect permanenti, come 301 e 308, non comportano una perdita di PageRank. Questo non significa però che qualsiasi redirect sia corretto: la destinazione deve essere pertinente e accessibile, mentre canonical, link interni e sitemap devono indicare la stessa pagina. Reindirizzare pagine non correlate verso una destinazione generica può essere interpretato come una soft 404.
Per quanto tempo vanno mantenuti i redirect dopo una migrazione?
Google consiglia di mantenere i redirect per almeno un anno. Lasciarli attivi più a lungo è spesso preferibile quando link, segnalibri, documenti o utenti possono ancora raggiungere i vecchi URL. La mappatura dei redirect va trattata come una parte stabile dell’infrastruttura del sito, non come un file provvisorio da eliminare appena il traffico sembra essersi stabilizzato.
Quando si usa lo strumento Cambio di indirizzo?
Usa lo strumento Cambio di indirizzo di Search Console quando il sito passa da un dominio o sottodominio a un altro, dopo aver attivato i redirect permanenti. Non va usato per il passaggio da HTTP a HTTPS, tra versione www e non-www o per una modifica dei soli percorsi all’interno dello stesso dominio. In questi casi il cambiamento viene comunicato attraverso redirect, canonical, sitemap e la normale nuova scansione del sito.
Conviene mantenere disponibile la vecchia sitemap XML dopo il lancio?
Mantenere temporaneamente disponibile una sitemap con i vecchi URL può aiutare il team a capire se Google li sta ancora richiedendo ed elaborando. La nuova sitemap deve invece contenere soltanto i nuovi URL canonici. Entrambi i file servono al monitoraggio e non sostituiscono i redirect permanenti diretti.
Come si gestiscono le pagine che non hanno una sostituta?
Una pagina eliminata senza un’alternativa davvero equivalente dovrebbe restituire un codice 404 o 410. Non reindirizzare ogni URL rimosso verso la home page o una categoria non pertinente soltanto per evitare un codice di errore. Se esiste una pagina che accorpa quei contenuti e risponde allo stesso bisogno, il redirect può portare lì, rispettando l’intento originario dell’utente.
Si possono cambiare insieme dominio, CMS e design?
È possibile, ma sommare molti cambiamenti rende più difficile isolare le cause di eventuali problemi e aumenta il numero di elementi che devono funzionare contemporaneamente. Dove possibile, Google consiglia di procedere per passaggi. Se esigenze commerciali impongono un unico rilascio, serve un quadro di partenza solido: limita le modifiche non necessarie a URL e contenuti, verifica template rappresentativi e stabilisci prima del lancio quando tornare alla versione precedente.
