Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
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ł.
Różnica jest w jednym słowie: trwałość.
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ż 308 i 307, 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.
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.
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.
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ą.
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.
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.
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.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |