Migrazione SEO: guida, checklist e piano di collaudo per PMI

Cos’è la migrazione SEO e quando serve

La migrazione SEO è la gestione del passaggio da una configurazione del sito a un’altra tenendo sotto controllo ciò che permette alle persone e ai motori di trovare i contenuti. Il punto non è soltanto trasferire file: è conservare le risposte che il sito offre e rendere comprensibile dove si trovano dopo il cambiamento.

Un cambio di dominio, di piattaforma o degli indirizzi delle pagine richiede particolare attenzione. Anche un restyling che mantiene le URL merita un collaudo: può cambiare navigazione, testo visibile, velocità o funzionamento dei moduli. Per decidere se rifare il sito, parti dalla guida generale al restyling. Qui affrontiamo la decisione successiva: come organizzare il passaggio.

Cambio dominio, CMS, URL o solo grafica?

Definire il tipo di passaggio evita di chiedere le stesse attività a progetti diversi. Un nuovo dominio modifica tutti gli indirizzi; un cambio di CMS può conservarli ma cambiare la struttura del codice; un restyling può mantenere entrambe le cose e modificare navigazione, contenuti e percorsi di conversione. Prima del preventivo chiedi una descrizione delle differenze previste, non soltanto il nome della nuova piattaforma.

Se una proposta unisce redesign, cambio dominio e riscrittura completa, il piano deve spiegare anche come riconoscere la causa di eventuali problemi. Separare i cambiamenti quando possibile rende più leggibili i risultati; se devono avvenire insieme, documenta le dipendenze prima del lancio.

Prima della migrazione: audit, inventario e dati di partenza

Prima dei nuovi bozzetti chiedi un elenco delle pagine da proteggere. La sitemap è un punto di partenza; integrala con i contenuti del CMS, le pagine che ricevono traffico, quelle con link e i documenti ancora utilizzati. Google descrive questo approccio nella guida agli spostamenti di siti.

Per una PMI, il file diventa utile quando ogni riga spiega anche il valore della pagina. Una scheda tecnica con poche visite può sostenere una trattativa importante. Una notizia molto letta può avere un contributo commerciale modesto. Chiedi al referente vendite di indicare i contenuti che invia ai clienti: è una verifica organizzativa che un semplice elenco di URL non può sostituire.

Il nostro criterio proposto è conservare almeno cinque informazioni: indirizzo attuale, funzione per il lettore, domanda organica osservata, percorso di contatto e decisione prevista. Non eliminare una pagina soltanto perché un tool non le attribuisce traffico stimato.

Quale fonte risponde a quale domanda

Un crawler mostra le risorse che riesce a raggiungere; Search Console descrive parte della domanda organica; Analytics e CRM aiutano a ricostruire percorsi e richieste. Il database di un tool SEO aggiunge query e confronti, ma non sostituisce le altre fonti. Se manca un dato, scrivi “non disponibile”: attribuire zero a una pagina non misurata può far eliminare un contenuto utile.

Il foglio di lavoro dovrebbe collegare ogni URL alla sua tipologia, allo stato HTTP, al canonical, al titolo, alle query osservate e alla destinazione prevista. Aggiungi immagini e PDF utilizzati dai clienti e pagine non più raggiungibili dai menu ma ancora richiamate da email o siti esterni. Conserva gli export con data, mercato, periodo e filtri: senza questo contesto il confronto successivo è fragile.

Una baseline commerciale richiede anche una definizione condivisa di contatto qualificato. Un invio duplicato, una candidatura o una richiesta fuori perimetro non devono diventare una vendita persa nel confronto dopo la migrazione.

Mappa delle URL e redirect: esempi di decisioni corrette

Per ogni URL scegli un trattamento comprensibile. La tabella seguente è un esempio didattico: gli indirizzi non appartengono a un progetto cliente.

Google raccomanda redirect permanenti lato server, percorsi diretti e destinazioni pertinenti. Reindirizzare indiscriminatamente tutto alla home può essere interpretato come un soft 404. Conservare i redirect almeno un anno è la sua indicazione generale; per i collegamenti ancora utilizzati la manutenzione può durare più a lungo.

Un esempio concreto di mappatura

Gli indirizzi seguenti sono fittizi. Servono a leggere il documento di progetto, non sono regole da copiare sul proprio server.

La documentazione Google sui redirect distingue gli spostamenti permanenti da quelli temporanei e raccomanda quelli permanenti lato server quando adatti al caso. Il canonical, invece, indica una preferenza fra versioni equivalenti: non accompagna il visitatore dal vecchio indirizzo a quello nuovo.

Fai collaudare le regole con tutte le URL inventariate. Una regola generica che funziona per dieci prodotti può sbagliare categorie, allegati o vecchi indirizzi già reindirizzati. La prova utile registra destinazione attesa e destinazione ottenuta, non soltanto la presenza di un codice 301.

