Pretty URLs w PrestaShop: konfiguracja i pułapki

Domyślne URL-e w PrestaShop: dlaczego są problemem

Jeśli kiedykolwiek otworzyłeś sklep na PrestaShop i spojrzałeś na pasek adresu, prawdopodobnie zobaczyłeś coś, co wygląda jak wewnętrzny identyfikator bazy danych. Bo tym właśnie jest. PrestaShop w domyślnej konfiguracji generuje adresy, które wyglądają mniej więcej tak:

• produkt: /pl/123-nazwa-produktu.html
• kategoria: /pl/12-nazwa-kategorii
• strona CMS: /pl/content/7-regulamin

Te numery (ID) w adresach to identyfikatory wewnętrzne bazy danych PrestaShop. Dla silnika sklepu są potrzebne, żeby szybko znaleźć odpowiedni rekord. Dla użytkownika i wyszukiwarki są bezużyteczne.

Z perspektywy SEO problem jest podwójny. Po pierwsze, URL z numerami nie komunikuje Google niczego o treści strony. Adres /pl/456-koszulka-polo-meska.html jest gorszy niż /mezczyzni/koszulki/koszulka-polo-meska, bo nie zawiera informacji o hierarchii i kontekście produktu. Po drugie, ID w adresie jest kruche. Jeśli odtworzysz bazę danych, zaimportujesz produkty ponownie lub zmienisz hosting, ID mogą się zmienić, co generuje masę niedziałających linków.

Dlatego praktycznie każdy sklep na PrestaShop prędzej czy później instaluje moduł do “ładnych” adresów.

Moduł Pretty URLs: co robi i jak działa

Najpopularniejszym rozwiązaniem jest moduł Pretty URLs (czasem spotykany pod nazwami Friendly URLs, Clean URLs lub SEO Expert URLs). Jego zadanie jest proste: usunąć ID z adresów i pozwolić na konfigurację struktury URL-i.

Po instalacji i konfiguracji adresy zmieniają się z:

• /pl/123-koszulka-polo-meska.html na /koszulka-polo-meska lub /mezczyzni/koszulki/koszulka-polo-meska
• /pl/12-mezczyzni na /mezczyzni

Moduł działa na poziomie routera PrestaShop. Przechwytuje żądania przychodzące, mapuje “ładny” adres na wewnętrzny URL z ID i przekazuje je dalej do silnika sklepu. Jednocześnie nadpisuje generowanie linków w szablonach, żeby wszędzie w sklepie pojawiały się nowe, czyste adresy.

Popularne moduły na rynku

Na marketplace PrestaShop i w repozytoriach zewnętrznych znajdziesz kilka modułów realizujących tę funkcję:

• Pretty URLs (module Presto-Changeo) - jeden z najstarszych i najbardziej rozpoznawalnych
• SEO Expert - łączy zarządzanie URL-ami z meta tagami i danymi strukturalnymi
• Advanced URL - daje dużą kontrolę nad formatem adresów per typ strony
• Moduły bezpłatne / community - istnieją, ale bywają słabo utrzymywane i niekompatybilne z nowszymi wersjami PrestaShop

Wybierając moduł, zwróć uwagę na trzy rzeczy: kompatybilność z Twoją wersją PrestaShop (różnice między 1.6, 1.7 i 8.x są ogromne), datę ostatniej aktualizacji (moduł nieaktualizowany od roku to ryzyko) i wsparcie techniczne producenta.

Opcje konfiguracji: co warto ustawić

Każdy moduł Pretty URLs oferuje kilka kluczowych ustawień, które wpływają na strukturę adresów. Zanim cokolwiek zmienisz, musisz podjąć świadome decyzje.

Kategoria w URL-u produktu: tak czy nie

Pierwsza decyzja: czy URL produktu ma zawierać ścieżkę kategorii?

• wariant bez kategorii: /koszulka-polo-meska
• wariant z kategorią: /mezczyzni/koszulki/koszulka-polo-meska

