Cosa si rompe la settimana dopo aver migrato a PrestaShop
Il giorno del cambio va quasi sempre bene. È un falso segnale
Una migrazione riuscita, nel senso stretto di "il negozio nuovo funziona e vende", è relativamente facile da ottenere: prodotti, prezzi, stock e ordini storici sono dati strutturati, gli strumenti di importazione li spostano bene, e nel primo giorno tutto sembra a posto. I problemi seri non emergono il giorno del lancio: emergono nei sette-dieci giorni dopo, quando arrivano i visitatori che avevano un vecchio indirizzo salvato nei preferiti, quando Google ricomincia a scansionare il sito con la mappa di indirizzi che aveva prima, e quando qualcuno nota che una funzione che "c'era prima" non c'è più, non perché sia stata tolta apposta ma perché nessuno strumento di importazione l'aveva anche solo considerata. Questo articolo non parla di come migrare (per quello esistono servizi specializzati, non è quello che facciamo): parla di cosa controllare nella settimana dopo, quando il negozio è già online e la lista dei problemi comincia a farsi vedere da sola.
Indirizzi morti, non a decine: a centinaia
Il problema più sottovalutato è la scala. Chi migra si aspetta di dover sistemare "qualche indirizzo", non l'intera struttura degli URL. In pratica quasi nessuna piattaforma condivide lo schema di indirizzi di un'altra: un catalogo che su WooCommerce viveva sotto /product/nome-prodotto/, su Magento sotto /nome-categoria/nome-prodotto.html o su Shopify sotto /products/nome-prodotto arriva su PrestaShop con un altro schema ancora, spesso con l'identificativo numerico del prodotto incluso nell'indirizzo. Ogni singolo indirizzo che un motore di ricerca aveva indicizzato, ogni link che un altro sito o un cliente ha salvato, punta quindi a un percorso che semplicemente non esiste più sul nuovo negozio. Su un catalogo di qualche migliaio di prodotti, con categorie, pagine di filtro indicizzate e contenuti editoriali, il numero di indirizzi da rimappare arriva facilmente a qualche centinaio anche per un negozio di dimensioni medie, non è un'eccezione dei cataloghi grandi.
La pratica corretta, quasi mai fatta per tempo, è esportare l'elenco completo degli indirizzi indicizzati dalla vecchia piattaforma (da Google Search Console, non dalla sitemap del vecchio sito, che spesso è già incompleta) prima del cambio, e costruire la mappa dei redirect come parte del piano di migrazione, non come intervento successivo quando arrivano le prime segnalazioni di traffico perso.
Il banner cookie che non distingue più i paesi
Un negozio multilingua migrato di corsa porta quasi sempre con sé testi e configurazioni pensati per la lingua principale, e la configurazione del consenso cookie è uno dei punti dove questo si nota per primo: un banner che prima distingueva correttamente il pubblico per lingua/paese, dopo la migrazione a volte torna a un unico default, o peggio mostra un testo non tradotto per le lingue secondarie (un difetto esattamente di questo tipo, non legato a una migrazione ma alla stessa causa di fondo, un testo che copre solo due lingue su cinque, lo abbiamo trovato e corretto nel nostro consenso cookie a settembre 2026). Vale la pena ricontrollare la configurazione del consenso su ogni lingua attiva subito dopo il cambio, non solo su quella principale con cui si è fatto il collaudo.
I dati di conformità che l'importazione non sapeva nemmeno cercare
Gli strumenti di importazione spostano bene ciò che esisteva già come concetto sulla piattaforma di origine: prezzo, descrizione, immagini, categorie. Un campo come "produttore GPSR", "avvertenza di sicurezza per questo prodotto specifico" o "mandatario UE" spesso non esisteva affatto come dato strutturato sulla vecchia piattaforma, quindi nessuno strumento di importazione poteva portarlo, semplicemente perché non c'era un campo sorgente da cui copiarlo. Il rischio concreto è che un negozio migrato dia per scontato che "se prima andava bene, andrà bene anche ora", quando in realtà il problema di conformità (se esisteva) era già presente prima e la migrazione lo rende solo più visibile, perché costringe a ripensare i dati prodotto da capo.
La ricerca interna che riparte da zero
Se il negozio precedente aveva un motore di ricerca affinato nel tempo, con sinonimi aggiunti a mano dopo che i clienti cercavano un termine e non trovavano niente, con stopword tarate sulla lingua del catalogo, con un ordine di rilevanza corretto dopo mesi di osservazione di cosa i clienti cliccavano davvero, quella messa a punto non si trasferisce con l'importazione dei prodotti. È un lavoro fatto sui comportamenti di ricerca, non sui dati di catalogo, e nessuno strumento di migrazione lo sa spostare perché non è nemmeno un dato nel senso classico: è configurazione accumulata. Il sintomo tipico è un calo delle conversioni da ricerca interna nelle prime settimane, non perché il nuovo motore sia peggiore in assoluto, ma perché parte da una configurazione di default generica al posto di mesi di correzioni.
I feed prodotto che puntano ancora al vecchio schema
Un feed per Google Shopping o per un marketplace è costruito sugli indirizzi e sugli identificativi della piattaforma di origine. Dopo la migrazione, se il feed non viene ricostruito da zero sul nuovo schema di indirizzi, ogni annuncio continua a puntare a un indirizzo che restituisce un redirect o, peggio, un 404: superata una certa percentuale di link non funzionanti, Google Merchant Center comincia a segnalare il feed e può sospendere la visibilità degli annunci, che è un danno commerciale diretto e immediato, non solo un problema di posizionamento organico.
Una checklist per la prima settimana
- Confrontate l'elenco degli indirizzi indicizzati prima della migrazione (da Search Console) con quelli che rispondono 200 oggi: ogni indirizzo mancante va o rimappato con un redirect permanente verso il contenuto equivalente, o chiuso deliberatamente se il contenuto non esiste più.
- Controllate il banner cookie su ogni lingua/paese attivo, non solo su quella principale.
- Riverificate i dati di conformità prodotto (GPSR e non solo) partendo dal presupposto che l'importazione non li abbia portati, perché quasi certamente non lo ha fatto.
- Misurate le conversioni da ricerca interna nelle prime due settimane separatamente dal resto, è il segnale più rapido per capire se la configurazione di ricerca va rifatta.
- Ricostruite il feed prodotto sul nuovo schema di indirizzi prima di riattivare le campagne, non dopo aver notato il calo.
In sintesi
La settimana dopo una migrazione non è un periodo di assestamento tranquillo, è quando emergono i problemi che il giorno del lancio non poteva mostrare: indirizzi che nessuno ha rimappato, configurazioni che non hanno un dato sorgente da cui essere copiate, mesi di messa a punto (ricerca, consenso, feed) che semplicemente non esistevano come "dato" da migrare. Un modulo per la gestione dei redirect e il monitoraggio dei 404, come cll_seoredirect, aiuta a vedere questi buchi mentre si aprono invece che quando i visitatori se ne sono già accorti, ma la lista di cose da controllare sopra vale indipendentemente da quale strumento la copre.
