Migration PrestaShop 1.6 vers 8 : ne pas perdre son SEO

Le risque principal n'est pas celui qu'on croit

Sur une migration PrestaShop 1.6, l'inquiétude porte spontanément sur les données : va-t-on perdre des commandes, des clients, des produits ? En pratique, ces données passent plutôt bien. Ce qui se perd, et qui ne revient pas tout seul, c'est le trafic organique.

La structure des URL change entre la 1.6 et les versions modernes. Sans plan de redirection, chaque URL indexée devient une 404. Google désindexe, les positions acquises disparaissent, et il faut ensuite des mois pour remonter. C'est la raison pour laquelle une migration réussie techniquement peut rester un échec commercial.

Le chemin de version est obligatoire

Première règle : il n'existe pas de saut direct de 1.6 vers 8. Les scripts de migration s'appliquent de façon incrémentale, et sauter des paliers laisse la base dans un état incohérent.

Le chemin est : 1.6.1.x → 1.7.8.x → 8.x (puis 9.x le cas échéant).

Chaque palier doit être vérifié avant de passer au suivant : le back-office se charge, une commande se passe, les produits s'affichent. Une base migrée trop vite produit des erreurs qui n'apparaissent qu'au bout de plusieurs semaines, sur des fonctionnalités périphériques.

Les six pertes classiques

1. Le thème. Un thème 1.6 ne fonctionne pas en 1.7 et au-delà. Le moteur de template a changé de version, et la structure des fichiers produit a été entièrement refondue. Il n'y a pas de conversion automatique : le thème est refait, ou remplacé.

2. Tous les overrides. Le dossier override/ doit repartir de zéro. Les classes surchargées ont changé de signature, et un override 1.6 conservé provoque une erreur fatale. C'est aussi une occasion : la moitié des overrides correspondent à des besoins abandonnés depuis longtemps.

3. Les modules 1.6. Les hooks ont été renommés (hookHeader devient hookDisplayHeader, par exemple) et l'architecture des modules a évolué. Chaque module doit être remplacé par sa version moderne, ou réécrit.

4. Les commentaires produits. Le module productcomments change de schéma. Les avis clients ne sont pas repris automatiquement : ils doivent être migrés par script, table par table. Ce contenu a une vraie valeur SEO, ne le laissez pas de côté.

5. Les images produit. La régénération des miniatures depuis Design > Paramètres d'images dépasse le temps d'exécution autorisé au-delà de quelques milliers d'images. Résultat : des produits sans visuel en front. Il faut passer par la ligne de commande, ou traiter par lots.

6. Les blocs CMS et contenus statiques. Pages CMS, blocs de réassurance, contenus de la page d'accueil : selon les modules utilisés en 1.6, ces contenus vivent dans des tables qui n'existent plus. Ils sont à exporter avant, et à ressaisir après.

Le plan SEO, étape par étape

C'est la partie qui mérite le plus d'attention.

Avant la migration

1. Exporter toutes les URL indexées. Croisez trois sources : un crawl complet du site, l'export des pages de Search Console sur 16 mois, et votre sitemap actuel. Search Console est indispensable : elle révèle des URL que le crawl ne trouve plus mais qui reçoivent encore du trafic.
2. Relever les positions. Un instantané des mots-clés positionnés avant bascule est votre seul point de comparaison objectif après.
3. Construire la table de correspondance. Chaque ancienne URL doit pointer vers son équivalent nouveau. Les produits supprimés vont vers leur catégorie, jamais vers la page d'accueil : une redirection massive vers l'accueil est traitée comme une erreur douce par Google.

Pendant la migration

4. Implémenter les redirections 301 au niveau du serveur, pas via un module, pour les volumes importants. Une redirection en PHP sur 40 000 URL pèse sur les performances.
5. Vérifier les balises canoniques et le fichier robots.txt. Une préproduction en noindex basculée en production sans retirer la directive est une catastrophe classique et parfaitement évitable.

Après la migration

6. Soumettre le nouveau sitemap et surveiller quotidiennement le rapport de couverture pendant un mois.
7. Suivre les 404 réelles dans les logs serveur, pas seulement dans Search Console qui remonte avec du retard. Chaque 404 récurrente sur une URL qui recevait du trafic est une redirection oubliée.

Combien de temps prévoir

Une migration 1.6 vers 8 avec refonte de thème et reprise des modules se compte en semaines, pas en jours. Le poste le plus lourd est presque toujours le thème, suivi de la reprise des développements spécifiques.

Le meilleur investissement reste l'audit préalable : inventaire des modules, des overrides, des templates surchargés et des URL indexées. Il transforme un devis approximatif en plan de charge, et révèle souvent que le chantier est plus léger qu'annoncé.

Si vous êtes déjà en version 8 et hésitez sur la suite, lisez notre article sur la fin de support de PrestaShop 8.

Faire migrer votre boutique

Nous prenons en charge la migration complète, plan de redirections inclus, avec suivi du trafic organique après bascule. Voir la page migration PrestaShop.