Chi decide, chi esegue, chi autorizza il lancio

Una buona mappa non basta se nessuno può prendere decisioni. Assegna un referente aziendale ai contenuti, un responsabile tecnico all’implementazione e un referente SEO al collaudo della reperibilità. Chi segue vendite o assistenza deve provare il percorso che porta dalla pagina alla richiesta.

Concorda anche chi autorizza il lancio e sulla base di quali prove. Il fornitore dovrebbe consegnare un registro delle anomalie con gravità, responsabile e stato. Un difetto che impedisce una richiesta commerciale pesa diversamente da una spaziatura da rifinire. La frase “abbiamo controllato tutto” non permette di capire né cosa sia stato provato né cosa resti aperto.

Queste responsabilità vanno chiarite già nel preventivo del sito web, insieme a manutenzione dei redirect e assistenza dopo il passaggio.

Checklist prima del lancio: indicizzazione, contenuti e conversioni

Prepara due percorsi di prova. Il primo segue gli indirizzi: pagina vecchia, eventuale redirect, pagina finale, collegamenti successivi. Il secondo segue una persona: arrivo da smartphone, lettura dell’offerta, apertura del form, invio di una richiesta di test e ricezione nel sistema previsto. Il test va concordato e chiaramente riconoscibile, così non viene contato come opportunità commerciale.

Controlla che i riferimenti canonici, i link interni e la sitemap siano coerenti con le pagine scelte. Un canonical è un segnale di preferenza per i contenuti equivalenti: non sostituisce il reindirizzamento necessario a chi apre un vecchio collegamento. La documentazione Google sulla canonicalizzazione chiarisce la distinzione.

Una verifica operativa spesso trascurata riguarda la differenza fra amministratore e visitatore: il sito può apparire corretto a chi è loggato e mostrare un’altra versione a chi arriva da fuori. Prova entrambe le condizioni. Sul telefono controlla inoltre la raggiungibilità dei pulsanti, non soltanto l’assenza di elementi tagliati.

Staging, robots.txt e noindex

L’ambiente di prova deve restare riservato durante lo sviluppo. Per questo è preferibile concordare una protezione di accesso reale: un blocco in robots.txt non è una password. Inoltre, Google spiega che per leggere un noindex deve poter scansionare la risorsa. Bloccare contemporaneamente la scansione può impedirgli di vedere quella direttiva.

Prepara due configurazioni distinte, prova e produzione, e assegna a qualcuno la verifica del passaggio. Non basta togliere una spunta nel CMS: controlla la risposta ricevuta da un visitatore esterno, eventuali header e i template delle principali tipologie di pagina.

Contenuto visibile, link e informazioni strutturate

Confronta una pagina servizio, un articolo, una categoria e, quando presenti, una scheda prodotto e una versione in altra lingua. Devono conservare contenuti essenziali, titoli pertinenti, collegamenti utilizzabili e informazioni corrette. Controlla anche ciò che il nuovo tema carica via JavaScript: una pagina formalmente 200 può avere un contenuto principale vuoto o incompleto.

Non trasferire automaticamente un vecchio dato strutturato se il contenuto visibile è cambiato. Un prezzo, un autore o una disponibilità devono descrivere la pagina attuale. La validità sintattica del codice non dimostra la correttezza del dato.

Il percorso commerciale va provato fino alla ricezione

Un pulsante che si apre non basta. Compila una richiesta di test riconoscibile, verifica il messaggio di conferma e il sistema che deve riceverla, poi confronta l’evento misurato. Se esistono più moduli, registra quelli provati e quelli ancora da collaudare. Il test del form contatti non certifica un checkout o una richiesta di preventivo presente in un altro template.

Il giorno del passaggio: controlli e responsabilità

Fissa una finestra in cui i responsabili siano disponibili e le modifiche editoriali siano coordinate. Conserva una copia recuperabile della versione precedente e stabilisci quali problemi richiedano una correzione immediata e quali giustifichino il ripristino. Il ripristino non deve dipendere da una persona irreperibile.

Se sono cambiati anche form, account o sistemi di misurazione, annotalo nel registro del progetto. Una variazione degli eventi registrati dopo il lancio non dimostra automaticamente una variazione del comportamento degli utenti. Prima di interpretare un calo o una crescita, verifica che la definizione del dato sia rimasta confrontabile.

La finestra operativa deve avere un ordine concordato: confermare il backup recuperabile, rilasciare la configurazione prevista, attivare i redirect necessari, controllare le pagine prioritarie dall’esterno e ripetere i percorsi di conversione. Verifica sitemap e riferimenti al dominio finale. Quando cambia il dominio, includi nel piano le proprietà Search Console e la valutazione dello strumento Cambio di indirizzo secondo le istruzioni applicabili al passaggio.

