Migrare un e-commerce senza perdere posizioni: la mappa dei redirect 301

Le guide sulla migrazione SEO di un e-commerce dicono tutte la stessa cosa: fai i redirect 301 dai vecchi URL ai nuovi. Giusto. Quello che non dicono è come si decide dove deve puntare ogni vecchio URL quando sono centinaia, il catalogo è cambiato nel frattempo e metà dei prodotti non esiste più.

È lì che le migrazioni perdono posizioni: non per i redirect mancanti, ma per quelli sbagliati. Qui racconto come ho costruito la mappa dei redirect 301 su un e-commerce B2B in PrestaShop, con i numeri della revisione fatta insieme al cliente, e quali regole tecniche contano davvero.

⚠️ Il problema: centinaia di vecchi URL e un catalogo che è cambiato

Il caso: un e-commerce B2B di ferramenta e utensili su PrestaShop 1.7, con URL in cinque lingue. Una migrazione precedente, fatta anni prima da un’altra agenzia, aveva lasciato in giro 831 vecchi URL in .html ancora linkati da descrizioni prodotto, siti esterni e indice di Google.

Di quegli 831:

• 458 avevano già un redirect nel modulo SEO dello shop;
• 367 non ce l’avevano: 264 abbinabili con buona sicurezza, 103 da rivedere a mano;
• 6 non avevano nessun gemello possibile.

In 418 casi il redirect esistente puntava a una destinazione diversa da quella che avrei scelto io. Non li ho toccati: un redirect che funziona da anni ha già trasferito i suoi segnali, cambiarlo crea solo rumore.

🛠️ Abbinare per reference, non per EAN

L’istinto è usare l’EAN: è un codice univoco, standard, sembra perfetto. Nella pratica è la scelta peggiore. Quando un fornitore sostituisce un prodotto con il modello nuovo, spesso riassegna l’EAN al successore. Il redirect costruito sull’EAN porta l’utente (e Google) su una scheda che ha lo stesso codice a barre ma non è lo stesso prodotto.

La revisione del file fatta con il cliente lo ha misurato in modo netto. Su 284 righe proposte:

In totale il cliente ha confermato 195 righe (69%) e ne ha corrette 89. Di quelle 89, 48 avevano l’EAN esatto ma la scheda sbagliata. Senza il controllo di chi conosce il catalogo, un terzo della mappa avrebbe mandato i visitatori sul prodotto sbagliato.

Un redirect sbagliato è peggio di un 404: il 404 dice “non c’è più”, il redirect sbagliato dice “è questo” e mente.

⚠️ I 301 che puntano a un 404

Il secondo errore classico è la destinazione spenta. Al primo giro, 43 righe della mappa puntavano a schede disattivate: un 301 che porta a un 404 è, per Google e per l’utente, un 404 con un passaggio in più.

La regola che applico: ogni destinazione si controlla con una richiesta HTTP prima di caricare la mappa. Alla versione finale, le 101 destinazioni distinte rispondevano tutte 200. Lo stesso vale per le catene: Google segue fino a 10 passaggi, ma ogni salto rallenta e disperde. Un redirect che punta a un URL che a sua volta redirige va riscritto verso la destinazione finale.

Per i 56 vecchi URL senza un prodotto equivalente, la risposta giusta è stata lasciare il 404. Mandarli tutti alla home o alla categoria è la scorciatoia che, per la stessa guida di Google, rischia di essere trattata come soft 404: un redirect che non trasferisce niente.

🛠️ Le regole tecniche che contano

Poche, ma da non sbagliare:

La riga che pesa di più è la prima: secondo la RFC 9110 un 301 è memorizzabile dal browser anche senza header di cache, quindi un 301 sbagliato può continuare a valere per chi l’ha già ricevuto, anche dopo che lo hai corretto sul server. Per questo la mappa si verifica prima, non dopo. Google, nella guida allo spostamento di un sito, consiglia di tenerli attivi il più a lungo possibile, in genere almeno un anno.

Su PrestaShop c’è un dettaglio in più: per i prodotti ancora attivi conviene usare il redirect nativo della scheda (tipo 301 più prodotto di destinazione), che vale per tutte le lingue in un colpo, invece di una riga per lingua nel modulo.

⚠️ Cosa dice davvero Search Console

Dopo una migrazione il report “Non trovata (404)” di Search Console fa paura. Va letto con calma. Su questo shop ho controllato 1.000 URL segnalati come 404:

• 789 rispondevano già 200: il report era vecchio;
• 140 avevano già un 301;
• 54 erano soft 404, cioè redirect temporanei verso la pagina di errore;
• 17 erano 404 veri, causati da un segnaposto video non risolto, da correggere alla fonte.

E nei log del server, su dieci giorni, 9.105 richieste in 404 su 2.515 URL diversi erano quasi tutte bot che cercavano pagine di WordPress. Il problema vero non era nei redirect: erano i link dentro le descrizioni prodotto che puntavano ancora ai vecchi URL.

✅ La procedura, in ordine

1. Esporta tutti i vecchi URL: sitemap, Search Console, log del server, link interni.
2. Abbina per codice articolo, usa l’EAN solo come indizio da confermare.
3. Fai rivedere la mappa a chi conosce il catalogo: nel caso qui sopra ha corretto un terzo delle righe.
4. Controlla che ogni destinazione risponda 200 ed elimina le catene.
5. Lascia il 404 dove non c’è un equivalente, niente redirect di massa alla home.
6. Correggi i link interni alla fonte, così i redirect servono solo a chi arriva da fuori.
7. Tieni i redirect almeno un anno e ricontrolla Search Console a 30 e 90 giorni.

Un limite da dichiarare: qui racconto la costruzione della mappa, non un prima e dopo di traffico su una migrazione completa, che su questo shop non è ancora avvenuta. Se stai pianificando il passaggio di versione, il percorso tecnico è nella guida su come aggiornare PrestaShop dalla 1.6 e dalla 1.7. La mappa dei redirect è uno dei lavori che faccio dentro l’assistenza PrestaShop: se hai una migrazione in vista, scrivimi o usa uno dei canali qui sotto.