Migrazione SEO per separazione e carve-out di sito

TL;DR — Una separazione di sito divide il sito di un’azienda in due. La parte difficile non è scrivere i redirect: è decidere chi possiede ogni pagina, dominio, account, immagine, download, link e dato storico. Mantieni invariati gli URL validi quando puoi. Quando una pagina si sposta davvero, reindirizza il suo vecchio URL alla nuova pagina equivalente. Se non esiste una sostituzione, restituisci un vero 404 o 410. Testa entrambi i patrimoni digitali, perché una carve-out può rompere il sito del venditore con la stessa facilità di quello dell’acquirente.

Che cos’è una separazione o carve-out di sito

Una separazione di sito è una migrazione in cui una parte di un sito web diventa un patrimonio digitale separato. Succede spesso dopo una cessione, uno spin-off, la separazione di un’area geografica, una vendita di prodotto o lo scioglimento di una joint venture.

Una normale migrazione di dominio è soprattutto one-to-one: il vecchio sito si sposta su quello nuovo. Una carve-out è one-to-many. Alcune pagine restano al venditore, alcune passano all’acquirente, alcune vengono copiate temporaneamente sotto licenza, alcune vengono ritirate e i sistemi condivisi devono continuare a funzionare mentre cambia la proprietà.

Questo crea tre attività:

1. Decidere la proprietà. Chi controlla ogni dominio, URL, asset di contenuto, account e servizio dopo la transazione?
2. Preservare il significato. La nuova pagina dell’acquirente sostituisce davvero la vecchia pagina del venditore per l’utente?
3. Dimostrare l’indipendenza. Dopo la fine dei servizi di transizione, ciascuna parte può sottoporre a crawling, pubblicare, misurare, proteggere e gestire il proprio patrimonio?

La regola dei redirect

Reindirizza un URL spostato solo quando la destinazione è la sua vera sostituzione. Una pagina prodotto venduta insieme all’attività può in genere reindirizzare allo stesso prodotto sul sito dell’acquirente. Una pagina corporate sulle posizioni aperte che resta al venditore non dovrebbe reindirizzare alla home dell’acquirente solo perché ha dei link.

Google sconsiglia di inviare molti vecchi URL a un’unica destinazione irrilevante, perché potrebbe essere trattata come un soft 404. Raccomanda redirect permanenti lato server come 301 e 308 per gli spostamenti permanenti. Vedi le indicazioni di Google sul trasferimento di sito.

Inizia prima della data di separazione

Fai l’inventario del patrimonio digitale mentre persone, sistemi e permessi esistono ancora. Come minimo, raccogli:

• domini, sottodomini, vecchi domini, DNS, certificati, hosting e regole CDN;
• ogni URL indicizzabile più immagini, video, PDF, script e feed;
• Search Console, analytics, gestione dei tag, pubblicità, consenso e profili aziendali;
• proprietari dei contenuti, licenze, autori, marchi, dati prodotto e file sorgente;
• redirect, canonical, hreflang, dati strutturati, sitemap e regole robots;
• vendor, API, autenticazione, ricerca, moduli e repository condivisi.

Il contratto e i consulenti legali determinano la proprietà giuridica. Il lavoro del team SEO è rendere visibile quando una separazione proposta dipende da un asset o da un diritto non ancora assegnato.

Che cosa significa avere successo

Dopo il lancio, le pagine spostate dell’acquirente dovrebbero essere sottoponibili a crawling, indicizzabili, collegate internamente, misurabili e mappate dai vecchi URL. Le pagine conservate dal venditore dovrebbero continuare a funzionare. Dati storici e accessi dovrebbero essere preservati in modo appropriato, mentre le parti precedenti dovrebbero perdere l’accesso operativo secondo il calendario concordato.

Questa è una carve-out riuscita. Il fatto che due siti vadano online è solo la parte visibile.

TL;DR — Tratta una carve-out come un programma di separazione degli asset con una migrazione SEO al suo interno. Costruisci una matrice dei diritti per URL, contenuti, domini, dati, link, account, infrastruttura e persone. Dai a ogni vecchio URL una disposizione esplicita: mantenere, spostare, consolidare, duplicare temporaneamente con diritti documentati o ritirare. Mappa solo gli spostamenti equivalenti, preserva gli asset condivisi o sostituisci i loro riferimenti, separa le misurazioni senza scartare la cronologia e organizza i cutover intorno a DNS, redirect, autenticazione, consenso e dipendenze dei servizi di transizione. Monitora entrambi i patrimoni per coorte di URL. Un guadagno dal lato dell’acquirente non giustifica danni dal lato del venditore.

