Table des matières :
- Cartographie d’URL : ce que vous perdez vraiment en quittant PrestaShop
- Inventorier les URL PrestaShop à rediriger (catalogue, CMS, pages techniques)
- Définir les permaliens WooCommerce et décider des équivalences (avant d’écrire la moindre règle)
- Construire une table de mapping robuste (CSV/SQL) et gérer les URL sans équivalent
- Implémenter des redirections 301 performantes (Apache/Nginx/HAProxy) sans dépendre de WordPress
- Vérifications post-bascule : crawl, logs 404, Search Console, KPI et correctifs rapides
Cartographie d’URL : ce que vous perdez vraiment en quittant PrestaShop
Une migration PrestaShop → WooCommerce se joue rarement sur l’export produits ou la reprise des clients. Le risque SEO principal, c’est la casse des URL historiques (pages produits, catégories, CMS, pages modules) et l’érosion du signal accumulé (liens entrants, maillage interne, historique de crawl). Sans cartographie d’URL SEO, vous remplacez mécaniquement des milliers de ressources indexées par des 404, puis vous “espérez” que Google retrouve ses repères. Dans l’e-commerce, ça se traduit par une chute immédiate du trafic non-brand et des pages transactionnelles.
Pour le rendre concret, voici un scénario classique : un produit “best-seller” a accumulé des backlinks (blog, comparateurs, forums), des signaux utilisateurs et une certaine stabilité d’indexation. Le jour J, l’URL change (ex. /123-produit-x.html devient /product/produit-x/). Sans redirection, Googlebot retombe sur une 404, retire progressivement l’URL de l’index, et la nouvelle page doit “réapprendre” à se positionner. Même avec une redirection tardive, vous perdez du temps de recrawl et vous introduisez de l’instabilité (surtout si plusieurs variantes d’URL coexistent).
Techniquement, PrestaShop et WooCommerce ne génèrent pas les URL de la même manière. PrestaShop mélange des routes legacy et Symfony selon les versions, avec une génération via Link/dispatcher et des règles de réécriture spécifiques (voir aussi : Génération d’URL PrestaShop : Link, routes Symfony et legacylink). WooCommerce repose sur WordPress (réécriture via règles de permaliens et endpoints), et la structure finale dépend autant des réglages “Permaliens” que des bases produits/catégories.
Une redirection 301 n’est pas une option “SEO”, c’est une sémantique HTTP standard. Le RFC est explicite : « The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI » (RFC 9110, section 15.4.2, RFC 9110). En clair : vous annoncez au client (navigateur, bot) qu’il existe un nouvel emplacement canonique, durable, et vous évitez une perte de continuité.
Point important : la 301 n’est pas seulement “un transfert de popularité”. C’est aussi un mécanisme d’orientation de crawl. Si vous redirigez proprement, vous aidez les robots à remplacer rapidement les anciennes URL par les nouvelles, ce qui stabilise l’indexation et limite la durée de la baisse post-migration.
Le piège classique en migration PrestaShop WooCommerce est de confondre cartographie et redirection. La cartographie, c’est un référentiel (source → cible, statut, règle, justification) validé avant la bascule. La redirection, c’est l’implémentation (Apache/Nginx/HAProxy/WordPress) appliquée à partir de ce référentiel. Sans référentiel, vous allez bricoler des règles regex “au jugé”, créer des chaînes de redirections, et injecter de la dette technique dans la couche HTTP.
Pour garder une vision “métier”, la cartographie vous force à répondre à 3 questions simples, mais souvent négligées :
- Quelle est la page cible la plus pertinente pour l’utilisateur ? (même intention, même assortiment)
- Quelle est la page cible la plus pertinente pour Google ? (même thématique, cohérence sémantique, contenu comparable)
- Quelle est la meilleure réponse HTTP ? (301 si remplacement, 410 si suppression définitive, parfois 302 uniquement en cas de besoin temporaire)
Inventorier les URL PrestaShop à rediriger (catalogue, CMS, pages techniques)
Pour construire une cartographie sérieuse, il faut d’abord une photographie exacte des URL qui reçoivent du trafic et/ou sont indexées. Les sources utiles ne sont pas seulement le catalogue : ce sont aussi les pages CMS, les pages “marques/fournisseurs” si vous les utilisez, les pages méta (ex : contact), les anciennes pages de blog si vous aviez un module, et parfois des endpoints de modules qui ont été linkés (FAQ, lookbook, landing promo).
Sur PrestaShop 1.7.x / 8.x (PHP 8.1/8.2 typiquement côté prod en 2026), l’inventaire propre se fait via un mix : export DB + crawl + analytics + logs. Côté base, vous récupérez au minimum les link_rewrite et leurs IDs, par langue. Exemples de requêtes (préfixe ps_ à adapter) :
-- Produits
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 p.active = 1;
-- Catégories
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 c.active = 1;
-- CMS
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 cms.active = 1;
Ces link_rewrite ne suffisent pas à eux seuls : l’URL finale dépend des réglages SEO/URL et des patterns (avec ou sans ID dans l’URL, suffixe .html, profondeur de catégories, etc.). Si vous avez des doutes sur la règle effective, fiez-vous à un crawl de production (Screaming Frog/OnCrawl/équivalent) pour récupérer l’URL “vue” par un client, puis réconciliez avec les IDs via des patterns.
Deux points sous-estimés lors de l’inventaire :
- Le multi-langue / multi-boutique : selon votre configuration PrestaShop, vous avez peut‑être des préfixes (
/fr/,/en/), des domaines par langue, ou desid_langqui ont produit des slugs différents. La cartographie doit être par langue (et vos redirections aussi), sinon vous redirigez de l’anglais vers du français (mauvaise expérience + signaux SEO brouillés). - Les médias et URLs d’images : si vous changez de stratégie d’images (format, chemin, CDN), certaines images peuvent être backlinkées ou apparaître dans Google Images. Vous n’êtes pas obligé de tout rediriger, mais a minima, identifiez les chemins qui recevaient des hits (logs) pour éviter une vague de 404 inutiles.
Ajoutez ensuite les URL à forte valeur qui ne sont pas “catalogue” : pages CMS stratégiques, pages “reassurance”, landing pages, pages de recherche interne si elles étaient indexées (souvent un problème), pagination, et navigation à facettes. Sur ce point, si votre PrestaShop laissait indexer des combinaisons de filtres, vous allez hériter d’un stock d’URL “toxiques” (paramètres) qu’il vaut souvent mieux désindexer (canonicals/noindex) et ne pas rediriger (ou rediriger vers la catégorie canonique). Pour cadrer ce travail d’hygiène, appuyez-vous sur une méthodologie d’audit technique (voir : Audit SEO technique : contrôle qualité avant publication des pages web).
Enfin, ne négligez pas les sources “terrain” : les logs 404/410 et les logs d’accès. Après bascule, ce sont eux qui révèlent les URL réellement demandées par les bots (y compris des URL très anciennes). Si vous avez déjà un monitoring correct côté PrestaShop, vous gagnerez du temps (voir : PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail).
Checklist d’inventaire (rapide, mais efficace) :
- Export DB (produits, catégories, CMS) par langue
- Crawl “comme Googlebot” (JS désactivé si besoin) + extraction des canonicals
- Export des top pages SEO (Search Console + analytics) pour prioriser
- Extraction logs : top URL demandées par bots + top 404 historiques
- Marquage des URL à ne pas sauver (recherche interne indexée, facettes inutiles, paramètres de tracking)
Définir les permaliens WooCommerce et décider des équivalences (avant d’écrire la moindre règle)
WooCommerce ne “subit” pas une structure d’URL : vous la choisissez. Le point de départ est WordPress → Réglages → Permaliens, puis WooCommerce → Produits → Permaliens. La doc WordPress sur les permaliens est la référence pour comprendre la mécanique de réécriture (Using Permalinks). Tant que vous n’avez pas figé ces réglages, toute table de mapping est instable.
Le choix n’est pas seulement esthétique. Il conditionne : (1) la capacité à faire du 1:1 (ancienne URL → nouvelle URL), (2) la densité de règles nécessaires, (3) le risque de collisions de slugs (WordPress impose des slugs uniques par type), et (4) la performance de la couche HTTP (plus vous dépendez de WordPress pour gérer les redirections, plus vous payez en I/O et en CPU à chaque requête bot).
En migration PrestaShop WooCommerce, l’approche la plus pragmatique est : reproduire autant que possible la “forme” des URL existantes, puis traiter les écarts au cas par cas. Exemples de décisions structurantes :
- Préfixe produit : WooCommerce utilise souvent
/product/slug/. Si vos URL PrestaShop étaient/slug.htmlou/categorie/slug.html, vous pouvez choisir un “custom base” pour réduire l’écart (et donc le nombre de règles spécifiques). - Catégories : WordPress gère les catégories produits via la taxonomie
product_cat. Vous pouvez conserver un chemin du type/categorie/sous-categorie/si votre SEO historique s’appuie sur la profondeur. - Suffixes : si vous aviez un suffixe
.htmlcôté PrestaShop, vous devrez décider si vous le gardez (possible mais atypique sous WordPress) ou si vous le supprimez (plus simple côté WP, mais implique des redirections systématiques).
Gardez aussi en tête que PrestaShop a des routes “fonctionnelles” (panier, commande, compte) qui ne doivent pas forcément être redirigées 1:1. Selon votre tunnel WooCommerce, il peut être plus propre de rediriger des pages non-SEO (ex : ancienne page panier) vers leur équivalent fonctionnel, sans chercher à conserver des URL inutiles en indexation. Le but : préserver le SEO des pages qui rankent, pas “sauver” toutes les routes.
Une bonne pratique consiste à formaliser les équivalences par “type d’entité” (ça aide à valider côté SEO et côté produit) :
| Type PrestaShop | Exemple source | Équivalent WooCommerce | Décision fréquente |
|---|---|---|---|
| Produit | /123-produit-x.html |
Fiche produit | 301 vers la fiche |
| Catégorie | /12-categorie-a/ |
product_cat |
301 si structure stable |
| CMS | /content/42-livraison |
Page WP | 301, parfois slug simplifié |
| Marque/Fournisseur | /manufacturer/7-marque-y |
Taxonomie/attribut | 301 si page conservée, sinon consolidation |
| Recherche / filtres | /recherche?query=... |
Recherche WP | généralement pas de redirection (noindex) |
Si vous avez besoin d’une méthode de staging/mapping transposable, l’article sur la migration vers Shopify décrit une démarche utile (audit → mapping → staging), même si la cible technique diffère : Migration PrestaShop vers Shopify : méthode d’audit, mapping et staging.
Construire une table de mapping robuste (CSV/SQL) et gérer les URL sans équivalent
Une cartographie d’URL exploitable n’est pas un tableur “à la main” rempli dans l’urgence. Le format qui marche en prod : une table (ou un CSV versionné) avec au minimum : source_path, target_path, status_code, rule_type (exact/regex), entity (product/category/cms), comment. Versionnez-la (Git) et faites-la valider (tech + SEO) avant la bascule.
Ajoutez, si possible, deux colonnes qui rendent la cartographie beaucoup plus actionnable :
priority(ex. 1 = top pages trafic / backlinks, 2 = important, 3 = long tail)source_evidence(ex. “GSC impressions”, “backlink”, “logs bot”, “maillage interne”)
Pour un catalogue volumineux, l’industrialisation passe par l’ID mapping : vous importez d’abord vos produits dans WooCommerce en conservant un identifiant externe (meta _prestashop_id, SKU, ou autre), puis vous reconstruisez la cible via l’API WP/WooCommerce ou via une extraction DB WordPress (wp_posts, wp_postmeta, wp_terms, wp_term_taxonomy, wp_term_relationships). L’objectif est d’éviter le matching fragile “par slug” (les slugs peuvent être translittérés différemment, et WordPress auto-incrémente en cas de conflit -2, -3, etc.).
Exemple simple de CSV de mapping (chemins relatifs, sans domaine) :
source_path,target_path,status_code,entity,comment
/123-produit-x.html,/produit/produit-x/,301,product,1:1
/categorie/a/b/,/categorie/a/b/,301,category,structure conservée
/content/42-livraison,/livraison/,301,cms,slug simplifié
/ancienne-landing-promo,/promotions/,301,cms,consolidation
/produit-obsolete.html,,410,product,produit supprimé sans équivalent
Le 410 n’est pas un gros mot : c’est un signal net pour les URL sans remplacement. Le standard HTTP le définit ainsi : « The 410 (Gone) status code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent » (RFC 9110, section 15.5.9, RFC 9110). Utilisez-le pour les produits définitivement supprimés, quand vous ne voulez pas “diluer” vers une catégorie générique.
En pratique, les cas “sans équivalent” se gèrent souvent en 3 familles :
- Produit arrêté mais substituable : 301 vers un successeur proche (même gamme / même intention).
- Produit arrêté non substituable : 410 (ou 404 si vous ne maîtrisez pas la couche serveur, mais 410 est plus explicite).
- Pages SEO obsolètes (anciennes promos) : consolidation vers une page “Promotions” ou “Nouveautés” si cela a du sens éditorial (sinon 410).
Le point non négociable : zéro chaîne de redirections. Chaque ancienne URL doit arriver en 1 hop vers la nouvelle URL canonique (en HTTPS, bon host, bon slash, bonne casse). Si vous avez aussi une normalisation “http → https” et “non-www → www” (ou l’inverse), faites-la au même niveau (reverse proxy / vhost) et testez les chemins pour éviter 301 → 301 → 200.
Enfin, n’oubliez pas le “SEO interne” : une fois la table validée, planifiez la mise à jour des liens internes (menus, blocs, cross-sell, footer, contenus CMS). Compter sur la redirection pour le maillage interne, c’est accepter de diluer du budget de crawl et d’ajouter de la latence à chaque visite bot.
Implémenter des redirections 301 performantes (Apache/Nginx/HAProxy) sans dépendre de WordPress
Pour quelques dizaines d’URL, une gestion applicative peut passer. Pour des centaines/milliers (cas réel en migration PrestaShop WooCommerce), faire porter les redirections à WordPress via un plugin est généralement un mauvais choix : surcharge PHP, accès DB, latence, et risque de timeouts sous crawl intensif. Le bon pattern : redirections au niveau du serveur web (Apache/Nginx) ou du reverse proxy (HAProxy), avant d’atteindre PHP-FPM.
En complément, gardez une règle simple : si une redirection peut être résolue par un lookup (clé → valeur), préférez-le à une regex. Les regex sont utiles pour des familles d’URL très régulières (ex. suppression d’un suffixe .html), mais elles peuvent aussi créer des faux positifs si l’historique PrestaShop contient des exceptions.
Apache 2.4 (vhost) : règles exactes + fichier de mapping
Dans .htaccess, vous êtes limité (pas de RewriteMap). Pour un gros mapping, passez par la conf du vhost. Exemple conceptuel :
# Exemple vhost (pas .htaccess)
RewriteEngine On
# Normalisation host + https (à adapter)
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]
# Mapping exact via RewriteMap (fichier clé->valeur)
RewriteMap redirects txt:/etc/apache2/redirects.map
RewriteCond ${redirects:$1} !=""
RewriteRule ^(.*)$ ${redirects:$1} [R=301,L]
Le fichier /etc/apache2/redirects.map contiendra des lignes source_path target_path. Avantage : lookup très rapide, maintenance simple, et pas de regex qui mangent du CPU. Si vous avez un hébergement où vous ne contrôlez pas le vhost (mutualisé), le compromis est d’exporter des règles Redirect 301 /old /new (module mod_alias) plutôt que des regex complexes.
Astuce opérationnelle : gardez le fichier de mapping généré (à partir du CSV versionné) et non édité à la main. Vous évitez les divergences “CSV vs prod” et vous pouvez redeployer à l’identique en staging puis en production.
Nginx : map + return 301
Nginx gère très bien des mappings massifs via map et include :
map $request_uri $redirect_target {
default "";
/123-produit-x.html /produit/produit-x/;
/content/42-livraison /livraison/;
}
server {
listen 443 ssl;
server_name www.example.com;
if ($redirect_target != "") {
return 301 $scheme://$host$redirect_target;
}
# Ensuite seulement : WordPress / WooCommerce
location / { try_files $uri $uri/ /index.php?$args; }
}
Si votre infra inclut déjà un cache/reverse proxy (Varnish/HAProxy), placez la normalisation et les redirections au plus “haut” possible pour éviter de faire travailler PHP. Sur ce point, les considérations d’architecture et de performance sont les mêmes que pour PrestaShop (voir : Cache PrestaShop : Varnish, Redis, Memcached et OPcache côté serveur et Serveurs dédiés infogérés e-commerce : NVMe, Redis, Varnish et haute disponibilité).
Un dernier point spécifique à WordPress : après import massif et réglage des permaliens, il faut “flush” les règles (via l’admin ou WP-CLI) pour éviter des 404 transitoires. Faites-le avant l’ouverture aux bots (maintenance/HTTP auth en staging), puis vérifiez que vos endpoints WooCommerce (panier/checkout/mon compte) répondent sans conflit avec vos redirections.
Vérifications post-bascule : crawl, logs 404, Search Console, KPI et correctifs rapides
La bascule terminée, la partie “SEO” devient un problème d’observabilité. Faites un crawl complet de l’ancien site (snapshot) et du nouveau, et comparez : (1) anciennes URL → statut final, (2) profondeur de crawl, (3) canonicals, (4) title/meta, (5) pagination, (6) données structurées (produit, breadcrumb). Pour les schémas et le maillage, gardez une cohérence minimale afin de ne pas perdre les rich results inutilement (référence : SEO e-commerce : implémenter schema Product Review Breadcrumb et maillage interne).
Ajoutez une vérification “migration-friendly” souvent oubliée : les canonicals doivent pointer vers les nouvelles URL finales, pas vers des anciennes URL redirigées. Un canonical qui pointe vers une URL en 301 crée des signaux contradictoires (et peut ralentir la stabilisation).
Ensuite, pilotez par les logs. Sur Nginx/Apache, sortez un rapport quotidien des 404/410 les plus demandées par les user-agents bots (Googlebot/Bingbot), et injectez des corrections dans la table de mapping. C’est là que vous rattrapez les URL “hors inventaire” : anciennes campagnes, backlinks qui pointent sur des variantes, fautes de frappe, URL avec slash manquant, ou anciennes règles de réécriture. Si vous n’avez pas un pipeline logs propre, vous allez corriger à l’aveugle ; mettez au moins une collecte/filtrage basique et des alertes (voir : PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail).
Dans Google Search Console, surveillez :
- Pages (indexation) : explosion de “Non trouvée (404)” = mapping incomplet ou permaliens mal figés.
- Sitemaps : soumettez le sitemap WooCommerce et vérifiez la vitesse d’absorption ; ne conservez pas un sitemap PrestaShop.
- Performances : filtrez sur les pages produits/catégories qui faisaient du trafic avant migration, et vérifiez que la page cible reçoit bien les impressions/clics.
Côté KPI, ne vous contentez pas du “trafic global” : mesurez le % d’anciennes URL qui finissent en 200 après redirection (objectif réaliste : >95% pour le catalogue actif), le nombre de chaînes 301→301, et le temps de réponse sur les URLs redirigées sous charge bot (sinon vous vous retrouvez avec des 503 côté WP/PHP-FPM). Si vous voyez des 503 lors du crawl, traitez-le comme un incident infra (diagnostic ressources + logs) avant de blâmer le SEO (référence utile : Erreur HTTP 503 : diagnostic serveur, logs et ressources).
Pour accélérer les correctifs (semaine 1 à 2), un tableau de bord minimal peut suffire :
- Top 404 bots (volume + URL) → action (301/410/ignore)
- Top redirections les plus lentes → optimisation (serveur/proxy)
- Top pages money (produits/catégories) → contrôle SERP + indexation + canonicals
- Ratio “ancienne URL → 200 final” sur l’échantillon top trafic
Enfin, verrouillez une checklist de correction continue (semaine 1 à 4) : ajout de mappings manquants, consolidation des URL supprimées en 410, nettoyage des paramètres (tracking, facettes), mise à jour des liens internes (éviter de “compter” sur les redirections), et contrôle des canonicals. Une migration PrestaShop WooCommerce réussie côté SEO n’est pas “zéro chute” (c’est rare), c’est une chute limitée, expliquée, puis une récupération rapide parce que la couche HTTP et la cartographie d’URL ont été traitées comme un composant technique à part entière.