KLC Richiedi un’analisi
Passa al contenuto principale
Migrazione SEO o semplice mappa redirect? Perché il mapping non basta

Migrazione SEO: perché la mappa redirect non basta

Scritto da KLC il . Pubblicato in SEO.

23 Settembre 2026 · SEO

Per cambiare sito, CMS (il programma che gestisce i contenuti) o dominio senza perdere posizioni su Google, richieste ed email, serve confrontare il vecchio sito con il nuovo. Va provato anche tutto il percorso del cliente, fino alla ricezione del messaggio. La mappa dei redirect collega i vecchi indirizzi ai nuovi, ma non basta a dimostrare che il cliente trovi ancora i dati tecnici e riesca a contattarti.

Questi controlli fanno parte della migrazione SEO, cioè del trasferimento del sito che tiene conto della sua presenza su Google. Quando indirizzi, schede e moduli cambiano tutti insieme, le richieste possono diminuire per motivi diversi. Tenere separate le modifiche aiuta a capire dove cercare il problema.

Dominio, CMS e hosting cambiano cose diverse

Il dominio è il nome che usi per raggiungere il sito. Il CMS gestisce pagine e contenuti, mentre l’hosting è il servizio che ospita il sito sui server. Un cambio di dominio modifica gli indirizzi pubblici. Con un altro CMS, invece, gli indirizzi possono restare identici mentre possono cambiare schede, collegamenti o invio dei moduli. Un cambio di hosting può rendere difficile accedere al sito anche se nessuna pagina è stata modificata.

Quando è possibile, Google consiglia di cambiare dominio, CMS e grafica in momenti diversi. Così è più facile capire quale modifica ha causato un difetto. Se il progetto prevede di pubblicare tutto insieme, mantieni separate le prove: un nuovo indirizzo che si apre correttamente non dimostra che funzioni anche il nuovo modulo.

Che cosa cambia determina quali rischi cercare e quali prove fare.
Cambiamento Rischio specifico Prova
Dominio Vecchi indirizzi non più accessibili Aprire vecchi link e documenti
CMS o grafica Dati mancanti, moduli che non funzionano Confrontare le schede e inviare richieste
Percorsi delle pagine Nuove pagine che non rispondono alla stessa esigenza Confrontare la ricerca con il contenuto di arrivo
Hosting Sito non raggiungibile Provare la copia del sito e il passaggio DNS

Quando cambi hosting, il DNS, cioè il sistema che collega il nome del sito al server, porta gli accessi ai nuovi server. Prima di questo passaggio occorre provare pagine, immagini, moduli e PDF sulla copia del sito. Il vecchio hosting va spento dopo aver controllato che non riceva più traffico.

La mappa dei redirect deve mantenere la risposta alla ricerca

Un redirect porta automaticamente da un indirizzo a un altro. I redirect permanenti lato server, con codice 301 o 308, indicano a Google quale indirizzo preferire. La nuova pagina deve rispondere alla stessa esigenza di chi cerca. Una pagina generale può quindi raccogliere più schede, purché mantenga le risposte utili che contenevano. Se tutti gli indirizzi portano a una pagina iniziale non pertinente, Google può interpretarla come un soft 404: una pagina di fatto assente, anche se il link si apre.

Prendiamo, per esempio, un produttore italiano di tessuti tecnici filtranti che cambia CMS e, dopo un cambio di marchio, valuta anche un nuovo dominio. Nel catalogo ci sono 60 schede e 12 PDF. Chi si occupa degli acquisti cerca «tessuto filtrante per filtropressa in polipropilene». Arriva così a una scheda che contiene una «Tabella di permeabilità», il manuale da scaricare e il pulsante «Richiedi un campione».

L’elenco delle risorse da trasferire deve includere questi percorsi, anche quando il cliente arriva a un PDF direttamente da Google o dai preferiti. Alla sitemap, cioè all’elenco delle pagine del sito, affianca gli indirizzi presenti in Search Console, nei dati di accesso e nei link da altri siti. Il menu potrebbe non mostrarli tutti. Registra non solo la nuova destinazione, ma anche i contenuti e le funzioni da mantenere. Quando elimini una risorsa senza sostituirla, la risposta corretta è un codice 404 o 410, che ne segnala l’assenza, non un rinvio a una pagina che parla d’altro.

