Migrazione SEO del sito: come trasferire senza perdere le posizioni

TL;DR: Una migrazione preserva la visibilità organica quando ogni vecchio URL con valore ha una destinazione rilevante, i redirect permanenti lato server lo indirizzano direttamente e Google può effettuare crawling e indicizzazione della sostituzione. Prima del lancio, fai un inventario e un benchmark del vecchio sito. Crea una mappa di redirect one-to-one, aggiorna i link interni e i tag canonical, invia nuovi sitemap, poi monitora l’incrocio tra indicizzazione vecchio e nuovo. Usa Change of Address per i trasferimenti di dominio, non per passaggi HTTP→HTTPS o cambi di hosting.

La prima domanda, nella SEO delle migrazioni di sito, non è quale plugin installare. È questa: dopo lo spostamento, utenti e Google vedranno URL diversi?

Google Search Central separa le migrazioni in site moves con modifiche agli URL e site moves senza modifiche agli URL. Questa distinzione determina gran parte del lavoro. I cambi di dominio, gli spostamenti da HTTP a HTTPS, i path modificati e i consolidamenti di domini rientrano nel primo gruppo. Passare host o migrare su una CDN mantenendo ogni URL visibile rientra invece nel secondo.

Noi abbiamo fatto una migrazione di dominio in prima persona, quando il nostro team di due persone, Lida ed io, ha spostato SEOJuice da seojuice.io a seojuice.com nel gennaio 2026. Spostare l’applicazione non era la parte che mi preoccupava. La parte rischiosa era dimostrare che ogni vecchio URL arrivasse alla sostituzione corretta, che il nuovo sito non dipendesse da link interni basati sul vecchio dominio e che Google stesse sostituendo gli URL in indicizzazione, non limitandosi a scoprirli.

Questa distinzione conta. “Il nuovo sito è online” è un traguardo infrastrutturale. Non è una prova che la migrazione abbia funzionato.

Che cosa conta come migrazione SEO di un sito?

Una migrazione SEO di sito è un cambiamento sufficientemente rilevante da influenzare il modo in cui i motori di ricerca raggiungono, eseguono crawling o indicizzano un sito web. Un nuovo dominio è l’esempio più evidente, ma anche diversi progetti meno “rumorosi” richiedono le stesse attenzioni.

• Cambio dominio: Passare a un altro dominio durante un rebrand, un’acquisizione o un cambiamento di top-level-domain.
• HTTP a HTTPS: Il protocollo fa parte dell’URL, quindi è una migrazione con modifiche agli URL anche se l’hostname resta lo stesso.
• Cambio piattaforma o CMS: Una nuova piattaforma può modificare path, parametri, paginazione, gestione delle maiuscole/minuscole o slash finali. Considerala una migrazione con modifica degli URL se anche solo alcuni URL risultanti differiscono.
• Redesign o ristrutturazione: Un redesign visivo non è automaticamente una migrazione. Diventa tale quando cambiano path, slug, navigazione, canonical, contenuti renderizzati o la capacità di indicizzazione.
• Consolidamento domini: Unire più domini o hostname in uno solo richiede un inventario e un piano di redirect separati per ogni dominio sorgente.
• Spostamento di hosting o CDN: Se gli URL visibili agli utenti restano identici, è principalmente un’operazione di DNS e infrastruttura, non un progetto di redirect.

Io eviterei di combinare questi cambi, a meno che il vincolo di business sia più forte del rischio diagnostico. La guida di Google è netta: “Cambia una sola cosa alla volta”. Un cambio simultaneo di dominio, CMS, design e tassonomia ti dà quattro cause plausibili per ogni landing page persa (in realtà di più, una volta entrati nel merito di rendering e template).

Prima del lancio: prima l’inventario, poi la migrazione

Costruisci un inventario solido dei vecchi URL

La tua mappa di redirect può proteggere solo gli URL inclusi. Esegui il crawling del vecchio sito, poi combina quel crawling con sitemap XML, esportazioni da Search Console, landing page da analytics, dati backlink quando disponibili e log di server. Ogni fonte vede una “fetta” diversa del sito.

Un crawler trova le pagine linkate, ma può perdere gli orfani. Una sitemap può escludere vecchi URL che comunque stanno ancora posizionandosi. Analytics non mostrerà le pagine senza visite recenti. I log possono evidenziare richieste a file e path legacy assenti dalla navigazione attuale. “Completo” è una parola scomoda qui (di solito mi accontento di riconciliazioni effettuate in modo indipendente).

Mantieni inclusi gli asset non-HTML quando hanno valore SEO o link esterni. PDF, guide scaricabili, immagini e vecchie pagine di campagne sono spesso facili da omettere perché non compaiono in un normale crawling di pagina.

Acquisisci un baseline fuori dal sistema che stai sostituendo

Esporta traffico organico sulle landing page, metriche importanti su query e performance di pagina, informazioni sulle pagine indicizzate, gli URL top-performanti e i risultati di crawling attuali. Segmenta i dati per directory o per tipologia di pagina. Un singolo numero di traffico “sitewide” è troppo generico per fare debug della migrazione.

Se il traffico cala del 12%, quel numero ti dice quasi nulla. Se scompare una directory di un prodotto mentre il blog resta stabile, hai un indizio utile. Controlla prima i redirect di quella directory, i template, i tag canonical e le direttive di indicizzazione.

Ho saltato il lavoro di baseline perché sentivo che il lancio fosse urgente. Avrà risparmiato forse un’ora, ma ha reso la diagnosi successiva più lenta e meno certa. Non è uno scambio “furbo”.

Mappa ogni vecchio URL con la sua sostituzione più vicina

Google Search Central fornisce l’istruzione di base:

Una mappa di redirect invia ogni vecchio URL al suo vero equivalente nuovo, in modo one-to-one:

# 1:1 redirect map (Nginx) - vecchio URL verso il suo equivalente nuovo più vicino
location = /old-blog/why-seo/    { return 301 /blog/why-seo/; }
location = /products/old-widget/ { return 301 /shop/blue-widget/; }

# Anti-pattern: non redirectare in massa tutto verso la homepage
# location / { return 301 /; }   # questo crea soft 404

“Una volta ottenuta la lista dei vecchi URL, decidi dove dovrebbe reindirizzarsi ciascuno di essi.”

Crea un mapping con una riga per ogni vecchio URL. Includi destinazione prevista, codice di risposta atteso, tipologia di pagina, stato della migrazione e qualsiasi motivazione per la “ritirata”. Dai priorità agli URL che ricevono visite organiche o link esterni, ma non interpretare “dai priorità” come permesso di ignorare il long tail.

La destinazione deve preservare l’intento. Una vecchia pagina prodotto dovrebbe portare allo stesso prodotto o al suo successore reale. Un articolo migrato deve portare a quell’articolo. La homepage non è una sostituzione universale.

Preserva i path esistenti quando possibile. Ogni URL non modificato rimuove una regola di redirect, una decisione di mapping e un potenziale punto di failure. I team spesso riscrivono gli slug durante un redesign perché le nuove versioni sembrano più pulite. Prima di accettare il rischio della migrazione, chiederei quale problema misurabile quel “cleanup” risolve.

Decidi cosa non deve essere reindirizzato

Il mapping one-to-one non significa che ogni pagina eliminata debba essere forzata verso qualche destinazione. Se una pagina non ha un equivalente e nessun successore utile, un 404 o un 410 corretti possono essere più chiari di un redirect irrilevante.

Serve un giudizio editoriale, non una formula da spreadsheet. Reindirizzare un prodotto dismesso al modello sostitutivo può avere senso. Reindirizzare una pagina di evento cancellata a un indice eventi non collegato potrebbe no. Prima la rilevanza.

