Una migrazione SEO è il cambio di qualcosa che modifica l’URL, il dominio, la piattaforma o la struttura del sito. Include rebranding (nuovo dominio), replatforming (Magento → Shopify, WordPress → Webflow), cambio di struttura URL, passaggio da HTTP a HTTPS (ormai raro, ma ancora capita), unificazioni di siti, separazioni. Tutti scenari in cui se si sbaglia qualcosa, si può perdere il 30-60% del traffico organico in poche settimane.

Questa guida è un processo end-to-end basato su cosa va fatto prima, durante e dopo. Gli errori che vedo più di frequente sono concentrati nel “dopo”: chi non pianifica il monitoraggio post-migrazione scopre i problemi a danno fatto.

Quando serve (e quando NO) una migrazione SEO

Vera migrazione (approccio completo, rischio reale):

  • Cambio dominio (rebranding, acquisizione)
  • Replatforming (nuovo CMS)
  • Cambio struttura URL a livello sitewide
  • Unificazione di più domini in uno
  • Separazione di un sito in più domini

Non è una vera migrazione (cambio incrementale, rischio basso):

  • Redesign senza cambiare URL
  • Cambio tema/template sullo stesso CMS
  • Aggiornamento di singole pagine
  • Traduzioni aggiunte

Questa guida si riferisce al primo caso.

Fase 1: pre-migrazione (da iniziare 6-8 settimane prima)

1.1 Audit SEO del sito attuale

Fotografia completa di com’è il sito oggi. Senza questa, nel post-migrazione non saprai cos’è cambiato e cosa no.

Dati da raccogliere:

  • Liste completa di URL indicizzate (Screaming Frog crawl + estrazione da sitemap + Search Console)
  • Posizionamenti attuali per le keyword principali (Ahrefs, Semrush, Search Console ultimo anno)
  • Traffico organico per pagina (GA4 + Search Console)
  • Backlink in entrata (Ahrefs Site Explorer)
  • Pagine più performanti per traffico e conversioni
  • Meta tag (title, description) di tutte le pagine principali
  • Schema.org in uso
  • Internal linking principale (pagine più linkate internamente)
  • Canonical, hreflang, robots.txt, sitemap attuali

Salva tutto in spreadsheet / export. Sarà il benchmark di confronto.

1.2 Mapping degli URL

La cosa più critica di tutta la migrazione. Per ogni URL del vecchio sito, deciderai dove va nel nuovo.

Tre categorie:

  1. URL che ha un equivalente nel nuovo sito → redirect 301 da vecchia a nuova
  2. URL che non ha più equivalente ma tratta lo stesso tema → redirect 301 alla pagina più pertinente (categoria, pagina più generale)
  3. URL che non ha più senso → 410 Gone o redirect alla home (ultima scelta)

Non fare mai redirect di massa alla home: è un pattern che Google tratta come “soft 404” e ignora, perdendo tutto il link equity.

Formato tipico del mapping, in spreadsheet:

URL vecchia Status URL nuova Tipo Priorità
/scarpe-running 200 /running-shoes 301 diretta Alta
/blog/articolo-1 200 /blog/nuovo-articolo 301 diretta Alta
/vecchia-campagna 200 /offerte 301 tematica Media
/sessione-temporanea 200 410 Bassa

Per siti grandi (oltre 500 URL): lavoro noioso ma irrinunciabile. Per siti enormi (oltre 10k URL): script automatici per il matching iniziale, revisione manuale su URL con traffico o backlink.

1.3 Setup del nuovo sito

Sul nuovo sito (staging, mai in produzione in questa fase):

  • [ ] robots.txt impostato su Disallow: / (staging non indicizzabile)
  • [ ] Tutti gli elementi SEO critici configurati: canonical, meta tag, schema, sitemap, hreflang se multilingua
  • [ ] Performance verificata: Core Web Vitals testati, tempo di caricamento accettabile
  • [ ] Struttura interna dei link coerente
  • [ ] Search Console già configurata (proprietà aggiunta, in attesa di go-live)
  • [ ] Test di rendering: Googlebot vede la pagina correttamente? (Usa View-Source, Lighthouse)

1.4 Piano dei redirect 301

Tutti i redirect devono essere:

  • 301 (permanenti), non 302
  • Diretti: una sola hop, non catene (A → B → C è male; A → C è bene)
  • Attivi dal go-live: implementati prima che il DNS punti al nuovo sito

Implementazione:

  • Apache: .htaccess con regole RewriteRule
  • nginx: blocchi rewrite in nginx.conf
  • CDN/edge: Cloudflare Workers, Vercel Edge Config
  • CMS: plugin di redirect (Redirection su WordPress è lo standard)

Per siti grandi preferisci regole server-level o CDN: più veloci, non dipendono dal CMS.

Fase 2: go-live

2.1 Timeline del day-0

Sequenza tipica del lancio:

  1. Pre-lancio finale: ultimo backup del sito vecchio, ultimo crawl Screaming Frog
  2. Deploy: pubblicazione del nuovo sito
  3. Switch DNS: punta il dominio al nuovo sito
  4. Rimuovi Disallow: / dal robots.txt del nuovo sito
  5. Attivazione redirect: verifica che tutti i 301 funzionino
  6. Sitemap: carica la nuova sitemap in Search Console
  7. Comunicazione a Google: Controllo URL → Richiedi indicizzazione sulle pagine più importanti

2.2 Verifiche nelle prime ore

Test redirect: campiona 20-50 URL vecchie, verifica che restituiscano 301 verso le nuove URL corrette. Strumenti: httpstatus.io, Screaming Frog in modalità List.

