Rifare il sito senza perdere il posizionamento: il metodo di una migrazione SEO

Le migrazioni che fanno crollare il traffico raramente falliscono per motivi misteriosi. Falliscono per redirect mancanti, contenuti persi per strada, un noindex dimenticato dallo staging o canonical che puntano ancora ai vecchi indirizzi. Sono errori prevedibili, e quindi evitabili con un metodo. Questo è il mio, diviso nelle fasi in cui lo applico.

Fase 1: inventario

L'elenco degli URL esistenti è la base di tutto, e non si ricava da una sola fonte.

• Crawl completo del sito attuale, con status, canonical, title, description, H1, link interni.
• Sitemap XML esistenti.
• Search Console: pagine con impressioni e clic negli ultimi 12-16 mesi, comprese quelle che il crawl non trova più.
• Log del server o della CDN: URL richiesti da Googlebot e dagli utenti.
• Backlink: URL che ricevono link esterni, compresi quelli con errori di battitura.

Dall'unione si ottiene la lista degli URL che contano, ordinata per traffico, conversioni e link. Si salvano anche le metriche di partenza: clic, posizioni medie per gruppi di pagine, Core Web Vitals.

Fase 2: decisioni e mappa dei redirect

Per ogni URL una decisione esplicita: mantenere, spostare, unire, eliminare. Poi la mappa dei redirect, uno a uno:

• ogni URL che cambia porta con un 301 al contenuto equivalente;
• niente redirect di massa alla home: Google li tratta come soft 404;
• niente catene: un vecchio URL arriva alla destinazione in un solo salto, anche se nel frattempo c'erano già stati altri redirect;
• regole per i pattern (parametri, maiuscole, barre finali, vecchie strutture di paginazione) oltre ai singoli URL;
• URL eliminati senza equivalente: 404 o 410, non 200.

La mappa si scrive in un formato che si può testare automaticamente: un file con origine e destinazione attesa.

Fase 3: parità nel nuovo sito

Il nuovo sito deve conservare i segnali che hanno fatto posizionare il vecchio, almeno per le pagine importanti:

• contenuti equivalenti, non riassunti per far stare il design;
• title, description, struttura degli H1 e H2;
• link interni verso le pagine chiave, con profondità di clic simile o migliore;
• dati strutturati;
• hreflang coerenti se il sito è multilingua;
• immagini importanti con gli stessi URL o con redirect.

Un principio: se una pagina porta traffico, si adatta il design al contenuto, non il contrario.

Fase 4: staging e test

• Ambiente di staging protetto da password, non solo da noindex: è più sicuro e non lascia tracce da rimuovere.
• Crawl dello staging confrontato con quello del sito attuale: pagine mancanti, title vuoti, canonical sbagliati, link rotti.
• Test automatico della mappa dei redirect: ogni origine deve rispondere 301 verso la destinazione attesa, in un salto.
• Prestazioni e Core Web Vitals in laboratorio sui template principali.

Fase 5: il lancio

Il giorno del lancio, nell'ordine:

1. cambio DNS o deploy in un momento di traffico basso;
2. verifica di robots.txt e assenza di noindex ereditati dallo staging;
3. test della mappa dei redirect contro la produzione;
4. canonical e sitemap aggiornate con i nuovi URL, sitemap inviata in Search Console;
5. controllo a campione delle pagine più importanti.

Fase 6: monitoraggio

Nelle settimane successive: copertura dell'indice e soft 404 in Search Console, log per i 404 su URL con traffico o link, confronto di clic e posizioni per gruppi di pagine con le metriche di partenza, Core Web Vitals reali. Le correzioni si fanno subito: un redirect mancante scoperto dopo due mesi ha già fatto il suo danno.

Gli errori che costano di più

• noindex o blocchi in robots.txt ereditati dallo staging: il sito nuovo sparisce dall'indice in pochi giorni.
• Redirect di massa alla home: Google li tratta come soft 404 e il valore delle pagine vecchie si perde.
• Catene di redirect: ogni salto in più disperde segnali e rallenta la scansione.
• Contenuti tagliati per far stare il design: le pagine che portavano traffico perdono proprio ciò per cui si posizionavano.
• Canonical che puntano ancora ai vecchi URL o, peggio, al dominio di staging.
• Cambio di dominio e rifacimento insieme, senza lo strumento di cambio di indirizzo.
• Nessun monitoraggio dopo il lancio: gli errori si scoprono quando il calo è già consolidato.

Quasi tutti si intercettano con un crawl dello staging confrontato con il sito attuale e con il test automatico della mappa dei redirect. Sono controlli che richiedono ore, a fronte di danni che si misurano in mesi.

Come la vedo io

La migrazione è la parte di un rifacimento che conta più del design, e la tratto come codice: la mappa dei redirect sta nel repository insieme al sito, viene testata in automatico e fa parte del deploy. Con Nuxt e Netlify è particolarmente comodo: le regole di redirect vivono nella configurazione del progetto e ogni anteprima permette di verificarle prima della pubblicazione. Su questo stesso sito, quando la sezione articoli ha cambiato nome e alcuni contenuti sono stati unificati, ogni vecchio indirizzo è stato mappato sul contenuto più vicino.

Se stai valutando un passaggio da WordPress a un'architettura statica, la migrazione SEO è la parte da progettare per prima: ne parlo in Da WordPress a Nuxt, GitHub e Netlify.

E consiglio sempre di non far coincidere il lancio con un periodo di picco dell'attività: una migrazione merita settimane tranquille di osservazione.

Perché affidarlo a me

Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 agenzie, da Roma e da remoto. Gestisco migrazioni con inventario da più fonti, redirect testati in automatico e monitoraggio dopo il lancio.

Se stai per rifare il sito, scrivimi prima di toccare gli indirizzi: in una chiacchierata di circa 20 minuti capiamo cosa proteggere. Il servizio è in Velocità e SEO.