Definisci il perimetro della separazione

Inizia dal perimetro della transazione e trasformalo poi in un perimetro digitale. L’entità giuridica, la linea di prodotto, il brand, la geografia e il contratto con il cliente possono tracciare il confine in modo diverso. Non presumere che una cartella di URL sia la risposta definitiva.

Crea una matrice dei diritti con una riga per ogni asset e questi campi:

Transition service agreement (TSA) è il termine dell’accordo che vale la pena conoscere. Definisce i servizi che una parte continua a fornire temporaneamente dopo il closing. Per la SEO, un TSA può coprire l’hosting dei redirect, DNS, un CMS, una CDN di immagini, export di analytics, strumenti per il consenso o il personale che sa come funziona il sistema di pubblicazione. Assegna a ogni dipendenza un proprietario, un livello di servizio, una data di fine, un test di uscita e un fallback.

Costruisci un inventario degli URL completo di evidenze

Combina le fonti invece di fidarti della sitemap:

• crawl di produzione ed export dal CMS/database;
• sitemap XML, log del server/CDN, pagine di arrivo di analytics e pagine di Search Console;
• URL collegati dall’esterno, landing page pubblicitarie, feed e profili aziendali;
• immagini, video, PDF, file scaricabili, JavaScript, CSS, endpoint API e vecchi redirect.

Google dice esplicitamente ai proprietari dei siti di includere gli asset incorporati in un trasferimento e di usare sitemap, log, analytics, dati CMS e report dei link per identificare gli URL importanti. La documentazione corrente elenca queste fonti.

Assegna a ogni URL una disposizione:

• Mantenere: resta al venditore e conserva il suo URL.
• Spostare: passa a una pagina equivalente dell’acquirente.
• Consolidare: più pagine diventano davvero un’unica sostituzione completa.
• Uso duale temporaneo: compare in entrambi i patrimoni con diritti documentati, proprietario e scadenza.
• Ritirare: non ha una sostituzione utile e restituisce 404/410.
• Tenere in sospeso: non può essere lanciato finché proprietà, diritti o destinazione non sono risolti.

Nessuna cella vuota. «Decideremo dopo il lancio» è la decisione di accettare un problema non gestito.

Progetta le mappe intorno all’equivalenza per l’utente

L’acquirente compra un’attività, non automaticamente ogni segnale di ricerca associato al venditore. Un redirect è giustificato quando la destinazione soddisfa in modo sostanziale lo stesso intento dell’utente e continua a trattare lo stesso argomento, prodotto o servizio.

Rivedi le mappe con i responsabili di contenuti, prodotto, area legale e brand. Assegna un punteggio a ogni riga:

• successore esatto;
• consolidata ma equivalente;
• incerta e da rivedere manualmente;
• nessuna equivalente, restituire 404/410;
• vietata perché l’asset o la rivendicazione non vengono trasferiti.

Evita le catene risolvendo direttamente le vecchie regole verso la destinazione finale. Google dice che può seguire catene lunghe, ma raccomanda redirect diretti e di mantenere basse le catene inevitabili, idealmente non più di tre e meno di cinque. Mantieni i redirect permanenti per almeno un anno e più a lungo quando è pratico. Google documenta entrambi i punti.

Districa asset e servizi condivisi

Le dipendenze condivise sono il punto in cui le carve-out diventano strane.

Host degli asset

Una pagina spostata può ancora caricare immagini dalla CDN del venditore, font da un dominio corporate, PDF da un DAM condiviso o JavaScript da un host della società madre. Fai l’inventario delle richieste dai crawl renderizzati e dai log browser/rete. Per ogni dipendenza, scegli trasferimento, copia, hosting stabile con licenza o sostituzione. Aggiorna i riferimenti e testa cache, CORS, regole robots, firme, restrizioni di hotlink e scadenza.

Contenuti e dati prodotto

Separa i contenuti sorgente dalle pagine renderizzate. Descrizioni prodotto, specifiche, recensioni, biografie degli autori, memoria di localizzazione e campi dei dati strutturati possono provenire da sistemi esterni al CMS. Gli specialisti legali e dei dati determinano che cosa può essere trasferito. Non risolvere diritti poco chiari copiando tutto.

