Redirections 301 et 404 après une migration : que vérifier

Ce que perd une boutique quand les adresses changent

Les moteurs de recherche, les liens externes, les favoris et les campagnes pointent vers des adresses précises. Si, après une migration ou un changement d’URL, ces adresses répondent 404, Google ne les indexe pas : selon sa documentation, les URL qui renvoient un code 4xx ne sont pas indexées et celles déjà indexées sont retirées de l’index. Une redirection permanente indique au contraire que la page existe et a été déplacée : Google l’utilise comme signal que la destination est l’URL canonique et affirme que les 301 et les autres redirections permanentes ne causent pas de perte de PageRank. La part de trafic réellement perdue dépend du site, et c’est pourquoi on la mesure avec la Search Console plutôt que de se fier à des chiffres génériques.

Les codes HTTP qui comptent

La même RFC précise que le 410 est préférable au 404 lorsque le serveur sait que la condition est probablement permanente.

Ce que fait PrestaShop 9.1 tout seul

Ce qui suit a été vérifié dans le code de PrestaShop 9.1.5, avec les fichiers cités dans les sources.

Rediriger vers l’URL canonique

Dans Paramètres de la boutique, Trafic et SEO, Configuration des URLs, l’option « Rediriger vers l’URL canonique » (PS_CANONICAL_REDIRECT) vaut 0 (aucune redirection), 1 (302) ou 2 (301). Dans le FrontController, pour les requêtes GET, si l’URL demandée ne coïncide pas avec l’URL canonique, PrestaShop répond par un 301 lorsque l’option vaut 2, par un 302 sinon, et ne fait rien avec 0. La documentation officielle recommande le 301 une fois les modifications terminées et avertit que, sans redirection, on peut avoir des URL en double. En mode développement, une page de débogage s’affiche à la place de la redirection : gardez-le à l’esprit lorsque vous testez.

Le slug d’un produit ou d’une catégorie change

Les règles par défaut mettent l’id dans l’URL ({id}{-:id_product_attribute}-{rewrite}.html pour les produits, {id}-{rewrite} pour les catégories). L’ancienne URL, avec l’ancien slug, retrouve donc encore l’objet, et le contrôleur la compare à l’URL actuelle : avec l’option sur 301, il redirige ; avec 0, les deux adresses répondent et les doublons restent.

Le schéma des URL change

Le Dispatcher part du contrôleur pagenotfound et ne le remplace que si l’URI correspond à l’une des routes actuelles, celles par défaut ou celles personnalisées (PS_ROUTE_*). Le code ne conserve pas les schémas précédents : les anciennes adresses qui ne correspondent plus à aucune route aboutissent sur une page qui répond avec un véritable statut 404. Les redirections depuis les anciens schémas doivent être créées à part.

Produit désactivé ou plus disponible

Le champ « Redirection quand le produit est désactivé » de la fiche produit (redirect_type) a dix valeurs : default, 404 et 410 (page d’erreur), 200-displayed, 404-displayed et 410-displayed (produit affiché comme hors catalogue avec ce code), 301-category et 302-category (redirection vers une catégorie), 301-product et 302-product (redirection vers un autre produit). Avec default, c’est « Comportement par défaut des produits désactivés » (PS_PRODUCT_REDIRECTION_DEFAULT) qui s’applique. Un produit supprimé n’existe plus et la page répond 404.

Catégorie désactivée ou supprimée

Une catégorie désactivée suit le champ « Redirection en cas de non-affichage » : 301 par défaut, vers la catégorie parente active la plus proche si vous n’en choisissez pas une autre, ou bien 302, 410, 404. Une catégorie supprimée répond 404, et Category::deleteRedirections() remet au comportement par défaut les produits et les catégories qui redirigeaient vers elle.

Migration depuis une autre plateforme

En changeant de plateforme, presque toutes les URL changent de forme : produits, catégories, pages, images et fichiers. PrestaShop ne peut pas deviner les anciennes adresses : il faut les collecter et en faire le mapping.

1. Collectez les anciennes URL. Google suggère de partir des sitemaps, des journaux du serveur ou de l’analytics pour les URL les plus visitées, du rapport « Liens » de la Search Console et de la liste du CMS. Le rapport « Performances » comporte la dimension « Pages » et un bouton d’exportation. Incluez les images, les vidéos, le JavaScript et le CSS.
2. Faites correspondre chaque URL. Google écrit qu’il est important de faire correspondre les URL de l’ancien site à celles du nouveau et de décider vers où chacune doit pointer : la page la plus pertinente, une à une.
3. Gérez ce qui n’a pas d’équivalent. Google demande que les contenus supprimés répondent 404 ou 410. Évitez d’envoyer de nombreuses anciennes URL vers une seule destination non pertinente, comme la page d’accueil : selon Google, cela peut dérouter les utilisateurs et être traité comme une soft 404. Si plusieurs pages ont été regroupées en une seule, c’est une destination légitime.
4. Évitez les erreurs courantes : chaînes de redirections (Googlebot en suit jusqu’à 10, mais Google conseille de pointer vers la destination finale et, si ce n’est pas possible, de rester idéalement à 3 étapes au plus et en tout cas sous les 5) ; boucles ; 302 au lieu de 301 ; liens internes, balises canonical, hreflang et sitemaps restés sur les anciennes URL ; redirections vers des URL qui n’existent pas ; noindex ou blocages robots.txt de la phase de développement restés actifs ; redirections retirées trop tôt.

Ce qu’il faut vérifier dans la Search Console

