Przekierowania 301 i błędy 404 w PrestaShop: konfiguracja

Dodawanie przekierowania

Na karcie Redirects należy kliknąć Add a redirect, aby otworzyć formularz reguły.

• Source path or pattern: ścieżka przychodząca, np. /old-page. Przy włączonym Pattern matching można używać symboli wieloznacznych * i ? lub regex w ogranicznikach.
• Target: ścieżka wewnętrzna (zaczynająca się od /) albo adres URL w sklepie lub na hoście z białej listy. Cele zewnętrzne spoza białej listy są odrzucane (ochrona przed otwartym przekierowaniem).
• Redirect type: 301 Permanent lub 302 Temporary.
• Shop scope multistore: w instalacji multisklepu formularz pokazuje selektor Shop scope, który pozwala ograniczyć przekierowanie do jednego sklepu albo zastosować je dla All shops.
• Pattern matching i Append the original query string to the target: opcjonalne przełączniki dla poszczególnych reguł.

Dodawanie przekierowania: źródło, cel, typ i zakres dla sklepu

Settings master switch

Karta Settings grupuje przełącznik silnika, zachowanie dopasowywania, zabezpieczenie przed otwartym przekierowaniem i obsługę danych.

• Enable the redirect engine: główny przełącznik. Po wyłączeniu żadne przekierowania nie są realizowane i nic nie jest rejestrowane.
• Log 404 errors: zapisuje adresy URL kończące się stroną 404, aby można je było zamienić w przekierowania.
• Auto-create 301 on slug change: gdy zmieni się slug produktu, kategorii lub strony CMS, automatycznie tworzy przekierowanie 301 ze starego adresu na nowy.
• Ignore the query string when matching: dopasowuje ścieżkę niezależnie od parametrów ?a=b (oryginalny ciąg zapytania można nadal dołączać w ustawieniach reguły).
• Case-insensitive matching i Normalize trailing slashes: traktują /Page, /page i /page/ jako to samo źródło.
• Allowed external hosts: nazwy hostów oddzielone przecinkami, na które przekierowanie może wskazywać poza własnymi domenami sklepu. Puste pole oznacza dozwolone wyłącznie przekierowania wewnętrzne, co stanowi ochronę przed otwartym przekierowaniem; każdy inny cel zewnętrzny jest odrzucany.
• 404 log size cap: maksymalna liczba przechowywanych różnych adresów URL z błędem 404.
• Drop data on uninstall: po włączeniu odinstalowanie usuwa wszystkie reguły i dziennik 404. Aby zachować przekierowania po ponownej instalacji, opcję należy pozostawić wyłączoną.

Ustawienia: silnik, dopasowywanie, zabezpieczenie przed otwartym przekierowaniem i dane

Wybór w skrócie

• Treść została przeniesiona i nadal istnieje: kod 301, na jeden najbardziej odpowiedni zamiennik, a nie na stronę główną jako rozwiązanie zbiorcze.
• Treść jest tymczasowo niedostępna, ale wróci pod ten sam adres: kod 302, a nie 301, aby wyszukiwarka zachowała oryginał w indeksie i sprawdziła go później.
• Treść zniknęła i nie ma bezpośredniego zamiennika: kod 404 albo 410, jeśli wiadomo na pewno, że nigdy nie wróci (wyszukiwarki zwykle szybciej usuwają takie adresy z indeksu).
• Treść nigdy nie istniała pod tym adresem: zwykły kod 404, nic więcej nie trzeba robić.

Soft 404, którego należy unikać

Soft 404 to strona, której tekst informuje odwiedzającego „produkt nie został znaleziony”, podczas gdy serwer nadal odpowiada kodem 200 OK. Wyszukiwarki zauważają tę niezgodność i i tak traktują adres jako błąd, tyle że zajmuje on zwykłe miejsce w indeksowaniu, zamiast być obsłużony jako błąd, którym jest. Rdzeń PrestaShop poprawnie odpowiada kodem 404, gdy produkt nie istnieje: soft 404 pojawia się zwykle wtedy, gdy motyw lub moduł przechwytuje stronę i pokazuje komunikat „nie znaleziono” z kodem 200. Jeśli tekst strony mówi, że czegoś brakuje, jej kod statusu też powinien o tym mówić.

