Migration WooCommerce vers PrestaShop : préserver le SEO et les URL

Table des matières :

1. Inventorier les URLs WooCommerce : crawl, permaliens et “vraies” pages à préserver
2. Comprendre pourquoi reproduire les URLs Woo à l’identique est rarement une bonne idée
3. Construire le mapping : correspondances 1:1, règles par pattern, et cas impossibles
4. Redirections 301/308 : serveur d’abord, application ensuite (avec exemples Nginx/Apache)
5. Préserver le SEO au-delà des URLs : canonicals, contenu, maillage, médias, données structurées
6. Plan de lancement : staging, bascule DNS, sitemaps, monitoring 404 et métriques
7. Check-list opérationnelle (réaliste) pour une migration WooCommerce vers PrestaShop sans casse SEO

La migration WooCommerce vers PrestaShop n’est pas un problème d’import produit. C’est un problème de stabilité des signaux SEO (URLs, contenus, maillage, statuts HTTP, canonicals). Si vous cassez les URLs, Google ne “comprend” pas votre nouvelle boutique : il réapprend, vous perdez du trafic, et vous découvrez trop tard que PrestaShop n’a pas d’outil natif sérieux pour gérer un plan de redirections massif.

Dans les faits, une migration e-commerce « réussie SEO » ressemble rarement à un big-bang parfait : c’est plutôt une bascule maîtrisée + une phase de rattrapage (logs 404, ajustements de mapping, nettoyage des URLs parasites) pendant 2 à 6 semaines. Le point clé est d’éviter les signaux contradictoires : 200 sur la bonne page, 301 en une seule étape, pas de duplication inutile (paramètres, facettes, pagination, tri).

Contexte technique utilisé ci-dessous : PrestaShop 8.1.x ou 9.x, PHP 8.2/8.3, serveur Nginx ou Apache, base MariaDB. Les exemples de configuration sont volontairement “serveur-first” : c’est plus rapide, plus fiable, et ça évite de charger PrestaShop pour servir une 301.

Inventorier les URLs WooCommerce : crawl, permaliens et “vraies” pages à préserver

Avant de parler redirections, il faut figer l’état des lieux. Sur WooCommerce, l’URL d’un produit dépend de la structure des permaliens WordPress (réglage global) + des slugs (post_name) + parfois d’un “base” (/product/, /produit/, etc.) + des plugins (langues, filtres, SEO). Donc on commence par extraire la liste exhaustive des URLs indexables (produits, catégories, pages CMS utiles) et leur statut HTTP.

En pratique, un crawl type Screaming Frog / Sitebulb, couplé à une exportation des sitemaps XML (si présents), donne une base solide. Ne vous contentez pas du sitemap : sur Woo, les pages “orphelines” existent (anciens produits, tags, pages de blog, filtres paramétrés) et Google peut en avoir indexé une partie.

Ajoutez deux sources souvent oubliées, mais très utiles pour réduire les angles morts :

• Google Search Console : exportez les pages les plus vues (Performances) et les pages détectées / indexées (Indexation). Ça ne remplace pas un crawl, mais ça priorise les “vraies” URLs qui comptent.
• Logs serveur (Nginx/Apache) : sur 30 à 90 jours, ils révèlent les URLs réellement demandées (bots + utilisateurs), y compris des anciennes URLs absentes du sitemap.

L’objectif est d’obtenir un tableau : old_path, type, status, canonical, title, inlinks. Dans la pratique, rajoutez deux colonnes qui font gagner du temps au moment des arbitrages :

• indexable : oui/non (selon meta robots, X-Robots-Tag, canonical, status).
• priority : haute/moyenne/basse (par exemple basée sur trafic GSC, backlinks, ou profondeur de clic).

Une grille simple de tri (utile pour décider quoi rediriger et quoi laisser mourir) :

Type d’URL Woo	Exemple	Action recommandée	Pourquoi
Produit	/product/chaussure-x/	301 → fiche produit PrestaShop	Cœur du trafic SEO + intention d’achat
Catégorie	/product-category/chaussures/	301 → catégorie PrestaShop	Important pour la découverte / maillage
Page utile (SAV, livraison, retours)	/livraison/	301 → page CMS équivalente	Valeur utilisateur + confiance
Variantes / paramètres ?attribute=	?attribute_pa_taille=42	Souvent ne pas rediriger (ou canonicaliser)	Risque duplication + crawl budget
Recherche interne	/?s=...	410 ou 404 (selon cas)	Faible valeur, souvent indexation parasite
Panier / checkout historiques	/cart/, /checkout/	Redirection vers la nouvelle URL si stable, sinon laisser 404/410	Éviter de polluer l’index avec des pages “non SEO”

À ce stade, vous devez aussi classer les URLs non souhaitées : paramètres de tracking, pages de recherche interne, archives auteur, pagination infinie, endpoints (/wp-json/, ?add-to-cart=), etc. Garder ces URLs “vivantes” via des redirections inutiles plombe le crawl budget. Sur PrestaShop, le sujet des URLs générées (filtres/facettes) est déjà délicat ; si vous importez des erreurs Woo en plus, vous payez deux fois. Référence utile : Budget de crawl PrestaShop : maîtriser URLs de filtres et facettes.

Enfin, faites attention aux détails “bêtes” qui cassent des mappings :

• slash final (/produit/x vs /produit/x/)
• encodage (%C3%A9 vs é) et translittération (accents, apostrophes)
• casse (URLs en majuscules, très rare mais vu sur de vieux contenus)
• multi-langue (WPML/Polylang en sous-dossiers /fr/ /en/, ou paramètres)

Comprendre pourquoi reproduire les URLs Woo à l’identique est rarement une bonne idée

Techniquement, vous avez deux stratégies : (1) imiter la structure Woo dans PrestaShop, ou (2) accepter une nouvelle structure et compenser avec un plan 301 propre. La tentation d’imiter est forte (“on garde tout pareil, donc pas de SEO impact”). En réalité, c’est souvent fragile parce que PrestaShop et WooCommerce n’ont pas les mêmes invariants : multi-catégorisation, règles de réécriture, gestion des IDs, langues, et collisions de slugs.

Côté PrestaShop, les URLs sont générées par le Dispatcher et des routes configurables dans Paramètres de la boutique → Trafic & SEO → Configuration des URLs (noms exacts variables selon version). Le cœur privilégie généralement un pattern stable du type /{id}-{rewrite} pour éviter les collisions. Retirer l’ID peut sembler “plus Woo”, mais c’est risqué : deux produits avec le même slug (ou slug proche après translittération) peuvent produire des conflits, et vous finissez avec des 404 intermittentes ou des canoniques qui se battent.

Un cas concret fréquent en FR : deux déclinaisons de libellés qui se ressemblent après nettoyage (ex. T-shirt été et T shirt ete) peuvent finir avec le même link_rewrite si vous “normalisez” trop agressivement. Avec un ID dans l’URL, le front reste stable ; sans ID, vous créez une dette technique SEO (et parfois des incohérences en multi-boutique).

Autre point : WooCommerce encode souvent la taxonomie dans l’URL (ex. /product-category/chaussures/), alors que PrestaShop peut générer une URL produit avec la catégorie par défaut, mais celle-ci n’est pas un identifiant unique et peut changer. Si votre SEO Woo reposait sur des URLs “catégorisées”, vous pouvez les conserver en façade… mais c’est un coût permanent (maintenance de routes + redirections). À partir d’un certain volume, la stratégie rationnelle est : URLs PrestaShop cohérentes + redirections 301 au niveau serveur.

Deux heuristiques utiles pour décider :

• Si votre boutique a peu de catégories et des produits très “éditorialisés” (pages evergreen), reproduire partiellement des patterns peut se défendre.
• Si vous avez beaucoup de produits, des changements fréquents de catégories, ou du multi-langue, privilégiez des URLs PrestaShop stables et misez sur le mapping + monitoring.

Construire le mapping : correspondances 1:1, règles par pattern, et cas impossibles

Un “mapping d’URL” n’est pas un export de slugs. C’est une table de correspondance entre une ressource (produit/catégorie/page) et sa nouvelle URL. L’important est le 1:1 : une ancienne URL doit pointer vers une unique destination pertinente. Tout ce qui n’a pas de correspondance doit être traité explicitement (410 si supprimé, ou 301 vers une catégorie/landing si équivalent réel).

Commencez par mapper les ressources “stables” :

• produits : sku (référence) comme clé de vérité, pas l’ID Woo
• catégories : slug + hiérarchie (attention aux catégories homonymes)
• pages CMS : slug ou ID, selon ce que vous migrez (CGV, livraison, retours)

Puis, formalisez vos règles d’arbitrage avant de générer le fichier de redirections. Exemple de règles réalistes (et auditables) :

• Produit migré tel quel → 301 vers sa fiche produit (cible 200)
• Produit supprimé sans équivalent → 410 (ou 404, mais 410 est plus explicite)
• Produit fusionné → 301 vers le produit “parent” ou la nouvelle fiche unique
• Variation Woo devenue déclinaison PrestaShop → 301 vers la fiche (et, si nécessaire, gestion côté front via paramètres/ancres, mais sans créer des URLs indexables par variation)
• Catégorie renommée mais équivalente → 301 vers la nouvelle catégorie
• Contenu blog non migré → décider : conserver WordPress (sous /blog/), ou assumer 410/404 (mais alors plan de redirection à prévoir pour les articles qui ont des backlinks)