• Rapport « Indexation des pages » : « Introuvable (404) », « Erreur “soft 404” », « Page avec redirection » et « Erreur liée à des redirections » (chaîne trop longue, boucle, URL trop longue ou non valide). Le rapport lui-même indique qu’une 404 n’est pas forcément un problème si la page a été supprimée sans remplacement, et qu’il faut utiliser une 301 si elle a été déplacée.
• « Inspection d’URL » : le test sur l’URL publiée suit les redirections, mais n’indique pas en avoir suivi une et n’affiche pas l’URL finale. Pour voir les codes et la chaîne, il faut un outil en ligne de commande ou un script.
• Sitemap : envoyez celui qui contient les nouvelles URL. Celui qui contient les anciennes peut afficher des avertissements sur les redirections, et c’est normal.
• « Changement d’adresse » : il ne sert que pour passer d’un domaine ou sous-domaine à un autre, pas pour HTTP vers HTTPS, www ou non-www, ni pour des chemins d’un même domaine.
• Délais : pour un site de taille petite ou moyenne, Google indique quelques semaines pour la plupart des pages, avec des fluctuations temporaires de la visibilité.

Liste de contrôle

1. Liste des anciennes URL avec visites et liens, à partir des sitemaps, des journaux et de la Search Console.
2. Mapping une à une ; 404 ou 410 pour ce qui n’a pas d’équivalent.
3. 301 côté serveur pour les contenus déplacés, 302 seulement si c’est temporaire.
4. Aucune chaîne : chaque ancienne URL pointe vers la destination finale, vérifié par un script sur toute la liste.
5. Liens internes, balises canonical, hreflang et sitemaps sur les nouvelles URL.
6. « Rediriger vers l’URL canonique » sur 301 lorsque la boutique est en ligne.
7. Suivi des 404 et du rapport « Indexation des pages » dans les semaines après la migration ; redirections conservées le plus longtemps possible, en général au moins un an.

Comment le module Redirections SEO - Gestion 301/302/404 (SEO Redirects) s’y prend

• Règles 301, 302 et 410 avec chemin simple, wildcard (* et ?) ou regex validée, et options sur la query string (l’ignorer, comparer l’URL complète ou exiger un paramètre). Le 410 répond avec un véritable statut 410 et X-Robots-Tag: noindex, avant le chargement du thème.
• La redirection se déclenche dans le hook actionDispatcher, avant la construction de la page : les règles simples se trouvent par une recherche indexée sur le hash du chemin, les wildcards et les regex sont évaluées dans l’ordre.
• Le moniteur 404 enregistre les URL manquantes avec le nombre de requêtes, le dernier accès, le referer et le user agent (jusqu’à 5 000 URL distinctes, modifiable) ; « Créer une 301 » préremplit la règle.
• Crée une 301 lorsque le slug d’un produit, d’une catégorie ou d’une page CMS change, pour chaque langue, si aucune règle ne couvre déjà cette URL.
• Importe et exporte des CSV (colonnes source, target, type, is_regex, keep_querystring, qs_mode, qs_param, qs_value, active), avec le décompte des lignes importées et ignorées : pratique pour charger le mapping d’une migration.
• Refuse les destinations externes qui ne sont pas sur la boutique ou dans une liste d’hôtes autorisés (protection contre l’open redirect).

Voir la fiche du module ou lire le guide d’installation et de configuration.

Sources

• RFC 9110, HTTP Semantics : sections 15.4.2, 15.4.3, 15.4.9, 15.5.5 et 15.5.11
• Google Search Central : Redirections et recherche Google, migration de site avec changement d’URL, codes d’état HTTP
• Aide de la Search Console : Indexation des pages, Inspection d’URL, Changement d’adresse, Performances
• Code de PrestaShop 9.1.5 sur GitHub : FrontController, ProductController, CategoryController, Dispatcher
• Documentation de PrestaShop : SEO et URL, gestion des produits

Questions fréquentes

301 ou 302 pour une migration ?

301 (ou 308) pour les contenus déplacés de façon définitive : Google l’utilise comme un signal fort, alors que le 302 est un signal faible. Sa documentation recommande les redirections permanentes lorsque l’on est sûr qu’elles ne seront pas annulées.

Faut-il rediriger toutes les anciennes URL vers la page d’accueil ?

Non. Google déconseille d’envoyer de nombreuses anciennes URL vers une destination unique non pertinente : cela peut dérouter les utilisateurs et être traité comme une soft 404. Mieux vaut la page la plus pertinente, ou une 404 ou 410 s’il n’y a pas d’équivalent.

Pendant combien de temps faut-il conserver les redirections ?

Google indique de les conserver le plus longtemps possible, en général au moins un an, afin que les signaux soient transmis aux nouvelles URL et que les liens externes soient réattribués.

PrestaShop redirige-t-il tout seul l’ancienne URL lorsque le slug change ?

Oui, si l’id figure dans l’URL et que « Rediriger vers l’URL canonique » est sur 301 (avec 302 la redirection est temporaire, avec 0 il n’y a pas de redirection). Ce n’est pas le cas si le schéma des URL change : les anciennes adresses qui ne correspondent plus à aucune route renvoient une 404.

404 ou 410 pour les pages supprimées ?

La norme préfère le 410 lorsque la suppression est probablement définitive. Pour Google, les deux codes sont traités de la même façon, comme tous les 4xx sauf le 429.

Le module suffit-il à lui seul ?

Non. Le module gère les règles, le moniteur 404, le CSV et les 301 automatiques, mais le mapping doit être préparé par vous. Il ne contrôle pas les chaînes et les boucles entre les règles et ne corrige pas les liens internes, les balises canonical, les hreflang et les sitemaps : ils restent à vérifier avec un script et avec la Search Console.