Configurer les redirections 301 dans PrestaShop après une migration

Comprendre les redirections et pourquoi la 301 est le seul choix correct

Lorsque vous migrez une boutique PrestaShop, les URL changent. Les produits qui se trouvaient à une adresse se retrouvent à une autre. Les catégories qui avaient un slug en ont désormais un différent. Sans redirections, chaque ancienne URL devient une impasse, retournant une erreur 404 aux visiteurs comme aux moteurs de recherche. L'effet cumulé est dévastateur : perte de trafic, perte de positionnement et perte de ventes.

Une redirection est une instruction de votre serveur qui indique aux navigateurs et aux robots d'exploration des moteurs de recherche qu'une page a été déplacée. Lorsqu'un visiteur ou Googlebot demande l'ancienne URL, le serveur répond avec le nouvel emplacement, et le client le suit automatiquement. Mais toutes les redirections ne se valent pas, et utiliser le mauvais type peut compromettre l'ensemble de votre migration.

301 vs 302 : une distinction cruciale

Une redirection 301 signale un déplacement permanent. Elle indique aux moteurs de recherche de transférer l'équité de liens accumulée (la valeur SEO construite grâce aux backlinks, à la qualité du contenu et à l'engagement des utilisateurs) de l'ancienne URL vers la nouvelle. Avec le temps, Google remplace l'ancienne URL dans son index par la nouvelle. C'est exactement ce que vous souhaitez après une migration.

Une redirection 302 signale un déplacement temporaire. Elle indique aux moteurs de recherche que l'ancienne URL reviendra à terme, ils doivent donc conserver l'ancienne URL dans l'index et ne pas transférer l'équité de liens. Utiliser des redirections 302 après une migration permanente signifie que Google continue d'essayer d'indexer vos anciennes URL, que vos nouvelles URL peinent à acquérir de l'autorité, et que vous perdez du positionnement inutilement.

Il existe également la redirection 307, qui est l'équivalent HTTP/1.1 de la 302, et la redirection 308, qui est l'équivalent HTTP/1.1 de la 301. Pour les besoins du SEO PrestaShop, la 301 est le choix standard et universellement pris en charge.

La règle est simple : si la page a été déplacée de manière permanente, utilisez une 301. Après une migration, la page a été déplacée de manière permanente. Utilisez toujours une 301.

Configurer les redirections dans .htaccess (Apache)

La plupart des installations PrestaShop fonctionnent sur Apache, et le fichier .htaccess est l'endroit où vous configurez les redirections. Ce fichier se trouve dans le répertoire racine de votre PrestaShop, à côté de index.php.

Le placement est important

Le fichier .htaccess de PrestaShop contient des règles de réécriture qui gèrent les URL simplifiées, forcent le HTTPS et routent les requêtes vers les bons contrôleurs. Vos règles de redirection doivent être placées avant les règles de réécriture de PrestaShop. Si vous les placez après, les règles de PrestaShop peuvent intercepter la requête en premier et vos redirections ne s'exécuteront jamais.

Recherchez la ligne de commentaire qui indique # Dispatcher ou le bloc commençant par RewriteRule ^api. Vos redirections personnalisées vont au-dessus de cette section, mais après RewriteEngine On.

Redirections de pages individuelles

La forme la plus simple de redirection fait correspondre une ancienne URL spécifique à une nouvelle URL spécifique :

Redirect 301 /ancienne-categorie/ancien-produit.html https://www.exemple.com/nouvelle-categorie/nouveau-produit

La directive Redirect fait partie du module mod_alias d'Apache. Le premier argument est le code de statut HTTP (301), le deuxième est l'ancien chemin (relatif à la racine du document), et le troisième est la nouvelle URL complète.

Détails importants : l'ancien chemin doit commencer par une barre oblique et ne doit pas inclure le nom de domaine. La nouvelle URL doit être une URL complète incluant le protocole et le domaine. L'ancien chemin est mis en correspondance exactement, y compris les barres obliques finales et les extensions de fichiers.

Redirections basées sur des modèles avec RewriteRule

Lorsque de nombreuses URL suivent un changement de modèle prévisible, les redirections individuelles deviennent impraticables. Le module mod_rewrite d'Apache vous permet d'écrire des règles basées sur des modèles utilisant des expressions régulières :

