Czym są friendly URL w PrestaShop i co realnie dają

Adres surowy i adres przyjazny prowadzą do tego samego zasobu — różni je wyłącznie zapis. Surowy: ?controller=product&id_product=12. Przyjazny: /buty/nike-air-max-90.html. Serwer obsłuży oba, ale tylko drugi wkleisz do maila, opisu kampanii Google Ads czy posta na Facebooku bez tłumaczenia klientowi, co znaczy ciąg znaków z pytajnikiem.

Google traktuje słowa w adresie jako sygnał pomocniczy, a nie samodzielny czynnik rankingowy. W dokumentacji Google Search Central o tworzeniu treści dla ludzi nie ma obietnicy skoku pozycji za samą zmianę URL-a — liczy się treść i intencja użytkownika, nie konstrukcja adresu.

Co realnie zyskujesz po wdrożeniu:

• Wyższy CTR w SERP. W wyniku widać /buty/nike-air-max-90.html zamiast ?controller=product&id_product=12. Użytkownik wie, gdzie trafi, i częściej klika.
• Linki, które da się użyć. Krótszy adres nie łamie się w mailu ani w SMS-ie. W kampaniach e-mail skracacze przestają być konieczne.
• Czytelniejsza analityka. W GA4 raport „Strony i ekrany” pokazuje /buty, a nie listę parametrów — łatwiej porównać kategorie i kampanie.

Rozróżnienie, które oszczędza rozczarowań: friendly URL to techniczna warstwa routingu. Mapuje adres na kontroler i parametry po stronie PrestaShop. Nie zastępuje title, meta description, treści kategorii ani danych strukturalnych. Sklep z idealnymi adresami i pustymi opisami nadal nie będzie widoczny. To jeden element z wielu — punkt startu do całości prac znajdziesz w naszym wdrożeniowym hubie PrestaShop.

Jak włączyć friendly URL w PrestaShop — krok po kroku

W PrestaShop 1.7, 8 i 9 ścieżka jest identyczna: Konfiguracja sklepu → Ruch i SEO (Shop Parameters → Traffic & SEO). W sekcji „Ustawienia URL” znajdziesz przełącznik Przyjazne URL. Zanim go włączysz, załatw trzy rzeczy:

1. mod_rewrite na Apache. Bez niego plik .htaccess nic nie zrobi. Na serwerze sprawdź: apache2ctl -M | grep rewrite — musi pojawić się rewrite_module.
2. Kopię .htaccess. Kliknięcie „Zapisz” regeneruje plik i nadpisuje Twoje dopiski: reguły cache, przekierowania 301, blokady botów. Skopiuj plik przed zmianą.
3. Zrzut bazy i plików. Jeśli coś pójdzie nie tak, wrócisz w kilkanaście minut, a nie w kilka godzin.

Po włączeniu przełącznika wyczyść cache: Parametry zaawansowane → Wydajność → Wyczyść cache. Jeśli przed sklepem stoi Cloudflare lub inny CDN, wyczyść też jego cache — inaczej w podglądzie zobaczysz stare adresy i uznasz, że zmiana nie zadziałała.

Test na trzech adresach — strona główna, kategoria, produkt. Zrób to przed i po zmianie: curl -I https://twojsklep.pl/buty/nike-air-max-90.html. Oczekujesz 200 OK i braku pętli przekierowań. Jeśli produkt zwraca 404, w 9 na 10 przypadków nie wygenerował się .htaccess albo brakuje mod_rewrite.

Nginx. Nie czyta .htaccess. Musisz dopisać w konfiguracji serwera przekierowanie na index.php, np. try_files $uri $uri/ /index.php?$args;. Bez tego każdy przyjazny adres zwróci 404, choć w panelu wszystko wygląda poprawnie. Wymagania środowiska — wersje PHP, rozszerzenia, uprawnienia — opisaliśmy w artykule o wymaganiach serwera dla PrestaShop.

Wzorce tras (route patterns) — jak zbudować strukturę URL

Wzorce tras sterują kształtem adresu. Ustawiasz je w Konfiguracja sklepu → Ruch i SEO → Ustawienia URL, w sekcji „Wzorce”. Każdy placeholder ma ściśle określone znaczenie — pomylenie ich to najczęstsza przyczyna adresów z powtórzonym slugiem albo bez kategorii.

• {id} — numeryczne ID zasobu (produktu, kategorii).
• {rewrite} — slug wygenerowany z nazwy, np. nike-air-max-90.
• {category} — slug bieżącej kategorii.
• {categories} — pełna ścieżka kategorii nadrzędnych, np. buty/sportowe.
• {-:ean13} — opcjonalny segment z kodem EAN; gdy pole jest puste, segment w ogóle nie pojawia się w adresie.

