Migrazione sito SEO: Migra subito il tuo sito senza perdere posizionamento!

Una migrazione sito SEO ben fatta non deve far perdere traffico, ma serve metodo rigoroso: audit, mapping degli URL, redirect 301 uno a uno, monitoraggio dei primi 30 giorni. In questa guida trovi le fasi operative, gli errori più costosi che vedo nei progetti dei miei clienti e il piano di recovery se il traffico è già calato.

Una migrazione sito SEO è uno dei momenti più delicati nella vita di un sito web, perché cambi dominio, CMS, struttura URL o passi a HTTPS, e in poche ore puoi trovarti con il traffico organico dimezzato.

Non è un rischio teorico: è quello che vedo capitare ogni volta che una migrazione viene gestita come un semplice intervento tecnico, senza una pianificazione SEO alle spalle.

In questa guida ti mostro le fasi operative da seguire prima, durante e dopo il go-live, gli errori più costosi che ricorrono nei progetti che prendo in mano a crollo avvenuto, e un piano di recovery per quando il danno è già fatto.

L’obiettivo è semplice: arrivare al nuovo sito senza regalare a Google motivi per smettere di fidarsi di te.

Cos’è davvero una migrazione sito SEO e quando serve farla

Il termine migrazione sito SEO raggruppa cambiamenti anche molto diversi tra loro, che per Google condividono però lo stesso problema: devi aiutarlo a capire che il tuo nuovo sito è lo stesso del vecchio, con un’autorità già costruita da trasferire. Capire di che tipo di migrazione stai parlando è il primo passo per decidere sforzo e rischio.

Che cosa intendo per migrazione sito SEO

Una migrazione sito SEO è l’insieme di operazioni che accompagnano un cambiamento strutturale del tuo sito, con l’obiettivo di preservare traffico organico, autorità di dominio e posizionamenti già ottenuti.

Non si tratta solo del momento del go-live, ma di tutto il percorso che va dall’audit preliminare fino al monitoraggio dei primi mesi dopo il passaggio. Lo sviluppo di un sito in ottica SEO è un punto di partenza, ma una migrazione è un’operazione separata, più delicata.

Nei progetti che seguo ragiono su tre domande.

• Cosa cambia agli occhi di Google: dominio, URL, template, performance tecniche
• Cosa posso trasferire in modo trasparente: contenuti, link in ingresso, autorità
• Cosa Google deve rielaborare da zero: nuove architetture, nuovi contenuti, nuove categorie

La differenza con un semplice redesign estetico sta tutta qui. In un redesign Google non deve rifare un lavoro cognitivo. In una migrazione sì. Ogni volta che cambia qualcosa di sostanziale lato URL, template o server, Googlebot deve ricostruire il quadro, e questo richiede tempo e pulizia operativa.

Le 5 tipologie principali e come cambia il rischio

Non tutte le migrazioni comportano lo stesso rischio ed è il motivo per cui una checklist unica funziona poco. Le 5 tipologie che vedo più spesso hanno pesi molto diversi in termini di sforzo e probabilità di impatto sul traffico organico.

Il cambio hosting è quello che generalmente mi preoccupa meno, a patto che la performance del nuovo server non peggiori rispetto al vecchio.

Il cambio di dominio è il caso in cui applico sempre la massima rigidità, perché una perdita di autorità in caso di errore è difficilmente recuperabile in tempi brevi.

Perché un cambio apparentemente piccolo può far crollare il traffico

Un cambio “banale” come il passaggio da HTTP a HTTPS, se gestito senza redirect 301 corretti e senza aggiornamento dei canonical, può portare Google a vedere due versioni dello stesso sito e a diluire i segnali di ranking tra le due.

Ho visto siti perdere il 40% di traffico organico per questo motivo, per poi recuperare in 3 settimane una volta sistemati i redirect.

Il punto è che Google non “capisce” che hai cambiato qualcosa. Lo deve dedurre dai segnali che gli invii: redirect, sitemap, link interni, canonical, autorità del nuovo dominio.

Se questi segnali sono contraddittori, il motore sceglie la strada più prudente, che è penalizzare temporaneamente la fiducia riposta nel vecchio sito.

