Przepisywanie URL PrestaShop: checklista 5 kroków na naprawę zepsutych Friendly URL

Friendly URL jest włączone, lecz linki produktów nadal wyglądają jak index.php?id_product=12 – albo każda przyjazna ścieżka zwraca 404. Przepisywanie URL PrestaShop działa dopiero wtedy, gdy przełącznik w Back Office, plik rewrite w katalogu głównym (Apache) i reguły serwera WWW są ze sobą zgodne. To checklista w 5 kroków: określ symptom, potwierdź ustawienie sklepu, napraw warstwę serwera, zweryfikuj jeden URL, na końcu uporządkuj duplikaty i stare 404.

Ogólna rada „włącz Friendly URL” łatwo znaleźć w chatbocie. Zwykle najwięcej czasu marnuje się na niewłaściwą naprawę dla danego symptomu – albo na pominięcie testu OK/błąd po każdym kroku. Przechodź listę w podanej kolejności. Oficjalne nazwy w dokumentacji PrestaShop 9: Shop Parameters → Traffic. Przed edycją konfiguracji serwera warto wykonać pełną kopię zapasową PrestaShop.

Krok 1 – Określ, co jest zepsute

Otwórz stronę produktu w prywatnym oknie i zapisz, który przypadek występuje. Nie pomijaj tego kroku – trzy scenariusze wymagają różnych napraw.

• A – Nadal brzydkie URL. W pasku adresu nadal widać id_product, id_category lub controller= po włączeniu Friendly URL. PrestaShop nie generuje przepisanych linków (albo cache serwuje starą stronę).
• B – Przyjazne URL zwracają 404. Linki wyglądają poprawnie (/category/product-slug), ale każda przyjazna ścieżka zwraca stronę nie znaleziono. Sklep generuje slugi; serwer WWW nie kieruje ich do PrestaShop.
• C – Działa tylko na jednej domenie. Główny sklep jest w porządku; domena multistore, subdomena lub sklep w podkatalogu nie działa. To często kwestia URL sklepu / DNS / document root – a nie drugiego błędu Friendly URL. Równolegle z tą checklistą warto zajrzeć do przewodnika o multisklepie w PrestaShop.

OK: przed dotknięciem Apache lub Nginx można wskazać A, B lub C.

Krok 2 – Potwierdź Friendly URL w Back Office

1. Przejdź do Shop Parameters → Traffic & SEO.
2. Otwórz Set up URLs.
3. Ustaw Friendly URL na Yes i zapisz.
4. Wyczyść cache PrestaShop (Advanced Parameters → Performance) i przetestuj ponownie ten sam produkt w prywatnym oknie.

Na Apache zapis tej strony powinien utworzyć lub odświeżyć plik .htaccess w katalogu głównym z regułami rewrite PrestaShop. Jeśli plik brakuje, jest pusty lub starszy niż zapis, PHP nie może zapisywać w katalogu głównym sklepu – napraw uprawnienia przed szukaniem winy w modułach.

Na Nginx sam przełącznik nie instaluje reguł rewrite. Nadal potrzebny jest krok 3.

OK (przypadek A): po wyczyszczeniu cache nowe linki w HTML używają slugów (nawet jeśli nadal zwracają 404 – wtedy przechodzi to w przypadek B). OK (przypadek B/C): Friendly URL jest Yes i pozostaje Yes po przeładowaniu.

Krok 3 – Napraw warstwę serwera (Apache lub Nginx)

Aby kontynuować przepisywanie URL PrestaShop, sprawdź Advanced Parameters → Information → Server information (albo zapytaj hosta). Wykonaj tylko ścieżkę odpowiadającą serwerowi.

Przy serwerze Apache

• Włącz mod_rewrite (często domyślnie włączone).
• Potwierdź, że document root sklepu ma czytelny .htaccess, który PrestaShop zaktualizował przy ostatnim zapisie SEO.
• AllowOverrides musi zezwalać na dyrektywy rewrite dla tego katalogu.
• Instalacje w podkatalogu wymagają dopasowanego RewriteBase.
• Niestandardowe reguły nad blokiem PrestaShop mogą przerwać przepisywanie – tymczasowo przenieś dodatki pod sekcję PrestaShop na czas testu.
• Po ręcznej edycji przełącz Friendly URL off/on raz i zapisz, aby PrestaShop odtworzył własną sekcję, potem dodaj z powrotem tylko potrzebne niestandardowe linie.

