Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Les URL simplifiées PrestaShop ne fonctionnent plus ou renvoient une erreur 404

Les URL simplifiées PrestaShop reposent sur la réécriture d’URL du serveur web, activée dans Préférences > SEO & URLs. Sous Apache, ça passe par un fichier .htaccess régénéré ; sous Nginx, il n’y a pas de .htaccess, les règles doivent être écrites manuellement dans la configuration serveur. Une erreur 404 généralisée après activation, ou un changement d’URL qui casse des liens déjà indexés, ont chacun leur propre cause.

Décrire mon problème Discuter sur WhatsApp

Pourquoi le même réglage se comporte différemment selon l’hébergement

Le réglage Activer les URL conviviales, dans Préférences > SEO & URLs, s’appuie sur le module de réécriture d’URL du serveur web. Sous Apache, l’activation régénère un fichier .htaccess à la racine du site, et le module mod_rewrite doit être actif côté serveur pour qu’il soit pris en compte.

Sous Nginx, il n’existe pas de fichier .htaccess : les règles de réécriture doivent être traduites manuellement dans la configuration du serveur. C’est pour ça que la même case cochée fonctionne sur un hébergement et ne fait rien sur un autre : le mécanisme qui l’applique n’est pas le même.

Erreur 404 généralisée après activation

Une erreur 404 sur toutes les pages, juste après avoir activé les URL simplifiées, vient très souvent d’un .htaccess non régénéré, ou écrasé par une intervention côté serveur : changement d’hébergeur, restauration de sauvegarde, mise à jour. Le bouton de régénération, dans le même écran de réglage, recrée ce fichier avec les règles à jour.

Modifier le format des URL de produits après coup, ou changer de nom de domaine, casse tous les liens déjà partagés ou indexés dans Google : sans redirections 301 mises en place pour chaque ancienne adresse, ces liens tombent en erreur 404 au lieu de rediriger vers la nouvelle page.

Ce que je vérifie selon le symptôme

  1. Apache ou Nginx

    Le type de serveur détermine si la solution passe par la régénération d’un fichier .htaccess ou par une modification de la configuration serveur elle-même.

  2. Le fichier .htaccess actuel

    Je vérifie s’il a été régénéré depuis la dernière modification du site ou de l’hébergement, et s’il correspond à la structure d’URL réellement en place.

  3. L’ampleur des liens cassés

    Je liste les anciennes URL encore appelées, via les journaux du serveur ou la Search Console, pour mesurer s’il faut une redirection au cas par cas ou une politique en masse.

Pages liées

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Quelle version de PrestaShop ?
Sur quoi avez-vous besoin d’aide ?
Quel est l’état actuel de la boutique ?
Le thème est-il un thème du marché ou sur mesure ? (facultatif)

Un thème très modifié change la façon d’intervenir sans rien casser.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

J’ai coché « URL conviviales » mais rien ne change, pourquoi ?
Sous Nginx, cocher la case ne suffit pas : il n’y a pas de fichier .htaccess à générer, les règles doivent être ajoutées manuellement dans la configuration du serveur.
Toutes mes pages renvoient une 404 depuis peu, que vérifier en premier ?
Le fichier .htaccess : sous Apache, c’est la cause la plus fréquente d’une erreur 404 généralisée, surtout après une intervention côté hébergement.
J’ai changé le format d’URL de mes produits, les anciens liens ne marchent plus, c’est normal ?
Oui, sans redirection 301 mise en place pour chaque ancienne adresse, l’ancien lien tombe en erreur 404 au lieu de rediriger vers la nouvelle page.
Comment rediriger un grand nombre d’anciennes URL vers les nouvelles ?
Pour quelques adresses, une redirection au cas par cas suffit. Pour un volume important, un travail en base de données ou un script dédié est plus fiable qu’une saisie manuelle une par une.

Pages liées