URL PrestaShop, URL canoniques et redirections

Ce que nous ferions

Nous définirions la nature de l'intervention avant de choisir les outils : correction de la politique d'URL actuelle, nouveau besoin de routage ou déplacement de la boutique elle-même. La bonne approche dépend de votre boutique existante : schémas configurés, modules, thème, données du catalogue, intégrations, langues et marchés, et responsables de la maintenance des redirections après l'intervention. Incluez dans cette évaluation les liens générés par le thème et les modules, les slugs importés et les points d'accès des intégrations.

Effectuez le changement convenu sur une copie de préproduction protégée avec les mêmes composants de routage et des données de catalogue représentatives. Isolez la copie des e-mails clients réels, des paiements et des exports de stocks ou vers l'ERP. Répétez les correspondances de routes et les parcours d'achat, puis planifiez la bascule en production avec un responsable nommé, une configuration sauvegardée et un moyen d'annuler le changement. Conservez ensemble les correspondances approuvées et les résultats de test pour que la mise en production utilise les règles réellement testées.

Pour faire examiner les preuves et les priorités avant la mise en œuvre, le service PrestaShop SEO Audit & Action Plan fournit une analyse en lecture seule et un plan de correction ordonné ; la mise en œuvre est distincte.

Comprendre les URL natives avant de les modifier

Inspectez les routes réelles de la boutique avant de prévoir une restructuration. Sur les versions modernes, utilisez Paramètres de la boutique > Trafic et SEO. Dans PrestaShop 1.6, utilisez Préférences > SEO et URL.

• URL simplifiée : PS_REWRITING_SETTINGS active des routes lisibles. Apache nécessite une configuration de réécriture fonctionnelle ; Nginx nécessite ses propres règles serveur correspondantes.
• URL accentuées : PS_ALLOW_ACCENTED_CHARS_URL contrôle les slugs accentués. Choisissez une politique cohérente de caractères et testez l’encodage plutôt que de supposer que les URL non ASCII sont invalides.
• Redirection canonique : PS_CANONICAL_REDIRECT contrôle la redirection native vers les URL préférées pour les pages prises en charge. Testez la réponse réelle, pas seulement le paramètre.

Les routes natives de produits, catégories et CMS utilisent des identifiants. Les schémas produits de PrestaShop 1.7/8 peuvent contenir des informations de catégorie. La règle produit par défaut de PrestaShop 9 est {id}{-:id_product_attribute}-{rewrite}.html, sans catégorie. Les boutiques mises à niveau peuvent conserver les schémas configurés.

Affecter un produit à deux catégories ne signifie pas que les liens natifs utilisent automatiquement chacune d’elles. Des requêtes avec d’autres chemins de catégorie peuvent aboutir, tandis que la génération normale de liens et la redirection canonique les consolident. Auditez les liens générés, les balises HTML canoniques et les réponses HTTP avant de changer la structure.

Conserver un identifiant est un choix de conception valide. Si vous avez besoin d’un schéma sans identifiant comme /blue-wallet, il faut un routage qui le résolve. Supprimer simplement {id} ou rediriger vers un chemin plus joli n’implémente pas cette route.

Modifiez une structure fonctionnelle pour résoudre un problème défini, comme un routage défectueux ou des liens incohérents persistants. Ne supposez pas que retirer identifiants, extensions ou composante de catégorie améliore en soi le classement.

Auditer les slugs, langues, boutiques et conflits de routes

Les valeurs link_rewrite se trouvent dans les tables de langue comme product_lang, category_lang et cms_lang. Elles peuvent aussi être propres à une boutique. Un audit des slugs doit préserver les contextes de langue et de boutique.

Cet exemple en lecture seule cherche les slugs produits répétés dans la boutique 1 et la langue 1. Remplacez le préfixe et le périmètre selon vos besoins.

SELECT id_shop, id_lang, link_rewrite,
       COUNT(DISTINCT id_product) AS distinct_products