Prepara la sostituzione per il crawling

Importa i contenuti, configura HTTPS, prepara il file robots.txt di produzione, verifica le proprietà rilevanti in Search Console e controlla le direttive di indicizzazione a livello di pagina. Valida i tag canonical, hreflang dove usato, gli URL per structured data, la paginazione e le sitemap XML rispetto all’hostname di produzione.

Gli staging site sono spesso protetti con regole di robots.txt, direttive noindex, autenticazione o una combinazione di questi elementi. Queste protezioni non devono “trapelare” in produzione. Se le pagine restano assenti dopo il lancio, i controlli in Perché il mio sito non è su Google? coprono i controlli su robots, le direttive noindex e lo strumento di Ispezione URL.

Per un sito grande, migra prima una sezione se l’architettura lo consente. Google consiglia: “Inizialmente sposta solo una parte del sito per testare eventuali effetti sul traffico e sull’indicizzazione dei risultati di ricerca”. Un passaggio a step non è sempre possibile, ma vale la pena valutarlo prima di accettare un cutover tutto-o-niente.

Durante il lancio: fai combaciare ogni segnale

Usa redirect diretti e permanenti lato server

Google raccomanda: “redirect permanenti lato server dagli URL vecchi agli URL nuovi, come indicato nella mappa”. Se le meccaniche di redirect non ti sono familiari, leggi prima Cos’è un redirect?. Il nostro confronto 301 vs 302 redirect entra più nel dettaglio sulla scelta permanente rispetto temporanea.

Come dice Patrick Stox, autore principale del capitolo SEO del Web Almanac:

“Assicurati che i tuoi redirect siano codici di stato 301 o 308, invece di 302 o 307, quando stai facendo uno spostamento permanente e vuoi che gli URL vengano indicizzati sul nuovo sito, invece che su quello vecchio.”

Il codice di stato non è “cerimoniale”. La documentazione sui redirect di Google spiega cosa succede con un redirect permanente: “Googlebot segue il redirect e la pipeline di indicizzazione usa il redirect come segnale sul fatto che la destinazione del redirect debba essere considerata canonica.”

Ogni vecchio URL deve puntare direttamente alla destinazione finale. Evita catene vecchio→intermedio→finale. Testa per rilevare loop causati da regole sovrapposte su HTTPS, www, slash finale, CDN, server e applicazione.

Poi controlla la risposta live invece che il file di configurazione. Una regola può essere corretta in isolamento e comunque entrare in conflitto con un altro livello. È qui che smetto di fidarmi del foglio di migrazione (e, per essere onesti, anche della mia memoria) e faccio crawling in produzione.

Non eseguire redirect massivi delle pagine verso la homepage

Google avverte in modo esplicito:

“Non reindirizzare molti vecchi URL verso una singola destinazione irrilevante, come la homepage del nuovo sito.”

Un redirect massivo verso la homepage nasconde un lavoro di mapping mancante; non lo completa. Motori di ricerca e utenti si aspettavano una risorsa specifica. Inviare tutte le richieste a una pagina generica spezza quel legame.

Se molti URL condividono un successore legittimo, una mappa molti-a-uno può avere senso. Ad esempio, più URL prodotto duplicati possono risolversi tutti nella pagina prodotto canonica. Il problema non è l’aritmetica, ma l’irrilevanza.

Aggiorna link interni, canonicals e riferimenti generati

I redirect sono infrastruttura di fallback. Non dovrebbero diventare il nuovo sistema di linking interno del sito.

Aggiorna navigazione, breadcrumb, link agli articoli, moduli di contenuti correlati, tag canonical, riferimenti hreflang, structured data, voci della sitemap ed eventuali riferimenti agli asset per usare direttamente gli URL finali. L’indicazione di Google è: “Cambia i link interni sul nuovo sito dai vecchi URL ai nuovi URL.”