Test rendering: Controllo URL in Search Console su 5-10 pagine chiave, verifica che Googlebot le veda correttamente.

Test performance: PageSpeed Insights su homepage e pagine principali.

Test tracking: Google Analytics traccia? Tag manager funziona? Conversioni si registrano?

Test canonical: verificare su 5 pagine che il canonical punti alla URL giusta del nuovo sito.

Test hreflang (se multilingua): validatore hreflang online.

2.3 Errori comuni al go-live

  • robots.txt ancora con Disallow: /: Google non può crawlare il nuovo sito. L’ho visto più volte. Controllare subito dopo lo switch.
  • Redirect 302 invece di 301: non passano link equity correttamente
  • Catene di redirect lunghe: A → B → C → D. Google si ferma, perdi equity
  • URL canoniche sbagliate: puntano al dominio vecchio, o a staging, o sono relative
  • Tag noindex dimenticato dalla fase staging
  • Sitemap che contiene URL vecchie o URL del nuovo sito ma miste con URL 404

Fase 3: post-migrazione (monitoraggio intensivo, 4-8 settimane)

3.1 Prime 48 ore

Cosa deve succedere:

  • Googlebot comincia a crawlare il nuovo sito (visibile in Search Console > Impostazioni > Statistiche di scansione)
  • I redirect 301 vengono rilevati e processati
  • La prima ondata di URL viene indicizzata

Cosa monitorare:

  • Errori server: monitora tramite tool (UptimeRobot, Pingdom) per 5xx
  • Errori 404 in aumento: indicatore che qualche redirect manca
  • Log server: chi crawla cosa, ci sono errori?
  • Conversioni in GA4: si registrano normalmente?

3.2 Settimane 1-4

Monitoraggio Search Console:

  • Indicizzazione pagine: il numero di pagine indicizzate dovrebbe avvicinarsi al numero del sito vecchio entro 2-4 settimane
  • Rendimento: clic e impressioni dovrebbero mantenersi (calo normale 10-20% nei primi 15 giorni, poi recupero)
  • Copertura errori: monitora aumenti di 404, redirect problematici
  • Core Web Vitals: verifica che non siano peggiorati rispetto al sito vecchio

Monitoraggio ranking:

  • Posizioni per keyword principali (ogni giorno le prime 2 settimane, poi 2-3 volte a settimana)
  • Normale: fluttuazioni di ±5 posizioni
  • Preoccupante: cali sostenuti sopra 10 posizioni per molte keyword

Azioni reattive:

  • URL che mostrano 404 ma non erano state mappate → aggiungere redirect
  • Pagine che non vengono indicizzate → controllare noindex, canonical, robots
  • Pagine che perdono ranking → verificare contenuto, link interni, Core Web Vitals

3.3 Mese 2-3

Consolidamento:

  • Il 90% dei redirect dovrebbe essere processato da Google
  • Il ranking dovrebbe stabilizzarsi su valori simili al pre-migrazione (o migliorare se la migrazione era anche un upgrade tecnico)
  • Backlink in entrata dovrebbero trasferire equity completamente

Analisi finale: Dopo 2-3 mesi, confronto traffico organico pre vs post. Obiettivo realistico: mantenere il 90-100% del traffico. Un 100% pulito significa migrazione ben fatta; un 85% indica problemi da investigare; sotto 70% è un indicatore grave che richiede audit completo.

Cosa NON fare mai in una migrazione

  • Cambiare troppe cose insieme: se cambi dominio E struttura URL E CMS E design, non saprai quale variabile ha causato cosa. Meglio separare le migrazioni nel tempo (ideale: una variabile alla volta)
  • Lanciare di venerdì pomeriggio: se qualcosa si rompe, ci sono meno persone disponibili per weekend. Preferire martedì-mercoledì
  • Migrare in alta stagione: e-commerce che migra a novembre perde mesi di vendite a Black Friday. Pianificare in periodi di traffico basso
  • Dimenticare canonical e robots sul vecchio sito: se il vecchio sito resta online per qualche motivo, deve avere tutto noindex e canonical verso il nuovo, per evitare duplicati
  • Non comunicare con marketing e dev: ogni stakeholder deve sapere cosa succede. Tracking, campagne, link esterni possono rompersi

Caso particolare: migrazione di dominio

In aggiunta a tutto quanto sopra:

  • Change of Address in Search Console: dichiara ufficialmente a Google il passaggio dal dominio vecchio al nuovo
  • Mantieni il vecchio dominio attivo con redirect 301 per almeno 12 mesi (idealmente per sempre)
  • Aggiorna i link dei backlink più importanti contattando direttamente i webmaster: niente passa completamente via 301, un aggiornamento manuale dei link autorevoli vale molto
  • Social, email signature, assetto brand: tutto va aggiornato progressivamente

Takeaway

  • Una migrazione SEO non è un evento del day-0: è un processo di 10-14 settimane che parte 6-8 settimane prima e finisce 4-8 settimane dopo
  • L’URL mapping è la cosa più importante: fallo manualmente per le pagine che contano
  • Redirect 301 diretti, senza catene, tutti attivi dal go-live
  • Monitora intensamente per 4 settimane: Search Console, ranking, errori 5xx, 404
  • Non cambiare troppe variabili insieme: separare migrazione strutturale da redesign
  • Calo temporaneo di traffico del 10-20% nei primi 15 giorni è fisiologico; sopra il 30% stabile è segnale che qualcosa non va

Link interni suggeriti:

Torna in alto