Migration PrestaShop 8 : stratégie SEO et plan d’URL cross‑site

Table des matières :

1. Pourquoi une migration PrestaShop 8 casse le SEO (et pourquoi ce n’est pas “juste une mise à jour”)
2. Inventaire et cartographie : construire un plan d’URL cross-site qui survit aux équipes et aux sprints
3. Redirections 301, canonicals, hreflang : la plomberie SEO qu’on oublie toujours
4. Paramètres, facettes et pagination sur PrestaShop 8 : éviter l’index bloat (le vrai tueur silencieux)
5. Déploiement sans drame : blue/green, contrôle des en-têtes, et perf qui ne sabote pas le crawl
6. Contrôles post-migration (J0 à J+30) : quand Google recrawl, il ne pardonne pas vos approximations
7. Ce que vous gagnez quand le plan d’URL cross-site est bien fait (et comment en faire un projet vendable en interne)

Pourquoi une migration PrestaShop 8 casse le SEO (et pourquoi ce n’est pas “juste une mise à jour”)

Migrer vers PrestaShop 8 n’est pas un simple composer update avec un café et une prière. On touche au cœur : thème, modules, routing, génération d’URL, performance, parfois même au domaine (rebranding, internationalisation, fusion de boutiques). Et Google, lui, ne “comprend pas l’intention” : il crawl des URL, lit des codes HTTP, compare des contenus, et ajuste des signaux. Si votre migration change 20% des URL (même “un petit slash”), vous venez de déclencher une suite d’événements digne d’un incident de prod.

Ce qui rend la migration particulièrement risquée en SEO, c’est que plusieurs couches bougent en même temps :

• Couche URL : réécriture, trailing slash, casse, encodage, paramètres, multi-langue, host (www vs non-www).
• Couche contenu : gabarits (Hn, blocs descriptifs), produits “vidés” par un import, variations qui changent de page.
• Couche signaux : maillage interne, canonicals, données structurées, sitemap, hreflang.
• Couche perf & crawl : temps de réponse et erreurs (5xx) pendant le recrawl, cache/CDN mal invalidé, surcharge DB.

La stratégie SEO de migration doit être traitée comme une migration applicative critique : inventaire, mapping, tests, observabilité, rollback. Une refonte qui “passe” fonctionnellement peut quand même perdre 30% de trafic organique si les redirections sont bancales, si les canonicals pointent vers le passé, ou si les facettes se mettent à indexer 200 000 URL inutiles. Pour cadrer la partie technique avant de toucher au moindre template, un audit sérieux aide à mettre les risques noir sur blanc : voir par exemple votre méthodologie dans Audit de site web : technique, SEO, UX et sécurité pour une roadmap.

Côté sources, Google ne fait pas mystère des règles du jeu. Dans la doc Search Central sur les changements d’URL, Google recommande explicitement les redirections permanentes : « Use 301 redirects from the old URLs to the new ones whenever possible. » (Google Search Central — Site move with URL changes). Traduction : si vous ne mappez pas, vous perdez. Et si vous mappez mal, vous perdez aussi, mais avec plus d’élégance.

À garder en tête (et utile pour “vendre” le sujet en interne) : une migration SEO n’échoue pas forcément par “grosse erreur”, mais par accumulation de petites approximations (302 au lieu de 301, canonicals incohérents, 10 000 liens internes vers des URL redirigées, facettes ouvertes, etc.). Le plan est là pour empêcher ces approximations de devenir un système.

Inventaire et cartographie : construire un plan d’URL cross-site qui survit aux équipes et aux sprints

Un plan d’URL cross‑site (ou “cross-domain”) est une cartographie ancienne URL → nouvelle URL qui couvre : changement de CMS/versions, changement de structure, changement de domaine, multi-boutiques (PrestaShop multistore), ou bascule vers un sous-domaine (www vs root). Le mot “plan” est important : ce n’est pas un fichier Excel décoratif, c’est un contrat d’interface entre SEO, dev, infra, et parfois les métiers. Et oui, c’est rarement sexy… jusqu’au moment où le trafic tombe.

La base : l’inventaire des URL existantes (crawl + logs + sitemaps + Search Console + analytics). Ne vous contentez pas du sitemap, il est souvent incomplet ou “optimiste”. Sur un e-commerce, les URL vraiment crawlées sont souvent celles générées par la navigation à facettes, les campagnes, les pages de recherche interne… bref, tout ce que vous n’aviez pas prévu. Pour estimer le périmètre proprement, l’article Comment compter les URL d’un site internet sans utiliser les résultats de recherche Google donne une approche pragmatique (et moins hasardeuse que de “deviner” via site:).

Pour construire un inventaire “qui tient la route”, visez une triple source :

1. Crawl (outils type crawler) : ce que votre site expose via maillage.
2. Logs serveur : ce que Googlebot et les autres bots visitent réellement (souvent très différent).
3. Données business & SEO : pages qui génèrent CA/leads + pages qui reçoivent des backlinks.

Ensuite, on segmente l’inventaire par types d’URL (produits, catégories, CMS, marques, filtres, pagination, images, pages compte/checkout à exclure, etc.) et par valeur SEO (trafic, conversions, backlinks, positions). Une cartographie propre ressemble à ça :

Ancienne URL	Nouvelle URL	Type	Code attendu	Priorité	Notes
/category.php?id=12	/chaussures-homme	Catégorie	301	P1	Canonical + breadcrumbs à vérifier
/product.php?id=987	/nike-air-xyz	Produit	301	P1	Conserver contenu + données structurées
/search?query=...	(bloquée)	Interne	410	P3	Pas d’indexation

Quelques règles simples qui évitent 80% des drames :

• P1 = pages qui “comptent” : top pages organiques (Search Console), pages de catégories stratégiques, produits phares, URLs avec backlinks. Ce sont celles que vous testez en premier en pré-prod, puis en prod.
• One-to-one autant que possible : une ancienne catégorie doit rediriger vers la nouvelle catégorie équivalente, pas vers la home.
• Gérer les “disparitions” : si un produit est définitivement supprimé et n’a pas d’équivalent pertinent, un 410 (Gone) peut être plus propre qu’une redirection opportuniste (à manier avec stratégie, surtout si l’URL avait du trafic).
• Stabiliser les patterns : décider dès le départ si vous forcez https, www (ou non), slash final (ou non), et comment vous gérez les langues (/fr/ vs domaine dédié). Ensuite seulement, vous mappez.

Le point clé “cross‑site” : si vous migrez vers un nouveau domaine, vous devez aussi définir une politique de consolidation (ex. http → https, non-www → www, anciennes langues sur sous-domaines → sous-répertoires, etc.). Sans standard, vous allez finir avec 4 variantes indexables par URL. Et non, “Google va choisir la bonne” n’est pas une stratégie.

Pour que le plan survive aux sprints (et aux changements de scope), formalisez-le comme un livrable versionné :

• un fichier source (CSV/Google Sheet) avec colonnes figées (old, new, code, type, priorité, owner, date),
• une règle de “pas de mise en prod sans mapping” (même pour 50 URL),
• et un test automatisé (au moins un échantillon P1/P2 vérifié à chaque release).

Redirections 301, canonicals, hreflang : la plomberie SEO qu’on oublie toujours

La redirection 301 est un signal de migration permanente au niveau HTTP. L’IETF le rappelle très clairement : un 301 indique que la ressource « has been assigned a new permanent URI » (RFC 9110, HTTP Semantics : RFC 9110 — HTTP Semantics). Donc, si votre serveur renvoie des 302 “par défaut”, ou des 200 avec une page “produit introuvable” (soft-404), vous venez d’expliquer à Google que rien n’a vraiment bougé… sauf votre contenu, vos liens internes et vos métriques.

Sur PrestaShop 8, la difficulté est rarement “activer les URL simplifiées”. Le vrai sujet, c’est la cohérence :

• Redirections one-to-one autant que possible (une ancienne page de catégorie ne doit pas toutes finir sur la home, sinon vous diluez la pertinence).
• Chaînes de redirection interdites (301→301→200) : elles allongent la latence, consomment du budget crawl, et créent des erreurs de mapping.
• Redirections au niveau edge (CDN) ou serveur (Nginx/Apache) plutôt qu’applicatif quand la volumétrie est élevée.
• Normalisation des variantes : rediriger systématiquement http → https, non-www → www (ou l’inverse), et éviter les doublons avec/sans slash final.

Exemple Nginx “propre” avec map (utile quand vous avez des milliers d’URL) :