Ensuite, traitez les patterns : si vos produits Woo étaient en /product/{slug}/ et vos nouveaux produits en /{id}-{slug}.html, vous pouvez générer des règles semi-automatiques… à condition d’avoir un dictionnaire slug → id. C’est là que beaucoup échouent : ils veulent une règle regex générale, mais les slugs ne sont pas garantis uniques (et peuvent changer).

La bonne approche est de générer un fichier de redirections “plat” (clé/valeur), produit depuis une export PrestaShop (SQL ou API) et le crawl Woo. Recommandation simple : versionnez ce fichier (Git) et conservez un champ source/comment dans votre table de travail (pour documenter les exceptions). Ça facilite aussi les retours arrière : “Pourquoi /produit/x/ part vers telle catégorie ?”.

Enfin, acceptez qu’il existe des cas impossibles sans arbitrage : produits fusionnés, variations Woo transformées en déclinaisons PrestaShop, bundles, pages filtrées indexées, etc. Pour ces cas, l’objectif SEO est de réduire la casse : rediriger vers la page la plus proche, éviter les chaînes de redirections, et documenter les exceptions pour le support.

Deux pièges à éviter lors de la génération :

• Rediriger en masse vers la home : c’est souvent interprété comme “soft 404” et c’est rarement pertinent.
• Créer des redirections en chaîne : /a → /b → /c. Visez /a → /c directement.

Redirections 301/308 : serveur d’abord, application ensuite (avec exemples Nginx/Apache)

Google est explicite : lors d’une migration avec changement d’URL, il faut utiliser des redirections permanentes et préserver autant que possible les correspondances. La documentation Google Search Central – Site moves with URL changes détaille la démarche et insiste notamment sur les redirections 301 : Google Search Central – Site moves with URL changes. 308 est aussi “permanent”, mais dans l’écosystème e-commerce, 301 reste la valeur sûre (outils, caches, CDN, historiques).

Techniquement, 301 et 308 diffèrent surtout sur le comportement de certains clients HTTP (308 préserve la méthode). Comme on redirige majoritairement des pages GET (produits/catégories/pages), la différence est rarement déterminante — d’où le choix conservateur du 301.

Point de détail important : dans Nginx/Apache, votre mapping portera presque toujours sur le path (ex. /product/xxx/) et non sur la query string. Ça évite d’exploser le nombre de règles, mais ça exige de décider quoi faire des paramètres (utm_*, gclid, tris, filtres).

Nginx : map + fichier généré (scalable)

Pour des milliers d’URLs, évitez 10 000 rewrite à la main. Utilisez map avec un fichier :

# /etc/nginx/conf.d/redirects-woocommerce.map
# format: old_path new_path;
# /product/ancien-produit/ /123-ancien-produit.html;

map $uri $new_uri {
    default "";
    include /etc/nginx/conf.d/redirects-woocommerce.map;
}

server {
    # ...
    if ($new_uri != "") {
        return 301 $scheme://$host$new_uri;
    }
}

Cette méthode a trois avantages concrets : (1) lookup O(1) côté Nginx, (2) rechargement sans downtime (nginx -s reload), (3) vous gardez PrestaShop hors du chemin critique des redirections.

Si vous voulez préserver certains paramètres (par exemple utm_source), adaptez le return pour réattacher la query string… mais seulement si vous êtes sûr de ne pas créer des doublons indexables :

return 301 $scheme://$host$new_uri$is_args$args;

Dans beaucoup de migrations e-commerce, la stratégie la plus propre est : on conserve les paramètres pour l’utilisateur, mais on empêche leur indexation via canonical et/ou règles de robots (selon les cas). Le point clé reste : ne pas faire exploser les variations crawlées.

Apache : RewriteMap (si vous êtes sur httpd)

Même principe avec RewriteMap :

RewriteEngine On

RewriteMap wc2ps txt:/etc/apache2/redirects-woocommerce.map
RewriteCond ${wc2ps:$1|NOT_FOUND} !NOT_FOUND
RewriteRule ^(.*)$ ${wc2ps:$1} [R=301,L]

Note : selon l’hébergement, RewriteMap n’est pas autorisé en .htaccess. Dans ce cas, passez par une conf vhost, ou assumez un fallback applicatif (moins performant).

Dans tous les cas, testez sur un échantillon représentatif :

