Guida completa alla migrazione SEO di un sito web

Cosa significa migrare un sito web

La migrazione di un sito web è una delle operazioni più delicate nella gestione di un progetto digitale. Un errore nella pianificazione o nell’esecuzione può tradursi in un crollo immediato di visibilità organica, con conseguenze dirette su traffico e revenue.

Questa guida documenta la procedura operativa che utilizzo nelle migrazioni SEO, dalla fase di audit pre-migrazione al monitoraggio post-lancio. L’approccio è agnostico rispetto al CMS: che si tratti di WordPress, Magento, Shopify, headless o siti custom, i principi e le verifiche tecniche restano identici.

Tipologie di migrazione

Le migrazioni si classificano in base a cosa cambia. Ogni tipologia comporta rischi e complessità diverse:

• Cambio struttura URL — abbreviare, normalizzare o riorganizzare i permalink. Esempio: rimuovere la data dallo slug, passare da parametri query a path statici.
• Consolidamento contenuti — unire pagine che si cannibalizzano su stesse query in un unico URL più forte. Operazione frequente dopo un content audit.
• Redesign e ristrutturazione — modifica del layout, dell’architettura informativa e spesso del contenuto stesso. Il rischio principale è la perdita di struttura dei link interni.
• Migrazione HTTP → HTTPS — cambio di protocollo. Google considera HTTP e HTTPS come URL distinti, quindi tutti gli URL cambiano.
• Cambio hosting o infrastruttura — nuovo server, CDN, edge computing. L’URL non cambia ma cambiano IP, performance, configurazioni server-side.
• Cambio CMS o stack tecnologico — da monolitico a headless, da server-side rendering a SPA con client-side rendering, da un CMS proprietario a WordPress o viceversa.
• Cambio dominio — rebranding, acquisizioni, passaggio da ccTLD a gTLD. È la migrazione con il rischio più alto perché si perde l’associazione dominio-segnali di ranking accumulata negli anni.
• Merge di più siti — consolidamento di domini separati in un unico sito. Frequente dopo acquisizioni societarie o passaggio da strategia multi-dominio a dominio singolo. Per approfondire: conviene unire più siti web?

Nella pratica, le migrazioni raramente ricadono in una sola categoria. Un redesign spesso implica cambio CMS, nuova struttura URL e passaggio a HTTPS — ognuno di questi fattori moltiplica i rischi.

Perché le migrazioni sono rischiose

Cambiare URL a una pagina significa chiedere a Google di trasferire tutti i segnali di ranking — PageRank, anchor text dei backlink, segnali di engagement — dal vecchio URL al nuovo. Questo trasferimento non è mai perfetto: anche con redirect 301 implementati correttamente, una quota di link equity viene persa nel processo.

I rischi principali includono:

• Perdita di ranking — i segnali accumulati su URL vecchi non vengono trasferiti integralmente ai nuovi
• Redirect chain e loop — catene di redirect che diluiscono il PageRank e rallentano il crawling
• Orphan pages — pagine del nuovo sito non raggiungibili dai crawler per link interni mancanti
• Cannibalizzazione — vecchi URL ancora indicizzati competono con i nuovi per le stesse query
• Perdita di backlink — link esterni che puntano a URL non più redirezionati o a un server spento
• Problemi di rendering — cambio CMS o framework che introduce client-side rendering non compatibile con Googlebot

Nota: la regola generale è evitare di modificare gli URL quando non strettamente necessario. Può essere più efficace migliorare il ranking con URL non ottimali piuttosto che affrontare i rischi di una migrazione.

Fase 1: Pre-migrazione

La fase pre-migrazione è la più importante. Una pianificazione accurata riduce drasticamente i rischi e consente di gestire i problemi prima che impattino sulla visibilità organica. Questa fase richiede tipicamente da 2 a 8 settimane a seconda della complessità del sito.

1.1 Crawling completo del sito attuale

La prima attività è un crawling completo del sito con Screaming Frog (o un crawler equivalente). L’obiettivo è ottenere un inventario esaustivo di tutte le risorse indicizzabili:

