Migration PrestaShop vers Shopify : SEO, redirections 301 et plan de lancement

Table des matières :

1. Contraintes SEO spécifiques d’une migration PrestaShop → Shopify (ce qui casse, ce qui se conserve)
2. Inventaire et cartographie d’URL : extraire le graphe PrestaShop et préparer les handles Shopify
3. Redirections 301 : stratégie, outillage et implémentations (Shopify natif vs frontal)
4. Préserver les signaux : canonicals, hreflang, données structurées, facettes, pagination
5. Plan de lancement : DNS, bascule, validation, monitoring et rollback (sans se raconter d’histoires)

Contraintes SEO spécifiques d’une migration PrestaShop → Shopify (ce qui casse, ce qui se conserve)

Migrer une boutique PrestaShop (1.7.x, 8.x ou 9.x) vers Shopify n’est pas une « mise à jour » : c’est un changement de moteur, de conventions d’URL et de surface de contrôle. Côté SEO, la différence majeure est que PrestaShop vous laisse façonner vos routes (modules, règles .htaccess, patterns d’URL, facettes très libres), alors que Shopify impose une taxonomie de chemins (/products/, /collections/, /pages/, /blogs/). Cette contrainte est structurante : vous ne reproduirez pas à l’identique une arborescence d’URL historique de type /categorie/sous-categorie/123-produit.html sans un plan de redirections sérieux.

Deuxième point : l’accès à l’infrastructure. Avec PrestaShop (Apache/Nginx + PHP-FPM, MySQL/MariaDB), vous contrôlez les headers, les logs HTTP, les caches (Varnish/Redis), la compression et les règles de réécriture. Sur Shopify, vous êtes sur un SaaS : pas d’nginx.conf, pas de logs serveur natifs, et une capacité limitée à faire du “surgery SEO” (ex. redirection d’anciens chemins d’images /img/p/...). En contrepartie, vous bénéficiez d’un CDN global, d’un TLS propre, et d’un risque opérationnel réduit (moins de surface d’attaque côté serveur). Pour un comparatif TCO/SEO/sécurité 2026, voir l’article interne : Shopify vs PrestaShop 2026 : TCO, SEO, sécurité et évolutivité.

Enfin, le SEO ne se limite pas aux URL : vous migrez des signaux. Titres, H1, contenus, maillage interne, canonical, données structurées (Product/Review/Breadcrumb), pages CMS, et surtout la capacité à contrôler l’indexation des facettes et de la pagination. PrestaShop + ps_facetedsearch (ou équivalent) génère souvent des milliers d’URL à paramètres : si ces pages sont aujourd’hui indexées et performantes, les perdre sans stratégie (landing pages SEO dédiées, redirections, ou équivalents Shopify) crée un trou dans le trafic. À ce sujet, l’approche “landing pages maîtrisées + facettes contrôlées” est détaillée ici : Pages d’atterrissage SEO : maîtriser facettes, indexation Google et maillage interne.

Pour cadrer la migration, il est utile de distinguer ce qui casse vs ce qui peut se conserver :

• Casse (souvent)
• Patterns d’URL (suffixes .html, inclusion d’ID, chemins catégoriels profonds).
• URLs d’images PrestaShop (/img/p/..., /img/cms/...) si elles ont été partagées ou backlinkées.
• Contrôle fin des règles de réécriture (regex, conditions).
• Certaines logiques de facettes “SEO-friendly” construites au fil des ans via modules.
• Se conserve (si vous le préparez)
• Le contenu (H1, descriptions longues, FAQ, guides d’achat).
• La logique de maillage interne (à condition de la réimplémenter dans le thème et les menus).
• Une grande partie des signaux via redirections 301, si la couverture est forte et les cibles cohérentes.
• Les marqueurs de confiance (avis, UGC), à condition de migrer les données et/ou d’utiliser un système d’avis compatible.

Point de vigilance “terrain” (souvent observé sur des boutiques FR/BE/CH) : si vous aviez une stratégie multi-langue ou multi-pays via PrestaShop (sous-dossiers /fr/, /en/, domaines .fr/.be, ou multi-boutique), la migration vers Shopify doit trancher un modèle clair (Shopify Markets + sous-dossiers, ou domaines dédiés). Une redirection “grossière” qui renvoie toutes les langues vers /fr peut créer un mélange d’intentions, dégrader la pertinence et brouiller les signaux régionaux.