• top 50 pages produit (trafic GSC)
• top 20 catégories
• anciennes URLs avec paramètres
• URLs avec et sans slash final
• URLs encodées (accents, espaces)

Fallback PrestaShop : module de redirection (quand vous n’avez pas la main serveur)

Le cœur PrestaShop ne fournit pas un gestionnaire de redirections massives fiable. Si vous êtes contraint (mutualisé, pas d’accès Nginx/Apache), écrivez un module minimal qui intercepte la requête tôt et consulte une table ps_redirect_legacy(old_path VARCHAR(255) PK, new_path VARCHAR(255), code TINYINT).

Deux points pour éviter que ce fallback ne devienne un problème de performance :

• Cache : APCu/Redis (au minimum sur les hits fréquents) pour éviter de taper MariaDB à chaque requête.
• Journalisation : loggez les “miss” (ancienne URL sans mapping) pour alimenter votre boucle de correction.

Pour les aspects performance et diagnostic, vous pouvez recouper avec : Optimisation PrestaShop : accélérer pages produit et panier et, côté base, PrestaShop MySQL : analyser slow query log et optimiser index.

Préserver le SEO au-delà des URLs : canonicals, contenu, maillage, médias, données structurées

Les redirections ne suffisent pas si vous changez ce que Google “voit” sur la page cible. Après import, vérifiez que les champs SEO sont bien peuplés : meta_title, meta_description, link_rewrite, textes longs.

Astuce simple : sur un échantillon de pages (par exemple 100 produits), comparez avant / après :

• H1 (présence et cohérence)
• 1er paragraphe de description (contenu réel, pas vide)
• prix et disponibilité (visibles et cohérents)
• balise canonical (auto-référente et en HTTPS)
• maillage interne (liens vers catégories, produits liés, cross-sell)

Sur PrestaShop, l’import CSV classique peut suffire pour un petit catalogue, mais dès que vous avez des contraintes (multi-langue, champs custom, mapping fin), une approche API-first est plus contrôlable (idempotence, logs, reprises). Référence : Import catalogue PrestaShop : pipeline API-first automatisé et supervisé.

Ensuite, traitez la canonicalisation. Dans Woo, beaucoup de sites vivent avec des canoniques “plugin SEO”, parfois incohérents en présence de paramètres. Dans PrestaShop, vous devez surveiller : (1) le HTTPS forcé, (2) la normalisation des slashs, (3) les paramètres de tri/pagination, (4) les facettes.

Trois contrôles rapides (souvent révélateurs) :

• Une URL avec paramètres (?order=price) a-t-elle une canonical vers l’URL “propre” ?
• Deux URLs différentes renvoient-elles la même canonical (signe de duplication non maîtrisée) ?
• Les pages filtrées (facettes) génèrent-elles des URLs indexables en masse ?

Une canonical qui pointe vers une URL non redirigée ou une variante filtrée est un générateur de dilution. Pour l’hygiène HTTPS, cf. HTTPS SEO : bonnes pratiques, certificats SSL et audit technique.

Enfin, ne négligez pas les assets. Les anciennes URLs d’images Woo (/wp-content/uploads/...) peuvent être référencées depuis des blogs, comparateurs, ou posts sociaux. Si vous ne pouvez pas les conserver, redirigez-les (301) vers les nouvelles images, ou au minimum servez une image équivalente (200) pour éviter une hémorragie de liens cassés.

Mini-scenario typique : un comparateur a “aspiré” vos images Woo il y a 2 ans et continue d’appeler /wp-content/uploads/2022/05/xxx.jpg. Si l’URL casse, vous perdez des visuels (et parfois des pages produit affichées “vides”) sur des canaux qui convertissent. Même si ces images ne sont pas le cœur du SEO, c’est un signal de qualité et une source de trafic indirect.

Côté “rich results”, validez les pages produit via le test Google (test des résultats enrichis) : PrestaShop dépend beaucoup du thème, et certains thèmes cassent le JSON-LD (microdata partiel, prix/stock manquants). Une migration est le moment idéal pour imposer une sortie structurée correcte (Product + Offer avec prix, devise, disponibilité), et de vérifier qu’aucune page ne renvoie des données structurées contradictoires (ex. stock “InStock” alors que la page affiche “épuisé”).

Plan de lancement : staging, bascule DNS, sitemaps, monitoring 404 et métriques

Un lancement propre se fait en deux temps : staging index-blocked puis production. En staging, vous répliquez l’environnement (PHP, modules, conf serveur) et vous empêchez l’indexation (auth HTTP + X-Robots-Tag: noindex), sans bricoler des Disallow: / qui finissent oubliés. Pour industrialiser le staging (Docker, réplication proche de prod), voir : Staging PrestaShop : créer un environnement Docker fidèle à la production.

