Migrazione SEO: come ho salvato (e visto distruggere) il traffico organico di decine di siti

Il giorno che un'agenzia web ha azzerato cinque anni di SEO

Un cliente mi ha chiamato di lunedì mattina. Il suo e-commerce aveva perso il 73% del traffico organico nel weekend. L'agenzia web aveva lanciato il nuovo sito il venerdì sera, senza redirect, senza avvertire nessuno, senza nemmeno sapere cosa fosse una mappa di redirect.

Cinquecento pagine prodotto avevano cambiato URL. Tutte restituivano 404. I backlink che puntavano al vecchio dominio finivano nel vuoto. La sitemap XML conteneva ancora gli URL del sito precedente. Google, nel giro di 48 ore, aveva iniziato a delistare le pagine.

Ci sono voluti quattro mesi per recuperare. Quattro mesi di lavoro intenso, non per migliorare qualcosa, ma per tornare al punto di partenza. Il fatturato perso in quel periodo non lo ha recuperato nessuno.

Racconto questa storia non per spaventare, ma perché succede con una frequenza che trovo sconcertante. Nel 2026, con tutto quello che sappiamo, agenzie web che fatturano centinaia di migliaia di euro lanciano siti senza una minima pianificazione SEO della migrazione.

Che cos'è davvero una migrazione SEO

Il termine "migrazione" è fuorviante. Fa pensare a un trasloco: prendi le cose da una parte, le metti dall'altra, fine. In realtà è un trapianto. Stai spostando un organismo vivente, con il suo storico, la sua autorità, le sue relazioni con Google, in un corpo nuovo. Se sbagli qualcosa, il rigetto è immediato.

Una migrazione SEO si verifica quando cambi qualcosa di strutturale nel tuo sito. Cambio dominio, passaggio da un CMS all'altro, ristrutturazione degli URL, consolidamento di più siti, passaggio da HTTP a HTTPS. Anche un redesign che modifica la struttura delle pagine è, a tutti gli effetti, una migrazione.

La parte che nessuno dice: ogni migrazione comporta una perdita temporanea. Anche quelle perfette. Google deve rielaborare la sua comprensione del tuo sito, e questo richiede tempo. La differenza tra una migrazione ben fatta e una disastrosa è la differenza tra un calo del 5-10% che rientra in tre settimane e un crollo del 70% che richiede mesi di ricostruzione.

Perché le agenzie web ignorano la SEO nelle migrazioni

Dico una cosa impopolare: la maggior parte delle agenzie web non ha competenze SEO. Costruiscono siti, sanno programmare, hanno competenze di design, ma trattano la SEO come un optional, qualcosa da aggiungere dopo. E nella migrazione, il "dopo" è troppo tardi.

Il problema è anche economico. Pianificare la SEO di una migrazione aggiunge tempo al progetto. Servono ore di analisi, mappatura dei redirect, testing. Sono costi che il cliente non capisce e che l'agenzia non sa vendere, perché il valore è invisibile: è il traffico che non perdi, non quello che guadagni. Vendere prevenzione è difficile in qualunque settore.

Il risultato è che la migrazione SEO viene gestita come un'appendice tecnica. "Ah sì, facciamo anche i redirect." Redirect generici alla homepage. Redirect mancanti per le pagine che contano davvero. Canonical rotti. Sitemap non aggiornata. È un classico.

L'inventario: la fase che decide tutto

Prima di toccare qualunque cosa, io faccio l'inventario completo del sito esistente. Non è opzionale. Non è "se c'è tempo". È il prerequisito assoluto.

Crawl completo con Screaming Frog: ogni URL, ogni title, ogni meta description, ogni H1, ogni link interno, ogni redirect esistente. Questo è il territorio, e non puoi navigare una migrazione senza una mappa.

Da Google Search Console estraggo il traffico organico pagina per pagina degli ultimi 12 mesi. Identifico le pagine che generano il grosso del traffico e delle conversioni. In un sito medio, il 10-15% delle pagine porta il 70-80% del traffico organico. Quelle pagine sono sacre. Se ne perdi anche solo una per un redirect sbagliato, il danno è enorme in proporzione.