Domyślna trasa produktu to {categories:/}{id}-{rewrite}{-:ean13}.html, co daje np. /buty/sportowe/nike-air-max-90-12.html. Końcówka .html to kosmetyka — PrestaShop i tak renderuje stronę dynamicznie. Daje wrażenie statycznej strony i wiele sklepów tego oczekuje. Ważne: nie mieszaj konwencji (raz .html, raz bez) na jednym sklepie, bo potem mnożą się przekierowania.

Kolejność tras to pułapka numer jeden. Reguły dopasowywane są od góry do dołu — pierwsza pasująca wygrywa. Jeśli ogólna reguła /{rewrite} trafi nad regułę kategorii, przechwyci jej adresy i produkty przestaną się rozwiązywać. Szczegółowe reguły wyżej, ogólne niżej.

Głębokość kategorii. Każdy poziom to kolejny slug. Pięć poziomów po 20 znaków daje ponad 100 znaków plus ID i slug produktu. Techniczny limit PrestaShop to 2048 znaków, ale w SERP widać kilkadziesiąt — adres staje się nieczytelny i traci sens, dla którego go włączasz. Rozwiązanie: skrócić ścieżkę w trasie albo przeprojektować drzewo kategorii. Zmiana wzorca wymaga zapisu i regeneracji .htaccess, a to unieważnia wszystkie stare adresy — przed wdrożeniem na działającym sklepie przygotuj mapę przekierowań 301; plan takich prac opisujemy w artykule o migracji PrestaShop 1.7 do 9. Dokumentacja deweloperska PrestaShop opisuje routing w module Dispatcher: PrestaShop Developer Documentation.

Usuwanie ID z adresów URL — kiedy warto, a kiedy to pułapka

W PrestaShop wzorzec adresu produktu ustawiasz w Ustawienia sklepu → Ruch → SEO i URL, w tabeli tras. Domyślna trasa produktu wygląda tak: {category:/}{id}-{rewrite}{-:ean13}.html, czyli w praktyce /buty/12-nike-air-max-90.html. Usunięcie {id} daje krótszy adres, który lepiej wygląda w mailu i w kampanii, ale zmienia zasady działania trzech mechanizmów.

Kolizje nazw. Sklep odzieżowy miewa dwa produkty o tej samej nazwie, wpisane jako osobne ID (145 i 312). Oba dostają link_rewrite równy koszulka-bawelniana. Bez {id} drugi produkt nie ma czym się odróżnić w adresie — PrestaShop dopisze końcówkę zależną od kolejności importu albo nadpisze istniejący wpis trasy. W katalogu powyżej 2000 SKU z powtarzalnymi nazwami („Torba M”, „Torba L”, „Etui 128 GB”) kolizje są regułą, nie wyjątkiem.

Zmiana nazwy = zmiana adresu. Przy {id} możesz poprawić nazwę produktu, a stary link nadal doprowadzi do celu, bo identyfikatorem pozostaje liczba. Bez {id} każda korekta literówki generuje nowy adres, a PrestaShop nie tworzy przy tym automatycznego przekierowania. Linki z artykułów branżowych, katalogów firm i starych kampanii lądują na 404 — i to są zwykle właśnie te linki, które budowały widoczność.

Test kolizji w 15 minut. Wyeksportuj produkty (Katalog → Produkty → Eksport) albo pobierz dane przez Zaawansowane → SQL Manager zapytaniem SELECT link_rewrite, COUNT(*) FROM ps_product_lang GROUP BY link_rewrite HAVING COUNT(*) > 1. W arkuszu dodaj kolumnę =LICZ.JEŻELI(A:A;A2) i odfiltruj wartości większe od 1. Wynik powyżej zera oznacza, że bez {id} problem masz pewny.

Rekomendacja: zostaw {id}. Rezygnuj tylko wtedy, gdy istnieje realny powód i kontrola nad nazewnictwem, czyli jedna osoba pilnująca, że żadna nazwa się nie powtórzy. Jeśli adresy bez ID już wdrożono i widzisz 404, ustaw w .htaccess regułę 301 mapującą adres z ID na wersję bez ID (Apache: RewriteRule, nginx: return 301) i przetestuj ją przed przełączeniem trasy. Szczegóły techniczne tras opisuje dokumentacja dla deweloperów PrestaShop.