Identità e transazioni

Moduli, login, recupero account, checkout, abbonamenti e portali di assistenza possono attraversare il confine della separazione. Testa i percorsi utente e gli stati indicizzabili che li circondano. La visibilità nella ricerca non è un successo se la pagina manda il cliente in un flusso account che la nuova azienda non può gestire.

Separa Search Console e le misurazioni in sicurezza

Preserva la cronologia prima di modificare gli accessi. Esporta i dati baseline per coorte di URL, query, paese, dispositivo e aspetto nella ricerca. Registra ambito della proprietà e fuso orario. Conserva un archivio in sola lettura secondo le regole sui dati della transazione.

Per Search Console:

1. Fai l’inventario delle proprietà Domain e con prefisso URL, utenti, proprietari e metodi di verifica.
2. Verifica le proprietà di destinazione dell’acquirente prima del lancio.
3. Preserva la verifica del venditore necessaria a monitorare vecchi URL e redirect.
4. Trasferisci o stabilisci la proprietà dell’acquirente tramite controlli approvati.
5. Revoca l’accesso precedente solo dopo il superamento dei test concordati di monitoraggio e passaggio di consegne.

Google distingue proprietari, utenti completi e utenti con accesso limitato. I token di verifica possono conferire controllo, quindi il disegno degli accessi appartiene alla sicurezza, non a un foglio di calcolo SEO condiviso. Google documenta i permessi di Search Console.

Per analytics e tag, definisci quale parte può conservare dati storici a livello di utente o commerciali. Spesso la baseline SEO più sicura è un export aggregato approvato più nuove proprietà di destinazione, non la copia di un intero account. Ricostruisci eventi, consenso, configurazione cross-domain, referral, regole dei canali e collegamenti con i risultati aziendali; poi verificali con transazioni di test.

Organizza il cutover

Usa fasi basate sulle dipendenze, non su conteggi arbitrari di URL:

1. Piano di controllo: registrazione del dominio, DNS, certificati, CDN, hosting, segreti, proprietà degli account e monitoraggio.
2. Prontezza della destinazione: template, contenuti, asset, accessibilità, analytics, consenso, robots, canonical, hreflang, schema e sitemap.
3. Coorte pilota: una sezione coerente e meno volatile, la cui performance possa essere misurata in modo indipendente.
4. Contenuti principali: coorti di prodotti, categorie, assistenza ed editoriali ad alto valore.
5. Long tail e legacy: pagine orfane, file, vecchi redirect, profili e integrazioni.
6. Uscita dal TSA: sostituisci o termina ogni dipendenza condivisa e revoca gli accessi.

Google raccomanda di dividere i trasferimenti grandi quando è utile, avvertendo però che un pilota potrebbe non rappresentare un trasferimento dell’intero sito. Raccomanda anche di cambiare una variabile principale alla volta e di lanciare, quando possibile, in un periodo di traffico più basso. Queste aspettative sono nella sua guida sul trasferimento di sito.

Gate di lancio

Non lanciare una coorte finché:

• proprietà e diritti non hanno uno stato documentato;
• le pagine di destinazione non restituiscono lo status previsto e non mostrano il contenuto principale;
• robots di produzione e direttive meta consentono crawling e indicizzazione desiderati;
• canonical, hreflang, dati strutturati, link interni e sitemap non usano gli URL finali;
• le regole di redirect non superano test esatti, rappresentativi e avversariali;
• analytics, consenso, conversioni e raccolta dei log non superano i percorsi di test;
• capacità, monitoraggio, proprietà degli incidenti, rollback e comunicazioni non sono pronti;
• il patrimonio conservato dal venditore non supera la propria suite di regressione.

Monitora le coorti, non i totali aggregati

Crea coorti fisse prima del lancio: URL mantenuti dal venditore, URL spostati all’acquirente, URL ritirati, URL condivisi in transizione e URL di controllo che non dovrebbero cambiare. Confronta a 7, 14, 30 e 90 giorni tenendo conto della stagionalità e dei rilasci non correlati.

Monitora:

• richieste ai vecchi URL ed esiti dei redirect;
• crawling, indicizzazione, impression, clic, ranking e conversioni dei nuovi URL;
• regressioni nelle pagine conservate dal venditore;
• errori server, latenza, volume di crawling e comportamento della cache;
• selezione del canonical, reciprocità hreflang, idoneità ai rich result e link interni;
• dipendenze TSA, credenziali in scadenza, rinnovo dei certificati e asset irrisolti.

Non promettere una data fissa di recupero. Google dice che i trasferimenti significativi possono oscillare mentre gli URL vengono sottoposti a crawling e reindicizzati e che il completamento avviene per URL. I siti grandi possono richiedere più tempo. Usa il modello di transizione atteso come contesto, non come scusa per un’implementazione rotta.

Considerazioni finali

Il file dei redirect non è il piano della carve-out. Il piano è una risposta dimostrabile a chi possiede ogni asset, a ciò che l’utente dovrebbe raggiungere, a come ciascuna azienda opera in modo indipendente e a quando finisce ogni dipendenza temporanea.

Riepilogo AI

• Tratta la carve-out come un patrimonio che diventa due, non come un normale cambio di dominio.
• Fai l’inventario di URL, diritti, domini, account, dati, infrastruttura, link e persone.
• Assegna a ogni URL una disposizione: mantenere, spostare, consolidare, uso duale temporaneo, ritirare o tenere in sospeso.
• Reindirizza solo a un vero successore; usa 404/410 quando non ne esiste uno.
• Testa gli asset e i servizi esterni al CMS, soprattutto CDN, DAM, moduli, identità, dati prodotto, consenso e analytics.
• Preserva la cronologia con ambito appropriato, stabilisci la nuova proprietà e revoca i vecchi accessi secondo un calendario concordato.
• Lancia per coorte di dipendenze e testa le regressioni nel patrimonio conservato dal venditore.
• Monitora separatamente coorti di acquirente, venditore, ritirati, transizione e controllo invariato.

Che cosa stabilisce la guida ufficiale

• Google: trasferimenti di sito con modifiche agli URL: mapping, redirect permanenti, asset, staging, sitemap, monitoraggio e troubleshooting.
• Google: redirect e Ricerca: metodi di redirect supportati e interpretazione dei segnali.
• Google: canonicalizzazione: segnali canonical e motivo per cui i redirect sono più forti delle sole annotazioni.
• Google: versioni localizzate: hreflang reciproco e implementazioni cross-domain.
• Google: utenti e permessi di Search Console: proprietà, livelli utente e controlli di verifica.

Queste fonti spiegano il comportamento dei sistemi di ricerca. Non decidono proprietà, licenze, privacy, lavoro, imposte o condizioni della transazione. Affida queste decisioni agli specialisti.

Citazioni dalla fonte

• “Split your move into smaller steps, if that makes sense for your site.” Google Search Central. Vai alla citazione

Checklist della carve-out

Prima della progettazione

• Blocca il perimetro della transazione e nomina gli asset irrisolti.
• Fai l’inventario di domini, URL, file, diritti, account, sistemi, vendor e persone.
• Esporta crawl, mappe, redirect, GSC, analytics, log, link e ranking.
• Identifica ogni dipendenza condivisa e il TSA proposto.
• Crea coorti di URL del venditore, dell’acquirente, ritirati, di transizione e di controllo.

Prima del lancio

• Assegna a ogni URL una disposizione e un responsabile delle evidenze.
• Approva ogni redirect per equivalenza dell’utente e diritti.
• Convalida asset, moduli, autenticazione, consenso, analytics e conversioni.
• Verifica crawling di produzione, canonical, hreflang, schema, link interni e sitemap.
• Testa rollback e regressioni dal lato del venditore.
• Organizza il monitoraggio e la risposta agli incidenti.

Dopo il lancio

• Esegui il crawl di ogni vecchio URL e verifica la destinazione finale.
• Controlla gli URL importanti in Search Console e confronta le coorti di indicizzazione.
• Monitora log, errori, latenza, traffico, ranking e risultati in entrambi i patrimoni.
• Risolvi le dipendenze TSA prima delle date di uscita.
• Revoca gli accessi e ruota i segreti dopo il superamento dei gate di handoff.

ROME: diritti, proprietà, significato, esecuzione

Usa quattro gate per ogni asset:

1. Diritti: la società di destinazione può usarlo, modificarlo, ospitarlo e reindirizzarlo?
2. Proprietà: chi controlla dominio, account, codice, contenuto e rinnovo?
3. Significato: la destinazione proposta è davvero equivalente per l’utente?
4. Esecuzione: la destinazione può renderizzarlo, misurarlo, proteggerlo e mantenerlo in modo indipendente?