OK: przyjazny URL produktu zwraca HTTP 200 z poprawnym produktem (nie domyślną stronę 404 hosta).

Przy serwerze Nginx

Nginx ignoruje .htaccess. Edytuj blok serwera witryny (często w /etc/nginx/sites-available/):

1. Dodaj aktualny przykład reguł rewrite Nginx dla PrestaShop z dokumentacji Nginx PrestaShop 9 (zachowaj rzeczywisty root i socket PHP-FPM).
2. Uruchom nginx -t.
3. Jeśli test przejdzie, przeładuj: systemctl reload nginx (lub odpowiednik w panelu hosta).

Jeśli chatbot wkleił stary przykład, zastąp go oficjalnym blokiem dla danej głównej wersji. Ścieżki i linie try_files się zmieniają; fragmenty z forów sprzed lat to częsta przyczyna przypadku B.

OK: jak przy Apache – przyjazny URL → 200 → poprawny produkt. Jeśli CDN lub reverse proxy stoi z przodu podczas awarii, wyczyść jego cache raz, aby nie serwował zapisanych 404.

Krok 4 – Zweryfikuj przepisywanie URL PrestaShop od początku do końca

Nie kończ na „linki w menu wyglądają ładnie”. Uruchom ten krótki test na jednym produkcie:

• Prywatne okno: otwórz produkt z listy kategorii.
• Pasek adresu pokazuje ścieżkę ze slugiem, nie tylko id_product.
• Skopiuj ten przyjazny URL i otwórz w nowej karcie: HTTP 200, ten sam produkt.
• Opcjonalnie: wywołaj znany błędny slug – powinna pojawić się szablonowa strona 404 sklepu, a nie pusta strona serwera, która nigdy nie dotarła do PrestaShop.

Jeśli krok 4 pada tylko na drugiej domenie, gdy główna przechodzi, wróć do przypadku C (URL multistore / DNS / document root) zanim ponownie edytujesz reguły rewrite.

OK: jeden produkt przetrwa klik z listy + bezpośrednie przeładowanie przyjaznego URL.

Krok 5 – Canonicals i pozostałe 404

Gdy przepisywanie URL PrestaShop działa, dokończ stronę SEO, aby wyszukiwarki nie dzieliły autorytetu między duplikaty i martwe ścieżki.

1. W Shop Parameters → Traffic & SEO ustaw Redirect to the canonical URL na 301 Moved Permanently w działającym sklepie.
2. Sprawdź moduły zewnętrzne dodające URL listingu lub blogu – też potrzebują dopasowanych canonicals.
3. Po zmianie slugów, przeniesieniu kategorii lub zmianie domeny dodaj 301 ze starych ścieżek (albo przywróć encję). Zmiana schematu URL bez przekierowań traci pozycje już zdobyte.
4. Wyślij zaktualizowaną mapę witryny, aby roboty wykryły preferowane URL – zobacz przewodnik o mapie witryny w PrestaShop.

Użyj raportu pokrycia Search Console (albo logów dostępu), aby wypisać rzeczywiste ścieżki 404 nadal trafiające na serwer. Napraw je przekierowaniami lub przywróceniem treści – samo przepisywanie nie ożywi usuniętych stron CMS.

OK: opcja canonical to 301; przykładowa alternatywna ścieżka produktu przekierowuje; znane stare slugi, które mają znaczenie, są przekierowane lub świadomie usunięte.

Krótkie podsumowanie 5 kroków

1. Określ symptom (A brzydkie / B przyjazne 404 / C jedna domena).
2. Potwierdź Friendly URL Yes + wyczyść cache (+ zapisywalny .htaccess na Apache).
3. Napraw Apache mod_rewrite/.htaccess lub reguły bloku serwera Nginx.
4. Potwierdź jeden produkt: przyjazny link + bezpośrednie przeładowanie = 200.
5. Ustaw canonical 301 i uporządkuj pozostałe 404 / mapę witryny.

Jeśli ma zostać jeden nawyk: po każdej zmianie przetestuj ponownie ten sam URL produktu, zanim otworzysz następne ustawienie. Tak przepisywanie URL PrestaShop przestaje być pętlą zgadywania.