Przy migracji PrestaShop z 1.7 na 8, przy zmianie motywu, przy reorganizacji struktury albo po prostu przy modyfikacji sluga produktu setki, a nawet tysiące adresów URL zmieniają się po cichu. Każdy z tych adresów gromadzi moc SEO i linki przychodzące, a być może figuruje w wynikach Google na dobrej pozycji. Bez przekierowania 301 na nowy adres ten kapitał znika.
Najgorsze jest to, że strata nie następuje natychmiast. Widzisz, jak ruch powoli spada przez 3 do 6 tygodni, bez wyraźnej awarii. Zanim zrozumiesz, straciłeś od 30 do 50 % ruchu SEO, a odzyskanie go zajmie od 6 do 12 miesięcy, o ile w ogóle się uda.
Ten artykuł rozkłada na części mechanikę przekierowań 301 w PrestaShop: co robi rozwiązanie natywne, czego nie ogarnia, jak wdrożyć porządny monitoring 404 i jak zautomatyzować odruch „zmiana sluga oznacza przekierowanie 301”.
Dlaczego przekierowania 301 są krytyczne dla SEO
Przekierowanie 301 („Moved Permanently”) mówi Google i użytkownikom: ten adres przeniósł się na stałe, oto nowy. Google przekazuje wtedy PageRank, historię adresu i zgromadzone linki zwrotne. Nowy adres dziedziczy kapitał SEO.
Bez 301 pierwotny adres zwraca 404 („Not Found”). Google kolejkuje stronę do wyindeksowania, linki zwrotne wskazują w pustkę, a PageRank się rozprasza. Po 3 do 6 miesięcy adres znika z indeksu. Kapitał przepada.
Kilka liczb z audytów sklepu po migracji bez porządnej obsługi 301:
- Od 40 do 60 % zaindeksowanych przez Google adresów zwraca 404 w ciągu 6 miesięcy.
- Ruch SEO spada o 25 do 50 % w kolejnym kwartale.
- Pozycje na zapytaniach z długiego ogona (często najbardziej dochodowych) załamują się jako pierwsze.
- Zewnętrzne linki zwrotne (prasa, blogi, katalogi) stają się nieaktualne i tracą swoją moc.
Co PrestaShop obsługuje natywnie (i czego nie ogarnia)
Natywny moduł SEO i adresy URL
PrestaShop 8 i 9 udostępnia zakładkę „Przekierowania” w Preferencje, Ruch, SEO i adresy URL. Pozwala ręcznie dodawać przekierowania 301, 302 i 410 parami (adres źródłowy, adres docelowy).
Ograniczenia:
- Brak obsługi wyrażeń regularnych i symboli wieloznacznych. Aby przekierować całą dawną kategorię
/stare-produkty/*na/promocje/, trzeba tworzyć każdy adres ręcznie. - Brak automatycznego przekierowania przy zmianie sluga. Jeśli zmienisz slug produktu, stary adres idzie w 404 bez przekierowania.
- Brak monitoringu 404 na adresach faktycznie odwiedzanych.
- Ograniczona wydajność. Powyżej kilku tysięcy przekierowań moduł spowalnia routing.
- Brak importu i eksportu w CSV do obsługi masowej.
Plik .htaccess
Alternatywa ręczna: pisanie reguł RewriteRule w pliku .htaccess. Wydajne (Apache przetwarza reguły wcześniej), ale:
- Wrażliwe na błędy składni (źle postawiony przecinek i cała witryna leci w 500).
- Trudne w utrzymaniu dla osób nietechnicznych.
- Nie działa na nginx, który używa własnej składni.
- Brak interfejsu w zapleczu i brak śladu zmian.
Stack, który powinniśmy mieć
1. Automatyczne przekierowanie przy zmianie sluga
Gdy produkt, kategoria albo strona CMS zmienia slug, stary adres musi automatycznie zapisać 301 na nowy. Żadnej ręcznej operacji, żadnego ryzyka przeoczenia. To zabezpieczenie numer jeden.
2. Monitoring błędów 404
Wszystkie adresy zwracające 404 muszą być logowane wraz z częstością i odsyłaczem. Adres wywoływany 200 razy miesięcznie z błędem 404 to problem do potraktowania priorytetowo. Adres z 404 raz do roku może poczekać.
3. Masowe przekierowania przez wyrażenia regularne i symbole wieloznaczne
Przy migracjach potrzebujemy wzorców. Regułę /stara-kategoria/(.*) → /nowa-kategoria/$1 trzeba móc skonfigurować jednym wpisem, a nie dwustoma.
4. Import i eksport CSV
Przed migracją przygotowujemy tabelę odwzorowań w CSV na podstawie eksportu starej i nowej mapy witryny. Importujemy jednym ruchem, zamiast wpisywać ręcznie.
5. Wykrywanie łańcuchów przekierowań
Adres przekierowujący na adres, który przekierowuje na kolejny adres, to antywzorzec SEO. Google deprecjonuje łańcuchy dłuższe niż 2 przeskoki. Dobre narzędzie wykrywa i sygnalizuje łańcuchy.
6. Ślad zmian i audyt
Kto utworzył dane przekierowanie, kiedy i z jakiego powodu? W razie problemu (spadek ruchu po migracji) możliwość zaudytowania reguł 301 jest kluczowa.
Przypadek szczególny: zmiana sluga produktu
W aktywnym sklepie slugi zmieniają się nieustannie. Produkt o zmieniającej się nazwie („Sukienka letnia 2025” na „Sukienka lniana letnia 2025”), optymalizacja SEO tytułu, poprawka literówki: każda modyfikacja pola link_rewrite w ps_product_lang zmienia adres kanoniczny.
Jeśli 301 nie powstaje automatycznie, stary adres idzie w 404. W ciągu 12 miesięcy, przy katalogu 5 000 produktów i 10 % zmienionych slugów, daje to 500 „utraconych” adresów. Jeśli każdy z nich ściągał średnio 50 wizyt miesięcznie, mówimy o 25 000 wizyt SEO traconych rocznie, bez żadnej widocznej awarii.
Właściwy odruch: hook na actionObjectProductUpdateAfter, który wykrywa zmianę link_rewrite i automatycznie tworzy 301, per język i per sklep w trybie multisklep.
Pułapka łańcuchów przekierowań
Klasyczny scenariusz: produkt A zmienia slug trzykrotnie w ciągu 6 miesięcy. Bez precyzyjnej obsługi kończy się to tak:
/slug-1.html → /slug-2.html/slug-2.html → /slug-3.html/slug-3.html → /slug-4.html
Zapytanie o pierwszy adres wykonuje 3 przeskoki, zanim dotrze do celu. Google deprecjonuje łańcuchy dłuższe niż 2 przekierowania. Budżet crawlu jest zużywany bez potrzeby, a PageRank rozprasza się przy każdym przeskoku (od 5 do 10 % straty na przeskok według analiz Moz).
Zasada: spłaszczać łańcuchy. Gdy powstaje nowe przekierowanie, system musi sprawdzić, czy adres źródłowy nie był już celem innego 301, i przepisać stare tak, aby wskazywało wprost na nowy cel. Koniec łańcucha, koniec przeskoków.
Nasz moduł dfredirects: kompletny menedżer 301
Wdrożenie tego stacku ręcznie wymaga od 7 do 12 dni pracy deweloperskiej w PrestaShop, plus utrzymanie. Nasz moduł dfredirects dla PrestaShop 8 i 9 uprzemysławia całą tę mechanikę:
- Przekierowania 301, 302 i 410 konfigurowalne z zaplecza, z filtrowalnym i stronicowanym interfejsem.
- Wzorce z wyrażeniami regularnymi i symbolami wieloznacznymi: jedna reguła może pokryć setki adresów (
/old-cat/(.*)$ → /new-cat/$1). - Automatyczne przekierowanie przy zmianie sluga produktu, kategorii, producenta, dostawcy i strony CMS, wielojęzycznie i w trybie multisklep.
- Monitoring 404 z częstością, ostatnią wizytą i odsyłaczem. Sortowanie po wolumenie pozwala priorytetyzować.
- Automatyczne spłaszczanie łańcuchów: żadnych przekierowań kaskadowych.
- Import i eksport CSV do obsługi masowej przed migracją.
- Ślad zmian: autor, data i opcjonalny powód per reguła.
- Zgodność z PS 8 i 9, bez zależności od Apache i pliku .htaccess (działa także na nginx).
- Wydajność: zoptymalizowana tabela z indeksami, do 100 000 reguł bez pogorszenia.
Za 49 € unikasz utraty ruchu po migracji i zakładasz trwałe zabezpieczenie przed dryfem 404.
Procedura migracji bezpiecznej dla SEO
Krok po kroku, procedura, którą stosujemy przy migracjach PrestaShop z 1.7 na 8 oraz przy dużych przebudowach:
- Przed migracją: eksport starej mapy witryny sitemap.xml. Zawiera wszystkie zaindeksowane adresy.
- Pełny crawl starej witryny narzędziem Screaming Frog albo równoważnym, aby zebrać wszystkie adresy, w tym strony spoza mapy (filtry, stronicowanie).
- Odwzorowanie stare na nowe w CSV: każdy stary adres dostaje swój nowy odpowiednik. Dla adresów, które zniknęły, wybierz sensowny cel zastępczy (kategoria nadrzędna, w ostateczności strona główna).
- Import CSV do dfredirects przed przełączeniem albo w jego trakcie.
- Test: 50 losowych adresów zweryfikowanych jako 301 bezpośrednio, bez łańcucha, na właściwy cel.
- Przesłanie nowej mapy sitemap.xml do Google Search Console.
- Codzienny monitoring 404 przez pierwszy miesiąc: każdy powtarzalny błąd 404 zamieniamy na 301.
- Audyt po 30, 60 i 90 dniach: pokrycie w Search Console, utracone zapytania, weryfikacja stabilności ruchu.
FAQ
Jaka jest różnica między 301 a 302?
301 jest trwałe i przekazuje PageRank. 302 jest tymczasowe i go nie przekazuje. Przy migracji albo zmianie sluga zawsze używaj 301. 302 jest zarezerwowane dla przypadków jawnie tymczasowych: prace serwisowe, testy A/B, przekierowania sezonowe.
A co z kodem 410 (Gone)?
410 mówi Google: ten adres już nie istnieje i nie wróci, wyindeksuj natychmiast. Szybsze niż 404 przy porządkowaniu indeksu. Przydatne dla produktów wycofanych na stałe, bez odpowiednika. Stosować jednak oszczędnie, bo po zwróceniu 410 PageRank przepada.
Ile czasu Google potrzebuje na uwzględnienie 301?
Crawl starego adresu przez Google może zająć od kilku dni do kilku tygodni, zależnie od częstotliwości odwiedzin robota. Pełne przekazanie PageRank na nowy adres zajmuje w praktyce od 1 do 3 miesięcy. Przesłanie nowej mapy witryny przyspiesza ten proces.
Czy można jednocześnie przekierować na HTTPS i zmienić domenę?
Tak, i jest to nawet częste. Jedno przekierowanie 301 może łączyć protokół (HTTP na HTTPS), domenę (stara.pl na nowa.pl) i ścieżkę. Zasada: jedno 301 na adres, nie łańcuch. Spłaszczać maksymalnie.
Czy przekierowania wpływają na wydajność?
Proste 301 dokłada około 100 do 200 ms do czasu odpowiedzi przy pierwszym żądaniu. Przy cache przeglądarki (nagłówek Cache-Control na 301) kolejne wizyty trafiają wprost na nowy adres, bez przeskoku. Koszt jest pomijalny poza wielokrotnymi łańcuchami. Łańcuch 3 przeskoków potrafi natomiast dołożyć 500 ms, stąd potrzeba spłaszczania.
Aby pójść dalej
Obsługa przekierowań to jeden z filarów migracji bezpiecznej dla SEO. Zobacz także naszą kompletną listę kontrolną migracji PrestaShop z 1.7 na 8, gdzie przekierowania 301 są ósmym krokiem procedury, oraz nasz przewodnik po SEO w e-commerce 2026 po pełny obraz SEO w PrestaShop. Trzy uzupełniające się artykuły na ten sam temat: przygotować, wykonać, zabezpieczyć.
Przeczytaj także: Indexing API, IndexNow i boty AI.
Aby przejść do działania: nasz wybór modułów SEO technicznego dla PrestaShop.
