Comment gérer les anciennes URL après une refonte PrestaShop ?

Une refonte PrestaShop qui change la structure des URL peut faire perdre 30 à 60 % du trafic organique en quelques semaines si les anciennes adresses ne sont pas correctement prises en charge. Poser des redirections 301 est la partie visible du travail. Il existe une étape technique, propre à PrestaShop, que la quasi-totalité des guides de migration oublient de mentionner, et qui peut annuler l’effet de redirections pourtant bien configurées. Ce guide complète notre article sur les URL canoniques PrestaShop côté gestion du changement plutôt que consolidation des signaux.

Avant la refonte : cartographier ce qui va changer

La redirection ne se pose pas dans l’urgence, après coup. Avant toute modification de structure, exportez la liste complète des URL actuellement indexées (Search Console, complétée par un crawl Screaming Frog ou Sitebulb pour ne pas dépendre uniquement de l’échantillon partiel remonté par Google) et notez, pour chaque URL, la page de destination prévue après refonte.

Trois types de changements déclenchent systématiquement un besoin de redirection sur PrestaShop : la modification de la structure d’URL (activation ou reparamétrage des URL simplifiées), un changement de domaine, et le passage HTTP vers HTTPS. Notre guide de configuration des URL simplifiées PrestaShop détaille le premier cas plus en profondeur si c’est votre situation.

Notez aussi les positions actuelles sur vos requêtes stratégiques avant de démarrer : c’est le seul moyen de mesurer objectivement l’impact réel de la migration une fois en ligne, plutôt que de se fier à une impression générale.

Les trois méthodes pour poser une redirection 301

Sur une refonte qui touche l’ensemble d’un catalogue, le module d’import CSV reste la seule méthode réaliste : il valide le format à l’import et évite la manipulation directe du fichier serveur, terrain le plus propice à casser le site entier pour une virgule mal placée.

L’étape que les guides de migration oublient

PrestaShop génère son fichier .htaccess UNE FOIS, au moment de l’activation des URL conviviales (Préférences puis SEO & URLs). Ce fichier ne se met pas à jour automatiquement à chaque changement de structure ou à chaque nouvelle règle de réécriture ajoutée par un module. Résultat : après une refonte qui modifie la structure d’URL du site, une partie des nouvelles routes peut rester invisible, ou renvoyer une 404, même si les redirections sont correctement posées en back-office ou via un module.

La régénération se fait par un aller-retour volontairement contre-intuitif : dans Préférences puis SEO & URLs, désactivez l’option Réécriture d’URL (Friendly URL) et enregistrez, puis réactivez-la et enregistrez de nouveau. Sur une installation multi-boutiques, le même effet s’obtient en désactivant puis réactivant l’option Multistore. Dans les deux cas, complétez par un vidage du cache PrestaShop (Paramètres avancés puis Performance) : le cache de template peut continuer à servir une version figée des routes même après régénération du fichier serveur.

Ce point ne figure dans aucun des guides de redirection généralistes consultés : ils détaillent comment poser une règle, jamais pourquoi une règle pourtant bien posée peut sembler ne produire aucun effet.

Après la refonte : la checklist de vérification

1. Tester un échantillon de redirections en navigation privéeAvant toute communication de mise en ligne, vérifiez manuellement une vingtaine d’anciennes URL réparties sur tout le catalogue (produits, catégories, pages CMS, blog).
2. Surveiller le rapport d’erreurs 404 de Search ConsoleDans les 48 premières heures, puis en suivi hebdomadaire pendant 2 à 4 semaines, le temps que Google réexplore l’ensemble du site restructuré.
3. Vérifier que les canonicals pointent vers les nouvelles URLUne balise canonical qui pointe encore vers une ancienne structure d’URL, même redirigée, sème la confusion sur la version de référence à indexer.
4. Mettre à jour et resoumettre le sitemap XMLUn sitemap qui liste encore d’anciennes URL après une refonte ralentit la découverte des nouvelles routes par Googlebot.
5. Comparer les positions sur les requêtes stratégiquesSur 2 à 4 semaines de recul, pas sur les premiers jours, naturellement bruités le temps que Google stabilise sa lecture du nouveau site.

Les erreurs qui aggravent une migration

Quatre erreurs reviennent, par ordre de fréquence constatée sur des refontes PrestaShop mal préparées.

Rediriger tout vers la page d’accueil

C’est la solution de facilité qui coûte le plus cher : rediriger une ancienne fiche produit vers la page d’accueil plutôt que vers son équivalent réel dilue le signal d’autorité au lieu de le transférer, et perd l’internaute qui cherchait un produit précis.

Oublier les pages qui portent des backlinks externes

Une page de contenu ou une fiche produit historique, oubliée dans la liste des redirections parce qu’elle ne génère plus beaucoup de trafic interne, peut porter des liens externes accumulés depuis des années. Perdre cette redirection détruit une autorité qu’aucun contenu neuf ne remplace en quelques mois.

Modifier simultanément les URL et le contenu

Changer la structure d’URL ET réécrire en profondeur le contenu des pages au même moment complique tout diagnostic ultérieur : impossible de savoir, en cas de baisse, si la cause est la restructuration d’URL ou le nouveau contenu. Séparez les deux chantiers dans le temps quand c’est possible.

Sauter l’environnement de test

Tester la restructuration complète en préproduction avant la mise en production reste la seule façon de repérer les redirections manquantes et les régénérations de cache oubliées avant qu’elles n’affectent le trafic réel. Pour une refonte de grande ampleur, un accompagnement migration SEO PrestaShop permet de sécuriser cette étape avec un plan de recette formalisé plutôt qu’une vérification informelle de dernière minute.

Questions fréquentes

Une redirection posée ne suffit pas, il faut qu’elle serve

La partie visible d’une migration réussie, ce sont les redirections. La partie qui détermine si elles servent réellement à quelque chose, c’est la régénération du fichier de réécriture et le vidage du cache qui suivent. Une refonte PrestaShop qui saute cette étape peut afficher un plan de redirections irréprochable sur le papier, et une majorité de 404 bien réelles pour Googlebot.