map $request_uri $new_uri {
  default "";
  /old-product-123 /nike-air-xyz;
  /old-cat-12 /chaussures-homme;
}
server {
  if ($new_uri != "") { return 301 $scheme://$host$new_uri; }
}

Pour valider rapidement la “plomberie”, un mini-protocole de test simple (et très efficace) :

• Sur un échantillon P1 (50 à 200 URL) : curl -I et vérifier status, Location, et absence de double saut.
• Vérifier que la destination finale renvoie bien 200, avec canonical auto-référente.
• Vérifier qu’une URL ancienne ne redirige pas vers une page noindex ou 404 (ça arrive plus souvent qu’on ne l’admet).

Ensuite, les trois pièges qui font “perdre” même avec des 301 :

1) Canonical : vos pages doivent déclarer une canonique stable, auto-référente, et surtout sur la bonne URL finale. Pour la théorie (et la pratique), revisitez Définition : contenu dupliqué et URL canoniques, qu’est ce que c’est et comment les optimiser.
2) Hreflang : si vous êtes multi-langues/multi-pays, le couple hreflang + canonical + redirections doit être cohérent. Une migration cross-site qui change les patterns (/fr/ vs fr.example.com) impose de revalider toutes les réciprocités (chaque version doit pointer vers les autres, et vers elle-même).
3) Liens internes : une migration qui garde des liens internes pointant vers des URL redirigées est une migration qui accepte volontairement de dégrader les temps de chargement et de gaspiller du crawl. Oui, vous payez deux requêtes pour arriver au même contenu. Bravo.

Enfin, un cas “terrain” fréquent en rebranding : vous migrez ancienne-marque.fr vers nouvelle-marque.fr, mais certaines campagnes (email, PDF, partenaires) continueront à publier l’ancien domaine. Si vous ne stabilisez pas les 301 cross-domain et les règles de canonicals, vous entretenez un bruit permanent : Google re-crawl l’ancien domaine, réévalue des pages redirigées, et vous payez ce bruit en crawl budget et en latence d’indexation.

Paramètres, facettes et pagination sur PrestaShop 8 : éviter l’index bloat (le vrai tueur silencieux)

Sur e-commerce, le risque n°1 post-migration n’est pas “une 404 sur une page CMS” : c’est l’index bloat. Autrement dit, vous laissez Google indexer une quantité absurde d’URL de filtres (?q=, ?order=, ?page=), de combinaisons (color=black&size=42&brand=nike), et de pages de tri (“prix croissant”…). Résultat : budget crawl dilué, signaux de pertinence fragmentés, cannibalisation. Et vous vous retrouvez à expliquer en comité de pilotage que “Google est lent”. Non : c’est votre site qui bavarde trop.

PrestaShop 8 (comme 1.7+) s’appuie sur des modules de navigation à facettes. Le bon pattern dépend du business, mais techniquement on vise généralement :

• Pages catégories indexables (200, canonical auto-référente).
• Pages filtres : soit non indexables (meta robots noindex,follow + canonical vers la catégorie), soit indexables pour un set très limité de facettes “SEO-driven” (ex. “chaussures de sécurité S3” si c’est une intention de recherche réelle). Le reste doit être bloqué proprement.
• Tri / pagination : pagination indexable ou pas selon stratégie, mais dans tous les cas, éviter de multiplier les variantes via paramètres.

Une façon pragmatique de décider quelles facettes méritent (ou non) d’être indexées :

• Intention + volume : existe-t-il des requêtes récurrentes correspondant au filtre (ex. “S3”, “anti-dérapant”, “largeur 3XL”) ?
• Stock & pérennité : si l’assortiment tourne trop, éviter de créer des pages qui tombent en rupture tous les mois.
• Contenu différenciant : si la page filtre n’a pas de texte, pas d’USP, pas de tri métier, elle est souvent un duplicat “faible”.

Google est assez clair sur l’usage du robots.txt : il empêche le crawl, pas l’indexation si l’URL est découverte via liens externes. Donc, si vous “bloquez tout” dans robots.txt sans traiter les canonicals/noindex, vous pouvez vous retrouver avec des URL paramétrées indexées… mais impossibles à crawler (bonjour les URL indexed, not crawled). La doc officielle sur le contrôle du crawl et de l’indexation vaut le détour (Google Search Central — robots meta tag).

La migration est le bon moment pour remettre au propre l’arborescence (et éviter que la navigation ne génère des chemins incohérents). Si vous changez les patterns d’URL, faites-le pour une raison : réduction de profondeur, meilleure catégorisation, cohérence multi-langues, etc. Pour structurer proprement, appuyez-vous sur Arborescence de site : 6 étapes pour un SEO performant.