FROM ps_product_lang
WHERE id_shop = 1 AND id_lang = 1
GROUP BY id_shop, id_lang, link_rewrite
HAVING COUNT(DISTINCT id_product) > 1
ORDER BY distinct_products DESC, link_rewrite;

Un slug répété n’est pas nécessairement un conflit sur les routes natives fondées sur les identifiants. Avec un résolveur sans identifiant, vérifiez le chemin généré complet parmi produits, catégories, CMS, marques, fournisseurs et routes de modules. Deux types d’entités différents peuvent revendiquer le même chemin même si chaque table n’a aucun doublon interne.

Testez la politique de résolution des conflits choisie et tout suffixe ajouté. Un gestionnaire d’URL lisibles peut ajouter un identifiant, un compteur, une référence ou un autre élément distinctif. Ne promettez jamais que toutes les URL obtenues seront sans chiffres.

Gardez un inventaire des routes pour chaque langue et boutique publiée. Examinez slugs vides, encodages alternatifs, casse, suffixes/barres finales, préfixes linguistiques et tout sous-répertoire d’installation.

Aligner URL canoniques, domaines et paramètres

Choisissez un hôte et une forme HTTPS privilégiés. Une fois HTTPS opérationnel avec un certificat valide, vérifiez les réglages « Activer le SSL » et « Activer le SSL sur tout le site » de PrestaShop, y compris pour les requêtes passant par un CDN ou un proxy. Testez ensemble les variantes du domaine avec et sans www et les variantes HTTP/HTTPS, y compris via le CDN. Utilisez votre hôte configuré et fiable comme destination de redirection pour éviter les boucles ou les comportements liés à un en-tête Host non fiable.

Réglez la redirection canonique native sur un déplacement permanent si approprié, puis testez les requêtes produit et catégorie. Dans PrestaShop 1.7.8 et 9, PS_CANONICAL_REDIRECT utilise 0 pour aucune redirection, 1 pour une 302 temporaire et 2 pour une 301 permanente. La redirection canonique du cœur s’applique aux requêtes GET : vérifiez donc une vraie réponse GET. Une balise canonique est un signal de préférence ; elle n’empêche pas les visiteurs d’ouvrir une autre URL.

• Générez les liens internes dans le format préféré.
• Utilisez une URL canonique appropriée pour les variantes équivalentes à paramètres de suivi.
• Vérifiez pagination et pages filtrées selon leur contenu réel et leur politique d’indexation.
• Gardez les variantes linguistiques dirigées vers leurs propres URL correctes et indexables.
• N'attribuez pas la même URL canonique à des pages réellement différentes au seul motif que leurs adresses se ressemblent.

N’appliquez pas une règle globale de suppression des barres finales aux fichiers, répertoires et routes sans vérifier leur sémantique. Des paramètres fonctionnels peuvent sélectionner une déclinaison, un filtre, une langue ou une action de session. Ils diffèrent du suivi de campagne supprimable.

Vérifiez le code HTML source, les en-têtes de réponse, liens internes et entrées de sitemap pour détecter des signaux contradictoires. Consultez les recommandations Google sur les URL canoniques.

Si le code source contient des balises canoniques concurrentes, identifiez leurs émetteurs : thème, module SEO ou code personnalisé. Convenez du composant responsable de cette sortie au lieu d'ajouter une autre balise. Si la sortie ne change qu'après une purge du cache, vérifiez les caches applicatifs et CDN avant de juger la règle. Comparez la langue et la boutique concernées ainsi que la vitrine par défaut ; une page correcte dans la langue par défaut ne prouve pas que les autres contextes le sont.

Construire la correspondance des anciennes URL vers les URL finales

Inventoriez le catalogue actuel et la configuration des routes, explorez les pages accessibles, inspectez sitemaps et journaux serveur, et ajoutez les données de performances/liens de Search Console et les liens externes connus. Le rapport d’indexation de Search Console fournit des exemples, pas la liste complète de toutes les URL indexées ; consultez sa documentation.