Le jour J, évitez la “bascule DNS et on verra”. Faites une fenêtre de gel : arrêt des commandes Woo, export delta (clients/commandes si nécessaire), import final PrestaShop, puis bascule.

Deux bonnes pratiques opérationnelles qui limitent les surprises :

• Test “pré-prod” des redirections : injectez le fichier de mapping sur le staging et exécutez un crawl des anciennes URLs (liste Woo) pour vérifier le triptyque 301 → 200 et détecter les chaînes.
• Contrôle des pages stratégiques : listez les 20 pages d’atterrissage SEO les plus rentables (GSC / analytics) et validez manuellement : contenu, prix, variations, livraison, balises.

Gardez l’ancienne stack Woo en ligne au moins quelques semaines, idéalement derrière le même domaine, uniquement pour servir les redirections (ou pour fournir le fichier de mapping si vous centralisez sur Nginx). Si vous changez aussi d’hébergement, anticipez TTL et propagation : Zone DNS OVHcloud : propagation, TTL et bonnes pratiques de configuration.

Après mise en ligne :

• soumettez les nouveaux sitemaps dans Search Console
• surveillez le taux de 404, les chaînes (301→301→200), les “soft 404”
• comparez impressions/clics (GSC) et sessions (analytics) sur 14/28 jours
• analysez les logs d’accès pour repérer les URLs Woo encore demandées

Indicateurs simples (sans sur-ingénierie) à suivre chaque jour la première semaine :

Indicateur	Ce que vous cherchez	Signal d’alerte
Volume de 404	Doit diminuer rapidement	404 stables/haut niveau = mapping incomplet
Chaînes de redirections	Proche de zéro	301→301 fréquents = dette de mapping
Pages indexées (GSC)	Reprise progressive	Chute brutale + erreurs = blocage technique
Temps de réponse (TTFB)	Stable	Pic après migration = redirections applicatives, DB, cache

Si vous avez une infra logs (OpenSearch/ELK), c’est le moment de l’exploiter ; sinon, même une extraction journalière des 404 suffit. Et pour une checklist technique globale, recoupez avec : SEO PrestaShop : checklist technique 2025 pour indexation et performance.

Check-list opérationnelle (réaliste) pour une migration WooCommerce vers PrestaShop sans casse SEO

1) Avant migration : crawl complet Woo + export sitemaps + extraction des URLs réellement indexables ; geler la structure des permaliens ; lister les templates d’URL (produits, catégories, pages). Documenter les cas spéciaux (variations, bundles, produits supprimés).
Bonus utile : exporter la liste des pages qui reçoivent le plus de trafic SEO (GSC) pour prioriser les tests et les mappings “à la main”.

2) Pendant build PrestaShop : importer le catalogue en conservant une clé stable (SKU), reconstruire catégories et pages CMS, valider que les pages cibles répondent 200 avec contenu équivalent (H1, description, prix, disponibilité). Vérifier la génération d’URLs et les canoniques. Ne commencez pas par “optimiser” les slugs : vous voulez de la correspondance, pas de la créativité.
Contrôle rapide : sur un échantillon de produits, vérifiez aussi l’URL image principale, la présence d’avis (si vous les migrez) et le fil d’Ariane.

3) Redirections : générer un mapping 1:1 (fichier) et l’appliquer au niveau serveur (Nginx map / Apache RewriteMap). Ajouter une couche de règles génériques uniquement pour les patterns simples (ex. /product-category/(.*) vers catégorie). Interdire les chaînes : une ancienne URL doit arriver en une seule 301 sur une URL finale 200.
Ajoutez un “filet de sécurité” : si une URL Woo ne peut pas être mappée, mieux vaut 410 (contenu supprimé) qu’une redirection vague vers la home.

4) Post-lancement : soumettre sitemaps, suivre logs 404, corriger les mappings manquants, et nettoyer les URLs parasites (paramètres, filtres). Les 2 premières semaines, votre objectif n’est pas “améliorer le SEO” : c’est rétablir la stabilité (statuts HTTP, indexation, perf). Côté perf et diagnostics, gardez sous la main un plan de dépannage : Dépannage boutique en ligne : 30 pannes classées par symptôme.

Si vous appliquez ça strictement, vous obtenez généralement un profil propre : >95–99% des URLs historiques avec une cible 200 pertinente, une chute SEO limitée (le temps de réévaluation), et une boutique PrestaShop qui n’est pas prisonnière d’une imitation fragile de WooCommerce.