Point d’attention concret sur PrestaShop : selon thème et modules, les facettes peuvent générer des URL propres (réécrites) ou paramétrées. Dans les deux cas, ce n’est pas le “look” de l’URL qui compte, mais votre capacité à :

• contrôler l’indexation (robots meta / X-Robots-Tag),
• déclarer des canonicals cohérentes,
• maîtriser le maillage interne (ne pas pousser 50 combinaisons de filtres dans la navigation principale).

Déploiement sans drame : blue/green, contrôle des en-têtes, et perf qui ne sabote pas le crawl

Une migration PrestaShop 8 réussie côté SEO est souvent… une migration DevOps réussie. Déployer en “one shot” un vendredi à 18h, c’est un choix de vie. Préférez un blue/green (ou au minimum une bascule DNS/Reverse proxy contrôlée) avec la possibilité de revenir en arrière. Objectif : tester les redirections, les canonicals, les headers cache, le comportement mobile, et les temps de réponse avant que Googlebot et vos clients ne découvrent les surprises.

Sur l’infrastructure, la performance n’est pas un bonus : elle conditionne la capacité de crawl. Surveillez : TTFB, erreurs 5xx, saturation PHP-FPM, latences DB, et cache (Varnish/Redis/CDN). Un CDN bien configuré peut lisser la charge pendant la période de recrawl post-migration, mais seulement si vous maîtrisez vos règles. Pour une approche CDN pragmatique, voir Cloudflare : notre avis sur cet opérateur CDN.

Ajoutez un contrôle simple mais souvent oublié : la vérification des en-têtes sur des pages clés (home, catégorie, produit, CMS) :

• Cache-Control / Surrogate-Control (éviter de servir du contenu obsolète après une bascule)
• Content-Type (HTML vs JSON accidentel, oui ça arrive avec certains reverse proxies)
• X-Robots-Tag (attention aux règles globales “noindex” héritées d’une pré-prod)
• Cohérence HSTS si vous forcez https (sinon, vous entretenez des variantes)

Côté mesure, ne pilotez pas la migration “au feeling”. Combinez monitoring synthétique + RUM (parce que vos vrais utilisateurs ont toujours un réseau plus mauvais que votre fibre), et corrélez avec les signaux SEO (couverture d’index, crawl stats, logs). Pour les fondamentaux, Real User Monitoring : RUM vs monitoring synthétique pour la performance web est une bonne base. Et pour instrumenter proprement côté infra : Prometheus monitoring : quickstart en 5 minutes et mise en production (oui, “quickstart” et “mise en prod” dans la même phrase, c’est osé, mais faisable).

Dernier point “anti-drama” très opérationnel : verrouiller la pré-prod. Une pré-prod indexée (ou accessible sans protection) pendant la migration peut créer du duplicate, générer des URLs dans les SERP, et semer la confusion. À minima : authentification, restriction IP, et/ou noindex global (mais en gardant une discipline : le noindex doit disparaître en prod, et ça se teste).

Contrôles post-migration (J0 à J+30) : quand Google recrawl, il ne pardonne pas vos approximations

J0-J2 : vous vérifiez l’essentiel, pas les détails cosmétiques. Priorités : taux de 404/410, présence de 5xx, conformité des 301, absence de chaînes, canonicals correctes, sitemaps à jour, robots.txt cohérent. Et surtout : logs. Les logs serveur sont le “langage natif” de Googlebot. Vous devez être capable de répondre à : “quelles URL crawlées renvoient quoi ?” et “à quelle fréquence ?”. Sans logs, vous faites du SEO comme on fait de la sécurité sans audit : à l’optimisme.

Actions concrètes (faciles à planifier, dures à improviser) :

• Soumettre les nouveaux sitemaps et surveiller leur taux de succès (URLs “découvertes” vs “indexées”).
• Contrôler un échantillon d’anciennes URLs stratégiques : elles doivent toutes terminer en 200 sur la bonne destination.
• Vérifier le rendu mobile et les assets (CSS/JS) : un thème cassé peut transformer des pages en contenu pauvre, sans que le serveur ne renvoie d’erreur.