Wariant z kategorią wygląda profesjonalnie i daje Google dodatkowy sygnał kontekstowy. Tyle że pojawia się problem, gdy produkt jest przypisany do wielu kategorii. PrestaShop pozwala na to, a wtedy powstaje pytanie: która kategoria powinna znaleźć się w URL-u?

Większość modułów rozwiązuje to przez pojęcie “kategorii domyślnej” produktu. URL generowany jest na podstawie tej jednej kategorii, niezależnie od tego, do ilu kategorii produkt faktycznie należy. To poprawne rozwiązanie, pod warunkiem że kategorie domyślne są ustawione świadomie, a nie losowo (co niestety jest normą w wielu sklepach).

Jeśli masz dużo produktów wielokategoriowych i nie chcesz ryzykować duplikacji, wariant bez kategorii w URL-u jest bezpieczniejszy. Tracisz sygnał hierarchii, ale unikasz problemów z duplikacją treści i upraszczasz zarządzanie.

Sufiks .html: zostawić czy usunąć

Domyślne URL-e produktów w PrestaShop mają rozszerzenie .html. Większość modułów pozwala je usunąć. Czy to ma znaczenie dla SEO?

Krótka odpowiedź: nie. Google traktuje adres z .html i bez niego identycznie pod względem rankingu. To kwestia czysto estetyczna i praktyczna. Adresy bez .html wyglądają nowocześniej i są krótsze. Jeśli zakładasz nowy sklep, nie ma powodu, żeby dodawać rozszerzenie.

Ale jeśli Twój sklep działa od lat i ma zaindeksowane tysiące stron z .html, usunięcie tego sufiksu to zmiana adresu każdej strony. Co oznacza konieczność przekierowań. Więcej o tym w następnej sekcji.

Wielojęzyczność i prefiksy językowe

PrestaShop w konfiguracji wielojęzycznej dodaje prefiks języka do URL-a (np. /pl/, /en/). Moduły Pretty URLs pozwalają kontrolować, czy ten prefiks jest wyświetlany dla domyślnego języka.

Jeśli Twój sklep działa tylko po polsku, prefiks /pl/ jest zbędny. Usunięcie go skraca adresy i upraszcza strukturę. Jeśli planujesz wersje wielojęzyczne, zostaw prefiksy dla wszystkich języków, żeby Google mógł poprawnie identyfikować wersje językowe i powiązać je przez hreflang.

Zmiana URL-i na żywym sklepie: jak stracić pozycje z dnia na dzień

To jest punkt, w którym najwięcej sklepów na PrestaShop popełnia kosztowny błąd. Instalacja modułu Pretty URLs i zmiana konfiguracji to operacja, która z dnia na dzień zmienia adres każdej strony w sklepie. Każdej. Produktów, kategorii, stron CMS, stron producentów, bloga.

Jeśli wczoraj Google znał Twoją stronę pod adresem /pl/456-koszulka-polo-meska.html, a dziś ta sama strona ma adres /mezczyzni/koszulki/koszulka-polo-meska, to z perspektywy wyszukiwarki to są dwie różne strony. Stara “znika” (błąd 404), nowa pojawia się jako nieznana. Wszystkie pozycje, cały autorytet zgromadzony przez stary URL przepada.

To nie jest teoria. Znam sklep, który w piątek po południu włączył moduł Pretty URLs “na szybko, bo i tak nikt nie będzie kupował w weekend”. W poniedziałek rano mieli o 70% mniej ruchu organicznego. Nikt nie przygotował przekierowań. Odbudowa zajęła pięć miesięcy, a na kilka fraz nigdy nie wrócili do poprzednich pozycji.

Dlaczego to się dzieje

Google nie wie automatycznie, że /pl/456-koszulka-polo-meska.html i /mezczyzni/koszulki/koszulka-polo-meska to ta sama strona. Musisz mu to powiedzieć explicite, przez przekierowanie 301 (trwałe). Bez tego przekierowania:

• stary URL zwraca 404, Google usuwa go z indeksu
• nowy URL jest traktowany jako świeża strona bez historii
• linki zewnętrzne prowadzące do starego URL-a przestają przekazywać autorytet
• wewnętrzne linki w zaindeksowanych stronach (w cache Google) prowadzą donikąd