Da quello che vediamo su SEOJuice, i link “vecchi” a livello di template sono più critici dei singoli link editoriali perché un singolo componente obsoleto può replicare la stessa dipendenza dai redirect su centinaia di pagine. Controlla prima i template, poi il corpo dei contenuti.

Invia sitemap e usa Change of Address correttamente

Invia la nuova XML sitemap in Search Console. Google dice che questo lo aiuta a conoscere i nuovi URL. Tenere separate sitemap per vecchi URL e nuove URL ti dà un modo pratico per monitorare la sostituzione.

Per una migrazione da dominio a dominio, invia Change of Address dalla vecchia proprietà di Search Console. L’indicazione precisa di Google è inviare richieste per “tutti i sottodomini e le varianti www e non-www del nome del dominio vecchio”. Lo strumento integra i redirect permanenti; non li sostituisce.

Non usare Change of Address per migrazioni HTTP→HTTPS. Il passaggio a HTTPS cambia l’URL, ma Google esclude esplicitamente questo caso dallo strumento. Inoltre non serve per cambi solo di hosting e per modifiche dei path all’interno dello stesso dominio.

Dopo il lancio: monitora la sostituzione, non solo il traffico

Una migrazione non è completa quando il DNS risolve e la homepage viene renderizzata. È completa quando utenti e crawler raggiungono in modo coerente il contenuto previsto e i nuovi URL sostituiscono i vecchi URL nell’indice di Google.

Monitora i report di indicizzazione di Search Console, gli errori di crawling, i ranking e il traffico organico sulle landing page rispetto al baseline. Google descrive chiaramente il pattern di indicizzazione atteso:

“Nel tempo, il numero di pagine indicizzate dalla sitemap degli URL vecchi dovrebbe scendere a zero, con un aumento corrispondente dell’indicizzazione dei nuovi URL.”

Questo incrocio è più utile di aggiornare una singola chart del traffico. Se una sezione non cresce lato nuovo, controlla i redirect, i tag canonical, i link interni, l’inclusione nelle sitemap, i contenuti renderizzati e le direttive di indicizzazione. La nostra guida su come funziona l’indicizzazione di Google spiega il processo di crawling e canonicalizzazione dietro questa sostituzione.

Può verificarsi un calo temporaneo mentre Google ricrawla e reindicizza gli URL modificati. Non esiste una percentuale credibile “universale” né una scadenza di recupero. La dimensione del sito, la frequenza di crawling, il linking interno, la qualità dei redirect e l’entità del cambiamento variano tutti. D’altro canto, una perdita netta a livello pagina o directory è più azionabile della media di settore.

Mantieni i redirect attivi

Google dice: “Mantieni i redirect per quanto più a lungo possibile, in generale almeno 1 anno.” Tenere redirect utili attivi a lungo termine può anche proteggere i visitatori che usano vecchi bookmark e link provenienti da siti che non controlli.

Non cancellare il vecchio dominio né ritirare infrastrutture di supporto in modo prematuro. Un redirect che funziona per il crawling di lancio ma scompare mesi dopo non può aiutare utenti o crawler che incontrano un link vecchio successivamente.

I fallimenti che controllerei per primi

Verifica accessibilità e redirect prima di riscrivere i titoli o dare la colpa a un aggiornamento dell’algoritmo. I problemi di migrazione sono spesso meccanici: una pagina è bloccata, un redirect collide con un’altra regola, oppure un canonical punta all’host sbagliato.

L’ordine conta. Sistemare i metadati su un URL che Google non può fare crawling è tempo buttato.

Una migrazione “solo hosting” è un’operazione diversa

Se ogni URL visibile all’utente resta invariato, non inventarti un progetto di redirect. Google definisce questo caso come il passaggio a un provider di hosting diverso o lo spostamento su una CDN senza modificare l’URL visibile.