Poi i backlink. Con Ahrefs esporto tutti i link in entrata, filtro per autorità, e identifico le pagine che ricevono i link più importanti. Un backlink da un quotidiano nazionale che punta a un URL che adesso restituisce 404 è autorità buttata nel cestino. Ogni singolo link di valore deve avere un redirect preciso.

Infine, le posizioni. Esporto un benchmark completo delle keyword principali prima del lancio. Sarà l'unico modo per misurare l'impatto reale della migrazione.

La mappa dei redirect: il cuore dell'operazione

Ogni URL che cambia deve avere un redirect 301 verso il suo equivalente esatto nel nuovo sito. Non verso la homepage. Non verso una categoria generica. Verso la pagina corrispondente.

Io costruisco questa mappa in un foglio di calcolo con tre colonne: URL vecchio, URL nuovo, priorità (alta/media/bassa basata su traffico e backlink). Su siti grandi questa mappa ha migliaia di righe. Su un sito medio, centinaia. Non importa la dimensione: va fatta per ogni singolo URL che cambia.

La regola è semplice ma non negoziabile: redirect 1:1. Se /servizi/consulenza-seo-brescia/ diventa /consulenza-seo/, il redirect deve essere esattamente quello. Se una pagina viene eliminata e non ha un equivalente diretto, il redirect va alla pagina tematicamente più vicina nella gerarchia del nuovo sito. Se non esiste nemmeno quella, meglio un 410 (Gone) esplicito che un redirect alla homepage: Google sa benissimo quando un redirect alla homepage è farlocco e lo ignora.

Ho visto migrazioni con redirect implementati tramite plugin WordPress generici che creavano catene assurde: A rimanda a B, che rimanda a C, che rimanda a D. Ogni passaggio disperde autorità e rallenta il crawl. La catena massima accettabile è zero: un redirect, una destinazione.

Staging e verifica pre-lancio

Il nuovo sito deve essere pronto e verificato in ambiente di staging prima che qualcuno prema il pulsante del lancio. Non il giorno del lancio. Prima.

In staging controllo che i canonical tag puntino agli URL definitivi del nuovo sito, non a quelli di staging. Errore banale, danni devastanti: ho visto siti che per settimane dopo il lancio avevano canonical che puntavano a staging.dominio.it, dicendo a Google di ignorare tutte le pagine reali.

Verifico che il robots.txt non blocchi nulla che dovrebbe essere indicizzato. Che la sitemap XML contenga solo i nuovi URL canonici. Che i redirect funzionino testando manualmente le venti pagine più importanti e automaticamente tutte le altre. Che il contenuto delle pagine critiche sia equivalente o migliore dell'originale, perché se cambi URL e contenuto contemporaneamente, Google non sa più cosa sta guardando.

Tutto questo prima del lancio. Il giorno del lancio non è il momento per scoprire problemi.

Il lancio: sequenza e tempismo

Ho una preferenza forte per i lanci al martedì o mercoledì mattina. Mai il venerdì. Se qualcosa va storto il venerdì sera, hai un weekend intero di traffico perso prima che qualcuno intervenga. Quel cliente che mi ha chiamato il lunedì mattina ha perso tre giorni di vendite per un lancio fatto il venerdì alle 18.

La sequenza operativa nel giorno del lancio:

1. Screenshot delle posizioni attuali in Search Console come backup visivo
2. Lancio del nuovo sito
3. Attivazione immediata di tutti i redirect: devono partire nello stesso istante in cui il vecchio sito smette di rispondere
4. Invio della nuova sitemap XML a Google Search Console
5. Richiesta di scansione manuale delle 20 pagine più importanti tramite "Verifica URL"
6. Monitoraggio attivo per le prime 72 ore

I redirect non si "attivano dopo". Non si "fanno domani". Ogni minuto in cui un URL importante restituisce 404 è un minuto in cui Google registra un errore e potenzialmente delista la pagina.

Le prime quattro settimane: il periodo critico

Il traffico organico dopo una migrazione segue un pattern riconoscibile. Nei primi 3-5 giorni i dati in Search Console sono inaffidabili: c'è latenza nel reporting. Dalla seconda settimana in poi i dati iniziano a stabilizzarsi e puoi capire com'è andata.