Plan przekierowań: co przygotować przed zmianą

Zanim dotkniesz konfiguracji modułu URL na działającym sklepie, potrzebujesz kompletnego planu przekierowań. Procedura wygląda następująco.

Krok 1: eksport obecnych URL-i

Wyciągnij listę wszystkich aktualnych adresów ze sklepu. Źródła:

• crawl narzędziem typu Screaming Frog lub Sitebulb
• eksport z sitemap.xml
• eksport z Google Search Console (raport “Strony”)
• eksport z bazy danych PrestaShop (tabele ps_product_lang, ps_category_lang, ps_cms_lang)

Potrzebujesz listy URL-i dla: produktów, kategorii, stron CMS, producentów, dostawców i wpisów blogowych.

Krok 2: wygenerowanie nowych URL-i

Skonfiguruj moduł Pretty URLs na środowisku testowym (staging) i wygeneruj nowe adresy. Większość modułów ma funkcję podglądu lub testowego generowania URL-i bez ich aktywacji.

Krok 3: mapowanie stary URL -> nowy URL

Stwórz tabelę mapowania. Dla każdego starego adresu przypisz odpowiadający mu nowy. Narzędzia typu Excel lub Google Sheets wystarczą. Przy dużych katalogach (tysiące produktów) warto napisać skrypt, który automatycznie mapuje adresy na podstawie ID produktu.

Krok 4: implementacja przekierowań 301

Przekierowania możesz wdrożyć na kilka sposobów:

• przez moduł przekierowań w PrestaShop (np. 301 URL Redirect, SEO Expert)
• przez plik .htaccess na serwerze Apache
• przez konfigurację nginx (jeśli serwer na nim stoi)

Dla sklepów z dużą liczbą URL-i najwydajniejsze jest wdrożenie reguł w .htaccess lub nginx, bo nie obciąża to silnika PrestaShop. Moduły przekierowań działają na poziomie PHP, co dodaje narzut do każdego żądania.

Krok 5: weryfikacja przed wdrożeniem

Na środowisku testowym sprawdź:

• czy każdy stary URL zwraca kod 301 (nie 302) i kieruje na poprawny nowy adres
• czy nowe URL-e działają i wyświetlają właściwe strony
• czy sitemap.xml zawiera nowe adresy
• czy linki wewnętrzne w szablonach sklepu generują nowe URL-e

Aktualizacje modułów, które resetują konfigurację

No i wisienka na torcie. Problem specyficzny dla PrestaShop: aktualizacja modułu Pretty URLs (lub zamiennika) potrafi zresetować ustawienia konfiguracyjne. To szczególnie dotyczy modułów, które trzymają konfigurację w osobnej tabeli bazy danych. Aktualizacja może nadpisać tę tabelę nową strukturą, a dotychczasowe ustawienia znikają.

Jak się zabezpieczyć

• przed każdą aktualizacją modułu rób backup bazy danych (szczególnie tabel z konfiguracją modułu i wygenerowanymi URL-ami)
• dokumentuj aktualną konfigurację: zrzut ekranu każdej strony ustawień modułu
• po aktualizacji sprawdź, czy URL-e nadal działają poprawnie, zanim Google zdąży zaindeksować zmiany
• rozważ opóźnienie aktualizacji o kilka dni po premierze, żeby sprawdzić na forach, czy inni użytkownicy nie raportują problemów
• jeśli moduł zresetował URL-e, natychmiast przywróć backup i skontaktuj się z producentem modułu

Warto też wiedzieć, że aktualizacja samego PrestaShop (np. z 1.7.8 na 8.0) może zmienić sposób, w jaki system routingu przetwarza URL-e. Moduły, które działały poprawnie na starszej wersji, mogą wymagać przebudowy. Przed każdą aktualizacją silnika sklepu sprawdź kompatybilność modułu URL z docelową wersją.

Monitoring po zmianie URL-i