Prepara e testa la nuova infrastruttura, abbassa il TTL del DNS dove appropriato, aggiorna il DNS e monitora le richieste servite da entrambi gli ambienti. Google consiglia di spegnere la vecchia infrastruttura solo quando sei sicuro che tutti gli utenti, inclusi Googlebot, ricevano correttamente i contenuti dal nuovo setup.

Non c’è una mappa dei redirect e non c’è una richiesta di Change of Address perché gli URL non si sono spostati. I rischi principali riguardano disponibilità, performance, configurazione DNS, risposte del server e differenze su ciò che la nuova infrastruttura serve ai crawler.

Come si inserisce SEOJuice dopo una migrazione

Dopo aver spostato seojuice.io su seojuice.com, ciò di cui avevamo bisogno era un’ispezione ripetibile del risultato live. Non un’altra spreadsheet di lancio.

L’audit SEO gratuito di SEOJuice verifica aspetti sensibili alle migrazioni, inclusi robots.txt, sitemap, tag canonical, configurazione HTTPS, redirect e link interni. Può evidenziare link che puntano ancora al vecchio dominio, destinazioni dei redirect che restituiscono errori, direttive noindex rimaste attive e mismatch tra canonical o HTTPS.

Il confine è importante. L’audit identifica cosa non va e dove. Non scrive per te regole di redirect lato server né invia Change of Address. Questi passaggi restano sotto il tuo controllo (che probabilmente è il punto in cui i cambi a livello di dominio dovrebbero rimanere).

Domande frequenti

Che cos’è una migrazione SEO di un sito?

Una migrazione SEO di sito è un cambiamento che incide su come i motori di ricerca raggiungono, fanno crawling o indicizzano un sito web. Esempi includono spostare domini, passare da HTTP a HTTPS, cambiare piattaforme CMS o strutture di URL, consolidare domini e spostare host. La distinzione chiave è se gli URL visibili cambiano: se cambiano, servono mapping e redirect.

Perderò posizionamenti quando migro il mio sito?

Non necessariamente. I redirect permanenti aiutano Google a trattare la destinazione come canonica e a sostituire il vecchio URL. Durante il recrawling e la reindicizzazione può verificarsi qualche oscillazione. Calare in modo stabile di solito giustifica controllare redirect mancanti, destinazioni irrilevanti, loop, redirect temporanei, contenuti modificati, canonical e indicizzazione bloccata.

Gli URL vecchi devono avere redirect one-to-one?

Ogni vecchio URL prezioso dovrebbe essere valutato singolarmente e reindirizzato alla sostituzione rilevante più vicina. Non inviare pagine non collegate alla homepage. Se non esiste una sostituzione rilevante, un 404 o un 410 corretto possono essere più accurati di un redirect fuorviante.

Quando dovrei usare lo strumento Change of Address di Google?

Usalo per uno spostamento da un dominio a un altro. Invia le richieste necessarie per i sottodomini e per le varianti www o non-www del dominio vecchio. Non usarlo per cambi HTTP→HTTPS, per modifiche dei path all’interno dello stesso dominio, né per spostamenti di hosting e CDN. Change of Address non sostituisce i redirect permanenti.

Per quanto tempo dovrebbero restare attivi i redirect di migrazione?

Google consiglia di mantenere i redirect per quanto più a lungo possibile, in generale almeno un anno. Conservare redirect utili a tempo indeterminato può proteggere vecchi bookmark e link esterni, a patto che le destinazioni restino rilevanti.

Come verifico che la migrazione abbia funzionato?

Confronta traffico post-lancio, ranking, URL indicizzati e risultati di crawling con il baseline. Esegui crawling dei vecchi URL per confermare redirect permanenti diretti, fai crawling del nuovo sito per individuare link interni verso il vecchio, quindi controlla robots directives, canonical, sitemap e risposte del server. In Search Console, il numero di URL indicizzati della sitemap vecchia dovrebbe diminuire mentre quello della nuova sitemap dovrebbe aumentare.