Il collaudo termina quando arriva la richiesta

Per fare una prova utile, confronti due versioni: il nuovo CMS con gli indirizzi attuali e il nuovo dominio con i contenuti e le funzioni attuali. La prima serve a cercare difetti nelle schede e nei moduli. Con la seconda controlli i vecchi collegamenti, i documenti e i servizi legati al dominio. Se l’errore si presenta anche con il vecchio dominio, hai un indizio per cercare il problema nel nuovo CMS prima di esaminare i redirect.

Nell’esempio del catalogo di tessuti filtranti, il vecchio link apre la scheda giusta, ma il nuovo modello di pagina non contiene la tabella di permeabilità. Chi deve acquistare non riesce quindi a confrontare il materiale. Dal manuale raggiunge comunque il pulsante per chiedere un campione, ma sul telefono il modulo non riesce a completare l’invio dell’allegato. I collegamenti della mappa funzionano, mentre il percorso che dovrebbe portare alla richiesta si interrompe. Per correggere il problema si ripristinano la tabella e l’invio da telefono. La prova ricomincia dal vecchio PDF e finisce quando arriva una richiesta con il prodotto e l’allegato.

Anche un dominio che serve solo a reindirizzare ha bisogno del suo certificato di sicurezza. In HTTPS, il protocollo per la navigazione protetta, la connessione protetta e la verifica del certificato precedono la richiesta HTTP. Per questo un certificato non valido può bloccare l’accesso prima che il redirect entri in funzione. Prova quindi anche i vecchi indirizzi dei documenti, nelle varianti che vengono effettivamente usate.

Le email seguono un percorso diverso. Per sapere dove consegnare il messaggio, il mittente cerca nei record MX del dominio dove recapitare l’email. Il redirect del sito non trasferisce le caselle di posta e cambiare dominio web non obbliga a cambiarne il nome. Se il progetto modifica anche la posta, prova a inviare e ricevere messaggi con indirizzi esterni, usando le caselle vecchie e nuove previste.

Redirect e Cambio di indirizzo hanno compiti e durate diversi

I collegamenti interni del nuovo sito devono aprire direttamente le pagine finali. Anche il canonical, che dichiara quale indirizzo preferire per una pagina, e la sitemap devono riportare i nuovi indirizzi, detti URL. Togli dal sito pubblico i blocchi usati sulla copia di prova, come noindex e le restrizioni nel file robots.txt. Queste impostazioni possono impedire a Google di leggere le nuove pagine o di inserirle correttamente nel suo indice.

Google raccomanda di mantenere i redirect generalmente per almeno 1 anno. Ai clienti possono servire anche più a lungo, perché i vecchi manuali e collegamenti continuano a circolare. Prevedi quindi di rinnovare il vecchio dominio e i certificati che gli permettono di rispondere. Pubblicare il nuovo sito non rende inutile l’accesso dal vecchio indirizzo.

Il Cambio di indirizzo in Search Console ha effetti sul trasferimento dei segnali per 180 giorni. Questo strumento serve a comunicare lo spostamento di un dominio o sottodominio, dopo aver completato il trasferimento e attivato i redirect. Per usarlo, lo stesso account proprietario deve aver verificato sia la vecchia sia la nuova proprietà. Non sostituisce i redirect e non fissa il tempo massimo per cui mantenerli.

Due schede distinguono la durata dei redirect dagli effetti dello strumento Cambio di indirizzo.
Durate con funzioni diverse nella migrazione: almeno 1 anno per i redirect secondo Google Search Central; 180 giorni per gli effetti del Cambio di indirizzo secondo Search Console Help. Documentazione consultata il 4 novembre 2026; unità: anno e giorni.

Scarica l’infografica (PNG ad alta risoluzione)

