Réécriture d’URL PrestaShop : checklist en 5 étapes pour réparer les Friendly URL cassées

La Friendly URL est activée, mais les liens produits ressemblent encore à index.php?id_product=12 – ou chaque jolie URL renvoie une 404. La réécriture d’URL PrestaShop ne fonctionne que lorsque l’interrupteur du back-office, le fichier de réécriture racine (Apache) et les règles du serveur web concordent. Voici une checklist en 5 étapes : identifier le symptôme, confirmer le réglage boutique, corriger la couche serveur, valider une URL, puis nettoyer les doublons et les anciennes 404.

Le conseil générique « activer la Friendly URL » est facile à obtenir d’un chatbot. Ce qui fait perdre des heures, c’est d’appliquer le mauvais correctif au mauvais symptôme – ou de sauter le test réussi/échoué après chaque étape. Suivre la liste dans l’ordre. Les libellés officiels se trouvent sous Paramètres de la boutique → Trafic dans la documentation PrestaShop 9. Avant de modifier la configuration serveur, effectuer une sauvegarde complète de PrestaShop.

Étape 1 – Identifier ce qui est cassé

Ouvrir une fiche produit en navigation privée et noter le cas rencontré. Ne pas sauter cette étape – les trois cas exigent des correctifs différents.

• A – URLs laides encore. La barre d’adresse affiche toujours id_product, id_category ou controller= après activation de la Friendly URL. PrestaShop n’émet pas de liens réécrits (ou le cache sert une ancienne page).
• B – Jolies URLs en 404. Les liens semblent corrects (/categorie/slug-produit) mais chaque jolie URL renvoie Page introuvable. La boutique génère les slugs ; le serveur web ne les route pas vers PrestaShop.
• C – Fonctionne sur un seul domaine. La boutique principale va bien ; un domaine multiboutique, un sous-domaine ou une boutique en sous-répertoire échoue. Souvent, c’est l’URL boutique / le DNS / le document root – pas un second bug Friendly URL. Consulter en parallèle notre guide multiboutique PrestaShop avec cette checklist.

Réussi : pouvoir désigner A, B ou C avant de toucher Apache ou Nginx.

Étape 2 – Confirmer la Friendly URL dans le back-office

1. Aller dans Paramètres de la boutique → Trafic et SEO.
2. Ouvrir Configuration des URLs.
3. Mettre Friendly URL sur Oui et enregistrer.
4. Vider le cache PrestaShop (Paramètres avancés → Performances) et retester le même produit en navigation privée.

Sous Apache, l’enregistrement de cette page doit créer ou actualiser le .htaccess racine avec les règles de réécriture PrestaShop. Si le fichier est absent, vide ou plus ancien que l’enregistrement, PHP ne peut pas écrire à la racine boutique – corriger propriété et permissions avant de chercher du côté des modules.

Sous Nginx, l’interrupteur seul n’installe jamais les règles de réécriture. L’étape 3 reste nécessaire.

Réussi (cas A) : après vidage du cache, les nouveaux liens HTML utilisent des slugs (même si ces slugs renvoient encore une 404 – ce devient le cas B). Réussi (cas B/C) : Friendly URL est sur Oui et le reste après rechargement.

Étape 3 – Corriger la couche serveur (Apache ou Nginx)

Pour avancer sur la réécriture d’URL PrestaShop, vérifier Paramètres avancés → Informations → Informations serveur (ou demander à l’hébergeur). Ne suivre que la branche correspondant au serveur.

Sous Apache

• Activer mod_rewrite (souvent déjà activé).
• Confirmer que le document root de la boutique contient un .htaccess lisible, mis à jour par PrestaShop au dernier enregistrement SEO.
• AllowOverrides doit autoriser les directives rewrite pour ce répertoire.
• Les installations en sous-répertoire nécessitent un RewriteBase adapté.
• Des règles personnalisées au-dessus du bloc PrestaShop peuvent court-circuiter la réécriture – déplacer temporairement les extras sous la section PrestaShop pour tester.
• Après une modification manuelle, basculer Friendly URL sur Non puis Oui une fois et enregistrer pour que PrestaShop réécrive sa propre section, puis ne réajouter que les lignes personnalisées encore nécessaires.