Ogni migrazione SEO è una conversazione con Googlebot. Come in ogni conversazione, la chiarezza paga più della velocità.

La fase di preparazione: cosa controllare prima di toccare qualunque cosa

La maggior parte dei problemi di una migrazione sito SEO si decide nelle due settimane precedenti al go-live, non il giorno stesso del passaggio. Se arrivi al deploy con un mapping incompleto o una sitemap non pronta, poi stai solo rincorrendo i danni.

L’audit del sito attuale e il crawl completo

Prima di toccare qualunque cosa, estraggo una fotografia completa del sito attuale. Serve a sapere esattamente cosa stai per migrare: ogni URL, ogni redirect già esistente, ogni pagina orfana, ogni risorsa statica collegata.

Lo strumento base è un crawler come Screaming Frog o Sitebulb, configurato per leggere l’intero sito. In parallelo esporto da Google Search Console le pagine indicizzate degli ultimi 90 giorni e le prime 1.000 query per performance, perché un audit SEO fatto bene parte proprio da qui.

Il risultato di questa fase è una lista di URL con metriche associate: clic organici degli ultimi 3 mesi, backlink in ingresso, posizione media.

Serve a decidere le priorità nel mapping dei redirect: una pagina con 2.000 clic al mese non può essere mandata in redirect verso la home. Una fotografia completa dello stato di partenza aiuta anche nella successiva analisi della presenza online.

La mappatura degli URL vecchi e nuovi (uno a uno, mai verso la home)

Il mapping è il documento operativo più importante di una migrazione sito SEO: un file in cui ogni URL del vecchio sito è associato a un URL coerente del nuovo. La regola che applico sempre è una sola: una pagina del vecchio sito punta a una pagina coerente del nuovo. Mai verso la home, mai verso una categoria generica.

Nei progetti dove ho messo mano a migrazioni già compromesse, la causa numero uno è esattamente questa.

Redirect di massa verso la home, perché “era più veloce da fare”. Google in questi casi smette di considerare validi i segnali di ranking della vecchia URL, perché non riesce a riconoscere una continuità di argomento.

Il mapping va preparato in Excel o Google Sheets, con una colonna per il tipo di contenuto, una per le metriche di priorità, una per l’URL di destinazione proposto. Lo rivedo sempre riga per riga nei giorni prima del deploy, perché un errore qui diventa un problema molto più costoso dopo.

Backup, staging e ambiente di test

Prima di qualsiasi passaggio in produzione pretendo tre cose: un backup completo del vecchio sito (database e file), un ambiente di staging con il nuovo sito accessibile solo in password, una checklist di test che simuli gli scenari più comuni.

Nel backup non guardo solo il contenuto, ma anche la configurazione di server, le regole di redirect del vecchio htaccess, i plugin SEO installati.

Spesso una regola htaccess vecchia di anni gestiva un gruppo di URL che tutti avevano dimenticato: perderla significa generare 404 inutili dopo il deploy.

Lo staging deve essere bloccato ai motori di ricerca con noindex o blocco robots, perché la cosa peggiore che possa succedere è che Google indicizzi la versione di test. Mi è capitato di prendere in mano siti in cui staging e produzione erano stati indicizzati in parallelo per settimane, con contenuti duplicati che Google ha fatto fatica a riconciliare.

Il giorno del go-live di una migrazione sito SEO: la sequenza che non puoi sbagliare

Il giorno del go-live non è il momento per improvvisare. Deve essere una sequenza prevedibile, con tempi stimati e punti di controllo, in cui ogni passo verifica il precedente. Ti mostro l’ordine che seguo nei progetti che gestisco.

L’ordine corretto delle operazioni

L’ordine conta più di quanto si creda, perché un passaggio invertito può generare downtime o 404 che Google scansiona nel momento sbagliato.

Nei progetti che gestisco faccio sempre il go-live di martedì mattina, mai venerdì pomeriggio. Serve margine per intercettare i problemi mentre il team è ancora operativo, non il lunedì successivo quando è già tardi.

I redirect 301 e perché la mappatura 1 a 1 è critica

Un redirect 301 è il modo con cui comunichi a Google che una pagina si è spostata in modo permanente, e che l’autorità di ranking va trasferita al nuovo URL. Se il redirect è temporaneo (302) o se punta a un URL non coerente, questa comunicazione si interrompe e Google può decidere di non trasferire nulla.

La mappatura 1 a 1 è critica perché ogni URL del vecchio sito con traffico, backlink o posizionamento merita una destinazione pensata.

Ho visto migrazioni in cui 1.200 URL erano stati rediretti su 15 destinazioni generiche: il traffico organico è crollato del 65% in 10 giorni e il recupero è durato 4 mesi.

Il controllo che eseguo subito dopo l’attivazione è un crawl del vecchio sitemap con uno strumento che segue i redirect: ogni URL deve rispondere 301, la destinazione finale deve essere 200. Qualsiasi 302, 404 o catena di redirect finisce in una lista di correzioni da fare entro 24 ore.

Verifiche immediate dopo il deploy

Nei primi 30 minuti dopo il go-live faccio sempre lo stesso giro di controlli, nello stesso ordine. Prima apro il nuovo sito da browser incognito e navigo manualmente le 15-20 pagine più strategiche: home, categorie principali, 5 articoli top per traffico, pagine di conversione.

Poi lancio un crawl parziale limitato a 500 URL per intercettare 404 veri, catene di redirect, link interni ancora al vecchio dominio.

In parallelo verifico che Googlebot stia già vedendo il nuovo sito, controllando i log del server se disponibili o lo strumento di ispezione URL in Search Console.

L’ultimo check riguarda la velocità del nuovo sito: una migrazione che peggiora il tempo di caricamento rischia di perdere posizionamenti per un motivo che non ha nulla a che vedere con la SEO on-page, ma solo con l’esperienza utente percepita da Google.

Cosa invii subito a Google Search Console e cosa no

In Google Search Console il nuovo sito deve essere una proprietà verificata prima del go-live. Appena il sito è live, invio tre cose nell’ordine: sitemap XML del nuovo dominio, change of address (solo se è un cambio di dominio radice), ispezione URL su 5-10 pagine strategiche per forzare un crawl immediato.

Cosa non invio subito: non chiedo rimozione delle vecchie URL (i redirect fanno il loro lavoro), non invio una sitemap del vecchio dominio aggiornata (confonde Googlebot), non attivo richieste di reindicizzazione massicce (sprecano budget di crawl e non accelerano davvero il processo).

L’errore più comune che vedo è l’ansia da “fare qualcosa in GSC”: ispezioni URL continue, richieste di reindicizzazione a raffica. Nella mia esperienza, dopo l’invio iniziale della sitemap, lasciare lavorare Googlebot per 7-10 giorni è spesso più efficace di qualsiasi intervento manuale.

I primi 30 giorni dopo la migrazione SEO: cosa monitorare e quando preoccuparsi

Nei primi 30 giorni dopo una migrazione sito SEO è normale vedere oscillazioni. L’importante è distinguere un assestamento fisiologico da un segnale di problema reale. Ti mostro i KPI che monitoro settimana per settimana e le soglie oltre le quali intervengo.

Giorni 1 e 3: la finestra iniziale e cosa guardare in GSC

Nei primi 3 giorni dopo il go-live non guardo ancora il traffico, guardo i segnali tecnici. In Google Search Console controllo tre cose: le prime pagine indicizzate del nuovo dominio, eventuali errori di scansione segnalati, l’andamento delle impression (non ancora dei clic).

È normale che le impression calino nelle prime 48 ore, mentre Google ridefinisce quali pagine mostrare. Quello che non è normale è vedere 404 di massa, pagine escluse per “noindex” quando non doveva esserci, o un calo di impression superiore al 50%.

Nei log del server verifico che Googlebot stia effettivamente scansionando il nuovo dominio.

Un segnale buono è vedere richieste GET sul nuovo sito nelle prime 24 ore, con risposte 200 sulle URL principali e 301 sulle vecchie. Se Googlebot ignora il nuovo sito per più di 48 ore, qualcosa nel robots.txt o nella configurazione del server sta bloccando l’accesso.

Settimana 1: segnali di normalità e segnali di allarme