Consignez ancienne URL, boutique/langue, statut, URL canonique actuelle, trafic/liens entrants pertinents, URL finale prévue et réponse attendue. Gardez inchangées les URL qui le restent. Incluez images, téléchargements et pages importantes des modules s’ils changent d’adresse.

Ajoutez la source des preuves et l'entité représentée par chaque ligne. Une exploration actuelle ne peut pas découvrir une ancienne adresse vers laquelle aucune page actuelle ne pointe, et les journaux ne couvrent que la période conservée. Marquez les destinations inconnues pour examen au lieu de les supprimer silencieusement. Traitez en priorité les pages d'entrée importantes et les liens d'achat cassés, sans considérer une colonne de trafic vide comme la preuve qu'une adresse n'est pas utilisée.

1. Configurez et testez d’abord le routage de destination.
2. Faites correspondre directement les pages modifiées à leur destination finale respective.
3. Examinez les pages importantes retirées pour trouver un remplacement pertinent ou une page de regroupement équivalente.
4. Utilisez 404 ou 410 lorsqu’une page a disparu sans équivalent adapté.
5. Réorientez les anciennes chaînes de redirection vers l’URL finale.

Une catégorie parente n’est pas automatiquement une destination équivalente pour un produit retiré. Les redirections générales vers l’accueil ou une catégorie peuvent tromper les utilisateurs et être traitées comme des soft 404. Une 410 ne garantit pas une suppression plus rapide qu’une 404 ; consultez les recommandations Google sur les pages supprimées.

Utilisez 301 ou 308 pour les déplacements permanents et le statut temporaire approprié pour les déplacements temporaires. Une 302 n’empêche pas systématiquement la consolidation des signaux ; son intention d’indexation diffère. Les redirections permanentes ne perdent pas intrinsèquement du PageRank à chaque saut. Raccourcissez les chaînes pour réduire la latence, faciliter l’exploration et limiter les points de défaillance. Consultez les recommandations Google sur les redirections.

Tester les destinations sur des exemples concrets

Un produit possède d'anciens chemins de catégorie

Supposons que votre audit trouve les anciennes adresses /bags/42-blue-wallet.html et /sale/42-blue-wallet.html pour le même produit, et que vous approuviez /42-blue-wallet.html comme route finale. Confirmez l'identité du produit avant de faire pointer les deux alias directement vers cette adresse. Retirer ensuite le produit des promotions ne doit pas envoyer l'ancien lien de promotion vers une liste générique de produits en promotion.

Testez un lien enregistré qui sélectionne aussi une déclinaison du produit. Suivez-le jusqu'à la fiche produit, ajoutez l'article au panier et examinez la taille, le prix et le stock retenus. Une redirection qui aboutit au bon produit mais perd silencieusement la déclinaison choisie par le client échoue à ce test. Vérifiez le même parcours depuis un flux ou un lien de campagne, au lieu de tester uniquement un lien fraîchement généré par la boutique.

Un produit et une page de contenu demandent le même slug

Supposons qu'un produit sans identifiant dans l'URL et une page CMS demandent tous deux /summer-sale. Vérifier les seuls slugs produits ne révèle pas ce conflit. Décidez quelle entité conserve l'adresse et attribuez une route distincte à l'autre avant de publier l'un ou l'autre changement. Consignez cette attribution dans la table de correspondances ; modifier la priorité des redirections ne permet pas à une même adresse de servir les deux pages prévues.

Implémenter des redirections exactes sous Apache

Placez les règles personnalisées à l’extérieur et avant le bloc de réécriture généré par PrestaShop. Gardez une sauvegarde de configuration, validez le serveur et testez en préproduction avant de recharger la production. Utilisez un mécanisme de redirection délibérément choisi ; mélanger mod_alias et mod_rewrite peut réserver des surprises d’ordre d’exécution.

Ces exemples se placent dans un .htaccess à la racine de la boutique pour une installation à la racine du domaine. Ils font correspondre des anciens chemins exacts à des routes natives finales testées sur le domaine illustratif.

