Nikola Arsić
Start

PrestaShop Friendly URLs: Remove IDs, Fix Rewrites & Canonicals

Nikola ArsićPrestaShop

Every PrestaShop store arrives at the same question about six weeks in: why do product URLs still look like /12-blue-widget when friendly URLs are switched on, and can the number be removed?

The short version is that the number is load-bearing, removing it is possible but expensive, and there are three other URL problems that cost you more traffic and are far cheaper to fix. Here is the order I actually work in on client stores.

How PrestaShop builds a URL

PrestaShop does not look up a product by its slug. It parses the ID out of the path and queries by primary key. The slug beside it is decoration for humans and for search engines.

That is why the default product route is:

/{id}-{rewrite}
/{category}/{id}-{rewrite}

The dispatcher matches the numeric segment. Change the slug and the URL still resolves, because the ID is the part doing the work. That behaviour is also your safety net: a renamed product does not 404.

1. Turn friendly URLs on properly

SEO & URLs → Set up URLs → Friendly URL: Yes. Then, in the same screen, regenerate the .htaccess file. Skipping the regeneration is the most common reason friendly URLs "do not work" - the setting flips, the rewrite rules are never written, and every pretty URL 404s.

On Nginx there is no .htaccess at all, and PrestaShop cannot write your config for you. You need the rewrite block in the server config, and it has to be reloaded. If your host manages Nginx, this is a support ticket, not a setting.

Check it worked by requesting a category URL directly rather than clicking a link. Clicking proves the link was generated; requesting proves the rewrite resolves.

2. Fix the route patterns before you fix the IDs

The Schema of URLs section on that same page controls the actual route patterns, and the defaults are worse than most people realise.

The category route in particular defaults to including the full category path, which means a product reachable through three categories has three URLs. That is a duplicate content problem generated by configuration, not by content, and it is the single biggest URL issue on most PrestaShop stores.

Two defensible choices:

  • Flatten the product route to /{rewrite} plus the ID, so a product has exactly one URL regardless of category. This is what I do on most stores.
  • Keep the category in the path but make absolutely sure canonicals point at one chosen path.

What you must not do is leave the category in the path and assume PrestaShop sorts the duplicates out. It does not.

3. Canonicals

PrestaShop does emit a canonical tag on product and category pages, and it is usually correct for the simple case. It is usually wrong for these:

  • Faceted navigation. Filter combinations generate URLs with query strings that either self-canonicalise or get indexed outright. Both are bad. Layered navigation should canonicalise to the unfiltered category, and the combinations you genuinely want indexed should be a deliberate, small list.
  • Pagination. Page 2 canonicalising to page 1 hides your deeper products from the index entirely. Page 2 should canonicalise to itself.
  • Multistore. Each shop needs its own canonical host. This breaks quietly and stays broken.

Fix canonicals before you touch IDs. It costs an afternoon and it is where the actual duplicate content is.

4. Removing the ID

Now the question everyone starts with.

PrestaShop core cannot do it. The dispatcher needs the ID to resolve the route, so removing it means one of:

  • A module that intercepts the route and resolves the slug to an ID itself, usually via an extra lookup table.
  • An override of the Dispatcher and Link classes doing the same thing by hand.

Both work. Both carry the same three costs, and you should decide with these on the table:

  1. A lookup on every request. You are adding a slug-to-ID resolution in front of the router. Cache it or you will feel it.
  2. Slug collisions become 404s. Two products named "Blue Widget" in different categories were fine when the ID disambiguated them. Now they are not.
  3. An upgrade liability. Overrides of the dispatcher are among the first things to break on a major version upgrade. If you are on PrestaShop 1.7 or 8 and heading for 9, do this after the migration, not before.

And the honest part: the ranking benefit is small. Google has been explicit for years that URL structure is a weak signal. A clean URL is nicer to share and marginally better for click-through in the SERP. It is not what is keeping you on page two.

If you have a store doing real revenue and a stable codebase, it is a reasonable polish item. If you have duplicate faceted URLs and broken canonicals, fixing those will move far more traffic for a fraction of the risk.

5. Redirect whatever you change

Any URL change needs a 301 from the old path. PrestaShop will happily change a product's slug when someone edits the name in the back office, with no redirect, silently. On a store where several people edit products, that is a slow leak.

The id_product in the path is what saves you here - the old URL still resolves - which is one more reason to be deliberate rather than eager about removing it.

The order I actually work in

  1. Friendly URLs on, .htaccess regenerated, rewrite verified by direct request
  2. Route patterns chosen so one product has one URL
  3. Canonicals fixed on facets, pagination and multistore
  4. Redirects in place for anything already changed
  5. Then, if the codebase is stable and the store is not mid-migration, consider removing IDs

Most stores never need step five. Nearly all of them need steps one to four, and most have never done step three.