• URL di tutte le pagine HTML con status code, title, meta description, canonical, hreflang
• URL delle immagini (anche le immagini ricevono backlink e possono generare traffico da Google Images)
• Mappa completa dei link interni con anchor text
• Redirect interni già esistenti (catene, loop, redirect temporanei)
• Risorse CSS/JS bloccate o con errori di caricamento

Esporta tutto in un file strutturato. Questo database sarà il riferimento per costruire il mapping dei redirect e per verificare la completezza della migrazione.

1.2 Audit dei contenuti e delle performance organiche

Scarica da Google Search Console i dati sulle landing page organiche degli ultimi 16 mesi:

• URL, click, impressioni, CTR, posizione media
• Query che generano traffico per ogni landing page
• Trend stagionali per identificare i periodi di picco (e quindi i giorni peggiori per migrare)

Questi dati servono a due scopi: identificare le pagine ad alto valore che richiedono redirect prioritari, e stabilire la baseline di performance pre-migrazione per il monitoraggio successivo.

Esegui anche un content audit completo per identificare pagine da consolidare, aggiornare o rimuovere. La migrazione è il momento ideale per fare pulizia dell’architettura dei contenuti.

1.3 Inventario e analisi dei backlink

Scarica il database completo dei backlink da più fonti (GSC, Ahrefs, Majestic) e consolida i dati:

• Identifica le pagine che ricevono più link esterni — queste richiedono redirect 1:1 perfetti
• Verifica lo status code delle pagine linkate — se ci sono backlink verso URL che già restituiscono 404, implementa redirect prima della migrazione
• Mappa le anchor text per verificare che il contenuto della pagina di destinazione post-migrazione sia coerente

I backlink rappresentano il PageRank accumulato nel tempo. Perderli significa perdere autorevolezza agli occhi di Google.

1.4 Correzione errori interni

Prima di migrare, il sito di partenza deve essere il più pulito possibile dal punto di vista tecnico:

• Correggi tutti i link interni che puntano a URL con status 3xx, 4xx o 5xx — ogni link deve puntare alla risorsa finale con status 200
• Risolvi le catene di redirect interne — Googlebot segue un massimo di 10 hop, ma già dopo 3-4 la perdita di PageRank è significativa
• Verifica che i tag canonical siano coerenti e puntino alla versione corretta di ogni pagina

Partire da una base pulita rende il mapping dei redirect più semplice e riduce la probabilità di errori a cascata.

1.5 Costruzione del mapping dei redirect

Questa è la fase più critica dal punto di vista tecnico. Per ogni URL del sito attuale, devi definire l’URL di destinazione nel nuovo sito. Per approfondire la parte tecnica dei redirect, consulta la guida ai redirect e l’articolo sulle differenze tra URL rewrite e HTTP redirect.

Regole fondamentali:

• Redirect 1:1 — ogni vecchio URL deve essere redirezionato al nuovo URL corrispondente. I redirect “many-to-one” (molte pagine → homepage) sono un errore grave: Google li interpreta come soft 404
• Redirect 301, non 302 — il redirect 301 (permanente) trasferisce i segnali di ranking. Il 302 (temporaneo) non li trasferisce nella stessa misura
• Redirect lato server — mai usare redirect JavaScript o meta refresh. Solo redirect HTTP implementati a livello di web server (Apache .htaccess, Nginx config, Cloudflare rules, Vercel/Netlify config)
• Pagine senza corrispondenza — se un URL vecchio non ha una controparte nel nuovo sito, redireziona alla pagina semanticamente più vicina (per topic e intent) o alla pagina di categoria
• Immagini e risorse — anche PDF, immagini e altri asset che ricevono backlink devono essere mappati nel redirect

Per migrazioni di grandi siti (10k+ URL), è necessario automatizzare il mapping con script che incrociano il crawl del vecchio sito, gli URL del nuovo sito e i dati di backlink. Tool come migTool possono velocizzare significativamente questa fase.

1.6 Preparazione Sitemap.xml e robots.txt