RewriteEngine On
RewriteRule ^old-wallet\.html$ https://www.example.com/42-blue-wallet.html [R=301,L]
RewriteRule ^old-category/$ https://www.example.com/3-wallets [R=301,L]

Les ancres rendent ces correspondances de chemins exactes. RewriteRule dans ce contexte ne voit pas de barre initiale et compare le chemin sans les arguments de requête. Ces règles préservent les arguments existants par défaut. Utilisez QSD uniquement si vous les supprimez délibérément et avez confirmé qu’ils ne portent aucun état requis.

Pour une boutique sous /shop/, adaptez le contexte des règles et les chemins cibles. Une ancienne requête index.php?id_product=42&controller=product nécessite un traitement tenant compte des paramètres ou un comportement canonique natif testé ; une règle limitée au chemin index.php correspondrait à de nombreuses pages sans rapport.

La directive simple Redirect utilise une correspondance de préfixe de chemin et ajoute les informations de chemin non capturées. Utilisez un RedirectMatch ancré ou une réécriture ancrée testée pour des correspondances exactes. Consultez la documentation Apache de Redirect.

N’utilisez pas de règle générale « retirer le préfixe numérique » ou « supprimer .html » avant de savoir que chaque route cible fonctionne. Ces règles peuvent affecter produits, catégories et points d’entrée sans rapport et créer des chaînes si elles s’exécutent successivement.

Implémenter une correspondance de chemins sous Nginx

Pour une table plus importante limitée aux chemins, définissez map dans le contexte http et utilisez-la depuis le bloc server concerné. Cet exemple utilise des expressions régulières ancrées, sensibles à la casse, et préserve volontairement les arguments de requête.

# http context
map $uri $migration_target {
    default "";
    ~^/old-wallet[.]html$ /42-blue-wallet.html;
    ~^/old-category/$ /3-wallets;
}

# inside the intended server block
if ($migration_target != "") {
    return 301 https://www.example.com$migration_target$is_args$args;
}

$uri est le chemin courant normalisé sans paramètres ; $request_uri inclut la chaîne de requête d'origine. Une table utilisant des clés de chemin avec $request_uri ne reconnaîtrait pas /old-wallet.html?utm_source=email. Ne choisissez une correspondance sur la requête complète que si ses paramètres font partie de la clé voulue. Consultez les variables URI de Nginx.

Si une cible remplace ou supprime volontairement des paramètres, adaptez la construction de la réponse de redirection. Testez les caractères échappés et les barres obliques répétées selon votre politique de normalisation. Placez la logique de manière à ce qu'elle voie le chemin voulu avant que d'autres réécritures internes ne modifient $uri.

Exécutez nginx -t, examinez le résultat, rechargez l’instance voulue et testez des requêtes représentatives. Les domaines et chemins d’exemple décrivent une correspondance concrète ; générez votre vraie table depuis les destinations approuvées au lieu de copier cet exemple dans une autre boutique.

Changer de domaine et préserver les routes multilingues

Un changement d'hébergement conservant le même domaine public et les mêmes chemins peut préserver les URL. Avant de modifier le DNS, testez le nouveau serveur avec le nom d'hôte public prévu et le certificat HTTPS. Prévoyez comment les requêtes qui atteignent encore l'ancien serveur pendant la propagation DNS rejoindront la boutique active. Un nouveau domaine ou répertoire de base exige aussi la mise à jour de la configuration des URL de la boutique, des certificats prêts et le maintien du routage des anciennes adresses vers les nouvelles.

1. Copiez les fichiers et la base concordants vers le nouvel environnement et protégez la copie pendant les tests.
2. Mettez à jour l’URL de la boutique voulue via les paramètres du back-office pris en charge. Vérifiez shop_url.domain, domain_ssl, physical_uri et toute URI virtuelle multiboutique.
3. Vérifiez les valeurs pertinentes de PS_SHOP_DOMAIN et PS_SHOP_DOMAIN_SSL dans le bon contexte.
4. Si l’accès à la base change, mettez à jour app/config/parameters.php sur les versions modernes. Le chemin n’est pas config/parameters.php. L’ancienne version 1.6 utilise config/settings.inc.php.
5. Videz/reconstruisez les caches et régénérez les règles Apache applicables ou déployez les règles Nginx correspondantes.
6. Installez et testez les redirections de chaque ancienne page vers son équivalent final. Gardez l’ancien domaine et son certificat HTTPS fonctionnels.
7. Mettez à jour callbacks de paiement, tâches cron, liens des emails, flux, analytique et destinations des annonces.