J3-J15 : on mesure l’atterrissage. La doc Google rappelle aussi un point souvent ignoré (et pourtant écrit noir sur blanc) : « Keep the redirects in place for as long as possible. » (Google Search Central — Site move with URL changes). En pratique, visez 12 mois minimum (et idéalement plus), parce que les backlinks, les favoris, les caches, et les crawlers tiers vivent longtemps. Les redirections “temporaires” de 2 semaines sont une invention de gens qui n’ont jamais géré un site avec de l’historique.

Indicateurs utiles à suivre pendant cette période :

• Dans Search Console : évolution des pages indexées, des erreurs (Not Found, Soft 404), et des signaux de duplication (canonicals divergents).
• Côté logs : proportion de crawl sur les anciennes URLs (normal au début), puis bascule progressive vers les nouvelles.
• Côté business : conversions organiques (avec annotation de la date de migration pour éviter les débats stériles).

J15-J30 : vous optimisez et vous nettoyez. C’est là qu’on traite les cas résiduels : produits supprimés (410 vs redirection vers catégorie ?), pages dupliquées, facettes qui s’indexent malgré vous, incohérences hreflang, et réécriture de liens internes (pour pointer directement vers les URL finales). C’est aussi le moment de formaliser une TMA et un MCO/MCS, parce qu’un e-commerce en PrestaShop 8 ne s’“oublie” pas après la mise en ligne : modules, patchs, compatibilités, sécurité. Si vous cherchez une approche structurée, la page TMA – Tierce Maintenance Applicative pose le cadre.

Une bonne pratique “post-migration” qui aide aussi les équipes marketing : maintenir une liste de pages sensibles (top catégories, top produits, landing pages SEA/Email, pages marque) et les contrôler régulièrement (hebdo sur le premier mois). Ça évite de découvrir à J+45 qu’une page business redirige vers une catégorie vide suite à un changement de catalogue.

Ce que vous gagnez quand le plan d’URL cross-site est bien fait (et comment en faire un projet vendable en interne)

Quand la cartographie est propre, vous transformez la migration PrestaShop 8 en opération quasi “chirurgicale” : Google transfère plus vite les signaux, les backlinks conservent leur valeur, les équipes marketing ne voient pas leurs landing pages disparaître, et vos équipes support ne passent pas 3 semaines à répondre “oui, c’est normal”. Un bon plan d’URL cross-site, c’est aussi un outil de gouvernance : il fixe les patterns, évite les exceptions, et rend les futures évolutions (nouvelle langue, nouveau catalogue, fusion de sites) moins risquées.

Le bénéfice le plus sous-estimé : la qualité des données. Une migration bien instrumentée permet de comparer avant/après sur des métriques concrètes : taux de crawl des pages money, temps moyen d’exploration, proportion d’URL paramétrées, erreurs de couverture, et, côté business, conversions organiques. Et si vous poussez un peu, vous pouvez relier vos changements à des impacts de performance. (Oui, il existe des cas où améliorer le TTFB post-migration fait remonter la vitesse de crawl et stabilise l’indexation. Ce n’est pas magique, c’est juste de l’engineering.)

Pour “vendre” le projet en interne, un angle simple (et factuel) consiste à raisonner en risque évité et en temps gagné :

• Risque évité : perte de trafic organique sur les pages qui font le CA (catégories/produits phares).
• Temps gagné : moins de tickets support “page introuvable”, moins de hotfix, moins d’allers-retours SEO/dev, moins de réunions de crise.

Mini-scenario typique (vu sur des migrations e-commerce, y compris en contexte multi-boutiques) : sans mapping fin, 1 000 anciennes URLs de produits redirigent vers une catégorie générique. Résultat : la longue traîne s’effondre, les backlinks pointent vers des pages non pertinentes, et les équipes passent un mois à “réparer” en urgence… alors qu’un plan d’URL + un lot de tests P1/P2 aurait évité le problème avant la bascule.

Enfin, si votre migration implique refonte, changement d’hébergement, ou accompagnement SEO/tech, autant l’assumer : ce sont des sujets transverses qui demandent une équipe habituée aux migrations. Pour cadrer une refonte complète, vous pouvez pointer vers Refonte de sites internet existants ; pour la brique infra e-commerce (charge, cache, résilience), la page Hébergement spécial e-Commerce est pertinente. Et si vous voulez en parler sans transformer ça en épopée, la voie la plus simple reste de passer par Contacter Les Vikings avec vos contraintes (domaines, volumétrie d’URL, multistore, international, modules critiques).