Introduzione
Una migrazione sito web non coincide solo con un cambio dominio. Per molte aziende significa rifare il sito, cambiare CMS, riorganizzare gli URL, spostare l'infrastruttura, semplificare i contenuti o portare il progetto su uno stack piu moderno.
Il problema e che, se la parte SEO viene trattata come un controllo finale, il rischio non si vede subito. Il nuovo sito puo sembrare piu pulito, piu veloce e piu attuale, ma nel frattempo alcune pagine importanti smettono di intercettare traffico organico, alcuni lead arrivano meno facilmente e Search Console inizia a mostrare errori, redirect inattesi o segnali incoerenti.
Per un'azienda il costo non e solo tecnico. Si traduce in contatti persi, campagne che spingono su URL sbagliati, pagine strategiche che spariscono dai risultati e settimane di correzioni fatte quando il sito e gia online.
In questo articolo vediamo cosa controllare davvero in una migrazione sito web dal punto di vista SEO, prima e dopo il go-live.
Perche il rischio e piu alto proprio nei redesign moderni
Negli ultimi aggiornamenti della documentazione ufficiale, Google ha ribadito con maggiore chiarezza alcuni punti spesso sottovalutati nei progetti di redesign e replatforming:
- una migrazione con cambio URL richiede mapping preciso, redirect stabili, link interni aggiornati e monitoraggio post-lancio
- anche quando gli URL non cambiano, cambio hosting o CDN possono influenzare crawling e accessibilita
- redirect, canonical e sitemap lavorano insieme, ma non hanno lo stesso peso
- blocchi temporanei come
noindexorobots.txtusati in staging possono restare attivi in produzione se il passaggio non e governato bene
Nel frattempo, gli stack moderni rendono molto piu semplice cambiare struttura, naming delle pagine, percorsi e routing. Questo e un vantaggio se il progetto e pianificato. Diventa un problema quando la logica tecnica viene approvata senza una strategia chiara per preservare visibilita, URL storiche e segnali SEO gia consolidati.
Cosa rientra davvero in una migrazione sito
Molte aziende pensano alla migrazione solo quando cambiano dominio. In realta, il rischio SEO esiste anche in scenari piu comuni:
- redesign con nuova architettura URL
- passaggio da un CMS a un altro
- rifacimento del sito con Next.js o stack headless
- spostamento da HTTP a HTTPS
- unione di piu siti o sottodomini
- cambio hosting, CDN o infrastruttura con possibili impatti su crawlabilita e stabilita
- eliminazione, fusione o rinomina di pagine servizio, categorie o landing
Se cambia il modo in cui le pagine vengono raggiunte, interpretate o restituite ai crawler, stai gia entrando in un territorio di migrazione.
Gli errori che fanno perdere traffico e lead
1. Cambiare URL senza una mappa completa tra vecchio e nuovo
Questo e l'errore piu frequente nei redesign. Si approva la nuova struttura del sito, si spostano servizi, categorie, articoli o landing e solo alla fine ci si chiede "dove mandiamo le vecchie URL?".
Una migrazione seria parte invece da una mappa esplicita:
- URL vecchia
- URL nuova corrispondente
- tipologia di redirect
- eventuale pagina rimossa da chiudere con
404o410
Se questa mappa non esiste, il rischio e molto concreto:
- pagine con link esterni finiscono in errore
- campagne e profili social puntano a destinazioni non piu valide
- Google deve reinterpretare il sito senza segnali coerenti
- alcune pagine con storico SEO vengono sostituite da alternative meno pertinenti
Per un'azienda vuol dire perdere valore accumulato nel tempo proprio nel momento in cui si e investito per migliorare il sito.
2. Usare redirect temporanei, catene o fallback troppo generici
Non tutti i redirect valgono allo stesso modo. Google continua a distinguere tra redirect permanenti e temporanei, e usa quelli permanenti come segnale per mostrare il nuovo URL nei risultati di ricerca.
Il problema pratico nasce quando il progetto va online con uno di questi scenari:
- redirect temporanei lasciati in produzione
- catene di redirect da vecchio URL a URL intermedio e poi a URL finale
- redirect massivi tutti verso home page o pagina servizi
- logiche JavaScript usate come soluzione di comodo quando erano possibili redirect server-side
Un redirect fatto male non danneggia solo la SEO. Peggiora anche l'esperienza utente, complica il tracciamento, rende piu fragile il sito nel tempo e alza il costo di ogni futura modifica.
Se il sito usa Next.js, ad esempio, conviene gestire questi passaggi in modo esplicito e stabile lato server, senza affidarsi a scorciatoie introdotte a ridosso del lancio.
3. Lasciare canonical, sitemap e link interni incoerenti
Un altro errore comune e pensare che basti "mettere i redirect" e che il resto si sistemi da solo.
In realta, durante una migrazione, Google si aspetta coerenza su piu segnali:
- il nuovo URL deve avere canonical verso se stesso
- la sitemap deve riflettere le URL nuove e canoniche
- i link interni devono puntare gia alle destinazioni nuove
- menu, footer, breadcrumb e CTA non dovrebbero continuare a usare URL vecchie
Se questi elementi restano disallineati, il sito manda messaggi contrastanti. E qui nascono molti problemi silenziosi: Google sceglie canoniche diverse da quelle desiderate, continua a scoprire vecchie URL dai link interni o rallenta la transizione tra vecchio e nuovo.
4. Portarsi in produzione blocchi rimasti dallo staging
Questo punto viene sottovalutato piu spesso di quanto dovrebbe.
Durante lo sviluppo e normale proteggere l'ambiente di test con password, noindex, regole robots.txt restrittive o altre misure temporanee. Il problema nasce quando una di queste protezioni resta attiva sul sito definitivo.
Google e molto chiaro su un aspetto importante: se una pagina e bloccata da robots.txt, il crawler potrebbe non vedere il noindex. Questo crea situazioni ambigue e rallenta la correzione.
Nel concreto, prima del go-live conviene verificare almeno:
- presenza di
noindexnelle pagine che devono posizionarsi robots.txtcoerente con l'ambiente di produzione- assenza di autenticazioni o restrizioni che impediscono a Googlebot di accedere alle risorse corrette
- status code reali delle pagine principali, non solo il loro aspetto nel browser
5. Lanciare il nuovo sito senza monitoraggio nelle prime settimane
Molti progetti considerano la migrazione conclusa il giorno della pubblicazione. In realta, quella e solo la fase in cui iniziano i controlli piu importanti.
Google raccomanda di monitorare il passaggio tra vecchio e nuovo sito con Search Console, sitemap dedicate e analisi del traffico. Questo e il momento in cui emergono:
- errori di crawling inattesi
- pagine importanti non indicizzate
- sitemap con redirect o URL escluse
- cali di impression sulle pagine commerciali
- vecchie URL ancora molto presenti nei report
Se non c'e una finestra di osservazione post-lancio, i problemi vengono scoperti tardi, spesso solo quando marketing o commerciale notano un calo di richieste.
La checklist SEO prima del go-live
Prima di pubblicare un nuovo sito o una nuova architettura, conviene verificare almeno questi punti:
- Esiste una mappa completa tra URL vecchie e URL nuove, con eccezioni esplicite per i contenuti rimossi.
- I redirect permanenti sono testati sulle pagine piu importanti e non generano catene inutili.
- Le nuove pagine usano canonical coerenti e autoreferenziali quando serve.
- La sitemap include solo URL corrette e finali.
- I link interni del nuovo sito puntano gia alle nuove destinazioni.
- Nessuna pagina strategica resta con
noindex, blocchi da staging o autenticazioni residue. - I template principali restituiscono status code coerenti con i casi reali: pagine attive, pagine rimosse, contenuti non piu disponibili.
- Search Console e pronta sia per il sito vecchio sia per quello nuovo, quando il progetto lo richiede.
- Sono stati controllati form, immagini, download e asset che possono ancora ricevere traffico o link.
- Le landing che generano lead o vendite sono state testate prima del lancio con un controllo SEO mirato, non solo con test visuali.
Questa checklist non serve a rallentare il progetto. Serve a evitare che il redesign venga pagato con un calo di visibilita che poteva essere prevenuto.
Cosa controllare nelle prime 4 settimane
Le prime settimane dopo il go-live sono decisive. E utile guardare il progetto con una logica operativa, non solo estetica.
I segnali piu utili da controllare sono:
- andamento delle impression e dei click sulle pagine nuove rispetto a quelle sostituite
- presenza di errori, esclusioni o warning anomali in Search Console
- stato di indicizzazione delle URL piu importanti
- comportamento delle sitemap vecchie e nuove, soprattutto se una parte delle URL ora reindirizza
- log server o strumenti analoghi per intercettare richieste frequenti su URL non previste
- campagne adv, profili esterni e link proprietari ancora puntati a URL superate
In questa fase non serve panico se c'e una lieve oscillazione. Serve invece distinguere la normale transizione da segnali tecnici che indicano una migrazione gestita male.
Quando conviene rimandare il lancio
Ci sono casi in cui la scelta piu professionale non e pubblicare comunque, ma fermarsi un giorno in piu.
Conviene rimandare il go-live se:
- la mappa redirect non e pronta
- le pagine commerciali non sono state testate
- canonical e sitemap non sono allineate
- il team non ha ancora rimosso i blocchi da staging
- non esiste un piano di monitoraggio per i primi giorni
Per un'azienda, un giorno di ritardo controllato costa quasi sempre meno di una settimana di correzioni d'urgenza dopo una perdita di traffico o lead.
Conclusione
Una migrazione sito web non e un passaggio solo tecnico. E un momento in cui architettura, SEO, UX e continuita commerciale devono restare allineate.
Quando mapping URL, redirect, canonical, sitemap e controlli post-lancio sono gestiti bene, il nuovo sito puo migliorare performance, chiarezza e manutenibilita senza disperdere il valore accumulato nel tempo. Quando invece questi aspetti vengono trattati all'ultimo, il rischio e perdere proprio le pagine che dovrebbero sostenere contatti, richieste e vendite.
Se stai pianificando un redesign, un replatforming o un cambio infrastrutturale, conviene verificare questa checklist prima del go-live. Correggere una migrazione in fase di progetto costa molto meno che inseguire un calo SEO a sito gia pubblicato.
Link utili




