Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

PrestaShop friendly URLs stop working or return a 404 error

PrestaShop’s friendly URLs rely on the web server’s URL rewriting, switched on under Preferences > SEO & URLs. On Apache, that means a regenerated .htaccess file; on Nginx, there’s no .htaccess, and the rules have to be written manually into the server configuration. A site-wide 404 after activation, and a URL change that breaks already-indexed links, each have their own cause.

Describe my issue Send a message

Why the same setting behaves differently by host

The Enable friendly URLs setting, under Preferences > SEO & URLs, relies on the web server’s URL rewrite module. On Apache, turning it on regenerates a .htaccess file at the site root, and mod_rewrite needs to be active on the server for it to take effect.

On Nginx, there’s no .htaccess file: the rewrite rules have to be translated manually into the server configuration. That’s why the same tickbox works on one host and does nothing on another: the mechanism applying it isn’t the same.

Site-wide 404 after activation

A 404 error on every page, right after turning on friendly URLs, very often comes from a .htaccess that hasn’t been regenerated, or has been overwritten by a server-side change: a host switch, a backup restore, an update. The regeneration button, in the same settings screen, recreates the file with up-to-date rules.

Changing the product URL format after the fact, or switching domain name, breaks every link already shared or indexed by Google: without 301 redirects set up for each old address, those links fall into a 404 instead of redirecting to the new page.

What I check depending on the symptom

  1. Apache or Nginx

    The server type determines whether the fix is regenerating a .htaccess file or editing the server configuration itself.

  2. The current .htaccess file

    I check whether it’s been regenerated since the last change to the site or hosting, and whether it matches the URL structure actually in place.

  3. The scale of broken links

    I list the old URLs still being requested, via server logs or Search Console, to gauge whether case-by-case redirects are enough or a bulk policy is needed.

Related pages

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

version
besoin
etat
theme (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

I ticked ’friendly URLs’ but nothing changes, why?
On Nginx, ticking the box isn’t enough: there’s no .htaccess file to generate, the rules have to be added manually to the server configuration.
Every page has been returning a 404 recently, what should I check first?
The .htaccess file: on Apache, it’s the most common cause of a site-wide 404, especially after a hosting-side change.
I changed my product URL format and the old links stopped working, is that normal?
Yes, without a 301 redirect set up for each old address, the old link falls into a 404 instead of redirecting to the new page.
How do I redirect a large number of old URLs to the new ones?
For a handful of addresses, case-by-case redirects are enough. For a large volume, working at database level or with a dedicated script is more reliable than typing each one in by hand.

Related pages