Czym różni się błąd 301 (Permanent) od 302 (Temporary) z punktu widzenia SEO?

Jedna cyfra, dwie różne decyzje

Baner wejsciowyParallax

Czym różni się błąd 301 (Permanent) od 302 (Temporary) z punktu widzenia SEO?

Jedna cyfra, dwie różne decyzje

Autor nie posiada zdjęcia
Tomasz Piasecki
30 września 2022

Zacznę od sprostowania, bo samo nazewnictwo wprowadza w błąd. Ani 301, ani 302 nie jest błędem. To odpowiedzi z rodziny 3xx, czyli komunikat serwera „szukanego zasobu nie ma tutaj, idź pod ten adres”. Błędy zaczynają się od 4 i 5. Tymczasem w audytach spotykam listy „błędów przekierowań”, na których poprawnie działające 301 stoi obok realnej awarii serwera.

Ta pomyłka nie byłaby groźna, gdyby nie prowadziła do drugiej: skoro oba kody działają tak samo w przeglądarce, to jaka to różnica, który wybierze programista. Użytkownik faktycznie nie zauważy niczego. Robot wyszukiwarki zauważy wszystko, bo dla niego wybór między 301 a 302 to informacja o tym, który adres ma zostać w indeksie, a który z niego wypaść.

Poniżej rozkładam tę różnicę na części: co dokładnie deklarujesz każdym z tych kodów, co się dzieje z wartością starego adresu, kiedy 302 jest właściwym wyborem i skąd na kontach klientów bierze się tyle przypadkowych 302 w miejscach, gdzie nikt ich nie chciał.

Co deklarujesz kodem 301, a co kodem 302

Różnica jest w jednym słowie: trwałość.

  • 301 Moved Permanently — ten adres już nie wróci. Zasób przeniósł się na stałe i pod stary URL nie ma po co zaglądać w przyszłości.
  • 302 Found — obsługa jest chwilowo pod innym adresem, ale stary URL pozostaje właściwym miejscem tego zasobu i za jakiś czas znów będzie odpowiadał treścią.

Dla przeglądarki różnica sprowadza się głównie do buforowania: odpowiedź trwałą może zapamiętać, tymczasowej z zasady nie zapamiętuje na dłużej. Dlatego przy testowaniu przekierowań łatwo dać się nabrać na własny cache.

Para 301/302 nie jest jedyna. Istnieją też 308307, ich odpowiedniki z gwarancją zachowania metody zapytania. Dla SEO strony, gdzie robot wysyła zapytania GET, 308 zachowuje się jak 301, a 307 jak 302 — i tak też są interpretowane.

Który adres zostaje w indeksie

To sedno całej sprawy. Wyszukiwarka nie traktuje przekierowania jako polecenia do wykonania, tylko jako sygnał w procesie wyboru adresu kanonicznego.

Przy 301 sygnał jest mocny i jednoznaczny: nowy adres ma zastąpić stary. Google podąża za przekierowaniem, indeksuje cel, a źródło stopniowo znika z wyników jako osobny adres. Nie dzieje się to natychmiast — robot musi najpierw odwiedzić stary URL i przetworzyć zmianę, co przy rzadko odwiedzanych podstronach potrafi potrwać tygodnie.

Przy 302 sygnał jest odwrotny: skoro przeniesienie jest tymczasowe, adresem właściwym pozostaje stary URL. Wyszukiwarka zwykle zachowuje go w indeksie i to on nadal może wyświetlać się w wynikach, mimo że pokazuje treść z innej lokalizacji. Jeśli przeprowadzasz trwałą zmianę adresów, a serwer zwraca 302, prosisz Google, żeby trzymał się adresu, który chcesz wygasić.

Nie znaczy to, że długo utrzymywane 302 zostanie zignorowane na zawsze. Wyszukiwarka patrzy też na linkowanie wewnętrzne, mapę witryny i znaczniki kanoniczne. Kiedy wszystkie te sygnały wskazują na nowy adres, a stary od miesięcy zwraca 302, Google potrafi ostatecznie uznać przeniesienie za trwałe. Tylko po co oddawać tę decyzję i czekać, aż algorytm sam się domyśli.

Co z wartością linków

Tu obiegowa wiedza jest starsza niż stan faktyczny. Krąży przekonanie, że 301 „przekazuje moc” strony, a 302 nie przekazuje jej wcale. Tymczasem Google od kilku lat powtarza, że przy przekierowaniach 3xx nie ma utraty wartości linków i że z tego punktu widzenia typ przekierowania nie ma znaczenia. Traktuję to jako obowiązujący stan wiedzy i nie dobieram kodu odpowiedzi pod „przelewanie mocy”.

To nie zamyka jednak sprawy, bo pytanie nie brzmi „ile wartości przechodzi”, ale do którego adresu ta wartość się przypina. Przy 301 konsolidacja idzie na nowy URL, bo to on zostaje kanoniczny. Przy 302 sygnały nadal skupiają się na starym adresie. Efektem nie jest więc wyciek wartości, a rozdzielenie: historia zostaje przy adresie, którego nie chcesz już promować, a strona docelowa buduje pozycję od nowa.

