Come migrare un dominio senza affossare il posizionamento nei motori di ricerca

Cambiare dominio è uno dei pochi progetti SEO in cui un errore tecnicamente piccolo può diventare molto visibile molto in fretta. Un redirect mancante, un percorso di scansione bloccato o un canonical dimenticato possono trasformare un rebrand lineare in settimane di volatilità nel posizionamento.

Un certo movimento è normale. I motori di ricerca hanno bisogno di tempo per scansionare i vecchi URL, scoprire i redirect, elaborare i segnali e stabilizzare il nuovo dominio nell’indice. L’obiettivo non è evitare ogni calo. L’obiettivo è rendere la migrazione noiosa: un vecchio URL punta a un nuovo URL equivalente, il server risponde in modo chiaro e nulla di importante scompare.

Inizia da un inventario, non da una regola di redirect

L’errore più comune in una migrazione è trattarla come un’attività di configurazione server. Non lo è. È un’attività di architettura dell’informazione che finisce per concretizzarsi nella configurazione del server.

Prima di toccare il DNS, crea un elenco degli URL che contano:

• URL che ricevono traffico organico
• URL con backlink esterni
• URL che convertono, generano lead o supportano campagne
• URL canonical attualmente presenti nella tua sitemap XML
• PDF, immagini e file scaricabili linkati dall’esterno
• URL legacy di alto valore che potrebbero non comparire nella navigazione attuale

Per ogni vecchio URL, assegna una destinazione sul nuovo dominio. Nella maggior parte dei casi, quella destinazione dovrebbe essere la stessa pagina con lo stesso intento. Se /pricing diventa https://newdomain.com/pricing, è semplice. Se tre vecchie pagine prodotto vengono unite in una nuova guida, documenta deliberatamente quella decisione.

Evita lo schema pigro: reindirizzare tutto alla nuova homepage. È comodo, ma elimina la rilevanza. Sia i motori di ricerca sia gli utenti si aspettano che la destinazione risponda alla stessa esigenza dell’URL originale.

Mantieni la struttura degli URL quando puoi

Una migrazione di dominio è più semplice quando i percorsi restano stabili. Passare da oldsite.com/blog/example a newsite.com/blog/example è molto più pulito che cambiare dominio, CMS, slug, struttura delle cartelle e contenuti nello stesso momento.

A volte un redesign o una migrazione CMS rende inevitabili le modifiche agli URL. In quel caso, separa le decisioni:

1. Che cosa cambia perché sta cambiando il dominio?
2. Che cosa cambia perché sta cambiando la struttura del sito?
3. Che cosa viene eliminato, unito o riscritto?

Più variabili introduci, più diventa difficile diagnosticare i problemi in seguito. Se la migrazione è importante e il sito attuale sta performando bene, valuta di spostare prima il dominio e ridisegnare in un secondo momento.

Usa redirect permanenti e a un solo salto

Per una vera migrazione di dominio, usa redirect lato server 301 o 308 dai vecchi URL ai loro nuovi equivalenti. I redirect temporanei servono per situazioni temporanee. I redirect JavaScript, i meta refresh e i soft redirect sono segnali più deboli e più facili da rompere.

Gli obiettivi dei redirect sono semplici:

• Ogni vecchio URL importante restituisce un redirect permanente.
• Ogni redirect porta direttamente alla destinazione finale.
• HTTP reindirizza a HTTPS in modo pulito.
• Le varianti www e non-www sono gestite in modo coerente.
• I redirect non dipendono da comportamenti fragili delle query string, salvo necessità.

Una catena sbagliata appare così:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Alla fine potrebbe arrivare alla pagina giusta, ma è lenta, più difficile da scansionare e più incline a nascondere errori. Punta a un solo salto da ogni vecchia variante al nuovo URL finale.

Quando convalidi il comportamento, ispeziona le risposte HTTP effettive invece di fidarti di ciò che mostra il browser. La nostra guida al debug di redirect e header HTTP in produzione è utile qui perché i browser sono troppo educati: seguono la catena e nascondono le parti disordinate.

