Une migration PrestaShop peut changer la version, l’hébergement, le thème ou l’organisation du catalogue. Chaque changement a ses risques. L’objectif est de préserver la capacité de vente, les données et les signaux aidant les moteurs à comprendre les pages. Aucun plan ne garantit l’absence de fluctuations organiques ; un processus documenté permet de repérer les problèmes et d’agir dans leur contexte.
Ce guide aide à préparer la décision et à vérifier une proposition. Avant de fixer la transition, trois questions demandent des réponses précises : que va-t-on changer, comment le tester et comment rétablir l’exploitation si un test critique échoue ? Mise à jour technique et préservation du SEO font partie du même projet.
1. Distinguer mise à niveau, migration et reconstruction
Une mise à niveau actualise le logiciel ; une migration peut transférer données ou infrastructure ; une reconstruction peut remplacer thème, modules et parcours. Cette distinction évite une proposition limitée à l’installation lorsque l’activité demande aussi d’adapter des intégrations. Séparez les changements indépendants lorsque possible pour identifier l’origine des problèmes.
- Notez versions actuelle et cible, environnement PHP, base de données, thème, modules et personnalisations.
- Identifiez paiements, transporteurs, facturation, synchronisation des stocks et tâches automatiques qui ne peuvent s’arrêter sans coordination.
- Confirmez auprès des fournisseurs les compatibilités et exigences officielles de la version cible, avec licences et alternatives.
- Définissez les éléments exclus du projet : nouveau design, révision complète des textes ou changement d’ERP, par exemple.
2. Inventorier le patrimoine SEO avant de modifier les URLs
Exportez catégories, produits, marques, pages d’information, langues et images importantes. Ajoutez URLs du sitemap, pages recevant du trafic organique, destinations des campagnes et liens externes connus. Le résultat doit être une liste exploitable pour comparaison, pas un simple nombre de produits. Conservez aussi titres, descriptions, canonical et règles d’indexation d’un échantillon représentatif.
Si une adresse change, associez l’ancienne URL à une destination équivalente. La documentation Google sur les migrations recommande des redirections permanentes côté serveur, des destinations pertinentes et des chaînes courtes. Ne dirigez pas tous les produits retirés vers l’accueil. Une page supprimée sans équivalent peut demander une réponse 404 ou 410 plutôt qu’une continuité artificielle.
3. Créer un environnement de test réellement isolé
Le staging est une copie séparée pour répéter le changement. Sa configuration et ses données nécessaires doivent se rapprocher de la production, avec accès limité et protection des données personnelles. Désactivez ou remplacez e-mails, paiements réels, expéditions et intégrations déclenchant des actions externes. Dupliquer la boutique sans isoler ces connexions peut générer des commandes ou notifications indésirables.
La copie ne doit pas devenir une seconde boutique publique indexable. Utilisez l’authentification et contrôlez l’indexation ; robots.txt ne protège pas l’accès. Identifiez les blocages propres au staging pour ne pas les transférer à la boutique publique. L’équipe doit toujours savoir dans quel environnement elle travaille.
4. Tester la sauvegarde et le plan de retour arrière
L’Update Assistant de PrestaShop propose mise à jour, sauvegarde et restauration, sans remplacer la préparation du projet. Confirmez le contenu de la copie : base, fichiers, images et configurations importantes. Conservez-la hors de l’espace public et testez sa restauration sur une copie. La présence d’un fichier ne prouve pas qu’il permettra de rétablir la boutique.
Définissez qui décide du retour arrière et quels signaux le justifient : achat impossible, erreurs de paiement, écarts graves de stock ou perte de données, par exemple. Le retour doit rétablir un ensemble cohérent de fichiers et de base. Restaurer une ancienne base après de nouvelles commandes peut les effacer ; leur rapprochement doit être préparé.
5. Vérifier SEO et achat avec une matrice de tests
Comparez l’ancienne boutique et la copie migrée avec les mêmes cas : produits simples et avec déclinaisons, catégories importantes, plusieurs langues et ruptures de stock. Notez résultat attendu, résultat observé et éléments de preuve. Une panne connue et classée est plus utile qu’un accord vague affirmant que le site semble fonctionner.
- SEO : URLs et redirections, codes HTTP, canonical, langues, sitemap, liens internes, images et règles d’indexation.
- Catalogue : références, déclinaisons, prix, taxes, remises, disponibilité et recherche interne.
- Achat : visiteur et client inscrit, panier, codes promotionnels, adresses, transporteurs et tous les moyens de paiement souscrits.
- Après-achat : confirmation, statut du paiement, stock, facturation, e-mails et communication avec les systèmes externes.
Une redirection validée doit atteindre la bonne page sans boucle, avec le contenu attendu. Un paiement validé doit créer une commande cohérente et le bon statut après confirmation du prestataire. Utilisez les modes de test disponibles et préparez toute vérification réelle avec autorisation, sans données sensibles dans les captures ou rapports.
6. Préparer synchronisation et transition
Entre création de la copie et lancement, clients, commandes, paiements, retours et catalogue peuvent évoluer. Définissez comment intégrer ces mouvements dans la boutique finale. Une fenêtre de maintenance réduit les changements concurrents, avec un coût commercial. Une synchronisation incrémentale peut réduire cette fenêtre, mais exige des règles et vérifications plus complexes. Ne remplacez pas simplement la base actuelle par la copie de test.
Préparez une séquence avec responsables : interrompre les opérations convenues, réaliser la copie finale, rapprocher les données, effectuer le changement, vérifier et rouvrir. En cas de nouvel hébergement, considérez propagation DNS et tâches encore exécutées sur l’ancien serveur. Évitez deux systèmes traitant autonomement la même commande ou publiant des stocks contradictoires.
7. Suivre le lancement au-delà du premier achat
Après transition, répétez les tests critiques et observez erreurs, commandes et intégrations. Vérifiez que seuls les blocages de staging prévus ont été retirés. Actualisez sitemap, liens de campagne et sources de catalogue si nécessaire. Comparez l’évolution des pages et recherches dans Search Console ; une variation isolée n’identifie pas automatiquement une cause et ne justifie pas d’annuler toute la migration.
Exemple hypothétique : reconstruction avec de nouvelles URLs
Imaginez une reconstruction changeant les URLs et supprimant les identifiants numériques. L’apparence est approuvée, mais les anciennes destinations des campagnes répondent 404. Les correspondances suivantes sont illustratives et ne représentent ni client ni adresses réelles RedeShop.
Produit équivalent : /12-casaco-azul.html doit répondre 301 ou 308 vers /casaco-azul, qui répond 200 avec l’offre équivalente. Le test confirme code, destination finale et contenu.
Produit supprimé sans équivalent : /44-artigo-retirado.html répond 404 ou 410. Aucune correspondance fictive n’est créée uniquement pour supprimer une erreur du rapport.
Catégorie réorganisée : /7-casacos redirige de manière permanente vers /casacos, avec réponse 200 et sélection pertinente. Envoyer toutes ces URLs vers l’accueil ne répond pas au résultat attendu ; cette règle générique est rejetée à la vérification.
Que transmettre pour évaluer votre migration ?
Partagez l’adresse de la boutique, sa version actuelle, le motif du changement, les intégrations essentielles et toute échéance commerciale. N’envoyez pas de mots de passe dans le formulaire. L’équipe RedeShop peut évaluer mise à niveau ou migration, distinguer diagnostic et réalisation, puis préparer un périmètre avec tests, responsabilités et conditions de reprise définis.