Sul sito attuale:

• Rigenera la Sitemap.xml con tutti gli URL canonici attivi — questa servirà come base per la verifica dei redirect
• Verifica il file robots.txt — non deve bloccare risorse CSS/JS necessarie al rendering. Google deve poter accedere a tutte le risorse per indicizzare correttamente le pagine
• Invia la Sitemap aggiornata a GSC per assicurarti che Google abbia una mappa completa del sito prima della migrazione

Per il nuovo sito, prepara in anticipo la Sitemap.xml con tutti i nuovi URL. Puoi verificarne la completezza con tool specifici per l’analisi delle sitemap.

1.7 Registrazione su Google Search Console

Registra il nuovo dominio (o il nuovo protocollo HTTPS) su GSC. Assicurati di avere:

• Proprietà verificata per il nuovo dominio
• Accesso come proprietario (non come utente), necessario per lo strumento Cambio di Indirizzo
• Preferibilmente verifica tramite DNS per la massima flessibilità

Per approfondire l’uso avanzato di GSC nel contesto delle migrazioni: come indicizzare un sito web su Google.

1.8 Riduzione TTL DNS e backup

Nei giorni precedenti alla migrazione:

• Abbassa il TTL dei record DNS a 300 secondi (5 minuti) — questo garantisce che la propagazione DNS avvenga rapidamente e permette un rollback veloce in caso di problemi
• Esegui un backup completo — database, file, configurazioni server. Devi poter ripristinare tutto in meno di un’ora
• Testa i redirect su staging — carica la vecchia Sitemap.xml nel crawler puntando all’ambiente di staging del nuovo sito e verifica che ogni URL venga redirezionato correttamente

Fase 2: Il giorno della migrazione

La migrazione va eseguita in un giorno a basso traffico, possibilmente nelle prime ore del mattino. In un e-commerce con traffico internazionale non esiste un momento “sicuro” — in quel caso, minimizzare la finestra di downtime è prioritario.

2.1 Go live

1. Deploy del nuovo sito — carica file, database, configurazioni. Verifica che il robots.txt del nuovo sito non contenga ancora le restrizioni dell’ambiente di staging (Disallow: /)
2. Aggiorna il puntamento DNS — modifica i record A/AAAA per puntare al nuovo IP. Con il TTL a 300 secondi, la propagazione sarà completa in pochi minuti
3. Attiva i redirect sul vecchio server — le regole di redirect devono essere attive sul vecchio server (nel caso di cambio dominio/hosting) o sul nuovo server (nel caso di migrazione sullo stesso dominio)
4. Mantieni il vecchio server online — il server precedente deve restare attivo il più a lungo possibile. Finché è attivo, i backlink verso i vecchi URL vengono redirezionati correttamente. Spegnere il vecchio server significa perdere tutto il traffico e il PageRank di quei backlink

2.2 Verifiche immediate

1. Crawl del nuovo sito — lancia un crawling completo e confronta con l’inventario pre-migrazione. Verifica status code, title, canonical, hreflang, robots meta
2. Verifica redirect — carica la vecchia Sitemap.xml in Screaming Frog in modalità lista e scansiona. Ogni URL deve restituire 301 → 200 (non 301 → 301 → 200 o 301 → 404)
3. Invia la nuova Sitemap.xml a GSC — questo accelera la scoperta dei nuovi URL da parte di Googlebot
4. Verifica il robots.txt — usa lo strumento di test in GSC per confermare che non ci siano blocchi involontari
5. Controlla il rendering — usa lo strumento URL Inspection di GSC (o il Rich Results Test) per verificare che le pagine chiave vengano renderizzate correttamente da Googlebot
6. Pagina 404 — verifica che URL inesistenti restituiscano status code 404 (non 200 con pagina vuota o redirect alla homepage)
7. Strumento Cambio di Indirizzo (solo per cambio dominio) — attiva lo strumento dedicato in GSC. Richiede proprietà verificata su entrambi i domini e redirect 301 attivi dal vecchio al nuovo