Prepara DNS e certificati prima del lancio

Il DNS non trasferisce direttamente il posizionamento, ma un DNS configurato male può far sembrare rotta una migrazione. Abbassa i valori TTL prima della finestra di lancio, così le modifiche si propagano in modo più prevedibile. Conferma che il nuovo dominio abbia i record corretti per traffico web, email e qualunque sottodominio necessario.

Servono anche certificati TLS validi per entrambi i domini. È facile dimenticarlo. Il vecchio dominio deve ancora servire redirect HTTPS dopo la migrazione. Se il suo certificato scade, utenti e crawler potrebbero incontrare avvisi del browser prima ancora di raggiungere il nuovo sito.

Se lo spostamento coinvolge l’email, non trattarla come un dettaglio secondario. I cambi di dominio spesso rompono SPF, DKIM, DMARC, record MX, link di tracciamento e email transazionali. Per un ripasso sui record che contano, consulta la nostra guida per sviluppatori a MX, SPF, DKIM e DMARC.

Controlla canonical, link interni e sitemap

Dopo il lancio, il nuovo dominio dovrebbe comportarsi come se fosse sempre stato la sede canonical dei contenuti.

Questo significa:

• I tag canonical puntano ai nuovi URL, non al vecchio dominio.
• I link interni usano il nuovo dominio o percorsi root-relative.
• Le sitemap XML contengono solo nuovi URL finali e indicizzabili.
• Le annotazioni hreflang, se usate, fanno riferimento ai nuovi URL.
• Open Graph, dati strutturati e link alternativi sono aggiornati.
• Robots.txt non blocca sezioni importanti.

Non pubblicare una sitemap piena di vecchi URL aspettandoti che i redirect risolvano tutto. Una sitemap dovrebbe essere un elenco di URL che vuoi indicizzare. Dopo una migrazione, significa URL finali sul nuovo dominio.

Fai attenzione anche alle contraddizioni canonical. Una pagina che reindirizza dal vecchio al nuovo dominio ma ha un canonical che punta di nuovo al vecchio dominio invia segnali contrastanti. Di solito i motori di ricerca riescono a superare qualche incoerenza, ma non dovresti chiederglielo.

Non cambiare tutto il giorno del lancio

Una migrazione è già un evento abbastanza grande. Se possibile, evita di combinarla con grandi tagli ai contenuti, riscritture dei template, modifiche alla navigazione, cambiamenti nel rendering JavaScript o un nuovo profilo prestazionale.

Non è superstizione. È disciplina di debug. Se il posizionamento cala dopo il lancio, devi sapere se la causa è la mappatura dei redirect, l’accesso alla scansione, i contenuti modificati, un rendering più lento, dati strutturati mancanti o qualcos’altro.

Mantieni il lancio iniziale il più vicino possibile al vecchio sito. Una volta che il nuovo dominio è stabile, apporta modifiche editoriali e di design più ampie in lotti più piccoli.

Comunica ai motori di ricerca che cosa è cambiato

In Google Search Console, verifica sia il vecchio sia il nuovo dominio. Poi usa lo strumento Cambio di indirizzo quando lo spostamento è un cambio a livello di dominio e i contenuti vengono trasferiti a un nuovo dominio. Invia la nuova sitemap dopo il lancio.

Questo non sostituisce i redirect. Li supporta. I motori di ricerca hanno comunque bisogno di redirect scansionabili e persistenti per comprendere la mappatura a livello di URL.

Per Bing e altri motori di ricerca, usa i loro strumenti per webmaster quando disponibili. Aggiorna anche i punti che controlli: profili social, schede aziendali, destinazioni degli annunci, firme email, documentazione, link dei partner e riferimenti canonical nei contenuti distribuiti.

Non tutti i link esterni verranno aggiornati, e va bene così. Ma quelli più importanti dovrebbero esserlo. Se un partner importante, un app marketplace, un portale di documentazione o una pagina stampa rimanda al vecchio dominio, chiedi un aggiornamento.

Monitora le cose giuste dopo il lancio

I primi giorni dopo la migrazione dovrebbero essere di monitoraggio attivo, non di celebrazione.

