Przekierowania 301 i 404 po migracji: co sprawdzić

Co traci sklep, gdy zmieniają się adresy

Wyszukiwarki, linki zewnętrzne, zakładki i kampanie wskazują na konkretne adresy. Jeśli po migracji lub zmianie adresów URL te adresy zwracają 404, Google ich nie indeksuje: według jego dokumentacji adresy URL zwracające kod 4xx nie są indeksowane, a te już zaindeksowane są usuwane z indeksu. Przekierowanie stałe informuje natomiast, że strona istnieje i została przeniesiona: Google wykorzystuje je jako sygnał, że miejsce docelowe jest kanonicznym adresem URL, i twierdzi, że przekierowania 301 i inne przekierowania stałe nie powodują utraty PageRank. Ile ruchu traci się w praktyce, zależy od witryny, dlatego mierzy się to w Search Console, zamiast polegać na ogólnych liczbach.

Kody HTTP, które mają znaczenie

Ten sam RFC wyjaśnia, że 410 jest lepszy niż 404, gdy serwer wie, że stan jest prawdopodobnie trwały.

Co robi sam PrestaShop 9.1

Poniższe informacje zweryfikowano w kodzie PrestaShop 9.1.5, a pliki wymieniono w źródłach.

Przekieruj do kanonicznego URL

W sekcji Preferencje, Ruch, Ustaw URL-e opcja „Przekieruj do kanonicznego URL” (PS_CANONICAL_REDIRECT) przyjmuje wartość 0 (brak przekierowania), 1 (302) lub 2 (301). W FrontController, dla żądań GET, jeśli żądany adres URL nie pokrywa się z kanonicznym, PrestaShop odpowiada kodem 301, gdy opcja ma wartość 2, w przeciwnym razie kodem 302, a przy 0 nic nie robi. Oficjalna dokumentacja zaleca 301 po zakończeniu zmian i ostrzega, że bez przekierowania mogą powstać zduplikowane adresy URL. W trybie deweloperskim zamiast przekierowania pojawia się strona debugowania: warto o tym pamiętać podczas testów.

Zmiana sluga produktu lub kategorii

Reguły domyślne umieszczają identyfikator w adresie URL ({id}{-:id_product_attribute}-{rewrite}.html dla produktów, {id}-{rewrite} dla kategorii). Stary adres URL, z poprzednim slugiem, nadal więc znajduje obiekt, a kontroler porównuje go z aktualnym: przy opcji ustawionej na 301 przekierowuje, przy 0 odpowiadają oba adresy, a duplikaty pozostają.

Zmiana schematu adresów URL

Dispatcher zaczyna od kontrolera pagenotfound i zastępuje go tylko wtedy, gdy URI odpowiada jednej z aktualnych tras, domyślnych lub niestandardowych (PS_ROUTE_*). Kod nie przechowuje poprzednich schematów: stare adresy, które nie pasują już do żadnej trasy, trafiają na stronę zwracającą prawdziwy status 404. Przekierowania ze starych schematów trzeba utworzyć osobno.

Produkt wyłączony lub niedostępny

Pole „Przekierowanie w trybie offline” na karcie produktu (redirect_type) ma dziesięć wartości: default, 404 i 410 (strona błędu), 200-displayed, 404-displayed i 410-displayed (produkt wyświetlany jako wycofany z katalogu z danym kodem), 301-category i 302-category (przekierowanie do kategorii), 301-product i 302-product (przekierowanie do innego produktu). Przy default obowiązuje „Domyślne zachowanie wyłączonych produktów” (PS_PRODUCT_REDIRECTION_DEFAULT). Usunięty produkt już nie istnieje, a strona odpowiada 404.

Kategoria wyłączona lub usunięta

Wyłączona kategoria stosuje pole „Redirection when not displayed” (przekierowanie, gdy kategoria nie jest wyświetlana): domyślnie 301, do najbliższej aktywnej kategorii nadrzędnej, jeśli nie wybrano innej, albo 302, 410, 404. Usunięta kategoria odpowiada 404, a Category::deleteRedirections() przywraca zachowanie domyślne dla produktów i kategorii, które przekierowywały do niej.

Migracja z innej platformy