Budżet indeksowania to realny ruch, na liczbach naszego własnego sklepu

Wyszukiwarki, a coraz częściej także roboty AI, przydzielają każdej domenie przybliżony dzienny budżet żądań: każde żądanie zużyte na łańcuch przekierowań lub nieaktualne 404 to żądanie niewykorzystane na ważnej stronie. To nie jest abstrakcja. W naszym własnym sklepie, przed rutynowym porządkowaniem, filtr śledzenia odwiedzin używał listy sygnatur botów z 2010 roku: rejestrował 43 478 „odwiedzin” dziennie od botów, przy około 300 prawdziwych osobach, a dane śledzenia urosły do 1,4 GB, zanim porządki zmniejszyły je do 24 MB. Osobno pojedynczy robot (Meta) wysyłał 38 000 żądań dziennie, około 80% całego ruchu odbieranego przez serwer, dopóki nie dodano ukierunkowanej reguły.

410: kiedy jest właściwym wyborem, a kiedy działa na niekorzyść

Kod 410 zawsze trzeba zadeklarować świadomie: oznacza „nigdy więcej nic tu nie będzie”, a nie tylko „teraz nic tu nie ma”. Użycie go bez tej pewności to najkosztowniejszy błąd spośród czterech kodów. Dwa typowe przypadki: produkt niedostępny, ale wracający do oferty (410 zniechęca wyszukiwarkę do ponownego sprawdzania adresu właśnie wtedy, gdy się tego chce: właściwym narzędziem jest 404 albo 302 na stronę z informacją) oraz zbyt szeroka reguła dla wzorca wildcard lub warunku ciągu zapytania, która może trwale zamknąć drogę uprawnionemu ruchowi, mającemu tylko część wzorca.

Jak wygląda poprawnie zbudowany kod 410

W module wybranie typu 410 sprawia, że pole celu jest zbędne i jest ignorowane. Odpowiedź jest wysyłana jak najwcześniej w cyklu życia żądania, zanim aplikacja zbuduje motyw lub pobierze produkt z bazy danych, i zawiera trzy elementy często pomijane przy ręcznym wdrażaniu 410: prawdziwy status HTTP 410 Gone (a nie 200 z tekstem „niedostępny”), nagłówek X-Robots-Tag: noindex oraz minimalną treść strony przetłumaczoną na język odwiedzającego.

Prawdziwy przypadek: robot zapętlony na zatrutym parametrze

W naszym własnym sklepie robot (Meta) zapętlił się na adresach /login?back=..., które w wartości parametru nadal zawierały starą domenę sklepu: ponad 36 000 żądań w jedną noc, ponad 90% całego ruchu, z których każde było obsługiwane odpowiedzią 200 i pełnym renderowaniem strony, czyli kosztem procesora takim samym jak przy prawdziwym żądaniu. Jedna reguła 410 z warunkiem ciągu zapytania rozwiązała problem bez naruszania uprawnionego ruchu: reguła uruchamia się tylko wtedy, gdy parametr back zawiera starą domenę, a nie przy każdym żądaniu do /login. Sprawdzone na trzech różnych wersjach PrestaShop: /login?back=http://old-domain.example/x i /login?back=https://old-domain.example/login zwracają 410, natomiast /login?back=/my-account (uprawniony ruch) nadal zwraca 200, bez zmian.

Łańcuchy przekierowań: cichy podatek

Pojedyncze 301 kosztuje niemal nic. Łańcuch trzech lub czterech skoków zmusza każdego robota i każdego odwiedzającego do wykonania tylu żądań, by dotrzeć do jednej strony, a wyszukiwarki podążają tylko za ograniczoną liczbą skoków, zanim się poddadzą. Za każdym razem, gdy adres zmienia się ponownie, należy przekierować oryginał bezpośrednio na aktualny cel końcowy, zamiast dokładać kolejny skok do poprzedniego: spłaszczanie łańcuchów od razu po ich znalezieniu to jedno z najprzydatniejszych porządków w mapie przekierowań budowanej latami.