Un calo del 5-15% nella seconda settimana è fisiologico. Google sta rielaborando i segnali, aggiornando l'indice, rivalutando l'autorità delle nuove URL. Se la migrazione è pulita, entro la terza o quarta settimana il traffico torna ai livelli precedenti e inizia a crescere.

Un calo superiore al 30% che persiste oltre la terza settimana è un segnale d'allarme. Significa che qualcosa nella migrazione non ha funzionato. I problemi più comuni che trovo in queste situazioni: redirect mancanti per pagine importanti, canonical errati, contenuti duplicati tra vecchie pagine ancora indicizzate e nuove pagine, robots.txt che blocca risorse critiche.

Ogni giorno di monitoraggio controllo gli errori 404 in Search Console: ogni nuovo 404 è un redirect mancante che va aggiunto. Controllo la copertura dell'indice per verificare che Google stia indicizzando le nuove pagine e delistando le vecchie. Controllo le posizioni delle keyword principali per individuare cali anomali su pagine specifiche.

Due migrazioni, due risultati

Un caso andato bene: azienda manifatturiera bresciana, sito da 300 pagine, migrazione da Joomla a WordPress con cambio completo della struttura URL. Due settimane di preparazione. Mappa di 340 redirect 1:1. Testing completo in staging. Lancio di martedì. Calo del 7% nella prima settimana, recupero completo entro il giorno 18. Nessuna pagina critica ha perso posizioni.

Un caso andato male (prima del mio intervento): studio professionale, sito da 80 pagine, migrazione a nuovo CMS fatta dall'agenzia web senza nessuna pianificazione SEO. Zero redirect. Contenuti riscritti da zero senza considerare le keyword posizionate. La homepage è passata dalla prima alla quarta pagina di Google per la keyword principale. Recupero: tre mesi e mezzo di lavoro.

La differenza tra questi due casi non è tecnica. I redirect non sono difficili da implementare. La differenza è nella consapevolezza che la SEO esiste e che ignorarla ha conseguenze misurabili in euro.

L'errore che commettono anche i bravi

C'è un errore che vedo fare anche da chi pianifica bene la migrazione: cambiare troppe cose contemporaneamente. Nuovo dominio, nuovo CMS, nuovo design, nuovi contenuti, nuova struttura URL. Tutto insieme.

Google non sa isolare le variabili. Se cambi tutto nello stesso momento e il traffico crolla, non sai cosa ha causato il problema. Era il redirect mancante? Il contenuto riscritto? La struttura del sito? L'hosting più lento?

Quando è possibile, io consiglio di separare le operazioni. Prima migri la struttura tecnica mantenendo i contenuti. Poi, una volta stabilizzato il traffico, aggiorni i contenuti. Se devi cambiare dominio e CMS, valuta se farlo in due fasi. Ogni variabile in meno è un rischio in meno.

Non è sempre possibile, lo so. A volte il budget o i tempi impongono di fare tutto insieme. Ma almeno sii consapevole che stai aumentando il rischio, e compensalo con una pianificazione ancora più rigorosa.

La migrazione come opportunità

Chiudo con un cambio di prospettiva. Una migrazione forzata, quando il CMS vecchio non regge più, il sito è lento e la struttura è un disastro, è anche un'opportunità rara. È il momento in cui puoi correggere errori strutturali che trascinavi da anni: URL caotici, architettura piatta dove serviva profondità, contenuti duplicati, pagine zombie che diluiscono l'autorità del dominio.

Ho gestito migrazioni dove il traffico organico, dopo il calo fisiologico iniziale, è salito del 20-30% rispetto al pre-migrazione. Non per magia, ma perché la nuova struttura era migliore, i contenuti erano consolidati, l'architettura informativa finalmente aveva senso.

La migrazione è pericolosa solo se la tratti come un problema tecnico da delegare a chi costruisce il sito. Se la tratti come un'operazione strategica che tocca il cuore della tua visibilità online, diventa uno degli investimenti SEO con il ritorno più alto. Ma serve qualcuno che sappia cosa sta facendo. E serve coinvolgerlo dall'inizio, non il lunedì mattina dopo il disastro.