RewriteEngine On
RewriteRule ^ancienne-categorie/(.*)$ /nouvelle-categorie/$1 [R=301,L]

Cette règle capture tout ce qui se trouve après ancienne-categorie/ et l'ajoute à nouvelle-categorie/. Le $1 est une référence arrière vers le premier groupe capturé (la partie entre parenthèses). Les drapeaux [R=301,L] spécifient une redirection 301 et que c'est la dernière règle à traiter si elle correspond.

Scénarios courants de redirections basées sur des modèles pour les migrations PrestaShop :

Supprimer les extensions .html :

RewriteRule ^(.+)\.html$ /$1 [R=301,L]

Passer d'URL de catégories basées sur l'ID à des URL basées sur le nom :

RewriteRule ^3-ancien-nom-de-categorie(.*)$ /nouveau-nom-de-categorie$1 [R=301,L]

Rediriger un sous-répertoire entier :

RewriteRule ^boutique/(.*)$ /$1 [R=301,L]

Redirections conditionnelles

Parfois, vous avez besoin de redirections qui ne s'appliquent que sous certaines conditions. RewriteCond offre cette possibilité :

RewriteCond %{HTTP_HOST} ^anciendomaine\.com$ [NC]
RewriteRule ^(.*)$ https://www.nouveaudomaine.com/$1 [R=301,L]

Cela redirige toutes les requêtes de anciendomaine.com vers nouveaudomaine.com, en préservant le chemin. Le drapeau [NC] rend la condition insensible à la casse.

Pour rediriger uniquement si le fichier demandé n'existe pas sur le nouveau serveur (utile lors d'une migration progressive) :

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ancien-chemin/(.*)$ /nouveau-chemin/$1 [R=301,L]

Configurer les redirections dans Nginx

Si votre PrestaShop fonctionne sur Nginx, les redirections sont configurées dans le fichier de configuration du bloc serveur, généralement situé à /etc/nginx/sites-available/votredomaine.conf ou /etc/nginx/conf.d/votredomaine.conf.

Redirections individuelles

location = /ancienne-categorie/ancien-produit.html {
  return 301 https://www.exemple.com/nouvelle-categorie/nouveau-produit;
}

Le modificateur = spécifie une correspondance exacte. Sans lui, Nginx traite l'emplacement comme une correspondance par préfixe, ce qui pourrait rediriger plus d'URL que prévu.

Redirections basées sur des modèles

location ~ ^/ancienne-categorie/(.*)$ {
  return 301 /nouvelle-categorie/$1;
}

Le modificateur ~ active la correspondance par expression régulière. Le groupe capturé $1 fonctionne de la même manière que dans Apache.

Redirections basées sur map pour les grandes listes

La directive map de Nginx est idéale pour gérer des centaines ou des milliers de redirections individuelles sans encombrer le bloc serveur :

map $request_uri $redirect_target {
  /ancien-produit-1.html /nouveau-produit-1;
  /ancien-produit-2.html /nouveau-produit-2;
  /ancien-produit-3.html /nouveau-produit-3;
}

server {
  if ($redirect_target) {
    return 301 $redirect_target;
  }
}

Le bloc map n'est évalué qu'une seule fois par requête et reste très performant même avec des milliers d'entrées. Vous pouvez même charger le map depuis un fichier externe en utilisant la directive include.

N'oubliez pas de tester votre configuration avec nginx -t et de recharger avec systemctl reload nginx après toute modification.

Redirections en masse avec CSV

Pour les migrations impliquant des milliers de produits, écrire manuellement des règles de redirection n'est pas réalisable. Une approche basée sur un CSV simplifie le processus.

Créer le CSV

Exportez vos anciennes URL à partir de vos données d'exploration pré-migration ou de votre base de données. Exportez vos nouvelles URL depuis la nouvelle installation. Faites-les correspondre dans un tableur avec deux colonnes : ancien chemin d'URL et nouveau chemin d'URL. Enregistrez au format CSV.

Votre CSV pourrait ressembler à ceci :

