PrestaShop 8.1 – 404 error for brand URLs due to category alias conflict – even with reordered slugs

[Familis]

Hello.

I'm encountering a critical but somewhat unusual issue in a PrestaShop 8.1.7 store with friendly URLs enabled and no ID in the URL structure.

🔍 The issue:

In the shop, both categories and brands (manufacturers/publishers) are used. For example:

✅ https://familis.pl/na-jej-glowie → Category (working)

❌ https://familis.pl/marki/wydawnictwo-zycia-wewnetrznego-na-jej-glowie → Brand (404 error)

Here's what’s happening:

If a brand URL contains any part of an existing category alias (even just a word like "na" or "glowie"), the system throws a 404.

Even changing the order of words in the slug doesn’t help. But on some of those everything is working ok.

Examples:

✅ https://familis.pl/wydawnictwo-antyk-marcin-dybowski – works as category

✅ https://familis.pl/marki/wydawnictwo-antyk-marcin-dybowski – works as brand

 

✅  https://familis.pl/anna-mandrela-ksiazki - work as category  

✅   https://familis.pl/marki/anna-mandrela  - work as brand

 

 ✅  https://familis.pl/wydawnictwo-bialy-kruk - work as category

 ❌ https://familis.pl/marki/bialy-kruk - 404 as a brand

 

✅ https://familis.pl/na-jej-glowie - Category (working)

❌ /brand/wydawnictwo-zycia-wewnetrznego-glowie – 404 as brand

❌ /brand/glowie-wydawnictwo-zycia-wewnetrznego – 404 as brand

❌ /brand/na-jej-wydawnictwo-zycia-wewnetrznego – 404 as brand

❌ /wydawnictwo-zycia-jej-wewnetrznego – 404 as brand

It seems like the Dispatcher or router mistakenly parses part of the slug as a category, and breaks the routing for brand pages.??

Any other clue what could it be?

🔧 Configuration:

Categories URL format: {rewrite}

Brand URL format: brand/{rewrite} (translated as /marki/ ; with /brand/ - is the same - 404 )

No ID in URLs

Using "SEO Audit - SEO Analytics, Pretty URL, Image & Sitemap" module to manage slugs and URLs

🧩 Behavior observed:

The Dispatcher incorrectly routes brand URLs when part of the brand alias matches or overlaps a category alias.

This occurs even with partial word matches, not just full slug conflicts.

❓ Questions:

switching to brand/{id}-{rewrite} most likely will resolve these problem but still is not a clue of the problem. Its god to know whats happened and how to fixed that.

I need categories and brands (especially book publishers) to coexist even with similar or identical names – without breaking friendly URLs or requiring forced renaming.

Thanks in advance for any insight or experience you can share!

Best regards,
Patryk - Familis
PrestaShop 8.1.7 – Friendly URLs enabled, no ID in slugs

Edited May 21 by Familis (see edit history)

[El Patron]

My advice:

• Disable or remove the pretty URL module you installed, and revert any changes it made to the core files. If you have a backup, restore your site to the state before the module was added.
• PrestaShop’s built-in “Friendly URL” option (found under Shop Parameters > Traffic & SEO) is more than sufficient for most shops. It generates clean URLs without needing extra modules or core modifications.
• Overriding core URL logic can easily lead to unexpected routing conflicts, broken links, and 404 errors, as you’re experiencing now. Unless you have a very specific use case, it’s rarely worth the risk.
• If SEO is your main concern, focus instead on unique meta titles, quality content, and good internal linking—these have a far greater impact than the exact structure of your URLs.
• If you still want more control over your URLs, consider working with an experienced PrestaShop developer who can audit your specific needs and avoid conflicts with core functionality.

The pretty URL module you installed is causing 404 errors and broken links. I strongly recommend disabling it and restoring the default PrestaShop “Friendly URLs” (under Shop Parameters > Traffic & SEO). The built-in friendly URLs are already SEO-friendly, and custom modules that override core URL logic can easily break your shop and make future PrestaShop upgrades nearly impossible.

Site stability and working links are far more important than having extra-pretty URLs.