Wielojęzyczność i wielosklepowość — prefiksy /pl/, /en/ i hreflang

Języki dodajesz w Międzynarodowy → Lokalizacja → Języki, a prefiks w trasach ustawiasz w Ustawienia sklepu → Ruch → SEO i URL. Każda trasa ma osobny wpis dla każdego języka — dotyczy to produktów, kategorii, stron CMS i stron sklepu. Tłumaczenie sluga robisz w karcie produktu, w zakładce SEO: przełącznikiem języka u góry zmieniasz pole „Przyjazny URL” osobno dla PL i EN. To samo ustawienie jest w kategorii. Efekt jest taki, że /pl/buty/nike-air-max-90.html i /en/shoes/nike-air-max-90.html to dwa niezależne adresy, obsługiwane oddzielnie przez router.

Przekierowanie po IP — nie rób tego. Geolokalizacja w PrestaShop (Międzynarodowy → Lokalizacja) potrafi przekierować użytkownika na język kraju, z którego przychodzi. Problem: robot Google najczęściej wchodzi z adresów amerykańskich, więc zobaczy wersję EN, a nie PL, i zaindeksuje niewłaściwą treść. Klient z zagranicy z VPN-em też zobaczy sklep, którego nie chciał. Zamiast przekierowania postaw dyskretny baner z wyborem języka i zapisz decyzję w cookie. Wersja językowa ma być dostępna pod swoim adresem zawsze, bez pośrednich kroków.

Canonical i hreflang. Zasada brzmi: jeden język = jeden URL. PrestaShop generuje znaczniki hreflang na podstawie aktywnych języków, ale wymaga to poprawnych kodów ISO (pl-PL, en-GB, de-DE) i przetłumaczonych slugów. Canonical musi wskazywać na wersję tego samego języka, w której się znajduje — nie na polską. Wersję domyślną oznacz jako x-default. Jeśli po starej konfiguracji ten sam tekst odpowiada i pod /pl/produkt, i pod /produkt, masz duplikat do wyczyszczenia przekierowaniem.

Zmiana URL bez utraty ruchu: 301, canonical i sitemap

Migracja adresów bez planu kończy się wypadnięciem części katalogu z indeksu na kilka tygodni. Kolejność działań jest odwrotna do intuicji: najpierw przekierowania, dopiero potem przełącznik w panelu.

1. Inwentaryzacja. Crawl obecnej wersji sklepu (darmowa wersja Screaming Frog obsłuży do 500 adresów, większe sklepy crawlem partiami) plus eksport URL-i z sitemap.xml. Zapisujesz te ze statusem 200 w kolumnie old_url.
2. Mapowanie w CSV. Dwie kolumny: old_url i new_url, jeden wiersz na adres. Przy 3000 produktów to jedno popołudnie pracy na eksporcie z bazy, a nie ręczne klikanie.
3. Wdrożenie 301 przed zmianą. Reguły w .htaccess (Apache) lub w konfiguracji nginx, umieszczone przed regułami PrestaShop. Każdy adres testuj osobno: curl -I https://sklep.pl/stary-adres musi zwrócić kod 301 i nagłówek Location z nowym adresem.
4. Zmiana wzorców tras w SEO i URL dopiero teraz.

Duplikacja /kategoria/produkt i /produkt. Jeśli wzorzec zawiera {category:/}, a produkt siedzi w dwóch kategoriach, powstają dwa adresy tej samej treści: /obuwie/nike-air-max-90 i /wyprzedaz/nike-air-max-90. Wybierz wersję główną i pilnuj, by canonical wskazywał właśnie na nią. Bez tego Google zdecyduje sam — i podlinkowany zostanie adres, którego nie kontrolujesz.

Sitemap i monitoring. Wygeneruj sitemap od nowa, sprawdź, czy nie ma w niej starych adresów, i zgłoś nową wersję w Search Console (Sitemaps). Potem raport Indeksowanie: przez 2–4 tygodnie sprawdzaj, czy liczba błędów 404 nie rośnie. Krótkotrwały wzrost po migracji 2000-stronicowego sklepu jest normalny; utrzymujący się po dwóch tygodniach oznacza brakującą regułę przekierowania.

Najczęstsze błędy: 404, pętle przekierowań, 500 — jak diagnozować

Zanim cokolwiek zmienisz w panelu, sprawdź stan obecny. Jedno polecenie w terminalu: curl -I https://twojsklep.pl/nowy-url. Pierwsza linia odpowiedzi to kod statusu, druga to nagłówek Location przy przekierowaniu. 200 — adres działa. 301 lub 302 — sprawdź, gdzie prowadzi Location. 404 — brak reguły. 500 — błąd serwera, nie routingu. Testuj na pojedynczych adresach, nie na stronie głównej: tam wszystko zwykle działa.

