Jak wykrywać łańcuchy przekierowań i pętle przekierowań

Adres URL nie powinien prowadzić użytkownika przez objazd. Kliknięcie, jeden skok, właściwa strona. Tyle wystarczy. Problem zaczyna się wtedy, gdy stary adres przekierowuje na nowszy, ten na wersję HTTPS, potem na wariant z www, następnie na adres z ukośnikiem, a dopiero na końcu na właściwą podstronę. Użytkownik widzi chwilowe opóźnienie. Bot wyszukiwarki widzi łańcuch przekierowań.

Jeszcze gorzej, gdy adres A prowadzi do B, B do C, a C z powrotem do A. To już pętla przekierowań — błąd, który potrafi całkowicie zablokować wejście na stronę i zatrzymać crawlera.

W praktyce najdroższe nie są przekierowania widoczne od razu. Najwięcej szkód robią stare reguły po migracji, automatyczne wymuszanie HTTPS, pozostałości po zmianie CMS-a, niekontrolowane wtyczki, reguły w .htaccess, ustawienia CDN-u i warianty adresów, które osobno wyglądają niewinnie, ale razem tworzą techniczny bałagan. Dlatego przekierowań nie diagnozuje się „na oko”. Trzeba sprawdzić kody statusu HTTP, nagłówki, liczbę skoków, adresy pośrednie i finalny URL.

Diagnostyka przekierowań: co sprawdzić najpierw

Najpierw trzeba ustalić skalę problemu. Jeden adres diagnozuje się inaczej niż całą strukturę sklepu, bloga albo serwisu po migracji. Dla pojedynczego URL-a wystarczy test nagłówków. Dla większej strony potrzebny jest crawl i eksport danych.

Typowy łańcuch wygląda tak:

• użytkownik wpisuje http://example.pl/oferta,
• serwer przekierowuje na https://example.pl/oferta,
• potem na https://www.example.pl/oferta,
• następnie na https://www.example.pl/oferta/,
• na końcu na https://www.example.pl/uslugi/.

Technicznie strona może się otworzyć. Problem polega na tym, że zamiast jednego przekierowania mamy cztery. To klasyczny redirect chain. Priorytet naprawy jest wysoki, jeżeli taki łańcuch dotyczy adresów z linkami zewnętrznymi, stron generujących ruch organiczny, produktów, kategorii, landing page’y albo URL-i po migracji.

Przy analizie każdego adresu trzeba zanotować:

• adres startowy — URL, od którego zaczyna się test,
• adresy pośrednie — wszystkie kroki między startem a celem,
• kod statusu HTTP — najczęściej 301, 302, 307 albo 308,
• adres końcowy — finalną stronę, która powinna zwracać 200,
• liczbę skoków — im więcej, tym większe ryzyko błędów, opóźnień i problemów z crawlowaniem.

Najgroźniejsza sytuacja to pętla przekierowań. Przykład:

• /kontakt przekierowuje na /kontakt/,
• /kontakt/ przekierowuje z powrotem na /kontakt.

Efekt jest prosty: przeglądarka zatrzymuje ładowanie, crawler zgłasza błąd, a użytkownik widzi komunikat o zbyt wielu przekierowaniach. Tego nie odkłada się „na później”. Pętla przekierowań nie spowalnia dostępu do strony — ona go blokuje.

Kody przekierowań trzeba interpretować zgodnie z ich funkcją, a nie automatycznie zamieniać wszystko na 301. Błędny kod potrafi utrwalić adres, który miał być tylko tymczasowy, albo zostawić w indeksie URL, który powinien już zniknąć.

