Migrazione a Shopify senza perdere posizionamento: 3.000 prodotti da OpenCart

Il cambio di piattaforma è il momento in cui muore la SEO della maggior parte degli ecommerce. Non perché il nuovo stack sia peggiore — di solito è molto migliore — ma perché una migrazione cambia in silenzio e tutte insieme ogni URL, ogni title, ogni link interno e ogni blocco di dati strutturati. Google vede un sito che non riconosce, e il posizionamento costruito in cinque anni si azzera in due settimane.

MioMio vende oltre 170 case di moda — Furla, Casadei, Premiata, Bikkembergs. Il catalogo stava su un OpenCart legacy che nessuno voleva mantenere: nessun vero punto di integrazione, ogni collegamento un espediente, nessuna strada verso i servizi moderni. La ricostruzione è stata Shopify headless con vetrina su Next.js. Il vincolo: 3.000 prodotti dovevano spostarsi senza bruciare cinque anni di autorità accumulata.

Sono sopravvissuti tutti. Ecco il processo che ha reso la cosa noiosa invece che fortunata.

La regola che ha determinato tutto il resto

Una regola, decisa prima di scrivere una riga di codice: la struttura degli URL resta identica, 1:1. Non simile. Non migliorata. Identica.

È la decisione con più leva in qualsiasi replatform, ed è quella a cui si rinuncia più spesso — di solito per un formato di slug più pulito, o perché la nuova piattaforma ha opinioni sugli URL. Ogni rinuncia trasforma una migrazione gratuita in un progetto di redirect, e i progetti di redirect perdono pezzi. Un 301 trasferisce la stragrande maggioranza dei segnali, ma «stragrande maggioranza» su 3.000 URL è comunque una perdita misurabile, e ogni redirect dimenticato è un 404 secco su una pagina che prima posizionava.

La struttura di default di Shopify rema contro: vuole /products/handle e /collections/handle. È l'headless a ricomprare la libertà — il routing appartiene a Next.js, Shopify resta solo l'API commerciale dietro. L'identità del prodotto vive in Shopify; l'URL a cui quell'identità viene servita è tuo.

In un'architettura headless il CMS non detta più i tuoi URL. Per una migrazione non è un effetto collaterale: è l'intera ragione per andare headless.

Passo uno: inventariare ciò che Google sa davvero

Prima di toccare il nuovo stack, costruisci l'elenco degli URL che contano. Non l'elenco degli URL che esistono — sono numeri diversi, spesso di un ordine di grandezza.

Quattro fonti, unite:

• →Search Console: ogni pagina con impression negli ultimi 16 mesi. È la verità su cosa Google ha indicizzato e su cosa hanno cliccato gli utenti.
• →La sitemap XML esistente, come visione della piattaforma stessa su cosa dovrebbe esserci.
• →Una scansione completa del sito live, che intercetta le pagine dimenticate dalla sitemap — vecchie landing di campagne, filtri orfani, collezioni paginate.
• →L'analytics: qualsiasi URL con sessioni organiche, comprese quelle uscite da tempo dalla sitemap.

L'unione di queste quattro fonti è il contratto della migrazione. Ogni URL al suo interno, il giorno del lancio, deve rispondere 200 o 301. Nessuno può rispondere 404.

Il risultato utile è un unico file di mappatura, versionato nel repository accanto al codice:

// Una riga per ogni vecchio URL. Dove la mappatura non è meccanica, si verifica a mano.
export const REDIRECTS = [
  { from: "/index.php?route=product/product&product_id=482", to: "/uk/furla-metropolis-bag" },
  { from: "/women/bags/furla", to: "/uk/collections/furla" },
  // ...
] as const

I vecchi URL con query string sono quelli che si dimenticano. OpenCart, Magento e le vecchie installazioni PrestaShop hanno servito per anni indirizzi in stile ?route= o ?id_product=, rimasti indicizzati. In una mappatura ingenua slug-per-slug non compaiono — e sono esattamente gli URL con i backlink più vecchi e più forti.

Passo due: tenere il bilinguismo fuori dalla migrazione

MioMio serve ucraino e inglese. I siti multilingua si rompono in modo specifico durante una migrazione: le varianti linguistiche vengono trattate come duplicati, Google ne sceglie una arbitrariamente e metà del catalogo esce dall'indice sull'altro mercato.

Il rimedio è poco spettacolare e assoluto — ogni pagina dichiara il cluster completo delle sue varianti, e ogni variante rimanda indietro:

<link rel="canonical" href="https://example.com/uk/furla-metropolis-bag" />
<link rel="alternate" hreflang="uk" href="https://example.com/uk/furla-metropolis-bag" />
<link rel="alternate" hreflang="en" href="https://example.com/en/furla-metropolis-bag" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/furla-metropolis-bag" />

Tre regole fanno funzionare hreflang, e violarne una disattiva in silenzio l'intero cluster:

1. 01Reciprocità. Se la pagina A indica B come variante ucraina, B deve indicare A come inglese. Le annotazioni unidirezionali vengono ignorate.
2. 02Auto-riferimento. Ogni pagina include sé stessa nel proprio elenco di alternate. È la regola che si salta perché sembra ridondante.
3. 03Il canonical concorda con hreflang. Un canonical che punta a una lingua diversa da quella dichiarata dalla pagina è una contraddizione, e Google risolve le contraddizioni ignorando le tue istruzioni.

Genera tutto da un'unica funzione che riceve lingua e percorso. Non scrivere mai hreflang a mano nei template: si degrada nel momento esatto in cui qualcuno aggiunge una pagina.

Passo tre: i dati strutturati come risorsa della migrazione

I dati strutturati vengono di solito presentati come strumento per i rich result — stelline e prezzi nella SERP. Durante una migrazione fanno qualcosa di più utile: danno al crawler l'affermazione inequivocabile che il prodotto al nuovo URL è lo stesso prodotto che già conosceva.

Uno schema Product con un identificatore stabile — SKU, GTIN, MPN — trasportato dal vecchio catalogo è il segnale di continuità più forte a disposizione. Gli identificatori non cambiano solo perché è cambiata la piattaforma.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Furla Metropolis",
  "sku": "FRL-MTP-0412",
  "brand": { "@type": "Brand", "name": "Furla" },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "UAH",
    "price": "8400",
    "availability": "https://schema.org/InStock"
  }
}

Emettili lato server. I dati strutturati iniettati da JavaScript lato client vengono letti in modo incoerente e aggiungono una dipendenza dal rendering proprio al segnale che meno vuoi ritardare.

Passo quattro: la sequenza del giorno di lancio

L'ordine conta più della velocità:

1. 01Pubblica con la mappa dei redirect attiva dalla prima richiesta. Non «poco dopo»: è la prima scansione dopo il cambio DNS a fissare le aspettative.
2. 02Invia subito la nuova sitemap in Search Console e lascia accessibile la vecchia per qualche settimana, così Google può riconciliare le due.
3. 03Usa lo strumento di controllo URL su dieci-quindici pagine rappresentative: il prodotto con più traffico, la collezione più profonda, entrambe le home linguistiche, un listato paginato. Correggi ciò che segnala senza aspettare i dati aggregati.
4. 04Nelle prime 72 ore guarda i log del server, non l'analytics. I log mostrano cosa ha chiesto davvero Googlebot e con quale stato. L'analytics mostra solo gli umani che sono passati.

Il tasso di 404 nei log è l'unico numero che conta nella prima settimana. Deve avvicinarsi a zero in pochi giorni. Se non succede, il file di mappatura ha dei buchi, e ogni giorno che restano aperti è un giorno di decadimento.

Cosa ha prodotto davvero la migrazione

Tutti i 3.000 prodotti sono andati online senza perdere una posizione. Il caricamento è passato da 4,8 s a 1,2 s — quattro volte più veloce su mobile, dove su un catalogo di moda sta quasi tutto il traffico. La conversione è salita del 25% nel primo trimestre, e il punteggio SEO di Google è tornato 100/100 con dati strutturati, hreflang e Core Web Vitals puliti.

Vale la pena separare le cause: la conservazione del posizionamento viene dagli URL 1:1 e dai redirect. L'aumento di conversione viene dalla velocità e dal rebranding. Sono vittorie indipendenti, e confonderle è il modo in cui i team finiscono per credere che un redesign sia una strategia SEO.

La lezione generale è che una migrazione non è un evento tecnico da sopravvivere. È un contratto con un crawler che già si fida di te: tieni stabili gli indirizzi, tieni dimostrabile l'identità, e la fiducia si trasferisce intatta. Tutto il resto della ricostruzione — velocità, design, contenuti editoriali — diventa guadagno netto sopra ciò che avevi già guadagnato.