W przypadku migracji dochodzi jeszcze jedna rzecz. W Search Console jest narzędzie do zmiany adresu witryny, którym zgłasza się przeniesienie na inną domenę — i ono wymaga przekierowań trwałych. Przy 302 nie masz czym zgłosić migracji.

Kiedy 302 jest właściwym wyborem

Nie chcę, żeby to wyszło na tekst o tym, że 302 jest złe. Jest po prostu do innych zadań, a te zadania istnieją.

  • Prace serwisowe — lepiej sprawdza się tu kod 503 z komunikatem, ale tymczasowe przekierowanie na stronę informacyjną też nie zaszkodzi indeksowi.
  • Testy A/B — kierujesz część ruchu na wariant strony, przeniesienie z definicji jest chwilowe, a pierwotny adres ma zostać w indeksie.
  • Chwilowo niedostępny produkt — gdy karta wróci do sprzedaży w ciągu kilku tygodni, nie ma sensu wygaszać jej adresu na stałe.
  • Kierowanie po lokalizacji lub urządzeniu — przekierowanie zależne od tego, kto puka pod adres, nie opisuje trwałego przeniesienia zasobu.
  • Akcje wymagające logowania — przerzucenie niezalogowanego użytkownika na formularz to stan chwilowy, nie zmiana adresu.

Zasada, którą stosuję, jest banalna: jeśli potrafię wskazać moment, w którym stary adres znów będzie działał — 302. Jeśli nie potrafię — 301.

Skąd biorą się przypadkowe 302

Prawie nigdy nie są efektem decyzji. Są efektem domyślnych ustawień, o których nikt nie wiedział.

Najczęstsze źródło to warstwa aplikacji. Wiele frameworków i wtyczek do zarządzania przekierowaniami ustawia 302 jako wartość domyślną, bo jest bezpieczniejsza w razie pomyłki. Programista wpisuje regułę, nie rusza pola z kodem odpowiedzi i przekierowanie z podstrony przebudowanego serwisu zostaje tymczasowe na dwa lata.

Druga grupa to przekierowania generowane poza świadomością redakcji: wymuszanie wersji z www albo bez, ukośnik na końcu adresu, wymuszanie HTTPS, obsługa wielkich liter w URL. Każde dotyczy całej witryny, więc pomyłka na tym poziomie ciągnie się przez wszystkie podstrony.

Trzecia to łańcuchy mieszane, moim zdaniem przypadek najbardziej złośliwy. Adres zwraca 301 na drugi, ten 302 na trzeci, a dopiero trzeci odpowiada treścią. Narzędzie pokazujące tylko pierwszą odpowiedź wyświetli zielone 301 i audyt przejdzie. Robot przeczyta cały łańcuch i wyciągnie z niego wniosek, którego nikt nie planował — a przy dłuższych łańcuchach Googlebot po prostu przestaje iść dalej.

Osobno wspomnę o przekierowaniach po stronie przeglądarki — znacznikiem meta refresh albo skryptem. Wyszukiwarka je rozpoznaje, ale to sygnał słabszy od odpowiedzi serwera. Traktuję je jako rozwiązanie ostateczne, gdy nie mam dostępu do konfiguracji serwera.

Jak sprawdzić, co naprawdę zwraca serwer

Nie ufam temu, co widzę w przeglądarce, bo przeglądarka zapamiętuje przekierowania trwałe i potrafi pokazać stan z zeszłego miesiąca.

Najprościej odczytać nagłówki bezpośrednio. Zapytanie z linii poleceń, z opcją podążania za przekierowaniami, pokazuje cały łańcuch: każdy kod odpowiedzi i każdy nagłówek z adresem docelowym. To jedyny sposób, żeby zobaczyć przeskok ukryty w środku. Alternatywnie wystarczy zakładka sieci w narzędziach dla programistów, z pomijaniem pamięci podręcznej.

Po stronie wyszukiwarki sięgam do narzędzia do sprawdzania adresów URL w Search Console. Przy pobraniu na żywo widać, pod jaki adres robot został skierowany i który URL uznał za kanoniczny — a to najważniejsze, bo pokazuje, jak Google zinterpretował Twoją deklarację, nie jak Ty ją zamierzałeś.

Przy większej liczbie adresów robię przejście crawlerem i sortuję wyniki po kodzie odpowiedzi. Interesują mnie dwie rzeczy: 302 utrzymywane dłużej niż kilka tygodni oraz łańcuchy dłuższe niż jeden przeskok. Zamiana 302 na 301 to zwykle praca na kwadrans w jednym pliku konfiguracyjnym — problemem jest to, że nikt tam nie zagląda, dopóki nie zacznie szukać przyczyny spadków.

Podziel się tym artykułem z innymi!

Twitter Facebook Linke.din
Autor nie posiada zdjęcia
Tomasz Piasecki
Specjalista Google Ads / SEM
Zajmuję się kampaniami Google Ads i widocznością stron w wyszukiwarce. Na blogu UDI Group piszę o tym, jak ustawienia kampanii i decyzje techniczne przekładają się na realne wyniki. Staram się tłumaczyć mechanizmy, a nie tylko podawać gotowe przepisy.