/3-ancienne-categorie,/nouvelle-categorie
/ancienne-categorie/ancien-produit-1.html,/nouvelle-categorie/nouveau-produit-1
/ancienne-categorie/ancien-produit-2.html,/nouvelle-categorie/nouveau-produit-2
/content/5-a-propos,/content/a-propos

Convertir le CSV en règles .htaccess

Une approche simple consiste à convertir chaque ligne du CSV en une directive Redirect. En utilisant un éditeur de texte avec rechercher-remplacer ou un simple outil en ligne de commande :

awk -F',' '{print "Redirect 301 " $1 " https://www.exemple.com" $2}' redirections.csv >> .htaccess

Cela lit le fichier CSV, divise chaque ligne par la virgule et génère une directive Redirect pour chaque ligne.

Utiliser une table de base de données

Pour de très grandes listes de redirections (plus de 10 000 entrées), envisagez de stocker les redirections dans une table de base de données et de les gérer au niveau applicatif. Créez une table avec des colonnes pour l'ancien chemin et le nouveau chemin, et écrivez un petit module PrestaShop ou un override qui intercepte les erreurs 404, vérifie la table et retourne une redirection 301 si une correspondance est trouvée. Cette approche est plus facile à gérer via une interface d'administration mais ajoute une petite requête de base de données à chaque réponse 404.

Solutions de redirection par module

Plusieurs modules PrestaShop fournissent une gestion des redirections via le back-office, éliminant le besoin de modifier directement les fichiers de configuration du serveur.

Avantages des redirections par module

Un module de redirection offre une interface conviviale pour ajouter, modifier et supprimer des redirections. Il inclut généralement une fonctionnalité d'import/export pour les opérations en masse, un journal pour suivre quelles redirections sont utilisées, et la possibilité pour les membres non techniques de l'équipe de gérer les redirections sans accès au serveur.

Comment fonctionnent les redirections par module

La plupart des modules de redirection fonctionnent en s'accrochant au processus de traitement des requêtes de PrestaShop. Lorsqu'une requête arrive et qui résulterait normalement en une erreur 404, le module l'intercepte, vérifie sa base de données de redirections pour une ancienne URL correspondante, et si elle est trouvée, envoie une réponse de redirection 301 vers la nouvelle URL.

Certains modules vont plus loin en créant automatiquement des redirections lorsque vous modifiez l'URL simplifiée d'un produit dans le back-office. Cela évite le problème courant de casser les anciens liens lorsque vous optimisez vos slugs d'URL.

Considérations de performance

Les redirections par module ajoutent un léger surcoût à chaque requête 404 car elles doivent interroger la base de données. Pour la plupart des boutiques, c'est négligeable, mais si vous avez des milliers de redirections et un trafic bot significatif qui sollicite les anciennes URL, les requêtes de base de données peuvent s'accumuler. Envisagez d'utiliser une couche de mise en cache ou de déplacer les redirections les plus utilisées vers le .htaccess pour une performance optimale.

Redirections regex : puissance et danger

Les redirections par expressions régulières sont des outils puissants capables de gérer des transformations d'URL complexes avec une seule règle. Elles sont aussi la source la plus courante d'erreurs de redirection et de boucles infinies.

Quand utiliser les redirections regex

Utilisez les redirections regex lorsque le changement d'URL suit un modèle cohérent et prévisible. Les bons candidats incluent : supprimer ou ajouter des extensions de fichiers sur toutes les URL, changer un préfixe d'URL pour une section entière du site, supprimer ou ajouter des préfixes de langue, et supprimer des paramètres de requête.

Modèles regex courants pour PrestaShop

Supprimer le préfixe d'ID de catégorie que PrestaShop 1.6 ajoute aux URL de catégories :

RewriteRule ^([0-9]+)-(.+)$ /$2 [R=301,L]

Cela correspond aux URL comme /3-chaussures et redirige vers /chaussures.

Ajouter un préfixe de langue :

RewriteCond %{REQUEST_URI} !^/(en|de|fr)/
RewriteRule ^(.+)$ /en/$1 [R=301,L]

Supprimer les doubles barres obliques :

RewriteRule ^(.*)//(.*)$ /$1/$2 [R=301,L]

Tester les règles regex en toute sécurité

