301 stosuj wtedy, gdy zmiana adresu jest trwała i nowy URL ma przejąć rolę starego w Google. 302 stosuj wtedy, gdy zmiana jest czasowa i źródłowy URL ma wrócić. W SEO najważniejsze pytanie brzmi: czy stary adres ma jeszcze kiedyś obsługiwać tę samą treść, czy tylko zostawiasz stary kod z braku decyzji?
301 i 302 różnią się trwałością decyzji o adresie
Przekierowanie 301 oznacza stałe przeniesienie zasobu, a 302 oznacza przeniesienie tymczasowe. Użytkownik zwykle nie widzi tej różnicy, ale Google używa typu przekierowania jako sygnału kanonikalizacji: przy stałym przekierowaniu docelowy URL ma być kandydatem do wyników, przy tymczasowym źródłowy URL może pozostać właściwym adresem.
| Kod | Typ | Sygnał dla wyszukiwarki | Kiedy używać |
|---|---|---|---|
| 301 | Stałe przekierowanie | Sygnał, że docelowy URL powinien zastąpić stary adres jako wersja kanoniczna w wynikach. | Zmiana domeny, stała zmiana adresu, konsolidacja podobnych stron, przejście HTTP na HTTPS, wariant www bez www. |
| 302 | Tymczasowe przekierowanie | Sygnał, że źródłowy URL może pozostać kandydatem do wyników, bo zmiana ma być odwracalna. | Test A/B, krótkotrwała kampania, przerwa techniczna, czasowe przeniesienie użytkownika na komunikat lub alternatywną stronę. |
| 307 | Tymczasowe, zachowuje metodę | Pod względem intencji jest tymczasowe, ale nie zmienia metody żądania, np. POST na GET. | Tymczasowe operacje przy formularzach, logowaniu, koszyku, API albo procesach, w których metoda żądania ma znaczenie. |
| 308 | Stałe, zachowuje metodę | Pod względem stałości działa jak 301, ale nie zmienia metody żądania. | Stałe przeniesienie w aplikacjach, formularzach, API i e-commerce, gdzie utrata metody POST mogłaby przerwać proces. |
Oficjalna dokumentacja Google mówi, że stałe przekierowania, takie jak 301 i 308, nie powodują utraty PageRank. Nie oznacza to jednak, że każde przekierowanie jest neutralne. Nietrafny cel, pętla, łańcuch albo soft 404 nadal mogą zaszkodzić widoczności i użytkownikom.
Redirect działa jako odpowiedź serwera z instrukcją nowej lokalizacji
Typowy redirect serwerowy zaczyna się od żądania starego URL-a. Serwer odpowiada kodem 3xx i nagłówkiem Location, a przeglądarka lub crawler pobiera adres docelowy. Dla SEO najczystszy jest redirect serwerowy, bo Google otrzymuje sygnał przed pobraniem treści starej strony.
Użytkownik lub bot żąda starego URL-a
Adres może pochodzić z wyniku Google, linku zewnętrznego, starego linku wewnętrznego, sitemapy albo zakładki w przeglądarce.
Serwer zwraca kod 3xx i nagłówek Location
Kod mówi, czy zmiana jest stała, czy tymczasowa. Nagłówek Location wskazuje adres, do którego klient ma przejść.
Crawler podąża do adresu docelowego
Googlebot zwykle śledzi przekierowanie, ale długie łańcuchy zwiększają opóźnienie i utrudniają diagnostykę.
Google wybiera adres kanoniczny
Przekierowanie stałe jest silnym sygnałem kanonicznym. Przy tymczasowym Google nie powinien dostawać sygnału trwałej zamiany źródła na cel.
Nowa struktura wymaga spójnych sygnałów
Linki wewnętrzne, sitemap, canonicale, hreflangi i dane strukturalne powinny wskazywać finalne adresy, a nie stare URL-e po przekierowaniu.
Meta refresh i JavaScript redirect są obsługiwane przez Google, ale mają niższą przewidywalność niż przekierowania po stronie serwera. Jeżeli masz wpływ na konfigurację hostingu, CMS-a lub aplikacji, przekierowania HTTP powinny być pierwszym wyborem.
Dobór przekierowania zaczyna się od pytania, czy stary URL wróci
Najprostszy model decyzyjny ma cztery kroki: ustal trwałość zmiany, dopasowanie treści docelowej, wartość starego URL-a oraz wpływ na użytkownika. Dopiero potem wybieraj kod statusu.
| Sytuacja | Przykład | Decyzja | Dlaczego |
|---|---|---|---|
| Stary URL już nie wróci | zmiana slugów, przebudowa kategorii, rebranding, konsolidacja dwóch artykułów | 301 albo 308 | Potrzebny jest stały sygnał, że nowy adres ma przejąć rolę starego URL-a. |
| Stary URL wróci po krótkim czasie | test A/B, kampania sezonowa, przerwa techniczna, tymczasowy komunikat | 302 albo 307 | Nie chcesz, żeby wyszukiwarka traktowała zmianę jako docelową migrację. |
| Zmienia się wariant kanoniczny domeny | http na https, www na bez www, końcowy slash, małe litery w URL-u | 301 albo 308 | Wszystkie warianty powinny prowadzić do jednej, finalnej wersji adresu. |
| Adres obsługuje formularz lub koszyk | POST po logowaniu, koszyk, płatność, endpoint aplikacji | 307 albo 308 | Te kody zachowują metodę żądania, więc zmniejszają ryzyko utraty danych w procesie. |
| Strona znika bez dobrego odpowiednika | produkt bez następcy, nieaktualna oferta, pusty artykuł bez ruchu i linków | 404 albo 410 | Przekierowanie do nietrafnej strony może zostać odebrane jako soft 404 i pogorszyć UX. |
| Dwie strony mają pozostać dostępne | warianty podobnych treści, licencjonowany przedruk, filtr dostępny użytkownikom | canonical, noindex albo zmiana treści | Przekierowanie usuwa możliwość wejścia na źródłowy URL, więc nie zawsze jest właściwym narzędziem. |
Przekierowania 301 używaj przy trwałej zmianie adresu URL
Kod 301 jest właściwy wtedy, gdy nie planujesz przywrócenia starego adresu jako samodzielnej strony. W praktyce dotyczy to migracji domeny, zmiany struktury URL, usuwania zduplikowanych wersji, przejścia na HTTPS, konsolidacji podobnych treści i zmiany wariantu kanonicznego.
Stary URL ma bliski odpowiednik
Artykuł, produkt, kategoria lub usługa prowadzi do nowej strony, która odpowiada tej samej intencji użytkownika.
Cel nie pasuje do źródła
Stara karta produktu, poradnik albo oferta trafia do ogólnej strony głównej, mimo że użytkownik szukał konkretnej treści.
Po wdrożeniu 301 zaktualizuj linkowanie wewnętrzne i sitemapę. Redirect ma chronić historię starych linków, a nie zastępować docelową architekturę serwisu.
Przekierowania 302 używaj tylko wtedy, gdy zmiana jest czasowa
Kod 302 jest dobry, gdy źródłowy adres ma wrócić do normalnej roli: po teście, kampanii, pracach technicznych albo krótkiej zmianie komunikatu. W takim scenariuszu nie chcesz wysyłać Google sygnału, że nowa lokalizacja ma trwale zastąpić stary URL. 302 nie oznacza jednak, że docelowa strona nie może być indeksowana; oznacza, że sama reguła nie powinna być sygnałem trwałej kanonikalizacji.
- Test A/B prowadzi użytkowników do wariantu strony przez krótki czas.
- Landing promocyjny działa tylko w czasie kampanii.
- Usługa jest chwilowo niedostępna, a użytkownik ma dostać komunikat lub alternatywę.
- Nowa wersja adresu jest testowana przed decyzją o migracji.
302 bywa zostawiane po testach, bo nikt nie wrócił do decyzji. Jeśli mija kilka miesięcy i stary URL nie ma wrócić, trzeba sprawdzić, czy reguła nie powinna zostać zmieniona na 301 albo 308.
302 przestaje być dobrym wyborem, gdy nie ma planu powrotu URL-a
Największe ryzyko przy 302 nie wynika z samego kodu, tylko z braku kontroli po wdrożeniu. Jeśli tymczasowa reguła zostaje w serwisie po kampanii, zmianie sezonowej albo teście, zaczyna pełnić rolę trwałej migracji bez spójnych sygnałów SEO.
| Sygnał | Znaczenie | Działanie |
|---|---|---|
| Jest data lub warunek powrotu | 302 albo 307 ma sens, gdy wiadomo, kiedy źródłowy URL znowu będzie obsługiwał własną treść. | Zapisz datę kontroli reguły i osobę odpowiedzialną za decyzję. |
| Stary URL znika z menu, linków i sitemapy | To zwykle oznacza trwałą zmianę w architekturze, nawet jeśli kod HTTP nadal mówi 302. | Zmień regułę na 301/308 albo przywróć stary URL do normalnego obiegu. |
| Docelowy URL przez miesiące zastępuje źródło | Tymczasowość przestała być realnym stanem biznesowym, a redirect działa jak ukryta migracja. | Wykonaj mini-migrację: mapa, 301/308, linki, canonicale, sitemap i monitoring. |
| Cel ma inny temat niż źródło | Kod 302 nie naprawi niedopasowania intencji. Użytkownik nadal trafia w złe miejsce. | Znajdź bliższy odpowiednik albo zostaw źródłowy URL z komunikatem, 404 lub 410. |
307 i 308 są ważne wtedy, gdy metoda żądania nie może się zmienić
Kody 307 i 308 zachowują metodę żądania, więc są bezpieczniejsze w procesach opartych o POST, formularze, logowanie, koszyk, płatności lub API. W SEO 308 pełni rolę stałego przekierowania, a 307 tymczasowego, ale ich znaczenie aplikacyjne bywa ważniejsze niż sama etykieta SEO.
Dla zwykłych stron informacyjnych 301 i 302 są zwykle wystarczające. Przy serwisach transakcyjnych i integracjach technicznych decyzję uzgodnij z developerem, bo zły kod może przerwać proces użytkownika mimo poprawnej logiki SEO.
Meta refresh i JavaScript redirect są słabsze niż redirect serwerowy
Google potrafi wykrywać przekierowania inne niż odpowiedź HTTP, ale dla SEO i diagnostyki najczytelniejszy pozostaje kod 3xx zwracany przez serwer. Wariant klientowy zostaw na sytuacje, w których nie masz dostępu do konfiguracji serwera, CDN-u, CMS-a ani backendu.
| Metoda | Sygnał dla Google | Ograniczenie |
|---|---|---|
| Redirect serwerowy HTTP | Najbardziej jednoznaczny sygnał; Google dostaje kod 3xx przed pobraniem treści. | Wymaga kontroli nad serwerem, CDN-em, CMS-em albo warstwą aplikacji. |
| Meta refresh 0 sekund | Google interpretuje go podobnie do stałego przekierowania, gdy jest natychmiastowy. | To słabszy wybór niż kod HTTP, bo najpierw ładuje się dokument HTML. |
| Meta refresh z opóźnieniem | Google interpretuje go jako sygnał przekierowania tymczasowego. | Pogarsza UX i może mieszać sygnały, bo użytkownik widzi starą stronę przed przejściem. |
| JavaScript redirect | Może zostać wykonany po renderowaniu strony przez Google. | Jeśli renderowanie się nie uda albo skrypt jest zablokowany, redirect może nie zostać zauważony. |
Nie każdy problem z URL-em powinien kończyć się przekierowaniem
Przekierowanie jest właściwe, gdy chcesz przenieść użytkownika i robota do innego adresu. Jeśli celem jest usunięcie strony, blokada indeksowania, wskazanie preferowanej wersji albo ochrona danych, inny mechanizm będzie czytelniejszy.
| Cel | Lepszy wybór | Dlaczego |
|---|---|---|
| Strona ma zniknąć i nie ma zamiennika | 404 albo 410 | To czytelny sygnał dla użytkownika i Google, że treść jest niedostępna. |
| Strona ma być dostępna, ale nie ma być w indeksie | noindex albo X-Robots-Tag | Redirect zmienia adres użytkownika, a noindex rozwiązuje problem obecności w wynikach. |
| Masz podobne URL-e, ale użytkownik ma nadal je widzieć | rel canonical i spójne linkowanie | Canonical wskazuje preferowaną wersję bez zabierania użytkownikowi dostępu do wariantu. |
| Chcesz ukryć prywatne dane | autoryzacja, hasło lub blokada serwerowa | Przekierowanie i robots.txt nie są mechanizmem bezpieczeństwa. |
Migracja SEO wymaga mapy przekierowań, nie samej reguły globalnej
Przy małej zmianie domeny czasem wystarczy wzorzec ścieżka do ścieżki. Przy zmianie struktury, CMS-a, kategorii albo treści potrzebna jest mapa przekierowań, która łączy stare adresy z najbliższymi odpowiednikami.
1. Zbierz stare URL-e
Połącz dane z sitemap, Google Search Console, logów, analityki, CMS-a, linków wewnętrznych i linków zewnętrznych.
WynikLista adresów, które faktycznie mają historię, ruch, linki lub rolę biznesową.
2. Dopasuj adres docelowy
Każdy ważny URL przypisz do najbliższego odpowiednika tematycznego, a nie do strony głównej.
WynikMapa stary URL -> nowy URL z informacją, czy relacja jest 1:1, konsolidacyjna czy brak zamiennika.
3. Wdróż stałe przekierowania
Dla trwałej migracji użyj przekierowań serwerowych 301 lub 308 i prowadź bezpośrednio do finalnego adresu.
WynikKrótki łańcuch, najlepiej jeden skok: stary URL -> finalny nowy URL.
4. Zaktualizuj sygnały na nowej stronie
Popraw linki wewnętrzne, canonicale, hreflangi, dane strukturalne i sitemapę, żeby wskazywały nowe URL-e.
WynikNowa struktura nie polega na przekierowaniach jako codziennej nawigacji.
5. Monitoruj zmianę po wdrożeniu
Sprawdzaj indeksowanie, błędy 404, soft 404, crawl Googlebota, ruch na starych i nowych adresach oraz widoczność fraz.
WynikDecyzja, które reguły poprawić, które URL-e podlinkować, a które zostawić jako 404/410.
Google zaleca używanie stałych przekierowań serwerowych przy zmianie URL-i, aktualizację linków, zgłoszenie nowej sitemapy i monitorowanie ruchu po obu stronach migracji. Przy dużych serwisach trzeba też uwzględnić większe obciążenie serwera przez crawl po wdrożeniu.
Dobra mapa przekierowań opisuje decyzję, a nie tylko dwa adresy
Arkusz stary URL - nowy URL jest za słaby przy większej migracji. Mapa powinna pokazywać, dlaczego wybrano dany cel, jaką intencję ma obsłużyć i co trzeba sprawdzić po wdrożeniu.
| Kolumna | Co powinna zawierać? |
|---|---|
| Stary URL | adres źródłowy z GSC, sitemap, logów, CMS-a, analityki, linków wewnętrznych albo linków zewnętrznych |
| Nowy URL | najbliższy odpowiednik intencji, a nie automatycznie strona główna lub najbliższa kategoria |
| Typ relacji | 1:1, wiele do jednego, wariant kanoniczny, brak zamiennika, produkt z następcą, produkt bez następcy |
| Decyzja | 301/308, 302/307, 404/410, canonical, noindex albo pozostawienie strony jako 200 OK |
| Priorytet | ruch, linki zewnętrzne, konwersje, pozycje, liczba wejść z Googlebota i znaczenie biznesowe URL-a |
| Test po wdrożeniu | kod źródła, finalny status 200, liczba hopów, canonical celu, indeksowalność i obecność w sitemapie |
W sklepie internetowym przekierowanie zależy od dostępności i następcy produktu
E-commerce nie powinien używać jednej reguły dla wszystkich produktów. Produkt chwilowo niedostępny, produkt wycofany z następcą i produkt bez odpowiednika wymagają różnych decyzji, bo różna jest intencja użytkownika i wartość starego URL-a.
| Przypadek | Rekomendacja | Unikaj |
|---|---|---|
| Produkt czasowo niedostępny | Najczęściej zostaw 200 OK i jasny komunikat, datę dostawy, produkty podobne oraz powiadomienie o dostępności. | 301 do kategorii tylko dlatego, że produktu chwilowo nie ma. |
| Produkt wycofany, jest następca | 301 do następcy, nowszego modelu albo bardzo bliskiej kategorii, jeśli intencja użytkownika nadal zostaje obsłużona. | Przekierowanie do losowego produktu lub strony głównej. |
| Produkt wycofany, brak odpowiednika | 404 albo 410, a na stronie błędu ścieżka do kategorii, wyszukiwarki lub podobnych produktów. | Masowe przekierowanie wszystkich wygasłych produktów do jednego ogólnego URL-a. |
| Zmiana kategorii produktu | Mapa 1:1 ze starej ścieżki do nowej, aktualizacja linków wewnętrznych i sitemapy. | Zostawienie starej ścieżki w menu, filtrach, breadcrumbs albo plikach XML. |
Gdy sklep tylko czasowo ogranicza sprzedaż, Google rekomenduje raczej pozostawienie serwisu online i ograniczenie funkcji niż masowe przekierowania. W praktyce oznacza to komunikat na stronie, wyłączenie koszyka, aktualizację danych strukturalnych, dostępności produktów i feedu Merchant Center, jeśli sklep z niego korzysta.
Łańcuchy i pętle przekierowań pogarszają crawl, UX i diagnostykę
Łańcuch powstaje, gdy URL A prowadzi do B, a B dopiero do C. Pętla powstaje, gdy przekierowania wracają do wcześniejszego adresu. Oba problemy są szczególnie częste po kilku latach zmian struktury, migracji CMS-a, wymuszania HTTPS i porządkowania www.
A -> B -> C
Każdy dodatkowy skok dodaje żądanie HTTP. Google zaleca prowadzić bezpośrednio do finalnego adresu, a jeśli to niemożliwe, trzymać liczbę hopów nisko.
A -> B -> A
Przeglądarka kończy błędem zbyt wielu przekierowań, a crawler nie dostaje treści. To błąd krytyczny, nie drobna optymalizacja.
Najprostsza naprawa to aktualizacja wszystkich starych reguł tak, aby prowadziły do aktualnego finalnego URL-a. Przy okazji popraw linki wewnętrzne, bo one nie powinny stale przechodzić przez redirect.
Soft 404 pojawia się, gdy przekierowanie nie spełnia intencji starego URL-a
Google może potraktować stronę jako soft 404, jeśli technicznie zwraca inny status, ale praktycznie nie dostarcza użytkownikowi oczekiwanej treści. Masowe przekierowania usuniętych produktów, artykułów lub ofert do strony głównej są typowym źródłem tego problemu.
Jeśli użytkownik szukał konkretnego produktu, usługi lub poradnika, adres docelowy powinien odpowiadać tej samej lub bardzo bliskiej intencji. Gdy nie ma takiego odpowiednika, 404 lub 410 jest często bardziej uczciwą decyzją niż pozornie bezpieczne 301.
Przekierowania najlepiej wdrażać po stronie serwera
Najbardziej przewidywalnym rozwiązaniem SEO jest przekierowanie HTTP po stronie serwera: Apache, Nginx, konfiguracja hostingu, CDN, CMS lub aplikacja backendowa. Wtyczki WordPress są wygodne, ale przy dużej liczbie reguł mogą utrudniać wydajność, kontrolę i testy.
- Apache: reguły w konfiguracji serwera lub pliku
.htaccess. - Nginx: reguły
returnalborewritew konfiguracji vhosta. - CMS: panel przekierowań albo moduł, o ile generuje właściwe kody HTTP.
- CDN: reguły edge, szczególnie przy wielu domenach, HTTPS i dużej skali ruchu.
- WordPress: wtyczka tylko wtedy, gdy rozumiesz kolejność reguł, cache i wpływ na serwer.
Po wdrożeniu sprawdź wynik publiczny, a nie tylko konfigurację. Użyj narzędzia, które pokaże cały łańcuch, kod, nagłówek Location i finalny status. W KEO służy do tego tester przekierowań URL.
Efekt przekierowań mierz przez indeks, ruch, crawl i spójność sygnałów
Sam fakt, że adres przechodzi na inny URL, nie kończy pracy. Po migracji trzeba sprawdzić, czy Google rozumie finalne adresy, czy użytkownicy nie wpadają w błędy i czy stare sygnały nie zostały rozproszone przez sprzeczne linki, canonicale lub sitemapę.
| Obszar | Co sprawdzić? | Narzędzie |
|---|---|---|
| Statusy i łańcuch | Czy stary URL zwraca właściwy kod 301/302/307/308 i prowadzi do finalnego adresu? | Tester przekierowań KEO, curl, DevTools, crawler SEO |
| Indeksowanie | Czy stare URL-e znikają z indeksu, a nowe zyskują wyświetlenia i kliknięcia? | Google Search Console: Strony, Skuteczność, Inspekcja URL |
| Sitemapy | Czy sitemap zawiera nowe finalne adresy, a nie stare URL-e po przekierowaniu? | Raport Sitemapy w Google Search Console |
| Linkowanie | Czy menu, breadcrumbs, treści i linki modułowe prowadzą bezpośrednio do nowych URL-i? | Crawl serwisu, eksport linków wewnętrznych, kontrola szablonów |
| Logi serwera | Czy Googlebot trafia na finalne URL-e i czy po migracji nie rośnie liczba 404 lub 5xx? | Log analysis, monitoring hosta, raport statystyk indeksowania |
Po czym poznać, że migracja została zrozumiana?
Stare URL-e tracą kliknięcia, ale nie generują błędów
To normalny efekt migracji, jeśli finalne adresy przejmują widoczność i nie rośnie liczba nietrafnych 404.
Nowe URL-e zyskują wyświetlenia i zapytania
Google zaczyna traktować je jako właściwe adresy dla dawnych intencji.
Raport sitemapy pokazuje finalne adresy
Sitemap wspiera nową architekturę, zamiast prosić Google o crawlowanie starych URL-i po przekierowaniu.
Logi pokazują mniej wejść na stare ścieżki
Googlebot i użytkownicy częściej trafiają bezpośrednio na aktualne adresy dzięki linkom i aktualnym sygnałom.
Diagnostyka przekierowań łączy status, cel, indeks i intencję
Ten sam komunikat może oznaczać prawidłową kanonikalizację albo błąd migracji. Dlatego diagnozę zaczynaj od konkretnego URL-a: jaki kod zwraca, dokąd prowadzi, czy adres docelowy jest indeksowalny i czy spełnia intencję starej strony.
| Objaw | Prawdopodobna przyczyna | Co sprawdzić? |
|---|---|---|
| W GSC widzisz komunikat: Strona z przekierowaniem | To może być normalne dla wariantu niekanonicznego, np. http, www albo adresu bez ukośnika. | Sprawdź, czy finalny URL jest indeksowany i czy redirect prowadzi do preferowanej wersji. |
| Nowy URL nie przejmuje widoczności po migracji | Brak mapowania 1:1, zły kod, nietrafny cel, noindex, blokada robots.txt albo sprzeczny canonical. | Porównaj redirect, canonical, sitemapę, linkowanie wewnętrzne i raport indeksowania. |
| Stare URL-e długo pojawiają się w wynikach | Google potrzebuje czasu na recrawl albo pokazuje stary adres jako rozpoznawalną nazwę kanonicznego zasobu. | Monitoruj per URL, nie tylko domenę. Sprawdź, czy każdy stary adres ma poprawny cel. |
| Adres zwraca ERR_TOO_MANY_REDIRECTS | Pętla przekierowań: A prowadzi do B, B do A albo reguła przekierowuje adres do samego siebie. | Prześledź kolejne hop-y i usuń regułę, która wraca do poprzedniego URL-a. |
| Google zgłasza soft 404 po przekierowaniu | Docelowa strona nie odpowiada intencji starego adresu, np. produkt przekierowany na stronę główną. | Dopasuj cel tematycznie albo zwróć 404/410, jeśli odpowiednika nie ma. |
| Crawl pokazuje dużo 302 w ważnych sekcjach | Tymczasowe przekierowania zostały użyte jako stałe albo zostawione po testach. | Ustal, czy źródłowy URL ma wrócić. Jeśli nie, zmień regułę na 301/308. |
| Po zmianie reguły przeglądarka nadal otwiera stary cel | Cache przeglądarki, CDN albo wcześniejsze 301 utrudnia test, mimo że konfiguracja została poprawiona. | Porównaj wynik w curl, trybie prywatnym, innej przeglądarce i po wyczyszczeniu cache CDN. |
| Po przekierowaniu giną parametry kampanii lub filtrów | Reguła nie przenosi query stringa albo nadpisuje adres docelowy bez zachowania potrzebnych parametrów. | Przetestuj URL-e z UTM, filtrami, sortowaniem i wariantami produktu przed publikacją reguły. |
Najczęstsze błędy przekierowań w SEO
302 jako ostrożność przy trwałej zmianie - jeśli nie planujesz powrotu starego URL-a, tymczasowy kod tylko rozmywa sygnał migracji
301 przy czasowym braku produktu - wysyła sygnał trwałej zmiany, mimo że karta produktu może wrócić do sprzedaży
masowe przekierowanie do strony głównej - nie obsługuje intencji użytkownika i może zostać potraktowane jak soft 404
łańcuchy po kolejnych migracjach - A -> B -> C trzeba skrócić do A -> C, szczególnie przy większych serwisach
stare URL-e w sitemapie - sitemap powinna promować finalne, kanoniczne adresy, a nie źródła przekierowań
redirect do URL-a z noindex albo canonicalem na inny adres - docelowa strona wysyła wtedy sprzeczny sygnał względem przekierowania
utrata parametrów URL - reguła usuwa parametry kampanii, filtry, identyfikatory wariantów albo dane potrzebne aplikacji
Checklista przed publikacją przekierowań
- Każdy ważny stary URL ma przypisany konkretny, trafny adres docelowy albo decyzję 404/410.
- Dla trwałych zmian używasz 301 lub 308, a dla zmian czasowych 302 lub 307.
- Przekierowanie prowadzi bezpośrednio do finalnego adresu 200 OK, bez zbędnych pośredników.
- Reguła zachowuje potrzebne parametry URL albo świadomie je usuwa, jeśli nie mają wartości dla użytkownika i analityki.
- Adres docelowy nie jest zablokowany przez robots.txt, noindex, błędny canonical ani ochronę dostępu.
- Linki wewnętrzne, menu, breadcrumbs, canonicale, hreflangi i sitemap wskazują nowe URL-e.
- Nie przekierowujesz hurtowo niedopasowanych treści do strony głównej.
- Przed publikacją testujesz reguły na stagingu albo małej próbce URL-i.
- Po wdrożeniu monitorujesz GSC, logi, 404/410, soft 404, ruch organiczny i najważniejsze zapytania.
Powiązane tematy i narzędzia
Przekierowania są częścią szerszego systemu: crawlingu, indeksowania, architektury informacji, linkowania wewnętrznego i audytu technicznego. Te materiały pomagają przejść do sąsiednich decyzji.
Tester przekierowań
sprawdzenie statusów HTTP, łańcucha, pętli, czasu odpowiedzi i adresu finalnego
SEO techniczne
szerszy hub o statusach HTTP, przekierowaniach, canonicalach, JS, crawl i indeksowaniu
Crawling w SEO
jak Googlebot odkrywa URL-e i dlaczego łańcuchy przekierowań utrudniają crawl
Indeksowanie strony w Google
co zrobić, gdy URL po migracji nie pojawia się w wynikach albo ma błędny status
Linkowanie wewnętrzne
jak poprawić linki po zmianie adresów, żeby nie polegać na przekierowaniach
Audyt SEO
diagnostyka przekierowań, indeksowania, architektury i technicznych blokad
Nie masz pewności, czy przekierowania chronią widoczność?
W audycie sprawdzamy mapę URL-i, statusy HTTP, łańcuchy, soft 404, canonicale, sitemapę, linkowanie wewnętrzne, GSC i logi. Dzięki temu decyzja o 301, 302, 404 albo canonicalu wynika z realnej roli adresu, a nie z samej listy błędów w crawlerze.
FAQ
01Czym różni się przekierowanie 301 od 302?
301 oznacza trwałą zmianę adresu i jest sygnałem, że docelowy URL powinien przejąć rolę starego adresu. 302 oznacza zmianę tymczasową i pomaga utrzymać źródłowy URL jako kandydat do wyników, jeśli ma wrócić.
02Czy przekierowanie 301 przekazuje PageRank?
Według dokumentacji Google 301 i inne stałe przekierowania nie powodują utraty PageRank. Warunkiem praktycznym jest poprawne, trafne przekierowanie do strony, która odpowiada intencji starego URL-a.
03Czy przekierowanie 302 szkodzi SEO?
302 nie jest błędem, jeśli zmiana naprawdę jest tymczasowa. Problem pojawia się wtedy, gdy 302 obsługuje trwałą migrację, zmianę struktury URL albo rebranding.
04Jak długo trzymać przekierowania 301 po migracji?
Google zaleca utrzymywanie przekierowań tak długo, jak to możliwe, zwykle co najmniej rok. Z perspektywy użytkowników i linków zewnętrznych często opłaca się trzymać je dłużej.
05Czy komunikat Strona z przekierowaniem w Google Search Console jest błędem?
Nie zawsze. Jeśli sprawdzasz wariant niekanoniczny, np. http albo www, taki komunikat może być normalny. Błąd pojawia się wtedy, gdy redirect prowadzi do złego adresu, pętli, 404, soft 404 albo blokowanej strony docelowej.
06Co wybrać: przekierowanie 301 czy canonical?
301 wybierz, gdy użytkownik i robot nie powinni już korzystać ze starego URL-a. Canonical wybierz, gdy kilka wersji ma pozostać dostępnych, ale chcesz wskazać preferowany adres do indeksu.
07Ile przekierowań może mieć łańcuch?
Googlebot może śledzić kilka przekierowań, ale praktycznie należy prowadzić bezpośrednio do finalnego URL-a. Google zaleca unikanie łańcuchów, a jeśli nie da się ich usunąć, utrzymywanie ich nisko, najlepiej poniżej 3 i mniej niż 5.
08Czy przekierowywać wszystkie błędy 404 na stronę główną?
Nie. Masowe przekierowanie na stronę główną zwykle nie odpowiada intencji starego adresu i może zostać potraktowane jako soft 404. Jeśli nie ma trafnego odpowiednika, lepszy jest 404 albo 410.
09Czy meta refresh albo JavaScript redirect są dobre dla SEO?
Google potrafi obsłużyć meta refresh i JavaScript redirect, ale najbardziej przewidywalny jest redirect serwerowy HTTP. Meta refresh i JavaScript traktuj jako rozwiązania awaryjne, gdy nie masz kontroli nad serwerem lub aplikacją.
10Co zrobić z produktem chwilowo niedostępnym?
Najczęściej zostaw kartę produktu jako 200 OK, pokaż informację o dostępności, podobne produkty i aktualne dane strukturalne. 301 ma sens dopiero wtedy, gdy produkt jest trwale wycofany i istnieje bliski następca.