Inventaire et cartographie d’URL : extraire le graphe PrestaShop et préparer les handles Shopify

Le livrable #1 de la migration SEO n’est ni un thème Shopify ni un export produit : c’est une cartographie d’URL (old → new) priorisée par valeur business (sessions organiques, conversions, backlinks). Sur PrestaShop, la manière la plus fiable d’inventorier est de croiser : (1) un crawl (Screaming Frog / Sitebulb), (2) les landing pages organiques (GSC + analytics), et (3) la source de vérité DB. L’objectif est de sortir un set “exhaustif” des URL canoniques actuelles, et de détecter les variantes (avec paramètres, pagination, tri) qui doivent être neutralisées (canonical/noindex) plutôt que redirigées.

Une façon pragmatique de ne pas se perdre est de structurer la cartographie avec des colonnes “SEO” et “run” dès le départ (même dans un simple Google Sheet) :

Champ	À quoi ça sert	Exemple
Old URL (canonique)	Source de redirection	/12-chemises/1234-chemise-oxford-bleue.html
Type	Logique de cible (produit/collection/page/blog)	product
Priorité	Ordre d’implémentation et de QA	P1 / P2 / P3
Preuve de valeur	Justifier l’effort (trafic, CA, backlinks)	GSC clics 90j, Top ventes
New URL	Cible Shopify	/products/chemise-oxford-bleue
Statut	Pilotage	à créer / prêt / redirigé / testé
Note	Piège (facette, doublon, rupture, variante)	existe en 3 chemins cat.

Pour l’extraction DB (PrestaShop 1.7/8/9, MySQL/MariaDB), vous pouvez construire les URL “propres” via link_rewrite et id_* selon votre schéma d’URL. Exemple minimaliste pour récupérer les slugs de produits (à adapter selon multi-boutique et multi-langue) :

SELECT p.id_product,
       pl.id_lang,
       pl.link_rewrite,
       pl.name
FROM ps_product p
JOIN ps_product_lang pl ON pl.id_product = p.id_product
WHERE pl.id_shop = 1;

Même logique pour catégories et CMS :

SELECT c.id_category, cl.id_lang, cl.link_rewrite, cl.name
FROM ps_category c
JOIN ps_category_lang cl ON cl.id_category = c.id_category
WHERE cl.id_shop = 1;

SELECT cms.id_cms, cmsl.id_lang, cmsl.link_rewrite, cmsl.meta_title
FROM ps_cms cms
JOIN ps_cms_lang cmsl ON cmsl.id_cms = cms.id_cms
WHERE cmsl.id_shop = 1;

La difficulté n’est pas de récupérer des slugs : c’est de reconstruire le chemin exact réellement indexé (catégorie dans l’URL, suffixe .html, présence d’ID, etc.). Si votre boutique utilise des patterns du type /{category}/{id}-{rewrite}.html, il faut reproduire ce pattern dans votre export, sinon vous produirez des old URL qui n’existent pas (et vos tests de redirections seront faux positifs). Une approche robuste consiste à partir d’un crawl des URL 200 (ou des logs Nginx/Apache si vous en avez) et à enrichir avec les données DB (id produit, lang, statut, catégories) pour décider du mapping vers Shopify.

Concrètement, en audit de migration, on rencontre souvent 3 familles d’URL “pièges” à traiter explicitement dans la cartographie :

• Variantes d’accès au même produit : produit accessible via 2–5 catégories (donc 2–5 chemins), ou via une landing de facette + produit.
• Anciennes pages CMS renommées : /content/7-livraison devient /pages/livraison, mais la page “Livraison” a parfois été dupliquée (ex. “Livraison & retours”, “Livraison express”).
• Produits arrêtés : si une URL produit a des backlinks, la redirection doit aller vers la catégorie/collection la plus proche (ou une page équivalente), pas vers la home “par défaut”.