Réussi : une jolie URL produit renvoie HTTP 200 avec le bon produit (pas la page 404 par défaut de l’hébergeur).

Sous Nginx

Nginx ignore .htaccess. Modifier le bloc serveur du site (souvent sous /etc/nginx/sites-available/) :

1. Ajouter l’exemple actuel de réécriture Nginx PrestaShop depuis la documentation Nginx PrestaShop 9 (conserver le vrai root et le socket PHP-FPM).
2. Exécuter nginx -t.
3. Si le test passe, recharger : systemctl reload nginx (ou l’équivalent du panneau d’hébergement).

Si un chatbot a collé un ancien exemple, le remplacer par le bloc officiel pour la version majeure concernée. Les chemins et les lignes try_files évoluent ; les extraits de forum datant de plusieurs années sont une cause fréquente du cas B.

Réussi : identique à Apache – jolie URL → 200 → bon produit. Si un CDN ou un reverse proxy était devant pendant la panne, purger son cache une fois pour qu’il cesse de servir des 404 en cache.

Étape 4 – Valider la réécriture d’URL PrestaShop de bout en bout

Ne pas s’arrêter à « les liens ont l’air jolis dans le menu ». Exécuter cette vérification rapide sur un produit :

• Navigation privée : ouvrir le produit depuis la liste de catégorie.
• La barre d’adresse affiche un chemin en slug, pas seulement id_product.
• Copier cette jolie URL, l’ouvrir dans un nouvel onglet : HTTP 200, même produit.
• Optionnel : demander un slug connu comme incorrect – la 404 de la boutique doit s’afficher, pas une page vide du serveur web qui n’a jamais atteint PrestaShop.

Si l’étape 4 échoue uniquement sur un second domaine alors que le domaine principal passe, revenir au cas C (URL multiboutique / DNS / document root) avant de modifier à nouveau les règles de réécriture.

Réussi : un produit survit au clic depuis la liste + rechargement direct de la jolie URL.

Étape 5 – Canoniques et 404 résiduelles

Quand la réécriture d’URL PrestaShop fonctionne, finaliser le volet SEO pour que les moteurs cessent de répartir l’équité entre doublons et chemins morts.

1. Dans Paramètres de la boutique → Trafic et SEO, régler Rediriger vers l’URL canonique sur 301 Déplacé de façon permanente sur une boutique en production.
2. Vérifier les modules tiers qui ajoutent des URLs de listing ou de blog – ils doivent aussi avoir des canoniques cohérentes.
3. Après renommage de slugs, déplacement de catégories ou changement de domaine, ajouter des 301 depuis les anciens chemins (ou restaurer l’entité). Changer le schéma d’URL sans redirections brûle le classement déjà acquis.
4. Soumettre un sitemap mis à jour pour que les crawlers repèrent les URLs préférées – voir notre guide sitemap PrestaShop.

Utiliser la couverture Search Console (ou les journaux d’accès) pour lister les vrais chemins 404 qui touchent encore le serveur. Les corriger par redirections ou restaurations de contenu – la réécriture seule ne ranimera pas les pages CMS supprimées.

Réussi : l’option canonique est en 301 ; un chemin produit alternatif d’exemple redirige ; les anciens slugs importants sont redirigés ou volontairement supprimés.

Récapitulatif rapide des 5 étapes

1. Nommer le symptôme (A URLs laides / B jolie 404 / C un seul domaine).
2. Confirmer Friendly URL Oui + vidage du cache (+ .htaccess inscriptible sous Apache).
3. Corriger mod_rewrite/.htaccess Apache ou les règles du bloc serveur Nginx.
4. Valider un produit : joli lien + rechargement direct = 200.
5. Régler les 301 canoniques et nettoyer les 404 résiduelles / le sitemap.

S’il ne faut retenir qu’une habitude : après chaque modification, retester la même URL produit avant d’ouvrir le réglage suivant. C’est ainsi que la réécriture d’URL PrestaShop cesse d’être une boucle de tâtonnements.