Przekierowanie 301 oznacza, że strona przeniosła się na stałe; 302 – że przeniesienie jest tymczasowe i stary adres jeszcze wróci. Wyszukiwarki biorą tę różnicę pod uwagę: po 301 indeksują nowy adres w miejsce starego, po 302 zwykle zostawiają stary. Używaj 301 (lub 308) do wszystkiego, co trwałe, np. zmiany adresu strony, nowej domeny czy przejścia na HTTPS, a 302 (lub 307) tylko wtedy, gdy pierwotny adres naprawdę wróci. Każde przekierowanie ograniczaj do jednego kroku i sprawdzaj je narzędziem, które pokazuje każdy krok.
Kody statusu przekierowań
Przekierowanie to odpowiedź z zakresu 3xx z nagłówkiem Location, który wskazuje nowy adres. W praktyce liczy się pięć kodów:
KodZnaczenieZachowuje metodęZastosowanie301 Moved PermanentlyPrzeniesiono na stałeNie ma gwarancji: przeglądarki zamieniają POST na GETZmienione adresy stron, nowe domeny, HTTP na HTTPS302 FoundTymczasowo gdzie indziejNie ma gwarancji: przeglądarki zamieniają POST na GETKrótkoterminowe przeniesienia, kierowanie odwiedzających na stronę logowania303 See OtherPobierz wynik spod innego adresuNie, zawsze GETPo wysłaniu formularza, żeby odświeżenie nie wysłało go drugi raz307 Temporary RedirectTymczasowo gdzie indziejTak, metodę i treśćTymczasowe przeniesienia endpointów API i formularzy308 Permanent RedirectPrzeniesiono na stałeTak, metodę i treśćStałe przeniesienia endpointów API i formularzy
W przypadku zwykłych stron, które przeglądarki pobierają metodą GET, 301 i 308 działają tak samo, podobnie jak 302 i 307. Różnica pojawia się, gdy klient wysyła POST: po 301 lub 302 większość klientów ponawia żądanie jako GET bez treści, a 307 i 308 każą wysłać dokładnie to samo żądanie jeszcze raz. Dlatego API, które przenosi endpoint, powinno używać 308 lub 307. Pełną listę kodów znajdziesz w zestawieniu kodów statusu HTTP.
Jak przekierowania wpływają na SEO
Dokumentacja Google dotycząca przekierowań traktuje 301 i 308 jako stałe, a 302, 303 i 307 jako tymczasowe. Stałe przekierowanie to silny sygnał, że w wynikach wyszukiwania należy pokazywać adres docelowy zamiast starego. Tymczasowe to sygnał słaby, więc stary adres zwykle pozostaje w indeksie.
Stąd trzy częste błędy:
302 przy stałym przeniesieniu. Wiele frameworków i wtyczek domyślnie przekierowuje kodem 302. Po migracji serwisu sprawdź, czy przekierowania naprawdę zwracają 301 lub 308.
Przekierowywanie wszystkiego na stronę główną. Gdy stara strona nie ma odpowiednika, Google może potraktować przekierowanie na stronę główną jako soft 404. Kieruj każdą starą stronę do najbliższego odpowiednika albo pozwól jej zwrócić 404 lub 410.
Stare linki prowadzące do przekierowań. Przekierowanie to siatka bezpieczeństwa, a nie cel. Zaktualizuj linki wewnętrzne, tagi canonical i mapę witryny tak, by wskazywały adres końcowy – wtedy ani odwiedzający, ani roboty nie płacą za dodatkowy krok.
Najczytelniejszym sygnałem są przekierowania po stronie serwera. Tagi meta refresh i przekierowania w JavaScripcie działają dla odwiedzających, ale wyszukiwarki widzą je dopiero po wczytaniu strony, a inni klienci mogą ich w ogóle nie zauważyć.
Które wybrać
Strona zmieniła adres lub została połączona z inną: 301.
Serwis przeniósł się na nową domenę, na HTTPS albo między wersją z www i bez www: 301 z każdego starego wariantu prosto na adres końcowy.
Strona jest tymczasowo gdzie indziej, na czas kampanii lub przebudowy: 302.
Odwiedzający musi się najpierw zalogować: 302 na stronę logowania, a potem z powrotem.
Wysłano formularz: 303 na stronę z wynikiem.
Endpoint API zmienił adres: 308, jeśli na stałe, 307, jeśli na razie – wtedy klienci zachowają metodę i treść żądania.
Serwis jest wyłączony z powodu prac serwisowych: bez przekierowania. Zwracaj 503 Service Unavailable pod pierwotnym adresem, żeby wyszukiwarki wróciły później, zamiast indeksować stronę o pracach serwisowych.
Przeglądarki zapamiętują stałe przekierowania
Przeglądarki zapisują odpowiedzi 301 i 308 w pamięci podręcznej, często na długo, i podążają za nimi bez ponownego pytania serwera. Błędne stałe przekierowanie dalej kieruje więc powracających odwiedzających w złe miejsce, nawet gdy już poprawisz serwer. Nową regułę testuj najpierw jako 302, a na 301 zmień ją dopiero wtedy, gdy działa poprawnie. Jeśli błędne 301 już poszło w świat, nagłówek Cache-Control: no-store w kolejnych przekierowaniach pomoże nowym odwiedzającym, ale kopie, które przeglądarki już mają, wygasną według własnego harmonogramu.
Łańcuchy i pętle przekierowań
Łańcuch to przekierowanie na adres, który przekierowuje dalej: http://example.com na https://example.com na https://www.example.com na https://www.example.com/en/. Każdy krok to kolejna wymiana z serwerem, zanim strona zacznie się wczytywać, a Google podąża za najwyżej 10 krokami. Łańcuchy narastają latami, przy kolejnych migracjach, gdy każda dokłada swoją regułę na poprzednią. Naprawisz je, kierując każdy stary wariant bezpośrednio na adres końcowy, w jednym kroku.
Pętla to łańcuch, który nigdy się nie kończy: dwie reguły odsyłają odwiedzających tam i z powrotem, aż przeglądarka podda się z komunikatem „too many redirects”. Najczęstsze przyczyny:
HTTP i HTTPS. CDN łączy się z Twoim serwerem przez HTTP, a serwer przekierowuje każde żądanie HTTP na HTTPS. W Cloudflare odpowiada za to ustawienie SSL Flexible; rozwiązaniem jest Full (strict).
Wersja z www i bez www. Serwer WWW dodaje www, a aplikacja je usuwa, albo odwrotnie. W WordPressie sprawdź, czy Adres WordPressa i Adres witryny zgadzają się z regułą serwera.
Ukośniki na końcu adresu i reguły językowe. Jedna reguła dodaje ukośnik lub prefiks języka, a druga go usuwa.
Jak sprawdzić przekierowanie
W terminalu curl pokazuje każdy krok wraz z kodem statusu i nagłówkiem Location:
curl -sIL http://example.com/old-page | grep -iE „^(HTTP|location)”
HTTP/1.1 301 Moved Permanently
Location: https://example.com/old-page
HTTP/2 301
location: https://example.com/new-page
HTTP/2 200
Dwa kroki: druga reguła powinna była zadziałać jako pierwsza. W przeglądarce otwórz narzędzia deweloperskie, na karcie Network zaznacz Preserve log i wczytaj stary adres; każde przekierowanie to osobny wiersz. Pamiętaj, że przeglądarka może obsłużyć 301 z pamięci podręcznej, więc okno prywatne da czystszy obraz.
Możesz też skorzystać z naszego bezpłatnego narzędzia do sprawdzania przekierowań: wpisz URL, a zobaczysz każdy krok z kodem statusu, miejsce, w którym kończy się łańcuch, i to, czy się zapętla, jest zbyt długi albo używa tymczasowego przekierowania tam, gdzie prawdopodobnie chodziło Ci o stałe. Narzędzie podąża za maksymalnie 5 krokami i sprawdza je na żywo ze Sztokholmu.
Konfiguracja przekierowania 301
Większość hostingów i CDN-ów ma ustawienie przekierowań w swoim panelu. W konfiguracji serwera:
# nginx: one page
location = /old-page { return 301 /new-page; }
# nginx: a whole domain, keeping the path
server {
server_name old-example.com www.old-example.com;
return 301 https://example.com$request_uri;
}
# Apache (.htaccess): one page
Redirect 301 /old-page /new-page
Następnie sprawdź stary adres, jego warianty z HTTP i www oraz adres z parametrami zapytania i upewnij się, że każdy z nich trafia na stronę końcową w jednym kroku.
Monitorowanie przekierowań w Uptimecheck
Monitor HTTP(S) w ramach monitorowania dostępności Uptimecheck domyślnie podąża za maksymalnie 10 przekierowaniami i ocenia stronę na końcu łańcucha – uznaje ją za dostępną, gdy odpowiada statusem od 200 do 399. Pętla lub dłuższy łańcuch jest zgłaszany jako awaria z komunikatem „Too many redirects”, a incydent informuje, kiedy łańcuch odbija się między HTTP i HTTPS albo między wersją z www i bez www. Sprawdzenia mogą odbywać się nawet co minutę ze Sztokholmu, Londynu i Nowego Jorku, a drugie sprawdzenie potwierdza awarię, zanim dostaniesz alert.
Aby pilnować samego przekierowania, np. po zmianie domeny, wyłącz Follow redirects, żeby monitor oceniał własny kod statusu przekierowania, ustaw Expected status codes na 301 i dodaj sprawdzenie nagłówka, czy Location jest równy nowemu adresowi. Jeśli ktoś później zmieni przekierowanie na 302 albo skieruje je gdzie indziej, od razu się o tym dowiesz. Zobacz, jak dodać pierwszy monitor, oraz przewodnik po kodach statusu HTTP w monitoringu.
Dowiedz się, gdy przeniesienie przestanie działać. Wypróbuj Uptimecheck bezpłatnie przez 14 dni, bez karty kredytowej.