Côté Shopify, la “clé” URL est le handle (slug). Les produits sortent en /products/{handle}, les collections en /collections/{handle}, les pages en /pages/{handle}, les articles en /blogs/{blog-handle}/{article-handle}. Vous pouvez influencer le handle, mais pas le préfixe de route. Cela implique souvent une normalisation : un ancien produit PrestaShop pouvait vivre dans plusieurs catégories et être accessible via plusieurs chemins ; sur Shopify, le produit a une URL canonique unique. Votre mapping doit donc choisir une cible unique, puis rediriger toutes les variantes vers cette cible (sinon vous conservez de la duplication, ou vous perdez des signaux).

Bonnes pratiques côté handles (souvent négligées lors des imports) :

• Stabilité > “SEO rewriting” : changer un slug qui ranke déjà n’apporte généralement rien, et ajoute un risque. Si l’ancien slug est “propre”, essayez de le conserver (au moins conceptuellement) dans le nouveau handle.
• Unicité et collisions : deux produits qui finissaient par le même slug dans des catégories différentes sur PrestaShop devront être distingués (ex. chemise-oxford-bleue vs chemise-oxford-bleue-homme).
• Accents et caractères spéciaux : anticipez la translittération (é → e) et les apostrophes. Cela évite des divergences entre ce que vous “pensez” importer et ce que Shopify enregistre réellement.

Redirections 301 : stratégie, outillage et implémentations (Shopify natif vs frontal)

Une redirection 301 est une instruction HTTP qui indique un déplacement permanent. La définition normative est explicite : « The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI… » (RFC 9110, HTTP Semantics, section 15.4.2 : RFC 9110). Concrètement, en migration SEO, le 301 sert à transférer au maximum les signaux (liens, historique, pertinence) des anciennes URL vers les nouvelles, à condition de respecter trois règles : (1) 1 hop max (pas de chaînes), (2) cible sémantiquement équivalente, (3) couverture quasi totale des URL importantes.

Google documente aussi une contrainte opérationnelle souvent négligée : sur un site move avec changements d’URL, « Keep the redirects for at least 1 year. » (Google Search Central, Site move with URL changes : Site move with URL changes — Google Search Central). Traduction en termes de run : ne supprimez pas vos 301 après “2 mois parce que ça marche”. Un an est un minimum pour absorber la longue traîne (backlinks lents, caches, vieux bookmarks, URLs en SERP). En pratique, sur e-commerce avec beaucoup de produits, on garde souvent plus longtemps, et on met en place un monitoring 404 pour détecter les oubliés.

Avant même de parler “outillage”, clarifiez la doctrine de redirection (sinon vous créerez des incohérences à grande échelle) :

• Produit → produit équivalent (idéal).
• Produit supprimé → collection la plus proche (ou une page “alternatives” dédiée) si vous ne pouvez pas recréer l’équivalent.
• Catégorie PrestaShop → collection Shopify (ou page d’atterrissage SEO si vous aviez un contenu éditorial riche).
• CMS → page Shopify (en conservant le contenu + les balises).
• Facettes indexées : rediriger uniquement les facettes “gagnantes” vers des pages dédiées ; pour le reste, viser une canonicalisation/noindex plutôt qu’un millefeuille de 301.

Pour valider vite (et éviter les surprises après bascule), prévoyez des tests HTTP simples sur un lot P1. Exemple de commande utile (avant et après mise en place des règles) :

curl -I https://www.votredomaine.tld/12-chemises/1234-chemise-oxford-bleue.html

Ce que vous cherchez : HTTP/2 301 (ou HTTP/1.1 301) + un Location: qui pointe directement sur l’URL finale (pas vers une URL intermédiaire qui redirige à nouveau).

Implémentation 301 dans Shopify (sans infra)

Shopify fournit un gestionnaire de redirections (interface + import), et une API d’admin permettant aussi d’automatiser en masse (selon votre stack/outillage). Le point clé : Shopify sait faire des redirections chemin → chemin sur le domaine, mais vous êtes limités sur les cas “tordus” (regex complexes, redirections conditionnelles sur user-agent, réécriture d’anciens chemins d’images, etc.).