Pour les catalogues multilingues, associez chaque langue à la même langue, conservez la différenciation linguistique nécessaire et examinez les références canoniques et hreflang réciproques. Ne redirigez pas toutes les langues vers l’anglais.

Un catalogue de 5 000 produits et quatre langues peut comporter environ 20 000 paires d’URL produit-langue avant alias, catégories et ancien historique. Générez l’inventaire depuis les combinaisons réellement publiées au lieu de supposer que chaque produit possède chaque traduction.

Pour l’aspect plateforme/données du changement, utilisez le guide de migration.

Utiliser les modules URL et SEO pour le routage et les métadonnées

SEO Revolution fournit la gestion des redirections, l'examen des 404, le traitement des chaînes permanentes, les règles canoniques/hreflang et les processus de sitemap ; son aide du module détaille la configuration et les comportements de correspondance pris en charge.

Smart SEO Friendly URL Manager fournit des schémas d’URL par entité, des politiques de conflit et un historique de redirections, avec la condition qu’un ancien chemin ne soit pas détenu par une route actuelle ; utilisez sa page d’aide pour la configuration et l’interaction avec SEO Revolution.

Product Canonical Manager fournit des contrôles canoniques par produit ; consultez sa page d’aide avant de modifier les destinations préférées.

Hreflang Tags Manager fournit la gestion des variantes linguistiques ; sa page d’aide couvre la configuration.

Testez sur une copie les routes des modules, correspondances exactes/avec requête, règles de préfixe, fins de chaînes, éligibilité linguistique et priorité des routes actuelles. Un module de redirection nécessite toujours une correspondance de destinations vérifiée ; il ne peut pas choisir de façon sûre un équivalent sémantique pour chaque page manquante.

Vérifier le lancement et surveiller les résultats

Mettez à jour les références internes vers les URL finales : navigation, contenus CMS et produits, ventes croisées, modèles d’email, flux et données structurées. Les redirections doivent intercepter les anciennes références externes plutôt que d’ajouter des sauts à chaque nouveau lien interne.

Générez des sitemaps contenant les URL canoniques indexables prévues qui renvoient des réponses réussies. Vérifiez toutes les boutiques et langues. Retirez les destinations redirigées, manquantes ou noindex. Un sitemap est un signal de découverte/canonicalisation, pas une garantie d’indexation ; consultez les recommandations Google sur les sitemaps.

Testez la réponse et le contenu final avec un navigateur normal et une requête en ligne de commande. Certaines applications traitent HEAD différemment ; confirmez donc aussi avec GET.

curl -sS -D - -o /dev/null 'https://www.example.com/old-wallet.html?utm_source=email'
curl -sS -L -o /dev/null -w '%{http_code} %{url_effective}\n' 'https://www.example.com/old-wallet.html'

• URL modifiées : statut permanent attendu, en-tête Location correct, aucune boucle et page finale 200 au contenu correspondant.
• URL inchangées : 200 direct, bon contenu et URL canonique.
• Pages supprimées : 404/410 prévu, sans page de succès trompeuse.
• Variantes : hôte, protocole, suffixe, casse, encodage, arguments, langue et sous-répertoire d’installation.
• Workflows critiques : déclinaisons, recherche/facettes, commande, compte et callbacks de paiement.

Vérifiez les anciennes et nouvelles propriétés Search Console, soumettez le sitemap actuel et utilisez Changement d’adresse pour un changement de domaine pris en charge. Examinez rapports d’exploration/indexation, journaux, trafic des pages d’entrée organiques et conversion. Gardez les redirections permanentes de migration au moins un an, et davantage tant que des liens ou visiteurs les utilisent.