Entro la prima settimana le impression dovrebbero stabilizzarsi, anche se tipicamente su valori leggermente inferiori al pre-migrazione. I clic organici possono essere ancora erratici, ma la curva deve almeno appiattirsi, non continuare a scendere.

Il segnale buono è un numero crescente di URL indicizzati del nuovo dominio in Search Console, con un numero decrescente di errori 404 nei log del server.

Il segnale di allarme è l’opposto: pagine del nuovo sito che non vengono indicizzate dopo 7 giorni, o 404 che continuano ad aumentare invece di scendere.

In questa fase controllo anche il punteggio SEO delle pagine chiave, perché un calo generalizzato può indicare un problema di template o di contenuto duplicato tra vecchio e nuovo sito. Un calo isolato su una singola pagina è spesso tollerabile e si recupera da solo.

Settimana 2 fino al giorno 30: assestamento e aspettative di recupero

Dalla seconda settimana i KPI iniziano a parlare chiaro, e dalla quarta dovresti vedere i primi segnali di recupero stabile. Il traffico organico si muove tipicamente tra -20% e +0% rispetto al pre-migrazione come fluttuazione fisiologica.

Se dopo due settimane sei più basso di -30%, qualcosa non ha funzionato nel passaggio e serve un intervento diagnostico immediato.

Entro il giorno 30 l’obiettivo realistico è aver recuperato almeno l’85-90% del traffico organico pre-migrazione, con alcune URL già tornate al livello originale e altre ancora in fase di stabilizzazione.

Gli errori più costosi che vedo nelle migrazioni SEO

Dopo aver gestito e preso in mano migrazioni di clienti già partite, posso dire che gli errori più costosi sono sempre gli stessi. Non sono errori sofisticati, sono dimenticanze di base che però, prese insieme, possono costare metà del traffico organico.

Redirect verso la home: l’errore più grave di tutti

Il redirect di tutte le vecchie URL verso la home è l’errore più grave che vedo nelle migrazioni SEO. Succede quando il team di sviluppo “semplifica” l’operazione, puntando ogni redirect alla home e lasciando a Google il compito di capire cosa fare.

Google in questi casi fa l’unica cosa logica: considera i vecchi URL non più validi e la home non pertinente ai contenuti originali.

Il risultato è una perdita rapida di posizionamenti su decine o centinaia di URL, con un crollo del traffico organico che può arrivare al 50-70% in 2-3 settimane.

La correzione, quando prendo in mano un progetto compromesso così, è ricostruire il mapping URL con priorità alle pagine ad alto traffico perduto. Si recupera, ma il tempo necessario va dalle 8 alle 16 settimane, in base al numero di URL da rimappare e al danno accumulato.

Catene di redirect e loop

Una catena di redirect è un URL che punta a un altro URL che a sua volta ne punta a un terzo. Google segue le catene fino a un limite, ma la trasmissione dell’autorità si degrada a ogni salto: se la catena ha 4 o 5 passaggi, al termine arriva solo una frazione dell’autorità originale.

Un loop di redirect è peggio: A punta a B, B punta ad A. Googlebot si ferma e segnala errore.

Nei log del server queste situazioni appaiono come richieste ripetute con risposte 301 mai risolte. Un controllo veloce in Search Console mostra pagine escluse per “redirect error”.

Il controllo che eseguo sempre è un crawl del vecchio sitemap seguendo i redirect: ogni catena di più di 2 passaggi va riscritta per puntare direttamente alla destinazione finale. Ogni loop va spezzato immediatamente, anche a costo di escludere temporaneamente una pagina dal nuovo sito.

Robots.txt che blocca per sbaglio il nuovo sito

Il robots.txt dimenticato dallo staging è un classico delle migrazioni mal gestite. In ambiente di test è normale avere Disallow: / per impedire a Google di indicizzare la versione in sviluppo. Se questo file viene copiato in produzione senza essere ripulito, il nuovo sito nasce bloccato ai motori di ricerca.

Il sintomo è inconfondibile: Google Search Console segnala le pagine come “escluse da robots.txt” nel giro di 48 ore.

Il traffico non cala subito, perché le vecchie URL in redirect continuano a trasferire autorità, ma dopo 7-10 giorni la mancata indicizzazione del nuovo sito inizia a pesare in modo evidente.