Kod statusu	Typ przekierowania	Kiedy stosować w praktyce?	Znaczenie SEO
301 Moved Permanently	Stałe, trwałe	Zmiana struktury adresów URL, trwała migracja domeny, trwałe przeniesienie produktu, kategorii albo wpisu.	Najmocniejszy sygnał, że nowy adres powinien przejąć rolę starego URL-a.
308 Permanent Redirect	Stałe, nowoczesne	Podobnie jak 301, ale z zachowaniem metody żądania, np. POST. Przydatne w bardziej technicznych wdrożeniach.	Stały sygnał przeniesienia. W SEO pełni podobną rolę jak 301.
302 Found / Moved Temporarily	Tymczasowe	Prace serwisowe, krótkie promocje, testy A/B, czasowe wyłączenie sekcji.	Nie powinien być używany jako sygnał trwałej migracji. Przy długim stosowaniu może utrzymywać stary URL jako właściwy adres.
307 Temporary Redirect	Tymczasowe, nowoczesne	Nowoczesny odpowiednik 302, zachowujący metodę żądania. Często widoczny także jako wewnętrzne przekierowanie przeglądarki przy HSTS.	Nie jest kodem do trwałego przenoszenia adresów. Przy migracjach nie zastępuje 301/308.

W pierwszej kolejności sprawdzaj:

1. przekierowania z HTTP na HTTPS,
2. warianty z www i bez www,
3. końcowy ukośnik w adresie,
4. wielkość liter w URL-ach,
5. stare adresy po migracji,
6. przekierowania z parametrów, np. ?utm_source=,
7. wersje językowe i regionalne,
8. reguły CMS-a, CDN-u i serwera, które mogą nakładać się na siebie.

Osobny temat to HSTS, czyli HTTP Strict Transport Security. Jeżeli serwis poprawnie wdroży nagłówek HSTS, przeglądarka po pierwszym bezpiecznym połączeniu zapamiętuje, że ma używać HTTPS automatycznie. Przy kolejnych wejściach na adres HTTP nie musi odpytywać serwera i odbierać klasycznego przekierowania 301/302 — sama przełącza żądanie na HTTPS. W narzędziach developerskich można wtedy zobaczyć wewnętrzne przekierowanie 307, ale nie jest to zwykły skok wygenerowany przez serwer.

To ważny niuans. HSTS może ograniczyć techniczny koszt pierwszego skoku HTTP → HTTPS po stronie przeglądarki, ale nie naprawi bałaganu w regułach CMS-a, CDN-u czy .htaccess. Jeżeli po HTTPS nadal masz non-www → www → ukośnik → nowy slug, HSTS nie rozwiąże problemu łańcucha. On usuwa jeden typ objazdu, nie całą mapę błędnych tras.

Najczęstszy błąd w audytach? Sprawdzanie tylko adresu widocznego w pasku przeglądarki. Przeglądarka pokazuje finał. Nie pokazuje pełnej trasy, a właśnie trasa jest problemem.

Narzędzia do wykrywania łańcuchów i pętli przekierowań

Do szybkiego testu pojedynczego adresu wystarczy terminal. Najprostsza komenda:

curl -IL --max-redirs 10 https://example.pl/stary-adres

Ta komenda pokazuje kolejne nagłówki odpowiedzi, kody HTTP i nagłówek Location, czyli adres, na który serwer przekierowuje użytkownika. Parametr --max-redirs 10 ogranicza liczbę przekierowań. Przy pętli to zabezpieczenie ma znaczenie, bo bez limitu narzędzie mogłoby próbować iść dalej bez końca.

Dla ręcznej diagnostyki warto przyjąć prostą zasadę:

• 0 przekierowań — dobrze, jeżeli testowany adres jest finalny,
• 1 przekierowanie — akceptowalne i często poprawne,
• 2 przekierowania — do sprawdzenia, szczególnie na ważnych URL-ach,
• 3 lub więcej — zwykle do naprawy,
• pętla — naprawa natychmiastowa.

Przy większych serwisach ręczne sprawdzanie adres po adresie nie ma sensu. Tu potrzebny jest crawler, np. Screaming Frog SEO Spider. Darmowa wersja pozwala crawlować do 500 URL-i. Płatna licencja usuwa ten limit i kosztuje 199 GBP rocznie. To nie jest narzędzie wyłącznie do przekierowań, ale w tej pracy sprawdza się bardzo dobrze, bo pokazuje kody odpowiedzi, adresy docelowe, łańcuchy i pętle w skali całej witryny.