Pour une migration PrestaShop → Shopify, un format de travail pragmatique est un CSV “source path / target path” dérivé de votre table de mapping. Exemple conceptuel :

Redirect from,Redirect to
/12-chemises/1234-chemise-oxford-bleue.html,/products/chemise-oxford-bleue
/content/7-livraison,/pages/livraison
/12-chemises,/collections/chemises

Points de contrôle qui évitent des erreurs bêtes au moment de l’import :

• Les valeurs sont des paths (avec /), pas des URLs complètes avec domaine.
• Vous standardisez dès le début le format (avec ou sans slash final) et vous vous y tenez.
• Vous évitez de “sur-rediriger” des URL déjà propres : une redirection inutile est un hop potentiel si un jour vous changez à nouveau le handle.

Ensuite, vous testez sur un échantillon (top 100 URL SEO), puis vous importez en masse et vous recrawlez. Pour une méthodologie de cartographie d’URL (même si l’article cible WooCommerce), la logique est transposable : Méthode de migration : redirections 301 et cartographie d’URL SEO.

À noter : Shopify crée aussi des redirections automatiques à l’intérieur de Shopify quand vous changez un handle (produit/collection/page) si l’option est activée. C’est utile pour la vie du site après lancement, mais ça ne remplace pas votre mapping PrestaShop → Shopify.

Implémentation 301 via un frontal (Cloudflare/Nginx/HAProxy) : quand Shopify ne suffit pas

Dès que vous devez gérer des patterns, des milliers de règles, ou des cas hors périmètre Shopify (notamment les anciennes URLs d’images PrestaShop /img/p/... et certains paramètres), vous avez intérêt à mettre un proxy/edge devant Shopify. Cas courant : Cloudflare proxy sur le domaine, avec Redirect Rules, Bulk Redirects, ou Workers pour appliquer une table de mapping (KV/CSV) et renvoyer un 301 propre.

Pourquoi c’est souvent décisif en migration e-commerce :

• Vous pouvez gérer des familles d’URL (ex. toutes les URL en .html vers une version sans suffixe) sans créer une règle unitaire par URL — à condition de ne pas casser la pertinence (attention aux collisions).
• Vous récupérez de l’observabilité (logs/analytics edge) : quelles anciennes URL sont encore demandées, lesquelles tombent en 404, quelles sources (referrer) alimentent ces hits.
• Vous pouvez centraliser les redirections si vous avez plusieurs propriétés (ex. domaine principal + domaines historiques + sous-domaines).

Si vous avez la main sur un reverse-proxy (Nginx/HAProxy) devant Shopify (plus rare, mais faisable dans certaines architectures), vous pouvez utiliser une map Nginx générée depuis votre mapping :

map $request_uri $redirect_target {
  default "";
  /12-chemises/1234-chemise-oxford-bleue.html /products/chemise-oxford-bleue;
  /content/7-livraison /pages/livraison;
}
server {
  if ($redirect_target != "") {
    return 301 $redirect_target;
  }
  # proxy_pass vers Shopify
}

Ce type de frontal vous redonne aussi de la visibilité via logs (utile quand Shopify ne fournit pas de logs bruts) et permet de traiter les 404 “post-migration” à la volée. Attention : c’est une pièce d’infra en plus, donc un point de panne et un besoin de supervision. Autre piège : un frontal mal paramétré peut créer des boucles (old → new → old) ou des redirections “en cascade” si Shopify applique aussi une normalisation (HTTP→HTTPS, www→apex, etc.). D’où l’importance des tests automatisés sur un lot d’URL avant bascule.

Préserver les signaux : canonicals, hreflang, données structurées, facettes, pagination

Les redirections ne compensent pas une régression de contenu. Avant bascule, vous devez figer et exporter : titres SEO, meta descriptions, H1, contenu long, attributs (matière, dimensions), alt d’images, et contenu éditorial. Shopify sait gérer titres/meta et contenu via l’admin, mais la qualité dépend de votre thème et de votre discipline d’intégration. Si votre PrestaShop avait déjà un balisage schema.org propre (Product, Review, Breadcrumb), vérifiez que le thème Shopify ré-émets une sémantique équivalente (ou meilleure), et que vous ne perdez pas d’éléments critiques (GTIN, brand, availability, aggregateRating). Pour les attentes sur schema et maillage côté e-commerce, vous pouvez croiser : SEO e-commerce : implémenter schema Product Review Breadcrumb et maillage interne et, côté PrestaShop, SEO PrestaShop : optimiser fiches produits, schema.org et images WebP.

Une check-list simple (mais très efficace) est de comparer, sur un échantillon représentatif (top produits + top catégories/collections), avant vs après :

• title (même intention, longueur maîtrisée, mot-clé principal conservé)
• H1 (unique, aligné sur le contenu de page)
• contenu éditorial (texte, FAQ, guides, blocs “conseils”)
• données structurées Product + Breadcrumb (présentes, valides, cohérentes avec le contenu)
• images (alt, ordre, cohérence des variantes)
• liens internes (menus, breadcrumbs, cross-sell, liens depuis le blog)

Sur les canonicals, Shopify impose déjà des canoniques sur de nombreux templates, mais les pièges restent classiques : variantes produit (?variant=), produits accessibles via collections (chemins différents), et paramètres de filtres. L’objectif est simple : une page indexable = une canonical stable, et toutes les routes alternatives doivent converger. Sur des stores multilingues, vous devez aussi reconstruire correctement les hreflang (Shopify Markets ou app), sinon vous créez des conflits de duplication inter-langues. Dans une migration depuis PrestaShop multiboutique/multilang, la cartographie doit être par langue (old FR → new FR, old EN → new EN) et pas une redirection “tout vers /fr”.

Cas très concret en contexte francophone : si vous aviez un .fr qui servait la France, et que vous ouvrez après migration des marchés Belgique/Suisse francophone, évitez de mélanger les signaux “FR” et “FR-BE/FR-CH” sans hreflang/structure claire. Même si Google gère souvent “fr” global, les incohérences de structure (sous-dossiers vs domaines) peuvent créer des duplications et des cannibalisations.

Les facettes et la pagination sont souvent le point noir. PrestaShop + modules de facettes peuvent générer des landing pages indexées qui rapportent (ex. couleur=bleu + matiere=coton). Shopify propose des filtres de collections, mais la gestion SEO des URLs filtrées dépend du thème et de votre stratégie. Deux approches : (1) empêcher l’indexation des URLs de filtres (meta robots noindex + canonical vers la collection), ou (2) créer des pages d’atterrissage dédiées (collections ou pages) pour les segments rentables, et rediriger les anciennes facettes “gagnantes” vers ces pages. Si votre stratégie actuelle repose sur des pages de facettes indexées, relisez impérativement l’article interne sur la maîtrise des facettes : Pages SEO dédiées : facettes, indexation Google et maillage.

Dernier point : le sitemap. Shopify génère https://votredomaine.tld/sitemap.xml (index de sitemaps), ce qui suffit pour beaucoup de cas, mais vous devez vérifier : la présence de toutes les ressources attendues (produits, collections, pages, articles), l’absence d’URL non canoniques, et la cohérence avec vos directives robots.txt. La discipline “sitemap clair = indexation plus contrôlée” est détaillée ici : Plan de site : optimiser l’indexation Google avec un sitemap clair.

• Shopify génère un robots.txt (et permet, selon la configuration, une personnalisation via robots.txt.liquid) : validez que vos choix facettes/pagination sont cohérents avec ce fichier et avec les meta robots des templates.
• Le sitemap Shopify reflète ce que la plateforme considère “publiable” : si vous masquez des produits/collections, ou si vous jouez avec des canaux, vérifiez l’impact sur le sitemap et donc sur la découverte par Google.

Plan de lancement : DNS, bascule, validation, monitoring et rollback (sans se raconter d’histoires)