Conservez une référence antérieure au changement par page d'entrée, langue et boutique, et comparez les destinations de la table à leurs anciens équivalents. Les totaux de la boutique peuvent masquer une langue défaillante ou une catégorie importante manquante. Distinguez l'échec d'une requête d'une évolution des performances de recherche : une boucle, un mauvais produit ou une destination bloquée nécessite une correction technique, tandis qu'une URL fonctionnelle moins visitée nécessite un examen de l'indexation, du contenu et de la demande. Consignez l'heure du changement et les campagnes ou modifications du catalogue concomitantes pour ne pas les attribuer à tort à une autre cause.

Les délais de traitement et résultats de recherche varient. Les redirections ne garantissent pas le rétablissement et ne compensent pas une perte de contenu, des restrictions d’indexation ou une concurrence modifiée. Consultez les recommandations Google sur les changements de site.

Questions à poser à votre développeur ou agence

Demandez une documentation de transmission exploitable lors du prochain import, changement de nom ou mise à jour de module.

• Quel composant gère les redirections d'hôte, le routage des pages, les redirections historiques, les URL canoniques et hreflang, et dans quel ordre s'exécutent-ils ?
• Quelles lignes de la table de correspondances restent non résolues, qui approuve leurs destinations et où se trouvent les résultats des requêtes et les contrôles des pages finales ?
• Un import du catalogue peut-il écraser les slugs manuels ou créer de nouveaux conflits, et qui vérifie le résultat ?
• Quels liens du thème, flux, notifications de retour et tâches planifiées ont été testés avec le domaine et les langues prévus en production ?
• Qui peut restaurer la configuration précédente, qu'est-ce qui déclenche cette décision et comment les nouvelles commandes et modifications de stock seront-elles préservées ?
• Qui prend en charge la supervision et les signalements de liens cassés après la transmission du projet ?

Questions des commerçants

Peut-on restaurer une sauvegarde de la base pour annuler le changement d'URL ?

N'écrasez pas les nouvelles commandes, modifications clients ou mouvements de stock avec la base antérieure au lancement. Planifiez la reprise autour de la configuration du routage, de la table de redirections et des changements de données précis concernés. Les navigateurs et les intermédiaires peuvent mettre en cache les redirections permanentes ; testez donc la reprise pour les visiteurs qui suivent encore les nouvelles destinations publiées. Gardez ces destinations utilisables pendant la reprise. Si le retour arrière nécessite une réparation des données, votre développeur doit rapprocher les enregistrements écrits depuis le lancement plutôt que de restaurer aveuglément toute la boutique.

Peut-on réutiliser l'adresse d'un produit retiré pour un autre produit ?

Vérifiez les usages historiques avant de l'approuver. Les anciens favoris, campagnes et liens entrants ouvriraient désormais le nouveau produit, et une redirection historique peut ne plus s'exécuter lorsqu'une route actuelle possède le chemin. Conservez une adresse distincte lorsque les produits ne répondent pas à la même intention ; réservez les alias importants dans l'inventaire des routes pour qu'un import ne les réutilise pas sans précaution.

Un changement de domaine impose-t-il d'arrêter les commandes ?

Une répétition des redirections ne permet pas de trancher. Si vous déplacez aussi la base, convenez de l'environnement qui accepte les écritures, du fonctionnement de la synchronisation finale et de la nécessité éventuelle d'une pause des commandes. Les commandes, notifications de paiement et mises à jour de stock ne doivent pas se répartir entre des copies indépendantes pendant la bascule.

Qui maintient la table de correspondances après le lancement ?

Confiez à une personne nommée la responsabilité des destinations approuvées et du motif de chaque changement. Conservez la configuration des redirections avec les relevés de déploiement et examinez-la après les imports du catalogue ou les mises à jour du routage. Incluez les signalements de pages manquantes du support client : un lien d'achat cassé peut être important même s'il reçoit peu de trafic de recherche.