Praktyczna procedura w crawlerze:

1. Uruchom crawl domeny.
2. Odfiltruj adresy z kodami 3xx.
3. Sprawdź raport Redirect Chains i Redirect Loops.
4. Wyeksportuj listę: adres startowy, adresy pośrednie, finalny URL, liczba skoków.
5. Oznacz priorytety: ruch organiczny, linki zewnętrzne, strony sprzedażowe, stare adresy po migracji.
6. Dopiero potem poprawiaj reguły.

Nie poprawiaj wszystkiego naraz, jeżeli serwis jest duży. To kuszące, ale ryzykowne. Przy setkach reguł łatwo usunąć przekierowanie, które obsługuje stary adres z mocnymi linkami zewnętrznymi. Bezpieczniej pracować grupami: HTTP/HTTPS, www/non-www, ukośniki, stare katalogi, zmiany slugów, produkty wycofane, kategorie po migracji.

Są też narzędzia online typu redirect checker. Nadają się do szybkiego sprawdzenia pojedynczej strony, ale mają ograniczenia. Nie wrzucaj tam adresów z tokenami, linków podglądowych, paneli klienta, koszyków, linków resetowania hasła ani URL-i zawierających dane użytkownika. Do takich testów lepszy jest lokalny terminal albo crawler uruchomiony na własnym komputerze.

W audytach technicznych przydaje się również Google Search Console, ale z jednym zastrzeżeniem: to nie jest narzędzie do pełnego mapowania łańcuchów przekierowań. GSC może pokazać problemy z indeksowaniem, błędy po migracji albo adresy, które Google interpretuje inaczej, niż zakłada właściciel strony. Do samego wykrywania ścieżki przekierowań lepszy jest crawler, analiza nagłówków albo logi serwera.

Najlepszy zestaw na start:

• curl — pojedyncze adresy i szybka weryfikacja po poprawce,
• Screaming Frog — crawl całej strony i eksport błędów,
• logi serwera — sprawdzenie, czy boty i użytkownicy realnie trafiają w stare adresy,
• Google Search Console — kontrola skutków dla indeksowania,
• CMS / panel redirect managera — kontrola reguł tworzonych automatycznie.

Kolejność ma znaczenie. Najpierw dane techniczne, potem decyzja. Nie odwrotnie.

Jak naprawiać przekierowania bez tworzenia nowych problemów

Zasada główna jest prosta: stary adres powinien prowadzić bezpośrednio do finalnego adresu. Nie do kolejnego starego adresu. Nie do wersji pośredniej. Bez objazdu.

Zamiast:

A → B → C → D

powinno być:

A → D
B → D
C → D

To ogranicza liczbę żądań, zmniejsza ryzyko błędów i porządkuje sygnały kanoniczne. Dla użytkownika oznacza szybsze przejście. Dla crawlera — mniej marnowania crawl budget na adresy, które i tak nie mają być indeksowane.

Naprawę warto robić według priorytetów:

1. Pętle przekierowań — blokują dostęp, więc idą jako pierwsze.
2. Łańcuchy na stronach z ruchem lub linkami — wpływają na SEO, UX i sprzedaż.
3. Przekierowania po migracji — szczególnie stare adresy kategorii, produktów, wpisów i landing page’y.
4. Duplikaty wariantów URL — HTTP/HTTPS, www/non-www, ukośniki, wielkość liter.
5. Drobne łańcuchy na mało istotnych adresach — do uporządkowania, ale nie przed krytycznymi błędami.

Nie każda zmiana wymaga 301. Jeżeli podstrona została przeniesiona na stałe, 301 albo 308 są logicznym wyborem. Jeżeli przeniesienie jest czasowe, lepszy będzie 302 albo 307. Decyzja graniczna jest prosta: jeżeli nie masz pewności, że nowy adres zostanie na stałe, nie ustawiaj 301 tylko dlatego, że „tak jest lepiej pod SEO”. Stałe przekierowania bywają cache’owane, a ich odkręcanie po czasie potrafi być kłopotliwe.