2.3 Aggiornamento dei riferimenti interni

Dopo il go live, aggiorna tutti i riferimenti interni nel database del nuovo sito:

• Link interni che ancora puntano al vecchio dominio o alla vecchia struttura URL
• URL hardcoded nelle immagini, CSS, JavaScript
• Canonical tag, hreflang, og:url e altre meta che referenziano i vecchi URL
• Sitemap.xml interna che ancora elenca i vecchi URL

Su WordPress, questo processo può essere velocizzato con query SQL dirette per aggiornare i link URL in massa.

Fase 3: Post-migrazione e monitoraggio

Il monitoraggio post-migrazione è la fase in cui emergono i problemi. I primi 30 giorni sono critici: è il periodo in cui Google rielabora i segnali di ranking e aggiorna l’indice.

3.1 Monitoraggio KPI in GSC

Monitora giornalmente i seguenti indicatori confrontandoli con la baseline pre-migrazione:

• Pagine indicizzate — il numero di pagine nell’indice deve crescere progressivamente e avvicinarsi al totale delle pagine del nuovo sito
• Click e impressioni organiche — un calo iniziale del 10-20% è fisiologico. Un calo superiore al 30% richiede intervento immediato
• Errori di crawling — nuovi 404 che appaiono nel report di copertura indicano redirect mancanti da implementare
• Posizionamento delle keyword principali — traccia le query ad alto traffico e verifica che i nuovi URL compaiano al posto dei vecchi

3.2 Gestione degli errori 404

Nei giorni successivi alla migrazione, nuovi errori 404 appariranno inevitabilmente nel report di GSC. Non tutti richiedono un redirect:

• 404 con backlink o traffico — richiedono redirect 301 immediato verso la pagina più pertinente
• 404 di pagine irrilevanti — pagine senza backlink, senza traffico e senza valore possono restare 404. Un sito senza errori 404 non esiste
• 404 generati da bot o crawler esterni — spesso sono URL malformati o tentativi di exploit, non richiedono intervento

3.3 Aggiornamento dei backlink controllabili

I backlink che controlli direttamente vanno aggiornati manualmente al nuovo URL:

• Profili social (LinkedIn, Twitter/X, GitHub, ecc.)
• Directory aziendali e Google Business Profile
• Guest post e citazioni su siti partner
• Firme email e materiale marketing

Per i backlink da siti terzi che non puoi modificare, il redirect 301 dal vecchio server resta l’unica soluzione. Per questo il vecchio server deve rimanere attivo il più a lungo possibile — idealmente almeno 12 mesi.

3.4 Ripristino TTL DNS e rinnovo dominio

• Dopo 7-14 giorni senza problemi, riporta il TTL DNS al valore standard (3600-86400 secondi)
• Rinnova il vecchio dominio — se scade e viene registrato da un terzo, perdi i redirect e tutti i backlink associati

Casi particolari

Migrazione di siti con rendering JavaScript

I siti che dipendono da JavaScript per il rendering (React, Angular, Vue con CSR) introducono complessità aggiuntive durante la migrazione:

• Verifica che il rendering server-side (SSR) o la generazione statica (SSG) funzionino correttamente per tutte le pagine del nuovo sito
• Googlebot utilizza un renderer basato su Chromium aggiornato, ma il rendering avviene in una seconda fase (Web Rendering Service): un ritardo nel rendering significa un ritardo nell’indicizzazione
• Testa il rendering con URL Inspection di GSC per le pagine critiche

Migrazione di siti e-commerce

Gli e-commerce presentano sfide specifiche per il volume di URL e la gestione dei prodotti:

• Le pagine prodotto out-of-stock o discontinue devono essere gestite con redirect verso prodotti equivalenti, non verso la homepage o la categoria generica
• I filtri e la navigazione faceted generano URL parametrizzati che richiedono una strategia specifica di canonical e robots
• Le pagine di categoria con paginazione devono essere migrate preservando la struttura di crawling
• I dati strutturati Product, BreadcrumbList e Organization devono essere aggiornati con i nuovi URL

Migrazione di siti multilingua

Per siti con implementazione hreflang:

• Tutti i riferimenti hreflang devono essere aggiornati simultaneamente su tutte le versioni linguistiche
• I redirect devono mappare correttamente le coppie vecchio-URL/nuova-URL per ogni lingua
• Se cambia la struttura URL (da sottocartelle a sottodomini o viceversa), la complessità si moltiplica

Quando la migrazione fallisce

Le cause più frequenti di migrazioni fallite, dall’esperienza su decine di progetti:

• Redirect mancanti o incorretti — la causa numero uno. Redirect many-to-one, redirect 302 invece di 301, catene di redirect, URL non mappati
• Robots.txt che blocca il crawling — il robots.txt dello staging rimasto attivo in produzione con Disallow: /
• Canonical errati — canonical che puntano ancora ai vecchi URL o canonical self-referencing sbagliati
• Server vecchio spento troppo presto — tutti i backlink in ingresso restituiscono errore, perdita immediata di PageRank
• Contenuti diversi sulle nuove pagine — se la pagina di destinazione del redirect ha un contenuto significativamente diverso, Google potrebbe non trasferire i segnali di ranking
• Nessun monitoraggio post-migrazione — problemi non identificati per settimane che diventano irrecuperabili
• Nessun coinvolgimento SEO nella pianificazione — la migrazione viene gestita esclusivamente dal team di sviluppo senza competenze SEO

Nota: se scopri una migrazione fallita settimane dopo il lancio, il danno è spesso parzialmente recuperabile ma richiede intervento tempestivo. La priorità è implementare i redirect mancanti e ripristinare l’accesso del crawler a tutte le risorse.

Checklist di migrazione SEO

Riepilogo sintetico di tutte le attività, da usare come riferimento operativo durante l’esecuzione:

Pre-migrazione

• Crawling completo del sito attuale (HTML + immagini + risorse)
• Export dati GSC: landing page, query, click, impressioni, posizione media (16 mesi)
• Export e analisi backlink (GSC + Ahrefs + Majestic)
• Correzione errori interni 3xx/4xx/5xx
• Correzione backlink rotti (redirect verso pagine alternative)
• Costruzione mapping redirect 1:1 (old URL → new URL)
• Aggiornamento Sitemap.xml del sito attuale
• Verifica e aggiornamento robots.txt
• Registrazione nuovo dominio su GSC
• Riduzione TTL DNS a 300 secondi
• Backup completo (database + file + configurazioni)
• Test redirect su ambiente di staging

Giorno della migrazione

• Deploy nuovo sito (verifica robots.txt aperto)
• Aggiornamento DNS
• Attivazione redirect 301
• Verifica redirect (crawl della vecchia Sitemap.xml)
• Crawl completo del nuovo sito
• Invio nuova Sitemap.xml a GSC
• Test rendering con URL Inspection
• Verifica pagina 404
• Attivazione Cambio di Indirizzo in GSC (se cambio dominio)
• Verifica tracking analytics

Post-migrazione

• Monitoraggio giornaliero KPI in GSC (30 giorni minimo)
• Gestione errori 404 emergenti
• Aggiornamento link interni nel database
• Aggiornamento backlink controllabili
• Ripristino TTL DNS (dopo 7-14 giorni)
• Rinnovo vecchio dominio
• Mantenimento vecchio server attivo (minimo 12 mesi)

Risorse correlate

Per approfondire i temi trattati in questa guida:

• Guida ai redirect di URL — tutto quello che serve sapere sui redirect 301, 302, 307 e 308
• Canonical tag e SEO — gestione dei canonical durante e dopo la migrazione
• SEO tecnica — panoramica completa delle competenze e degli strumenti per la SEO tecnica
• Content audit SEO — come eseguire un inventario e una valutazione dei contenuti
• Come indicizzare un sito web su Google — strumenti e procedure per accelerare l’indicizzazione

---

La documentazione ufficiale di Google sulla gestione delle migrazioni è disponibile su Google Search Central: Move a site with URL changes.