Przy zmianie platformy prawie wszystkie adresy URL zmieniają postać: produkty, kategorie, strony, obrazy i pliki. PrestaShop nie może odgadnąć starych adresów, trzeba je zebrać i zmapować.

1. Zebranie starych adresów URL. Google sugeruje, aby zacząć od map witryn, logów serwera lub analityki dla najczęściej odwiedzanych adresów URL, od raportu „Linki” w Search Console i od listy z CMS. Raport skuteczności ma wymiar „Strony” i przycisk eksportu. Należy uwzględnić obrazy, filmy, JavaScript i CSS.
2. Zmapowanie każdego adresu URL. Google pisze, że ważne jest zmapowanie adresów URL starej witryny na adresy nowej i zdecydowanie, dokąd ma prowadzić każdy z nich: do najbardziej odpowiedniej strony, jeden do jednego.
3. Obsługa tego, co nie ma odpowiednika. Google oczekuje, że usunięte treści będą zwracać 404 lub 410. Należy unikać kierowania wielu starych adresów URL do jednego, nieistotnego miejsca docelowego, takiego jak strona główna: według Google może to wprowadzać użytkowników w błąd i może zostać potraktowane jako pozorny błąd 404 (soft 404). Jeśli kilka stron zostało połączonych w jedną, jest to uprawnione miejsce docelowe.
4. Unikanie typowych błędów: łańcuchy przekierowań (Googlebot podąża za nimi do 10 kroków, ale Google zaleca kierowanie do miejsca docelowego, a jeśli się nie da, pozostanie idealnie w granicach 3 kroków i w każdym razie poniżej 5); pętle; 302 zamiast 301; linki wewnętrzne, canonical, hreflang i mapy witryn pozostawione na starych adresach URL; przekierowania do adresów URL, które nie istnieją; noindex lub blokady robots.txt z fazy deweloperskiej pozostawione aktywne; przekierowania usunięte zbyt wcześnie.

Co sprawdzić w Search Console

• Raport „Indeksowanie stron”: „Nie znaleziono (404)”, „Pozorny błąd 404”, „Strona zawierająca przekierowanie” i „Błąd przekierowania” (zbyt długi łańcuch, pętla, zbyt długi lub nieprawidłowy adres URL). Sam raport wyjaśnia, że 404 nie musi być problemem, jeśli strona została usunięta bez zastępnika, oraz że jeśli została przeniesiona, należy użyć 301.
• „Narzędzie do sprawdzania adresów URL”: test wersji opublikowanej podąża za przekierowaniami, ale nie wskazuje, że jakieś wykonał, ani nie pokazuje końcowego adresu URL. Aby zobaczyć kody i łańcuch, potrzebne jest narzędzie wiersza poleceń lub skrypt.
• Mapy witryn: należy przesłać mapę z nowymi adresami URL. Mapa ze starymi może pokazywać ostrzeżenia o przekierowaniach i jest to normalne.
• „Narzędzie zmiany adresu”: potrzebne tylko przy przejściu z jednej domeny lub subdomeny na inną, nie dla HTTP na HTTPS, www lub bez www, ani dla ścieżek w obrębie tej samej domeny.
• Czas: dla witryny małej lub średniej Google podaje kilka tygodni dla większości stron, z tymczasowymi wahaniami widoczności.

Lista kontrolna

1. Lista starych adresów URL z odwiedzinami i linkami, z map witryn, logów i Search Console.
2. Mapowanie jeden do jednego; 404 lub 410 dla tego, co nie ma odpowiednika.
3. 301 po stronie serwera dla treści przeniesionych, 302 tylko jeśli tymczasowo.
4. Brak łańcuchów: każdy stary adres URL prowadzi do miejsca docelowego, co sprawdzono skryptem na całej liście.
5. Linki wewnętrzne, canonical, hreflang i mapy witryn na nowych adresach URL.
6. „Przekieruj do kanonicznego URL” ustawione na 301, gdy sklep jest online.
7. Monitorowanie 404 i „Indeksowania stron” w tygodniach po migracji; przekierowania utrzymywane jak najdłużej, ogólnie co najmniej rok.

Jak robi to moduł Przekierowania SEO - menedżer 301/302/404