W praktyce przekierowania najczęściej poprawia się w jednym z kilku miejsc:

• plik .htaccess na Apache,
• konfiguracja Nginx,
• ustawienia hostingu,
• reguły w CMS-ie,
• wtyczki SEO lub redirect manager,
• CDN, np. reguły na poziomie edge,
• konfiguracja platformy e-commerce.

Tu pojawia się typowa pułapka: jedna reguła działa w CMS-ie, druga na serwerze, trzecia w CDN-ie. Każda osobno wygląda sensownie. Razem tworzą łańcuch. Dlatego po poprawce trzeba ponownie sprawdzić cały adres startowy, nie tylko regułę, którą zmieniono.

Szczególnie ostrożnie trzeba podchodzić do WordPressa i wtyczek typu Rank Math, Redirection czy innych managerów przekierowań. Jeśli zmieniasz adres URL produktu, wpisu albo kategorii kilka razy w roku, wtyczka może automatycznie tworzyć kolejne reguły. Po czasie w bazie danych zostaje historia przekierowań, której administrator już nie pamięta: stary slug prowadzi do nowszego, nowszy do kolejnego, a po drodze dochodzi jeszcze reguła z serwera lub CDN-u.

To nie zawsze widać w pliku .htaccess. Część przekierowań działa z poziomu bazy danych CMS-a. Dlatego przy WordPressie trzeba kontrolować historię automatycznych przekierowań w panelu wtyczki, a nie tylko konfigurację serwera. Jeżeli sklep lub blog często zmienia slugi, warto raz na jakiś czas wyeksportować reguły i sprawdzić, czy nie powstały ukryte łańcuchy.

Przykład z praktyki: migracja sklepu i 4 skoki do produktu

Podczas migracji dużego sklepu internetowego z Magento na Shopify zostawiono część starych reguł w .htaccess. Do tego doszły nowe przekierowania po stronie platformy i osobne wymuszenie wersji HTTPS oraz www.

Efekt dla przykładowej karty produktu wyglądał tak:

stary-produkt.html → /produkt/stary-slug → https://www.domena.pl/products/stary-slug → https://www.domena.pl/products/nowy-slug

Robot Google musiał przejść przez 4 skoki, żeby dotrzeć do właściwej karty produktu. Użytkownik zwykle widział tylko wolniejsze ładowanie, ale crawler tracił czas na adresy pośrednie. Po kilku tygodniach część asortymentu zaczęła wypadać z indeksu, a w logach było widać, że bot regularnie odwiedza stare techniczne adresy zamiast finalnych kart produktów.

Naprawa nie polegała na usunięciu wszystkich starych przekierowań. To byłby błąd, bo część URL-i miała linki zewnętrzne. Rozwiązaniem było skrócenie tras:

stary-produkt.html → finalny URL produktu

oraz analogiczne mapowanie wszystkich pośrednich adresów bezpośrednio do finalnych kart. Dopiero po takim czyszczeniu crawl zaczął pokazywać jednoskokowe przekierowania, a Google Search Console przestało raportować narastające problemy z adresami pośrednimi.

Dobra procedura naprawy wygląda tak:

1. Zrób eksport obecnych przekierowań.
2. Oznacz adresy startowe, pośrednie i końcowe.
3. Ustal finalny adres dla każdej grupy.
4. Usuń zbędne kroki pośrednie.
5. Sprawdź, czy reguła nie dubluje się w CMS-ie, serwerze i CDN-ie.
6. Przetestuj próbkę ręcznie przez curl.
7. Uruchom ponowny crawl.
8. Sprawdź logi i Google Search Console po wdrożeniu.

Nie usuwaj starych przekierowań tylko dlatego, że są stare. Jeżeli adres ma linki zewnętrzne, pojawia się w wynikach wyszukiwania albo nadal dostaje wejścia, przekierowanie może być potrzebne. Usuwanie go „dla porządku” może zamienić działający URL w błąd 404.

