Una migrazione eCommerce non è un semplice cambio di piattaforma: modifica URL, architettura, segnali tecnici e percorsi che Google ha imparato nel tempo. Se questi elementi non vengono mappati prima del go-live, un sito più moderno può ritrovarsi con meno traffico organico e meno vendite.
Milano, 11 Novembre 2026. Ogni eCommerce accumula nel tempo un patrimonio invisibile: categorie che si posizionano, schede prodotto che ricevono link, pagine informative che intercettano ricerche, URL conosciute dai motori di ricerca e collegamenti interni che distribuiscono rilevanza. Una migrazione cambia una parte di questo sistema e, in alcuni casi, molte parti contemporaneamente.
Il rischio aumenta quando si modificano nello stesso momento piattaforma, struttura delle URL, tassonomia delle categorie, contenuti, navigazione e template. Se la vecchia pagina /scarpe-running/ diventa /running/scarpe/ e il passaggio non viene comunicato correttamente, Google deve ricostruire la relazione tra la vecchia risorsa e la nuova. Lo stesso vale per prodotti, brand, filtri e contenuti editoriali.
Google Search Central raccomanda, nei cambi di URL, di mappare le vecchie pagine verso le nuove destinazioni e di utilizzare redirect permanenti lato server quando possibile. Reindirizzare in massa tutto verso la homepage è invece una scorciatoia che può confondere utenti e motori di ricerca e può essere interpretata come soft 404.
Per questo BitHub affronta le migrazioni mettendo insieme sviluppo e SEO tecnica. Nella pagina dedicata al servizio SEO di BitHub il lavoro viene descritto in termini di mappa redirect, sitemap, canonical, Search Console, contenuti e controllo post go-live: elementi che devono essere progettati prima della pubblicazione, non aggiunti a posteriori.
Il primo passaggio è sapere che cosa non si può perdere. Non tutte le URL hanno lo stesso valore: alcune portano traffico, altre ricevono backlink, altre ancora generano vendite o presidiano query molto specifiche. Un audit pre-migrazione dovrebbe quindi unire dati di crawling, Search Console, analytics, backlink e informazioni commerciali.
La baseline serve anche dopo. Se, a due settimane dal lancio, una categoria perde il 60% delle impression mentre il resto del sito è stabile, il confronto con il periodo precedente permette di isolare il problema molto più rapidamente rispetto a un controllo basato soltanto sul traffico complessivo.
La redirect map è uno dei documenti centrali di una migrazione. Ogni vecchia URL che cambia dovrebbe avere una destinazione coerente. Una vecchia categoria va verso la nuova categoria equivalente; una guida va verso la nuova versione della guida; una scheda prodotto può essere reindirizzata solo se esiste una sostituzione realmente pertinente.
Anche le catene di redirect vanno evitate quando possibile. Un passaggio vecchia URL -> URL intermedia -> URL finale aumenta complessità e tempi di risposta. La mappa dovrebbe puntare direttamente alla destinazione finale e deve essere testata prima e subito dopo il go-live.
Una migrazione non è coerente se il redirect porta alla nuova URL ma la canonical indica ancora quella vecchia, la sitemap contiene indirizzi superati oppure i link interni continuano a usare percorsi destinati a essere reindirizzati. Google utilizza più segnali per scegliere la versione canonica di una pagina e può ignorare una preferenza dichiarata se il resto dell’architettura comunica indicazioni diverse.
Negli eCommerce il tema diventa più complesso con filtri, ordinamenti e parametri. Non tutte le combinazioni devono essere indicizzate: alcune possono avere un intento di ricerca reale, altre creano soltanto varianti quasi identiche. Per questo la gestione dei filtri va progettata insieme alla struttura delle categorie, non risolta con una regola generica applicata all’ultimo momento.
Durante un redesign è naturale voler riscrivere testi, title, heading e descrizioni. Farlo insieme al cambio di piattaforma, però, rende più difficile capire la causa di un eventuale calo. Le pagine che già generano traffico e vendite meritano un trattamento più conservativo: prima si preservano URL, intenti e contenuti che funzionano, poi si ottimizza in modo misurabile.
Questo non significa congelare il sito. Duplicazioni, pagine sottili o strutture obsolete possono essere consolidate, ma la decisione deve essere basata sui dati e sul ruolo di ciascuna pagina.
Nelle prime ore vanno controllati status code, redirect, sitemap, robots, canonical, tracking e raggiungibilità delle pagine strategiche. Nei giorni successivi Search Console aiuta a individuare picchi di 404, URL escluse, anomalie di scansione e cambiamenti nella canonical scelta da Google.
Un certo assestamento è fisiologico, ma cali importanti e persistenti non vanno archiviati come “normali”. Bisogna segmentare per directory, tipologia di pagina e query: spesso il problema riguarda una sola parte del catalogo e può essere corretto prima che diventi strutturale.
BitHub ha documentato pubblicamente il caso di QuattrozampeShop.it, migrato da una piattaforma precedente a una soluzione custom. Il punto interessante non è il cambio tecnologico in sé, ma il metodo: conservazione degli URL di valore, redirect, controllo dell’indicizzazione e verifica post-lancio. È il tipo di approccio che trasforma una migrazione da “rifacimento del sito” a progetto di continuità SEO e commerciale.
La domanda corretta non è se una migrazione possa produrre oscillazioni, ma se il progetto consenta di distinguere un normale assestamento da un errore tecnico. Per riuscirci servono dati prima del lancio, regole chiare sugli URL e monitoraggio dopo la pubblicazione.
Quando sviluppo, SEO, analytics e catalogo vengono gestiti come parti dello stesso sistema, il passaggio alla nuova piattaforma può diventare un’occasione per migliorare performance e struttura senza azzerare il valore accumulato dal sito nel tempo.
Quanto tempo serve a Google per recepire una migrazione?
Non esiste un tempo garantito. Dipende da dimensione del sito, frequenza di scansione, qualità dei redirect e coerenza dei segnali tecnici.
Per questo il monitoraggio deve iniziare subito e proseguire nelle settimane successive.
È corretto reindirizzare tutti i vecchi prodotti alla categoria?
Solo se la categoria è una destinazione davvero utile e pertinente. In assenza di un equivalente, un redirect generico può creare una cattiva esperienza e segnali poco chiari.
Conviene cambiare URL se non è necessario?
Non per principio. Una nuova struttura può essere utile, ma ogni cambio di URL introduce un costo di migrazione. Se un URL funziona e non esiste un vantaggio concreto nel modificarlo, mantenerlo riduce il rischio.
Contatti:
BitHub
Sede: Galleria della Sima 45, Jesi
Sito web: https://bithub.it/
Comunicato stampa - contenuto promozionale
Responsabilità editoriale di BitHub