• Reguły 301, 302 i 410 z prostą ścieżką, wildcard (* i ?) lub zwalidowanym regex oraz opcje dotyczące query string (ignorowanie jej, porównywanie pełnego adresu URL lub wymaganie parametru). Kod 410 odpowiada prawdziwym statusem 410 i nagłówkiem X-Robots-Tag: noindex, zanim zostanie załadowany motyw.
• Przekierowanie uruchamia się w hooku actionDispatcher, przed zbudowaniem strony: proste reguły znajduje się indeksowanym wyszukiwaniem po skrócie (hash) ścieżki, a wildcard i regex są oceniane po kolei.
• Monitor 404 rejestruje brakujące adresy URL z liczbą żądań, ostatnim dostępem, referer i user agent (do 5 000 różnych adresów URL, z możliwością zmiany); „Create 301” (utwórz 301) wstępnie wypełnia regułę.
• Tworzy 301, gdy zmienia się slug produktu, kategorii lub strony CMS, dla każdego języka, jeśli żadna reguła nie obejmuje już tego adresu URL.
• Importuje i eksportuje CSV (kolumny source, target, type, is_regex, keep_querystring, qs_mode, qs_param, qs_value, active), z liczbą zaimportowanych i pominiętych wierszy: wygodne do wczytania mapowania migracji.
• Odrzuca zewnętrzne miejsca docelowe, które nie znajdują się w sklepie ani na liście dozwolonych hostów (ochrona przed open redirect).

Zobacz kartę modułu lub przeczytaj poradnik instalacji i konfiguracji.

Źródła

• RFC 9110, HTTP Semantics: sekcje 15.4.2, 15.4.3, 15.4.9, 15.5.5 i 15.5.11
• Google Search Central: przekierowania i Google Search, przeniesienie witryny ze zmianą adresów URL, kody stanu HTTP
• Pomoc Search Console: Indeksowanie stron, Narzędzie do sprawdzania adresów URL, Narzędzie zmiany adresu, Raport skuteczności
• Kod PrestaShop 9.1.5 na GitHub: FrontController, ProductController, CategoryController, Dispatcher
• Dokumentacja PrestaShop: SEO i adresy URL, zarządzanie produktami

Najczęściej zadawane pytania

301 czy 302 przy migracji?

301 (lub 308) dla treści przeniesionych na stałe: Google wykorzystuje to jako silny sygnał, natomiast 302 jest sygnałem słabym. Jego dokumentacja zaleca przekierowania stałe, gdy ma się pewność, że nie zostaną cofnięte.

Czy warto przekierować wszystkie stare adresy URL na stronę główną?

Nie. Google odradza kierowanie wielu starych adresów URL do jednego, nieistotnego miejsca docelowego: może to wprowadzać użytkowników w błąd i może zostać potraktowane jako pozorny błąd 404 (soft 404). Lepiej wskazać najbardziej odpowiednią stronę albo użyć 404 lub 410, jeśli nie ma odpowiednika.

Jak długo należy utrzymywać przekierowania?

Google wskazuje, aby utrzymywać je jak najdłużej, ogólnie co najmniej rok, aby sygnały przeszły na nowe adresy URL, a linki zewnętrzne zostały przypisane na nowo.

Czy PrestaShop sam przekierowuje stary adres URL po zmianie sluga?

Tak, jeśli identyfikator jest w adresie URL, a „Przekieruj do kanonicznego URL” ma wartość 301 (przy 302 przekierowanie jest tymczasowe, przy 0 nie ma przekierowania). Nie dzieje się tak, gdy zmienia się schemat adresów URL: stare adresy, które nie odpowiadają już żadnej trasie, zwracają 404.

404 czy 410 dla usuniętych stron?

Standard preferuje 410, gdy usunięcie jest prawdopodobnie trwałe. Dla Google oba kody są traktowane tak samo, jak wszystkie 4xx z wyjątkiem 429.

Czy sam moduł wystarczy?

Nie. Moduł obsługuje reguły, monitor 404, CSV i automatyczne 301, ale mapowanie trzeba przygotować samodzielnie. Nie sprawdza łańcuchów i pętli między regułami i nie poprawia linków wewnętrznych, canonical, hreflang ani map witryn: te elementy trzeba zweryfikować skryptem i w Search Console.