Un cambio hosting richiede anche il coordinamento dei puntamenti e dei servizi collegati. Non spegnere componenti perché “il nuovo sito si vede”: prima accerta dove vengono serviti redirect, file e funzioni. La responsabilità deve essere assegnata al tecnico che conosce l’architettura effettiva.

Dopo la migrazione: come leggere un calo di traffico

Google avverte che durante una migrazione possono verificarsi oscillazioni temporanee. Questo non rende normale qualunque problema: pagine importanti irraggiungibili, destinazioni errate e moduli che non funzionano vanno gestiti subito.

Proponiamo un registro separato per tre domande: il sito funziona? Le pagine vengono trovate? Le visite utili producono richieste? Nelle prime verifiche prevale la prima; nelle settimane successive si aggiungono le altre, confrontando gruppi di pagine e periodi omogenei. Mantieni separati brand e ricerche generiche, dispositivi e mercati quando cambiano molto il risultato.

Se una pagina riceve meno clic, guarda anche le query e le impressioni prima di attribuire tutto alla migrazione. Stagionalità, domanda e modifiche concorrenti possono contribuire. Se cresce il traffico ma diminuiscono le richieste qualificate, il problema potrebbe trovarsi nell’offerta o nel percorso di conversione.

Non esiste una percentuale universale di perdita da considerare innocua. Un calo modesto su una pagina che porta ordini può meritare attenzione immediata; un’oscillazione ampia su pochissime visite può essere rumore. Valuta andamento, perimetro, domanda e difetti osservabili insieme.

E-commerce e siti multilingua: cosa aggiungere al piano

Nel passaggio di un e-commerce controlla anche categorie, varianti, prodotti ritirati, filtri e URL dei documenti. Una categoria ben posizionata non è sostituibile automaticamente con un prodotto; una scheda esaurita richiede una decisione sul contenuto e sulle alternative offerte al cliente. Prezzo e disponibilità visibili devono restare coerenti con le informazioni che il sito comunica ai sistemi esterni.

Nel cambio piattaforma chiedi una prova su casi diversi prima di applicare una regola a tutto il catalogo: prodotto con varianti, prodotto fuori catalogo, categoria con filtri e articolo che porta al negozio. Verifica carrello, richiesta commerciale o acquisto di test nel perimetro autorizzato. Il numero di prodotti trasferiti non certifica la qualità del passaggio.

Per le lingue, conserva una mappa per ciascuna versione. Controlla che selettori e collegamenti portino alla lingua giusta e che canonical e riferimenti fra versioni siano coerenti. Una traduzione non equivalente non deve diventare la destinazione predefinita di ogni pagina rimossa.

La matrice di via libera: decidere sulla base delle prove

Questo è il modello operativo che proponiamo per rendere verificabile la decisione di lancio. Non assegna un punteggio SEO e non promette risultati: collega ogni controllo alla responsabilità e alla decisione che ne consegue.

Esempio: tutte le pagine rispondono 200, ma una richiesta non arriva al CRM. L’esito “SEO tecnica completata” può essere vero entro quel perimetro; l’esito “sito pronto a generare richieste” non lo è. La matrice rende visibile questa differenza prima che il problema venga raccontato come un calo di conversione.

Costi e tempi: che cosa deve includere il preventivo

Il costo di una migrazione SEO dipende dal lavoro necessario, non soltanto dal numero di URL. Un sito piccolo con più lingue, funzioni su misura e dati incompleti può richiedere più coordinamento di un catalogo ampio ma regolare. Una stima seria distingue analisi, mappatura, implementazione, collaudo e assistenza successiva.

Chiedi quali attività esegue il consulente SEO e quali restano allo sviluppatore: raccomandare i redirect non equivale a configurarli. Specifica chi scrive i contenuti mancanti, mantiene il dominio precedente e corregge le anomalie scoperte dopo il rilascio. Concorda una finestra di supporto e condizioni per il passaggio di consegne.

Non confondere la data di pubblicazione con il tempo necessario a valutare la nuova presenza organica. La prima dipende dal progetto e dalle prove; il secondo dipende anche dalla risposta dei sistemi di ricerca. Per confrontare offerte diverse, usa il nostro approfondimento sul preventivo del sito web insieme alla matrice di collaudo.

Cosa chiedere nel documento finale

La chiusura del progetto dovrebbe lasciare all’azienda la mappa aggiornata, il registro dei controlli, l’elenco delle eccezioni aperte e i riferimenti di chi manterrà il sito. Chiedi che il rapporto distingua controlli completati e risultati ancora da osservare: una migrazione collaudata oggi non è una garanzia di ranking futuro.

Per noi la domanda utile prima di un restyling è questa: quali parti del sito stanno già lavorando per l’azienda e come verranno protette? Se stai preparando il passaggio, puoi condividere il progetto con Tready. Valuteremo il perimetro insieme al servizio di restyling del sito web, prima di proporre interventi.

Domande frequenti