Controlla:

• Log del server per l’attività di scansione sui vecchi e nuovi domini
• 404 ed errori 5xx imprevisti
• Catene e loop di redirect
• Stato di indicizzazione in Search Console
• Scoperta ed elaborazione della sitemap
• Landing page organiche e pattern delle query
• Percorsi di conversione che dipendono dai vecchi URL
• Filtri analytics ed esclusioni dei referral

Aspettati rumore nei report. Alcuni strumenti di analytics trattano il nuovo dominio come una nuova proprietà se non sono configurati correttamente. Alcune dashboard confrontano il traffico del vecchio dominio con quello del nuovo dominio e fanno sembrare la migrazione peggiore di quanto sia.

La visibilità nella ricerca può fluttuare per qualche settimana. Ciò che non vuoi è uno schema in cui vecchi URL di alto valore vengono scansionati ripetutamente ma non reindirizzati correttamente, oppure in cui nuove pagine vengono scoperte ma contrassegnate come duplicati del vecchio dominio.

Nemmeno le performance dovrebbero essere ignorate. Se il nuovo dominio viene lanciato con template più pesanti, caching rotto o asset non ottimizzati, gli utenti potrebbero percepire la migrazione come un rallentamento. Se usi Lighthouse come parte dei controlli, leggilo tenendo a mente le priorità; il nostro articolo su come leggere un report Lighthouse senza farsi prendere dal panico spiega come separare i problemi significativi dal rumore.

Mantieni il vecchio dominio a lungo

Non lasciare scadere il vecchio dominio dopo che la migrazione “funziona”. Tienilo registrato, mantieni validi i certificati e lascia attivi i redirect il più a lungo possibile. In pratica, spesso significa anni.

I vecchi link continuano a esistere in post di blog, bookmark, documentazione, PDF, email e post social. I redirect sono il ponte tra quella impronta storica e il nuovo dominio. Disattivarli troppo presto interrompe i percorsi degli utenti e spreca i segnali accumulati.

Conserva anche una copia della mappa dei redirect e delle note di lancio. Sei mesi dopo, quando qualcuno chiederà perché un URL legacy si comporta in un certo modo, sarai contento di averlo documentato.

<!-- tool-cta:start -->

💡 Prova questo: Dopo il passaggio, traccia i tuoi vecchi URL con Redirect Checker per confermare che ciascuno si risolva con un singolo hop 301 verso la nuova pagina corretta.

<!-- tool-cta:end -->

Una checklist di migrazione sensata

Prima del lancio:

• Verifica entrambi i domini in Search Console.
• Scansiona il sito attuale ed esporta gli URL importanti.
• Crea una mappa di redirect uno-a-uno.
• Abbassa i TTL DNS.
• Prepara certificati TLS per il vecchio e il nuovo dominio.
• Aggiorna canonical, link interni, hreflang, dati strutturati e sitemap.
• Testa i redirect in staging o in un ambiente controllato.

Il giorno del lancio:

• Distribuisci i redirect.
• Conferma il comportamento da HTTP a HTTPS.
• Testa campioni di URL importanti da ogni tipo di template.
• Invia la nuova sitemap.
• Usa lo strumento Cambio di indirizzo quando appropriato.
• Monitora errori server, loop di redirect e risorse bloccate.

Dopo il lancio:

• Monitora errori di scansione e report di indicizzazione.
• Aggiorna i link esterni importanti dove puoi.
• Confronta il traffico per intento della landing page, non solo per totali di dominio.
• Mantieni i redirect attivi indefinitamente.
• Rimanda redesign o esperimenti sui contenuti non correlati finché lo spostamento non si stabilizza.

Le migrazioni di dominio non sono prive di rischi, ma sono gestibili. Il posizionamento di solito soffre quando la migrazione invia segnali poco chiari: redirect mancanti, contenuti modificati, canonical contraddittori, crawler bloccati o un vecchio dominio dimenticato. Offri ai motori di ricerca e agli utenti una mappa pulita, e lo spostamento diventa molto meno drammatico.