Migrazione da PrestaShop 1.6 alla 8: non perdere il SEO

Il rischio principale non è quello che si crede

In una migrazione da PrestaShop 1.6 la preoccupazione va spontaneamente ai dati: perderemo ordini, clienti, prodotti? In pratica quei dati passano piuttosto bene. Ciò che si perde, e che non torna da solo, è il traffico organico.

La struttura degli URL cambia fra la 1.6 e le versioni moderne. Senza un piano di reindirizzamento, ogni URL indicizzato diventa un 404. Google deindicizza, le posizioni conquistate spariscono e poi servono mesi per risalire. È questo il motivo per cui una migrazione riuscita sul piano tecnico può restare un fallimento commerciale.

Il percorso di versione è obbligato

Prima regola: non esiste un salto diretto dalla 1.6 alla 8. Gli script di migrazione si applicano in modo incrementale, e saltare uno scalino lascia il database in uno stato incoerente.

Il percorso è: 1.6.1.x → 1.7.8.x → 8.x (poi 9.x, se serve).

Ogni scalino va verificato prima di passare al successivo: il back office si carica, un ordine va a buon fine, i prodotti si vedono. Un database migrato troppo in fretta produce errori che emergono solo dopo diverse settimane, su funzioni marginali.

Le sei perdite classiche

1. Il tema. Un tema 1.6 non funziona dalla 1.7 in poi. Il motore di template ha cambiato versione e la struttura dei file prodotto è stata completamente ridisegnata. Non esiste conversione automatica: il tema si rifà o si sostituisce.

2. Tutti gli override. La cartella override/ deve ripartire da zero. Le classi sovrascritte hanno cambiato firma, e un override 1.6 lasciato al suo posto provoca un errore fatale. È anche un'occasione: metà degli override risponde a esigenze abbandonate da tempo.

3. I moduli 1.6. Gli hook sono stati rinominati (hookHeader diventa hookDisplayHeader, per esempio) e l'architettura dei moduli è cambiata. Ogni modulo va sostituito con la sua versione moderna oppure riscritto.

4. Le recensioni dei prodotti. Il modulo productcomments cambia schema. Le recensioni dei clienti non vengono riprese in automatico: vanno migrate via script, tabella per tabella. Sono contenuti con un valore SEO reale, non li lasci indietro.

5. Le immagini prodotto. La rigenerazione delle miniature da Design > Impostazioni immagini supera il tempo di esecuzione consentito oltre qualche migliaio di immagini. Risultato: prodotti senza foto in front office. Bisogna passare dalla riga di comando oppure procedere per lotti.

6. I blocchi CMS e i contenuti statici. Pagine CMS, blocchi di rassicurazione, contenuti della home page: a seconda dei moduli usati in 1.6, quei contenuti vivono in tabelle che non esistono più. Vanno esportati prima e reinseriti dopo.

Il piano SEO, passo per passo

È la parte che merita più attenzione.

Prima della migrazione

1. Esportare tutti gli URL indicizzati. Incroci tre fonti: una scansione completa del sito, l'esportazione delle pagine da Search Console su 16 mesi e la sitemap attuale. Search Console è indispensabile: mostra URL che la scansione non trova più ma che ricevono ancora traffico.
2. Fotografare le posizioni. Un'istantanea delle parole chiave posizionate prima del passaggio è l'unico termine di paragone oggettivo che avrà dopo.
3. Costruire la tabella di corrispondenza. Ogni vecchio URL deve puntare al suo equivalente nuovo. I prodotti eliminati vanno verso la loro categoria, mai verso la home page: un reindirizzamento di massa alla home viene trattato da Google come un soft 404.

Durante la migrazione

4. Implementare i redirect 301 a livello di server e non tramite un modulo, quando i volumi sono importanti. Un reindirizzamento in PHP su 40.000 URL pesa sulle prestazioni.
5. Controllare i tag canonical e il file robots.txt. Un ambiente di staging in noindex portato in produzione senza togliere la direttiva è un disastro classico e perfettamente evitabile.

Dopo la migrazione

6. Inviare la nuova sitemap e controllare ogni giorno il rapporto sull'indicizzazione delle pagine per un mese.
7. Monitorare i 404 reali nei log del server, non soltanto in Search Console, che li segnala in ritardo. Ogni 404 ricorrente su un URL che riceveva traffico è un reindirizzamento dimenticato.

Quanto tempo mettere in conto

Una migrazione dalla 1.6 alla 8 con rifacimento del tema e sostituzione dei moduli si misura in settimane, non in giorni. La voce più pesante è quasi sempre il tema, seguita dal recupero degli sviluppi su misura.

L'investimento migliore resta l'audit preliminare: inventario dei moduli, degli override, dei template sovrascritti e degli URL indicizzati. Trasforma un preventivo approssimativo in un piano di lavoro e spesso rivela che il progetto è più leggero di quanto annunciato.

Se è già in versione 8 e ha dubbi sul da farsi, legga il nostro articolo sulla fine del supporto di PrestaShop 8.

Far migrare il suo negozio

Ci occupiamo dell'intera migrazione, piano di reindirizzamenti incluso, con monitoraggio del traffico organico dopo il passaggio. Veda la pagina migrazione PrestaShop.