Zmiana konfiguracji URL-i to nie jest operacja “ustaw i zapomnij”. Przez pierwsze 4-6 tygodni po wdrożeniu musisz aktywnie monitorować sytuację.

Co śledzić

• Google Search Console: błędy crawlowania (zakładka “Strony”). Wzrost błędów 404 to sygnał, że mapa przekierowań jest niekompletna
• ruch organiczny: spadek o 5-15% w pierwszym tygodniu jest normalny; ruch powinien wracać do normy w ciągu 2-4 tygodni
• pozycje kluczowych fraz: monitoruj top 50 fraz, na które sklep był widoczny przed zmianą
• indeksacja nowych URL-i: sprawdzaj w Search Console, czy Google indeksuje nowe adresy i usuwa stare
• budżet crawlowania: jeśli masz duży sklep, obserwuj, czy Googlebot przeskanował nowe URL-e i przestał odpytywać stare

Kiedy reagować

Jeśli po 2 tygodniach ruch nie zaczął wracać do normy, szukaj przyczyny:

• czy wszystkie przekierowania działają (sprawdź losową próbkę 100 starych URL-i)
• czy nowe URL-e nie zwracają błędów 500 lub soft 404
• czy kanoniczne URL-e na nowych stronach wskazują na poprawne adresy
• czy sitemap.xml nie zawiera nadal starych adresów

Przy dużych sklepach na PrestaShop z tysiącami produktów warto rozłożyć zmianę URL-i na etapy: najpierw kategorie i strony CMS, potem produkty w partiach. To pozwala wcześnie wykryć problemy bez narażania całego sklepu.

Najczęstsze pytania

Czy mogę zmienić URL-e bez utraty pozycji?

Tak, ale wyłącznie wtedy, gdy przygotujesz kompletną mapę przekierowań 301 ze starych adresów na nowe. Przekierowanie musi być trwałe (301, nie 302), działać natychmiast po zmianie i obejmować wszystkie strony, nie tylko produkty. Kategorie, strony CMS, strony producentów i wpisy blogowe też muszą mieć przekierowania. Przy poprawnym wdrożeniu spadek ruchu powinien być minimalny i tymczasowy.

Który moduł Pretty URLs wybrać dla PrestaShop 8.x?

Nie ma jednej uniwersalnej odpowiedzi, bo kompatybilność zależy od wersji sklepu, szablonu i innych zainstalowanych modułów. Kluczowe kryteria: aktywne utrzymanie (aktualizacje w ciągu ostatnich 3 miesięcy), kompatybilność z Twoją wersją PrestaShop, mechanizm automatycznych przekierowań 301 przy zmianie formatu URL i wsparcie techniczne producenta. Przed zakupem sprawdź recenzje na marketplace PrestaShop i przetestuj moduł na środowisku staging.

Czy usunięcie .html z URL-i poprawi moje SEO?

Samo usunięcie sufiksu .html nie wpłynie na rankingi. Google traktuje adresy z rozszerzeniem i bez niego identycznie. Ale zmiana sufiksu to zmiana adresu, która wymaga przekierowań 301. Jeśli Twój sklep ma zaindeksowane tysiące stron z .html, kalkulacja jest prosta: potencjalna korzyść estetyczna versus realny koszt i ryzyko migracji URL-i. Dla istniejących sklepów zwykle nie warto. Dla nowych sklepów nie ma powodu, żeby dodawać .html.

Co zrobić, gdy aktualizacja modułu zmieniła mi URL-e bez ostrzeżenia?

Natychmiast przywróć backup bazy danych sprzed aktualizacji. Jeśli nie masz backupu (a to oznacza, że musisz zmienić procedury), sprawdź w module, czy da się ręcznie przywrócić poprzednią konfigurację. Następnie w Google Search Console sprawdź, czy Googlebot zdążył zaindeksować zmienione adresy. Jeśli tak, wdróż przekierowania 301 ze “złych” URL-i na poprawne. Im szybciej zareagujesz, tym mniejsze straty. Każdy dzień z nieprzekierowanymi adresami to stracony ruch i autorytet.