404 po zmianie wzorca URL to najczęstszy scenariusz. PrestaShop wygeneruje nowe adresy produktów i kategorii, ale nie stworzy przekierowań ze starych. Brak reguły w .htaccess oznacza, że każdy link z Google, maila i kampanii zwraca 404. Nie dopisuj setek reguł ręcznie — wyeksportuj stare i nowe adresy, dopasuj je po ID produktu i wstaw jako osobny blok przed regułami PrestaShop.

Pętla przekierowań prawie zawsze wynika z mieszania wersji domeny i protokołu: sklep ustawiony na http://twojsklep.pl, w .htaccess wymuszone HTTPS, a przed serwerem CDN w trybie elastycznego SSL. Serwer dostaje żądanie po HTTP, przekierowuje na HTTPS, proxy znów oddaje HTTP — przeglądarka zatrzymuje się po kilku iteracjach. Kolejność ma znaczenie: najpierw jedna reguła kanoniczna (HTTPS plus wybrana wersja www albo bez www), potem reguły PrestaShop. Domena w Parametry sklepu → Ruch i SEO (w 1.6: Preferencje → SEO i URL) musi być zgodna z tym, co wymusza .htaccess.

500 po regeneracji .htaccess: przywróć plik z kopii i wróć do działającego stanu, dopiero potem czytaj logi — error_log Apache lub log PHP z panelu hostingu. Najczęściej to błędna dyrektywa, brak RewriteBase albo nieobsługiwany moduł. Zanim włączysz przyjazne URL na produkcji, sprawdź mod_rewrite: blok <IfModule mod_rewrite.c> w .htaccess plus prosta reguła testowa przekierowująca /test-rewrite na stronę główną. Jeśli zwraca 404, hosting nie ma włączonego modułu i dalsza konfiguracja nie ma sensu. Więcej o kolejności prac przy wdrożeniu i konfiguracji PrestaShop opisaliśmy osobno.

Friendly URL a SEO techniczne i szybkość — co ma znaczenie

Powtarzany mit: przyjazne URL przyspieszają sklep. Nie. Zamiana ?controller=product&id_product=12 na /buty/nike-air-max-90.html to operacja na łańcuchu znaków — koszt rzędu ułamka milisekundy. Za szybkość odpowiadają cache szablonów i zapytań, CDN, wersja PHP i indeksy w bazie. Jeśli po włączeniu friendly URL sklep zwalnia, szukaj przyczyny w konfiguracji serwera, nie w routingu. Punkt odniesienia to Core Web Vitals — LCP, INP i CLS mierzą realne doświadczenie użytkownika, a nie kształt adresu. Warto przy okazji sprawdzić wymagania serwera i PHP dla PrestaShop, bo stara wersja PHP kosztuje więcej wydajności niż jakakolwiek zmiana w routingu.

Canonicalizacja filtrów, sortowania i paginacji to realne ryzyko, nie teoria. Moduł filtrów generuje adresy typu /buty?q=Kolor-Czerwony, sortowanie dokłada ?orderby=price, paginacja ?page=3. Każda kombinacja to osobny adres, który Google może zaindeksować jako duplikat kategorii. Ustaw tag canonical tak, by wskazywał na adres bazowy kategorii bez parametrów, i sprawdź w panelu modułu filtrów, czy nie tworzysz setek indeksowalnych wariantów. Ten sam produkt w trzech kategoriach to ten sam problem — wybierz jedną ścieżkę kanoniczną.

Kiedy potrzebny własny routing. Standardowy mechanizm PrestaShop (klasy Link i Dispatcher) wystarcza większości sklepów. Własny moduł z trasą i front controllerem wchodzi w grę, gdy przebudowujesz drzewo kategorii i chcesz zachować inne adresy niż wynikające z hierarchii, potrzebujesz adresów landingowych pod kampanie, prowadzisz kilka sklepów lub języków i musisz kontrolować prefiksy oraz hreflang, albo ERP wymusza adres z wewnętrznym kodem towaru.

Integracje to najczęstsze miejsce awarii. Link do produktu żyje w mailu transakcyjnym, w feedzie dla porównywarki, w szablonie oferty w ERP i w stopce newslettera. Po zmianie wzorca te miejsca nadal wysyłają stare adresy. Przed wdrożeniem wypisz wszystkie systemy generujące linki, a po zmianie wymuś pełną regenerację feedu i szablonów maili.

