Nel linguaggio comune, migrare un e-commerce significa spostare prodotti, clienti e ordini da una piattaforma all'altra. È la parte del lavoro che gli strumenti di importazione gestiscono meglio e, proprio per questo, quella che preoccupa meno. Le perdite che emergono dopo il lancio raramente dipendono da un prodotto rimasto fuori dall'import: nascono da ciò che un file CSV non contiene. Gli indirizzi delle pagine che Google ha indicizzato in anni di attività, le credenziali con cui i clienti accedono alla propria area riservata, gli identificativi con cui Merchant Center collega ogni prodotto al suo storico di rendimento, la configurazione che consente alle email transazionali di arrivare a destinazione.
Il tema è tornato concreto per molti negozi costruiti su Magento. Secondo la policy sul ciclo di vita di Adobe Commerce, il supporto standard della versione 2.4.6 si è chiuso l'11 agosto 2026; ai clienti Adobe Commerce è offerto un anno di supporto esteso, seguito da un periodo transitorio di sole correzioni di sicurezza che la stessa Adobe invita a considerare tempo per la migrazione, non un livello di supporto su cui contare. Chi si trova in questa posizione deve scegliere tra l'aggiornamento a una release supportata e il cambio di piattaforma. Quando la scelta cade sulla seconda strada, gli errori che pesano di più sul fatturato si somigliano molto, qualunque sia la piattaforma di destinazione.
Piattaforma, dominio e grafica cambiati nello stesso momento
La tentazione è comprensibile: se il negozio va rifatto, sembra il momento giusto per un nuovo dominio, una nuova struttura delle categorie e un nuovo design. La documentazione di Google Search Central sui trasferimenti di sito con modifica degli URL suggerisce l'approccio opposto, cioè pianificare le modifiche una dopo l'altra, e porta come esempio proprio il caso di chi cambia insieme dominio, CMS e layout. La ragione è anzitutto diagnostica. Se dopo il lancio il traffico organico cala e il cambiamento in corso è uno solo, si sa dove cercare; con tre cambiamenti sovrapposti, separare l'effetto dei redirect da quello di un template più lento o di categorie riorganizzate diventa un esercizio di ipotesi.
Lo stesso documento raccomanda di far coincidere il trasferimento con una fase di traffico più basso, se il sito ne ha di ricorrenti. Per un e-commerce la differenza si misura in ordini: un difetto del checkout scoperto in un periodo tranquillo costa poche vendite, lo stesso difetto in pieno picco ne costa molte di più. C'è anche un aspetto tecnico, perché Google segnala che dopo una migrazione la scansione del nuovo sito aumenta temporaneamente, dato che le richieste verso i vecchi indirizzi vengono reindirizzate e si sommano a quelle ordinarie. Un server già sotto carico per le vendite si trova a gestire anche questo.
Procedere per passaggi separati non significa per forza allungare il progetto. In molti casi la nuova piattaforma può mantenere gli stessi URL o una struttura molto vicina, rinviando a una fase successiva la revisione delle categorie. Quando invece la destinazione impone uno schema di indirizzi proprio, come accade con diverse piattaforme in hosting che usano percorsi fissi per prodotti e collezioni, il cambio di URL diventa inevitabile e va trattato come il rischio principale dell'intero lavoro. La scelta della piattaforma, con i criteri per valutarla, è un tema a sé, che trova spazio tra gli altri approfondimenti della sezione dedicata alla realizzazione di siti e-commerce; qui interessa ciò che succede dopo la decisione.
Gli indirizzi che Google ha già imparato
Ogni scheda prodotto e ogni categoria indicizzata accumulano segnali legati al proprio indirizzo: link da altri siti, posizionamento, pagine salvate nei preferiti, URL usati nelle campagne e nelle newsletter passate. Quando l'indirizzo cambia, l'unico modo per trasferire questi segnali è un redirect permanente lato server dal vecchio URL al nuovo, con codice 301 o 308. Google precisa che i redirect permanenti non comportano perdita di PageRank, a condizione però che puntino alla pagina corrispondente.
È qui che si concentra la maggior parte dei problemi. La scorciatoia più diffusa, quando la mappatura uno a uno sembra troppo onerosa, è reindirizzare in blocco i vecchi URL verso la home page o verso una categoria generica. Google avverte che molti vecchi indirizzi convogliati su un'unica destinazione non pertinente possono confondere gli utenti ed essere trattati come soft 404, cioè come pagine di fatto inesistenti. Non meno frequente, secondo la stessa documentazione, è il redirect verso URL che sul nuovo sito non esistono, magari perché la mappatura è stata preparata su un ambiente di prova con indirizzi diversi da quelli definitivi. Anche le catene di redirect hanno un costo: Googlebot ne segue fino a dieci passaggi, ma l'indicazione è puntare direttamente alla destinazione finale, perché ogni passaggio aggiunge latenza per l'utente.
Per i prodotti che non vengono trasferiti, la risposta corretta è un codice 404 o 410. Il redirect resta legittimo quando esiste un equivalente reale, come il nuovo modello che sostituisce quello fuori produzione, perché Google ammette il reindirizzamento verso una pagina che consolida contenuti prima distribuiti su più URL. Nella mappatura vanno incluse anche le immagini dei prodotti, che possono ricevere traffico dalla ricerca per immagini e che la documentazione di Google chiede di trattare come qualunque altro contenuto spostato.
Sulla durata, l'indicazione è mantenere i redirect almeno un anno, il tempo necessario perché Google trasferisca i segnali ai nuovi URL e riassegni i link esterni; dal punto di vista degli utenti, è preferibile non rimuoverli affatto. Contano infine due dettagli che Google elenca tra le dimenticanze più comuni: le regole noindex o i blocchi nel file robots.txt usati durante lo sviluppo e rimasti attivi dopo il lancio, e le sitemap non aggiornate con i nuovi indirizzi.
Account dei clienti e identificativi dei prodotti
Le password dei clienti sono il caso più evidente di dato che non segue la migrazione. Ogni piattaforma le conserva in forma cifrata, e la destinazione non è sempre in grado di riutilizzarle. Shopify lo dichiara nella documentazione sull'importazione dei clienti: le password non possono essere migrate da un altro negozio tramite CSV e, dopo l'importazione, i clienti vanno invitati a crearne di nuove. La stessa pagina chiarisce che il CSV dei clienti non importa gli ordini né gli importi spesi, che vanno quindi trasferiti con altri strumenti se servono al servizio clienti o a un programma fedeltà. Per altre combinazioni di piattaforme la situazione dipende dagli algoritmi di cifratura in uso e dagli strumenti di migrazione disponibili, ed è un punto da chiarire in fase di progetto, non da scoprire il giorno del lancio.
La conseguenza pratica è una comunicazione da pianificare: un invito all'attivazione dell'account inviato in modo ordinato, con un testo riconoscibile che non somigli a un tentativo di phishing, e un percorso di reimpostazione della password semplice per chi arriva al login senza averlo letto. Quell'invito, come le conferme d'ordine, parte però dalla nuova piattaforma e quindi da un servizio di invio diverso dal precedente. Se il dominio non è configurato per autorizzarlo, i messaggi rischiano di finire nello spam proprio nei giorni più delicati. Le verifiche da fare prima del lancio sono le stesse descritte a proposito del monitoraggio del recapito di conferme d'ordine e newsletter con Postmaster Tools e i report DMARC.
Sul fronte di Google Shopping l'errore è meno visibile e più costoso. La specifica dei dati prodotto di Merchant Center chiede di assegnare a ogni prodotto un ID stabile, perché l'ID serve a tracciare lo storico del rendimento in Merchant Center e in Google Ads, e cambiarlo significa sovrascrivere il prodotto e la sua storia. Se il feed della nuova piattaforma usa ID diversi da quelli precedenti, le campagne Shopping ripartono senza lo storico accumulato, anche quando prodotti, prezzi e immagini sono identici. Prima di configurare il nuovo feed occorre quindi verificare come è costruito l'ID in quello attuale: se deriva dallo SKU, come Google raccomanda, sopravvive al cambio di piattaforma; se deriva dall'identificativo interno del database, la migrazione lo cambierà, a meno che il plugin o l'app del feed non venga impostato per riprodurre lo schema precedente. Un ragionamento analogo riguarda le recensioni dei prodotti, che quando sono gestite da un'estensione della vecchia piattaforma non seguono automaticamente il catalogo.
Le settimane successive al lancio
Una migrazione non si chiude il giorno della messa online. Google stima che per un sito di dimensioni piccole o medie servano alcune settimane perché la maggior parte delle pagine venga elaborata con i nuovi indirizzi, e più tempo per i siti grandi; nel frattempo la visibilità nei risultati può oscillare, e la documentazione considera queste fluttuazioni normali. Per chi gestisce il negozio la difficoltà è distinguere un'oscillazione fisiologica da un problema tecnico, e per farlo servono controlli decisi prima del lancio, non improvvisati dopo il primo calo.
Search Console offre il quadro più diretto se tutte le varianti del vecchio e del nuovo sito sono state verificate in anticipo e se si conservano sia la sitemap dei vecchi URL sia quella dei nuovi. Inviandole entrambe, il comportamento atteso è che le pagine indicizzate della prima scendano progressivamente verso zero mentre crescono quelle della seconda; gli avvisi sui redirect nella sitemap dei vecchi indirizzi, precisa Google, sono normali e si possono ignorare. Un aumento anomalo di pagine non trovate nel rapporto di indicizzazione indica di solito redirect mancanti o errati, mentre per le pagine nuove che non compaiono il controllo parte dallo strumento Controllo URL. Se la migrazione comporta anche un cambio di dominio, va inviata la richiesta di cambio di indirizzo in Search Console per tutte le varianti verificate del vecchio dominio; per un semplice cambio di percorsi sullo stesso dominio non serve.
Accanto ai dati di ricerca vanno verificati i flussi che generano fatturato: un ordine di prova completo per ogni metodo di pagamento e di spedizione attivo, l'arrivo delle email transazionali, la registrazione della conversione negli strumenti di analisi e nelle piattaforme pubblicitarie. Sono verifiche estranee ai rapporti di Google e, se trascurate, i problemi tendono a emergere attraverso le segnalazioni dei clienti. Nelle campagne a pagamento, inoltre, le pagine di destinazione degli annunci vanno aggiornate ai nuovi URL, come ricorda la stessa guida di Google: lasciarle passare dai redirect funziona, ma aggiunge un passaggio a ogni clic.
Il criterio per giudicare l'esito è semplice da enunciare e meno semplice da raggiungere. Dopo qualche settimana il traffico che arrivava ai vecchi indirizzi deve ritrovarsi sui nuovi, i clienti abituali devono riuscire ad accedere al proprio account senza passare dall'assistenza e i prodotti devono conservare in Shopping lo storico costruito negli anni. Se una di queste condizioni manca, la migrazione ha spostato i dati ma non il valore che il negozio aveva accumulato.