La bascule “propre” se prépare comme un changement de prod, pas comme une mise en ligne de thème. Si votre domaine reste identique (cas le plus fréquent), la partie critique est DNS : baisse de TTL quelques jours avant, préparation des enregistrements (A record et CNAME selon recommandations Shopify), et vérification que vous ne cassez pas la messagerie (MX, SPF, DKIM, DMARC). Sur OVHcloud, la gestion TTL/propagation mérite un vrai runbook : Zone DNS OVHcloud : propagation, TTL et bonnes pratiques de configuration. Le risque principal n’est pas “Google” : c’est un downtime ou un site partiellement accessible (www vs apex, HTTP vs HTTPS) qui génère des erreurs de crawl et du bruit.

Sur le timing, privilégiez un créneau à faible trafic et imposez un freeze contenu sur PrestaShop (catalogue, CMS, règles SEO) avant l’export final. Si vous avez des intégrations (ERP/WMS, paiement, feed produits), verrouillez la compatibilité avant le jour J : Shopify a ses connecteurs, mais le comportement n’est pas identique à celui d’un module PrestaShop. Ce lancement doit aussi intégrer un plan de rollback réaliste : si vous pointez directement le domaine vers Shopify, le rollback = remettre l’ancienne cible DNS et accepter une propagation. Une approche plus contrôlée (type blue/green) consiste à interposer un frontal (CDN/proxy) qui permet un switch quasi instantané et des règles de redirection centralisées. Pour la méthodologie générale “migration = plan incrémental + rollback”, l’article interne est pertinent : Migration PrestaShop : audit technique et plan incrémental blue/green.

Une check-list “jour J” réaliste (à adapter) :

• DNS
• TTL déjà abaissé (ex. 300s) et contrôlé.
• Enregistrements Shopify prêts (apex + www), sans toucher aux entrées mail.
• SEO & tracking
• GSC vérifiée (propriété du domaine, sitemap prêt à être resoumis).
• GA4 / pixels / conversions testés sur un panier de bout en bout.
• Redirections
• Import final effectué.
• Test manuel + test automatisé sur un lot P1 (top 100–500 URL).
• Qualité
• Pages critiques (home, collections, top produits, livraison/retours, CGV) validées.
• Recherche interne et filtres fonctionnels (sinon hausse de pogo-sticking et baisse de conversion).

Après bascule, votre check-list n’est pas “ça charge sur mon laptop”. Vous devez (1) recrawler un échantillon significatif d’anciennes URL (top SEO + long tail), (2) mesurer les codes HTTP (200/301/404), (3) valider l’absence de chaînes de redirection, (4) vérifier canonicals/hreflang/schema, (5) soumettre/rafraîchir le sitemap dans Google Search Console et suivre Couverture/Indexation/Erreurs. Mettez des seuils : par exemple < 1% d’URL anciennes en 404 sur le top 10 000, et 0 chaîne > 1 hop sur les URL à trafic. Comme Shopify ne donne pas de logs serveur, prévoyez une source de vérité alternative (CDN logs, Cloudflare analytics, outil de crawl planifié) et un alerting (ex. hausse de 404, chute de pages indexées). En environnement PrestaShop, on s’appuie souvent sur logs et slow queries pour diagnostiquer ; pour référence méthodo perf/observabilité côté stack classique : PrestaShop MySQL : analyser slow query log et optimiser index.

Ajoutez un réflexe simple de “triage” post-migration, très utile les 10–15 premiers jours :

• 404 qui reçoivent du trafic : à traiter en priorité (création de redirections manquantes).
• URL redirigées vers une mauvaise cible : à corriger (meilleure équivalence sémantique).
• Soft 404 (page qui renvoie 200 mais “aucun produit”) : à surveiller dans GSC, souvent plus toxique qu’un 404 franc.

La migration SEO PrestaShop vers Shopify est réussie quand, 2 à 6 semaines après bascule, vous avez (a) récupéré la quasi-totalité du trafic des pages “money”, (b) stabilisé les impressions/clics GSC, (c) réduit le backlog 404 à une poignée d’URL résiduelles, et (d) une gouvernance claire des futures créations d’URL (nouvelles collections/pages) pour ne pas réintroduire le chaos. Le cœur de PrestaShop a ses défauts, Shopify a ses verrous ; la seule constante, c’est que sans inventaire d’URL et sans redirections testées, vous payez la migration en visibilité organique, et ce coût se chiffre en semaines de CA — pas en lignes de Liquid.