# 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.

- Source canonique : [https://allaux.fr/en/prestashop/problemes/url-simplifiees-erreurs-404](https://allaux.fr/en/prestashop/problemes/url-simplifiees-erreurs-404)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> In Shop Parameters > Traffic & SEO, save the screen again to force the root .htaccess to be regenerated, then check that mod_rewrite is enabled on Apache. Under Nginx there is no .htaccess at all: the rewrite rules must be written into the server configuration, otherwise every page stays on a 404.

## 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.

## Regenerating .htaccess doesn’t fix links already broken

> Regenerating the file fixes the rewriting for new URLs, but doesn’t automatically recreate redirects to old, already-indexed addresses: that’s a separate piece of work.

## 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

- **500 error or blank page on PrestaShop** — A different family of server errors, with its own causes and its own diagnostic method. ([/prestashop/erreur-500](/prestashop/erreur-500))
- **PrestaShop 1.6 to 1.7 or 8 migration** — A version or hosting change is often the moment friendly URLs break. ([/prestashop/migration](/prestashop/migration))
- **Custom PrestaShop module development** — For a bulk 301 redirect policy, often carried out directly at database level. ([/prestashop/module-sur-mesure](/prestashop/module-sur-mesure))

## FAQ

### 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.