Najgorszy wariant po migracji to przekierowanie wszystkich nieistniejących adresów na stronę główną. Wygląda czysto w raporcie, ale jest słabe dla użytkownika i ryzykowne dla SEO. Stary produkt powinien prowadzić do odpowiednika, kategorii nadrzędnej albo sensownej alternatywy. Jeżeli nie ma żadnego odpowiednika, czasem lepsze będzie 410 Gone niż udawanie, że strona główna rozwiązuje problem.

Po naprawie nie oceniaj efektu po jednym wejściu w przeglądarce. Cache, CDN i przeglądarki potrafią pokazywać wynik sprzed zmiany. Testuj w trybie bez cache, przez terminal i z różnych wariantów adresu: HTTP, HTTPS, www, non-www, z ukośnikiem i bez ukośnika. Dopiero wtedy można uznać, że reguła działa.

FAQ: najczęstsze pytania o łańcuchy i pętle przekierowań

Ile przekierowań w łańcuchu jest dopuszczalne?
Najlepiej jedno. Dwa bywają akceptowalne, jeśli wynikają z tymczasowego procesu technicznego. Trzy i więcej to sygnał do naprawy, zwłaszcza na stronach z ruchem, linkami zewnętrznymi, sprzedażą albo widocznością w Google.

Czy każdy łańcuch przekierowań szkodzi SEO?
Nie każdy w tym samym stopniu. Największy problem pojawia się przy ważnych URL-ach: stronach z linkami zewnętrznymi, adresach po migracji, produktach, kategoriach i podstronach często odwiedzanych przez boty. Mało istotny adres techniczny ma niższy priorytet, ale nadal warto go uporządkować.

Czym różni się łańcuch przekierowań od pętli przekierowań?
Łańcuch prowadzi przez kilka adresów do finalnej strony. Pętla nie ma poprawnego końca, bo adresy odsyłają do siebie nawzajem. Łańcuch zwykle spowalnia i komplikuje crawl. Pętla potrafi całkowicie zablokować dostęp.

Czy 302 trzeba zawsze zamienić na 301?
Nie. 302 ma sens, gdy przekierowanie jest tymczasowe: przy teście A/B, krótkiej promocji, awarii lub czasowym wyłączeniu podstrony. Zamień je na 301 albo 308 dopiero wtedy, gdy przeniesienie jest trwałe i stary adres nie ma wrócić jako docelowy.

Jak sprawdzić przekierowanie bez płatnych narzędzi?
Użyj komendy curl -IL --max-redirs 10 adres-url. Dla pojedynczych adresów to wystarczy. Przy większej stronie darmowa wersja Screaming Frog pozwala sprawdzić do 500 URL-i w jednym crawlu.

Czy HSTS zastępuje przekierowanie HTTP na HTTPS?
Nie w pełnym sensie. HSTS pozwala przeglądarce automatycznie używać HTTPS po wcześniejszym otrzymaniu poprawnego nagłówka. To ogranicza potrzebę kolejnego serwerowego przekierowania HTTP → HTTPS dla danego użytkownika, ale nie naprawia łańcuchów tworzonych przez CMS, CDN, www, ukośniki albo stare slugi.

Czy przekierowanie wszystkich starych adresów na stronę główną jest dobrym pomysłem?
Zwykle nie. To skrót, który psuje intencję użytkownika. Lepsze jest przekierowanie na najbliższy odpowiednik. Gdy odpowiednika nie ma, trzeba rozważyć kategorię nadrzędną, stronę informacyjną albo kod 410.

Od czego zacząć naprawę, jeśli raport pokazuje setki błędów?
Najpierw usuń pętle. Potem popraw łańcuchy na adresach z ruchem, linkami i znaczeniem biznesowym. Następnie uporządkuj przekierowania po migracji oraz warianty HTTP/HTTPS, www/non-www i ukośniki. Mało istotne URL-e techniczne zostaw na koniec. Największy błąd to poprawianie raportu od góry bez priorytetów.