Avant de déployer des redirections regex en production, testez-les minutieusement. Utilisez un testeur d'expressions régulières en ligne (comme regex101.com) pour vérifier que votre modèle correspond aux URL que vous visez et ne correspond pas à celles qu'il ne devrait pas.

Commencez avec une redirection 302 pendant les tests. Cela empêche les moteurs de recherche de mettre en cache des redirections incorrectes. Une fois que vous avez vérifié que la règle fonctionne correctement, changez-la en 301.

Testez les cas limites : les URL avec des paramètres de requête, les URL avec des caractères spéciaux, les URL avec plusieurs modèles correspondants. Chacun de ces cas peut révéler des problèmes qui ne sont pas évidents avec des URL de test simples.

Tester les redirections

Déployer des redirections sans tests approfondis est une recette pour le désastre. Voici les méthodes que vous devez utiliser pour vérifier vos redirections avant et après la mise en production.

Tests en ligne de commande avec curl

La commande curl est le moyen le plus fiable de tester les redirections car elle vous montre exactement ce que le serveur retourne :

curl -I https://www.exemple.com/ancien-produit.html

Le drapeau -I demande uniquement les en-têtes. Dans la réponse, recherchez :

HTTP/1.1 301 Moved Permanently
Location: https://www.exemple.com/nouveau-produit

Vérifiez que le code de statut est 301 (et non 302) et que l'en-tête Location pointe vers la bonne nouvelle URL.

Pour suivre la chaîne de redirections et voir chaque étape :

curl -IL https://www.exemple.com/ancien-produit.html

Le drapeau -L indique à curl de suivre les redirections, vous montrant les en-têtes à chaque étape.

Tests en masse

Pour les grandes listes de redirections, automatisez les tests avec une boucle :

while IFS=, read -r old new; do
  status=$(curl -s -o /dev/null -w "%{http_code}" "https://www.exemple.com$old")
  echo "$old -> $status"
done < redirections.csv

Cela lit votre fichier CSV, teste chaque ancienne URL et affiche le code de statut HTTP. Toute URL qui ne retourne pas 301 nécessite votre attention.

Tests dans le navigateur

Ouvrez les outils de développement de votre navigateur (F12), allez dans l'onglet Réseau et naviguez vers une ancienne URL. L'onglet Réseau affiche la chaîne de requêtes, y compris toutes les redirections. Vérifiez le code de statut, la cible de la redirection et la page finale qui se charge.

Inspection via Google Search Console

Après le déploiement, utilisez l'outil d'inspection d'URL dans Google Search Console pour vérifier comment Google voit vos URL redirigées. Entrez une ancienne URL et voyez si Google reconnaît la redirection et a découvert la nouvelle URL.

Les chaînes de redirections et comment les éviter

Une chaîne de redirections se produit lorsqu'une redirection mène à une autre redirection, qui peut mener à encore une autre. Par exemple : l'URL A redirige vers l'URL B, qui redirige vers l'URL C, qui sert finalement le contenu. Chaque saut ajoute de la latence et dilue l'équité de liens.

Pourquoi les chaînes de redirections sont nuisibles

Google a déclaré qu'il suivrait les chaînes de redirections, mais avec des limites. Après un certain nombre de sauts (généralement 5 à 10), Googlebot abandonne et traite l'URL comme une erreur. Même pour les chaînes plus courtes, chaque saut retarde la livraison de la page et perd une petite quantité d'équité de liens.

Pour les visiteurs, chaque redirection ajoute 50 à 200 millisecondes de latence, selon les conditions réseau et le temps de réponse du serveur. Une chaîne de 3 redirections peut ajouter une demi-seconde ou plus au temps de chargement perçu.

Causes courantes des chaînes de redirections dans PrestaShop

La chaîne la plus courante se produit lorsqu'une migration ajoute des redirections par-dessus des redirections existantes. Par exemple, vous pourriez avoir d'anciennes redirections d'un précédent changement de structure d'URL, et la nouvelle migration ajoute une couche supplémentaire. L'URL A redirige vers l'URL B (de la première migration), et l'URL B redirige vers l'URL C (de la deuxième migration).