Scarica in PDF

Incorpora l’infografica nel tuo sito

Puoi ripubblicare l’infografica usando questo codice, con il collegamento all’articolo originale.


Per le varianti di sottodominio interessate, comprese www e non-www, servono verifiche e invii separati. Ogni richiesta copre i protocolli della proprietà di partenza. Lo strumento non serve se cambi solo i percorsi delle pagine, passi da HTTP a HTTPS o alterni www e non-www sullo stesso dominio. Non serve neppure se sposti l’hosting mantenendo gli stessi URL. Per ciascuno di questi passaggi restano comunque necessarie le relative prove tecniche.

Un calo dei risultati va distinto da un guasto del sito

Prima di pubblicare il nuovo sito, salva da Search Console i clic e le ricerche, insieme alle pagine da cui entrano i visitatori e alle richieste ricevute. Tieni separati i dati per famiglia di prodotto e dispositivo. Dopo la pubblicazione, confronta gli stessi gruppi usando periodi e impostazioni di misurazione confrontabili. Il totale può restare stabile anche se una famiglia di prodotti riceve meno visite. Se invece le richieste diminuiscono solo da telefono, il percorso da provare è quello da mobile.

In Google Analytics, generate_lead è l’evento consigliato per una richiesta di informazioni. È una registrazione dell’azione compiuta dall’utente: occorre configurarla e controllarla, perché non compare da sola. Verificala dopo un invio riuscito, usando DebugView o Tempo reale, le funzioni di controllo di Analytics. L’evento registrato non dimostra che siano arrivati anche il messaggio e l’allegato. La ricezione va provata a parte.

Anche la landing page è la pagina d’ingresso della sessione: è la prima pagina visitata e può non coincidere con quella del modulo. Per ritrovarla nella richiesta che ricevi, occorre configurare e provare il sistema che la conserva. Registrare l’evento non basta a farlo automaticamente. Per controllare gli accessi diretti a un PDF servono anche i dati di accesso al server: non si possono ricavare dai soli eventi delle pagine.

Se le richieste arrivano ma manca l’evento, il problema da cercare riguarda la misurazione. Se invece l’invio non funziona, ripristina subito la funzione. Quando cala la visibilità ma il percorso del cliente funziona, confronta le pagine e le ricerche perse con i contenuti, le destinazioni e la presenza nell’indice di Google. Se il calo continua, questa analisi viene prima di un altro cambio di dominio. Una risposta HTTP 200 non garantisce l’indicizzazione: una pagina che risponde correttamente non entra per questo automaticamente nell’indice di Google. Durante il trasferimento, inoltre, le posizioni possono oscillare.

Se serve tornare alla versione precedente, conserva prima le richieste e gli allegati arrivati dopo la pubblicazione. Ripristinare una vecchia copia del database senza recuperarli può cancellare proprio i contatti ricevuti dal nuovo sito.

Quando basta un intervento più limitato

Un cambio di marchio può giustificare un nuovo dominio per ragioni diverse dalla presenza su Google. Non serve invece cambiarlo solo perché un nome sembra più adatto alla SEO: le parole chiave nel nome del dominio hanno un effetto quasi nullo sulle posizioni. E un nuovo indirizzo non rende più chiaro un catalogo che si capisce poco.

Quando cambiano solo gli URL e hai già verificato contenuti e funzioni, il lavoro può concentrarsi sul trasferimento degli indirizzi. Se invece il CMS mantiene gli stessi indirizzi, la mappa può non essere necessaria. Restano da provare le modifiche alle pagine e al percorso delle richieste.

Prima di fissare la pubblicazione, porta al confronto questa domanda sul collaudo: «Se partiamo da un vecchio documento, riusciamo a trovare i dati del prodotto e a ricevere una richiesta completa anche da telefono?». Chiedi di dimostrarlo sulla versione che andrà online, aprendo il vecchio link e seguendo la richiesta dall’invio alla ricezione.

Fonti e riferimenti

Approfondisci il servizio: Recupero traffico organico.