Checklista wdrożenia friendly URL w PrestaShop

Kolejność jest ważniejsza niż narzędzia. Każdy krok zakłada, że poprzedni został zamknięty i sprawdzony.

1. Kopia zapasowa — pliki (w tym .htaccess), baza przez mysqldump, zrzut ustawień SEO. Odtwórz kopię na staging, zanim uznasz ją za backup.
2. Test na staging — subdomena zablokowana przed indeksowaniem (hasło w .htpasswd lub noindex). Tam włączasz przyjazne URL, generujesz .htaccess i testujesz 20-30 najważniejszych adresów: produkt, kategorię, stronę CMS, wyszukiwarkę, koszyk.
3. Mapa przekierowań 301 gotowa przed zmianą wzorca na produkcji, nie po niej.
4. Wdrożenie na produkcji w oknie niskiego ruchu — np. 2:00-4:00, nigdy w dniu wysyłki newslettera.
5. Sitemap i Search Console — regeneracja pliku, ponowne zgłoszenie, monitoring błędów 404 przez 30 dni.
6. Logi 404 przez 2-4 tygodnie i dopisywanie brakujących przekierowań.

Kto odpowiada za 301. Osoba wdrażająca konfigurację, nie dział marketingu. Reguła praktyczna: przekierowanie zdejmuj dopiero wtedy, gdy przez trzy kolejne miesiące w logach jest zero trafień na stary adres. Linki z maili sprzed dwóch lat i z wpisów na forach żyją dłużej, niż się wydaje.

Moment na dewelopera. Wchodzi w grę przy zmianie wersji lub struktury sklepu — to opisaliśmy w materiale o migracji do PrestaShop krok po kroku — a także przy przebudowie drzewa kategorii, konfiguracji wielu sklepów i języków, niestandardowych trasach oraz integracji z ERP. W prostym sklepie z jedną domeną i stabilną strukturą wystarczy poprawny .htaccess i mapa przekierowań.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Potwierdź mod_rewrite i zapis do .htaccess — Zrób to przed włączeniem opcji. Jeśli hosting tego nie wspiera, friendly URL nie zadziała, a sklep zwróci 404.
• Zrób kopię .htaccess i bazy danych — Przed każdą zmianą tras. Rollback bez kopii oznacza ręczne odtwarzanie reguł.
• Włącz „Przyjazne URL” — Konfiguracja sklepu → Ruch i SEO. Po zapisaniu od razu wyczyść cache.
• Przetestuj trzy adresy: główna, kategoria, produkt — W trybie incognito, przed i po włączeniu. Porównaj adresy i kody odpowiedzi.
• Sprawdź wzorce tras (route patterns) — Przejrzyj produkty, kategorie i pozostałe trasy. Usuń to, czego nie chcesz w adresach.
• Ustaw kolejność tras — Reguły szczegółowe przed ogólnymi. Weryfikacja: otwórz produkt i sprawdź, którą trasą się wyświetla.
• Zmierz długość adresów — Limit techniczny to 2048 znaków, ale praktyczny cel to poniżej 100. Głębokie kategorie rozdmuchują URL — sprawdź najdłuższe przypadki.
• Wyklucz duplikaty slugów — Eksport produktów do CSV i porównanie slugów zajmuje kilkanaście minut. Zrób to przed rozważeniem usunięcia {id}.
• Ustal, czy usunięcie {id} ma sens — Tylko jeśli masz kontrolę nad nazewnictwem i unikalne slugi. Inaczej zostaw {id} i nie ryzykuj kolizji.
• Sprawdź wersje językowe i sklepy — Prefiksy /pl/, /en/, poprawny canonical i hreflang — jedna wersja językowa to jeden adres.
• Zweryfikuj przekierowania 301 — Po zmianie adresów przetestuj losowo kilkanaście starych URL-i. Każdy musi prowadzić na działającą stronę.
• Zgłoś nową sitemap — W Google Search Console, zaraz po wdrożeniu zmian. Sitemap musi zawierać wyłącznie adresy finalne.
• Popraw linki w mailach, kampaniach i social media — To najczęściej pomijany krok. Stare linki w newsletterach i postach nie mają automatycznego 301.
• Monitoruj GSC przez 2–4 tygodnie — Sprawdzaj raport 404 i liczbę kliknięć. Reaguj, jeśli pojawi się skok błędów.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• Google Search Central – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów
• MDN Web Docs – HTTP