Une autre cause courante est l'interaction entre la redirection canonique intégrée de PrestaShop et vos redirections personnalisées. PrestaShop peut rediriger d'une URL non canonique vers la version canonique, et si votre redirection personnalisée correspond également, vous obtenez une chaîne.

Le forçage du HTTPS ajoute un autre saut potentiel. Si votre redirection pointe vers une URL HTTP et que le serveur redirige ensuite vers HTTPS, c'est une chaîne en deux étapes.

Corriger les chaînes de redirections

Auditez régulièrement vos redirections à l'aide d'un outil d'exploration qui détecte les chaînes. Lorsque vous trouvez une chaîne, mettez à jour la première redirection pour pointer directement vers la destination finale. L'URL A devrait rediriger directement vers l'URL C, en contournant l'URL B entièrement.

Lorsque vous ajoutez de nouvelles redirections lors d'une migration, vérifiez toujours si l'URL cible est elle-même une redirection. Si c'est le cas, configurez la nouvelle redirection pour pointer vers la destination finale plutôt que vers l'URL intermédiaire.

Pièges courants et comment les éviter

Boucles de redirections infinies

Une boucle infinie se produit lorsque l'URL A redirige vers l'URL B et que l'URL B redirige vers l'URL A. Le navigateur détecte cela et affiche une erreur ERR_TOO_MANY_REDIRECTS. Les causes courantes incluent des règles contradictoires dans le .htaccess (une règle redirige www vers non-www tandis qu'une autre redirige non-www vers www), des redirections contradictoires entre le .htaccess et un module de redirection, et des règles regex trop larges qui correspondent à leurs propres URL cibles.

Pour corriger une boucle, commencez par désactiver toutes les redirections personnalisées et réactivez-les une par une jusqu'à ce que la boucle réapparaisse. Cela identifie la règle en conflit.

Oublier les paramètres de requête

Par défaut, la directive Redirect d'Apache transmet les paramètres de requête à la nouvelle URL. Cependant, RewriteRule ne transmet pas les paramètres de requête à moins d'ajouter le drapeau [QSA] (Query String Append). Si vos anciennes URL incluent des paramètres de requête importants (comme ?id_product=123), assurez-vous qu'ils sont gérés correctement.

Sensibilité à la casse

Sur les serveurs Linux, les URL sont sensibles à la casse. /Produit.html et /produit.html sont des URL différentes. Si votre ancien site avait des URL en casse mixte et que votre nouveau site normalise en minuscules, vous avez besoin de redirections qui gèrent les deux cas. Utilisez le drapeau [NC] dans RewriteRule pour une correspondance insensible à la casse.

Ne pas rediriger toutes les variantes d'URL

Une seule page produit peut être accessible via plusieurs URL : avec et sans barre oblique finale, avec et sans extension .html, avec et sans le préfixe du chemin de catégorie, avec et sans www. Chaque variante qui a été indexée a besoin de sa propre redirection vers la nouvelle URL canonique.

Laisser les redirections en place indéfiniment

Bien que les redirections doivent rester en place pendant au moins 12 mois après une migration (Google recommande au moins un an), elles ne doivent pas rester indéfiniment. Après un an ou plus, les anciennes URL ne devraient plus apparaître dans les résultats de recherche ni recevoir de trafic significatif. Auditez vos journaux de redirections, supprimez les règles qui ne sont plus déclenchées et gardez votre configuration propre.

Résumé

La mise en place correcte des redirections 301 est la tâche technique la plus importante d'une migration PrestaShop. Chaque ancienne URL qui avait du trafic, des backlinks ou une visibilité dans les moteurs de recherche doit rediriger vers son équivalent avec un code de statut 301. La méthode d'implémentation dépend de votre serveur (Apache .htaccess ou configuration Nginx), du nombre d'URL (règles individuelles, modèles regex ou modules adossés à une base de données) et des capacités techniques de votre équipe. Testez chaque redirection avant la mise en production à l'aide de curl ou des outils de développement du navigateur. Surveillez les chaînes de redirections, les boucles infinies et les problèmes de sensibilité à la casse. Suivez Google Search Console après le déploiement pour vérifier que Google traite correctement vos redirections. Et rappelez-vous qu'une 302 là où une 301 devrait être n'est jamais inoffensive. C'est toujours le mauvais choix pour une migration permanente.