La correzione è immediata: ripulire il robots.txt, verificarlo con il tester ufficiale di Search Console, forzare l’ispezione delle URL principali per far ripartire la scansione. Nei casi fortunati il recupero è completo in 2 settimane. Nei casi dove il blocco è durato più di 20 giorni, serve un lavoro di ri-indicizzazione più profondo.

Link interni rimasti al vecchio dominio

Dopo una migrazione sito SEO è normale avere link interni ancora puntati al vecchio dominio o alle vecchie URL. In piccole quantità non è grave (i redirect li gestiscono), ma su larga scala i link interni al vecchio dominio generano decine di redirect inutili a ogni crawl.

Questo consuma budget di scansione e trasmette autorità in modo diluito, con un impatto cumulativo che si nota solo dopo settimane.

Il controllo lo faccio con un crawl del nuovo sito: ogni link interno dovrebbe puntare direttamente a un URL del nuovo dominio con risposta 200, non a un vecchio URL con risposta 301. Lo stesso vale per tag canonici, hreflang e sitemap: tutto deve essere coerente con il nuovo dominio.

La correzione è un lavoro di find and replace nel database o nei file del template. Dove possibile preferisco la via database, perché è più veloce e meno soggetta a errori di distrazione sui singoli file.

Se la migrazione sito SEO è già andata male: il piano di recovery passo per passo

Capita spesso che qualcuno mi contatti con una migrazione sito SEO già partita male: traffico in picchiata, posizioni perse, team di sviluppo che non riesce a capire cosa stia succedendo. In questi casi serve un piano di recovery strutturato, non interventi casuali.

Diagnosticare il tipo di crollo

La prima mossa in un recovery è diagnosticare esattamente cosa è crollato, perché cause diverse richiedono soluzioni diverse. Un calo generalizzato di traffico non è lo stesso problema di un calo isolato su alcune URL.

La diagnosi è il momento in cui serve freddezza. Nei progetti dove intervengo a crollo avvenuto parto sempre dai log di Googlebot e dai dati di Search Console, mai dai pannelli di Google Analytics, perché GA dà traffico ma non spiega il perché.

Le azioni di emergenza nei primi 7 giorni

Nei primi 7 giorni di recovery concentro le azioni ad alto impatto e basso rischio.

Nell’ordine: correggere redirect sbagliati (sostituire quelli verso la home con mapping specifici), ripulire robots.txt e canonical, verificare che ogni URL del vecchio sitemap abbia un target coerente nel nuovo.

In parallelo invio una verifica di penalizzazione a Google se Search Console segnala azioni manuali.

Nella mia esperienza quasi mai una migrazione sito SEO mal gestita genera penalizzazioni manuali: il calo è quasi sempre algoritmico, dovuto a segnali tecnici incoerenti che Google interpreta male.

Evito tre errori classici: aggiungere troppi redirect contemporaneamente senza testarli, lanciare richieste di reindicizzazione massicce (sprecano budget di crawl), cambiare l’architettura URL per la seconda volta (peggiora la situazione invece di risolverla). Un piano di emergenza vale solo se è ordinato.

La roadmap di recupero a 60-90 giorni e quando chiedere aiuto

Dopo le azioni di emergenza serve una roadmap di medio periodo. A 30 giorni dall’avvio del recovery il traffico dovrebbe aver recuperato almeno il 70% del livello pre-migrazione, se le correzioni sono state fatte bene. A 60 giorni l’obiettivo è l’85-90%, a 90 giorni il pareggio o il superamento del dato originale.

Il monitoraggio è settimanale, con 3-4 KPI chiave: clic organici, pagine indicizzate, posizione media sui cluster chiave, 404 nel log server.

Se dopo 30 giorni di correzioni il traffico non si muove, significa che il problema è più profondo e serve ripartire dalla diagnosi, non insistere con le stesse azioni.

Nei progetti dove i team interni hanno già provato a correggere e non ci sono riusciti, il valore di un consulente esterno sta nell’arrivare con metodo e senza bias sul lavoro già fatto. Puoi dare un’occhiata ai costi di una consulenza SEO o scrivermi direttamente dalla pagina consulente SEO per un confronto onesto sul tuo caso.

DOMANDE FREQUENTI