Una riga che fallisce un gate non è pronta per la migrazione.

Decidi che cosa succede a un vecchio URL

SOP del giorno del lancio

1. Conferma nel record della modifica la versione firmata della mappa URL e i responsabili.
2. Crea uno snapshot dello stato di DNS, CDN, redirect, robots, sitemap, analytics e certificati.
3. Rilascia la coorte di destinazione ed esegui smoke test prima di attivare i redirect.
4. Attiva i redirect diretti; esegui il crawl degli URL esatti, campionati, non corrispondenti, parametrizzati e degli asset.
5. Convalida i percorsi utente chiave e la misurazione in tempo reale nei patrimoni dell’acquirente e del venditore.
6. Invia le nuove sitemap e controlla URL rappresentativi ad alto valore.
7. Pubblica l’aggiornamento di stato con incidenti, responsabili, prossimo checkpoint e stato del rollback.
8. Mantieni il team disponibile finché la finestra di osservazione e i test aziendali non sono superati.

Modi comuni in cui le carve-out falliscono

• La cartella equivale alla proprietà: il confine legale e operativo raramente coincide con una singola directory ordinata.
• Logica basata sui diritti sul traffico: un traffico prezioso non dimostra che l’acquirente possieda la pagina o possa riceverne il redirect.
• Tutto verso la nuova home: redirect irrilevanti confondono gli utenti e possono essere trattati come soft 404.
• Copia ora, decidi dopo: la duplicazione temporanea diventa contenuto permanente e senza governance.
• QA solo dell’acquirente: modifiche a codice condiviso e redirect rompono silenziosamente il venditore.
• Il TSA come architettura: i servizi temporanei scadono. Ogni dipendenza ha bisogno di un’uscita.
• Cancellare subito i vecchi accessi: monitoraggio e cronologia spariscono prima del passaggio di consegne.
• Non revocare mai i vecchi accessi: le parti precedenti mantengono il controllo dopo la finestra approvata.

Strumenti per il lavoro

• SEO Migration Planner & Validator: rivedere mappe, redirect distribuiti, esiti dei vecchi URL, differenze tra sitemap e cronologia archiviata.
• Redirect Map Builder: suggerire e rivedere manualmente le mappe URL, conservare le righe non corrispondenti, appiattire le catene ed esportare le regole.
• Crawl con crawler e browser renderizzato: fare l’inventario degli URL e delle richieste agli asset condivisi.
• Log del server/CDN: dimostrare richieste dei bot, codici di stato, redirect e traffico conservato.
• Export di Search Console e analytics: stabilire le coorti pre-closing e monitorare il trasferimento.
• Inventari di DNS, certificati, dipendenze e segreti: dimostrare la separazione operativa.

Test che devono superare il gate

Risorse

Lavori verificati di Patrick

• Il ruolo della SEO nelle fusioni e acquisizioni: due diligence, decisione sulla fusione, integrazione per fasi, domanda del vecchio brand e monitoraggio post-acquisizione.
• Una migrazione di sito richiede più di una checklist: il processo di Patrick per pianificazione, baseline, modifica degli URL, test e monitoraggio, incluse le separazioni di sito.

Documentazione ufficiale

• Documentazione Google sul trasferimento di sito: inventario degli URL, mapping, redirect permanenti, trasferimenti per fasi, monitoraggio e troubleshooting.
• Modello di permessi di Search Console di Google: proprietari, utenti, metodi di verifica e rimozione dei token.
• Linee guida per i webmaster di Bing: indicazioni attuali su redirect, crawling/rendering e rimozioni.

Dal settore

• Digital Separation Blueprint di KPMG: contesto su modello operativo e servizi di transizione per una carve-out; non è una policy SEO o legale.
• Case study sulla migrazione di siti M&A di 9thCO: esempio di consolidamento multi-dominio riportato da un vendor.
• Guida alle migrazioni di sito di Search Engine Land: pianificazione, consolidamento, lancio e attività post-lancio.
• Tutorial di Screaming Frog sull’audit dei redirect: un flusso di lavoro recuperabile per testare su larga scala l’insieme dei vecchi URL.

Correlati su questo sito: Site Migrations, Checklist per la migrazione di sito e SEO Due Diligence per M&A.

Mettiti alla prova