Łańcuchy przekierowań w sklepie: jak je wykryć

Łańcuchy przekierowań SEO powstają wtedy, gdy stary adres nie prowadzi bezpośrednio do właściwej strony, ale najpierw przekierowuje na inny adres, a ten przekierowuje dalej. Przykład jest prosty: /stary-produkt prowadzi do /produkt, a /produkt przekierowuje jeszcze na /nowy-produkt. Dla użytkownika kończy się to właściwą stroną, ale po drodze wykonywanych jest kilka żądań HTTP.

W sklepie takie ścieżki mogą narastać przez lata. Produkt zmienia nazwę, kategoria dostaje nowy adres, potem przebudowywana jest struktura URL, a kolejne reguły przekierowań zostają na serwerze. Efekt to redirect chain, czyli łańcuch przekierowań, którego źródło często trudno zauważyć bez sprawdzenia odpowiedzi serwera.

Poniżej znajdziesz sposób na znalezienie takich przypadków, ustalenie pierwszego adresu w łańcuchu i poprawienie reguł tak, aby stary URL prowadził bezpośrednio do aktualnego miejsca.

Łańcuchy przekierowań SEO: jak wygląda problem

Pojedyncze przekierowanie nie jest tym samym co łańcuch. Jeśli adres /buty-meskie zwraca 301 i wskazuje bezpośrednio na /buty-meskie-sportowe, mamy prostą relację:

/buty-meskie → 301 → /buty-meskie-sportowe → 200

Problem zaczyna się wtedy, gdy kolejny adres również przekierowuje:

/buty-meskie → 301 → /buty-meskie-sportowe → 301 → /obuwie-sportowe → 200

Jeszcze bardziej rozbudowana ścieżka może wyglądać tak:

/buty → 301 → /buty-meskie → 301 → /buty-meskie-sportowe → 301 → /obuwie-sportowe → 200

Właśnie taki układ nazywa się łańcuchem przekierowań. Każdy kolejny adres jest pośrednikiem, chociaż użytkownikowi nie jest on potrzebny.

HTTP definiuje przekierowania jako odpowiedzi z grupy 3xx. W przypadku 301 serwer informuje, że zasób został przeniesiony na nowy, docelowy adres. O tym, gdzie ma zostać wykonane kolejne żądanie, informuje nagłówek Location.

Dla sklepu najważniejsza jest więc nie sama obecność przekierowania, ale cała ścieżka od starego URL do końcowej strony. Jeżeli po pierwszej odpowiedzi 301 następuje następne 301, trzeba sprawdzić, dlaczego pierwszy adres nie wskazuje od razu aktualnego celu.

Skąd biorą się łańcuchy przekierowań w sklepie

Najczęściej nie powstają podczas jednej zmiany. Są efektem kilku kolejnych modyfikacji wykonanych w różnych momentach.

Dobrym przykładem jest produkt, którego adres zmieniał się kilka razy. Początkowo sklep miał URL /produkt?id=123, później został ustawiony adres /buty/model-x, a po zmianie struktury sklepu powstał /obuwie/model-x. Jeżeli każda zmiana dopisała nową regułę, może powstać:

/produkt?id=123 → /buty/model-x → /obuwie/model-x

Podobnie wygląda sytuacja przy zmianie kategorii. Stary adres kategorii zostaje przekierowany do nowej kategorii, a po kolejnej reorganizacji ta nowa kategoria również dostaje przekierowanie.

Źródłem problemu bywają także:

• zmiana nazwy produktu i wygenerowanie nowego URL,
• zmiana kategorii nadrzędnej,
• usunięcie kategorii i przeniesienie produktów do innej,
• migracja sklepu na inną platformę,
• zmiana struktury adresów produktów,
• przejście z HTTP na HTTPS,
• zmiana wersji z www na bez www albo odwrotnie,
• ręczne dopisywanie kolejnych reguł w .htaccess lub konfiguracji serwera,
• moduły SEO, które automatycznie tworzą przekierowania,
• import produktów wraz ze zmianą adresów,
• łączenie kilku sklepów lub domen.

Problem może powstać również wtedy, gdy dwa systemy próbują zarządzać tym samym przekierowaniem. Przykładowo platforma sklepu ma własną regułę, a dodatkowo w konfiguracji serwera znajduje się stara reguła z poprzedniej migracji.

Dlatego przy analizie nie wystarczy znaleźć adres, który zwraca 301. Trzeba sprawdzić, dokąd prowadzi i co zwraca następny adres.

Jak znaleźć łańcuchy przekierowań

Najprościej zacząć od listy starych URL-i. Możesz ją zebrać z przekierowań zapisanych w sklepie, pliku .htaccess, konfiguracji serwera, danych z crawlera, sitemap, Search Console albo wcześniejszego audytu.

Jeżeli chcesz wiedzieć, jak znaleźć łańcuchy przekierowań w praktyce, nie sprawdzaj tylko kodu pierwszej odpowiedzi. Dla każdego podejrzanego adresu prześledź cały ciąg odpowiedzi HTTP.

Przykładowo:

GET /stary-url

serwer odpowiada:

301 Location: /nowy-url

Następnie sprawdzasz /nowy-url i otrzymujesz:

301 Location: /aktualny-url

Dopiero /aktualny-url zwraca:

200 OK

To oznacza, że pierwszy adres znajduje się w łańcuchu.

Do pojedynczego sprawdzenia możesz wykorzystać narzędzia deweloperskie przeglądarki albo polecenia w terminalu. Przykładowe zapytanie może wyglądać tak:

curl -I https://example.pl/stary-url

Jeżeli odpowiedź zawiera 301 oraz Location, sprawdzasz wskazany adres. Możesz też śledzić przekierowania automatycznie, ale przy audycie dobrze jest zobaczyć również poszczególne etapy.

Przy większym sklepie ręczne sprawdzanie każdego URL-a szybko przestaje mieć sens. Wtedy crawler powinien zapisać dla każdego adresu kod odpowiedzi, adres docelowy i pełną ścieżkę przekierowania. Wyniki można następnie posortować według liczby kolejnych przekierowań.

Szczególną uwagę zwróć na adresy, które występują w wielu ścieżkach. Jeden pośredni URL może być celem dużej liczby starych adresów. Jeśli sam przekierowuje dalej, powstaje problem dotyczący całej grupy URL-i.

Jak rozpoznać źródło łańcucha po zmianie URL

Samo znalezienie ścieżki nie mówi jeszcze, dlaczego ona istnieje. Trzeba ustalić, która reguła utworzyła poszczególne przejście.

Zacznij od końca i cofnij się do pierwszego adresu. Załóżmy, że crawler pokazał:

/produkt-a → 301 → /produkt-b → 301 → /produkt-c → 200

Najpierw sprawdź, dlaczego /produkt-b przekierowuje na /produkt-c. Jeżeli /produkt-c jest aktualnym adresem produktu, prawdopodobnie reguła dla /produkt-b została utworzona przy ostatniej zmianie URL.

Następnie sprawdź /produkt-a. Jeżeli przekierowuje do /produkt-b, jest to starsza reguła. Nie powinna już wskazywać pośrednika, tylko aktualny adres /produkt-c.

Po zmianach produktów przydatne jest zestawienie starego i aktualnego adresu. Jeżeli sklep ma historię zmian URL, wykorzystaj ją. Jeżeli nie, porównaj stare reguły z obecnym adresem kanonicznym produktu.

W podobny sposób analizuje się kategorie. Jeśli stara kategoria prowadzi do kategorii pośredniej, a ta do jeszcze innej, sprawdź, czy obie strony są nadal używane. Jeżeli jedna istnieje wyłącznie po to, aby wykonać kolejne przekierowanie, można zwykle uprościć regułę.

Przy migracji całego sklepu przydaje się wcześniejsza mapa URL-i. Google zaleca przygotowanie mapowania starych adresów na odpowiadające im nowe adresy przed uruchomieniem zmian. To ogranicza ryzyko tworzenia przypadkowych ścieżek przekierowań.

Jeżeli przy okazji zmian adresów pojawiają się problemy z wersjami kanonicznymi, osobno sprawdź konflikt między canonical a przekierowaniem, ponieważ redirect i rel="canonical" mogą przekazywać różne sygnały dotyczące preferowanego URL-a.

Czy łańcuch przekierowań szkodzi SEO

Pytanie, czy łańcuch przekierowań szkodzi SEO, wymaga rozdzielenia kilku kwestii. Samo przekierowanie 301 jest normalnym mechanizmem stosowanym przy zmianie adresu strony. Google traktuje permanentne przekierowania jako silny sygnał dotyczący docelowego adresu.

Problemem jest długość ścieżki. Google w dokumentacji dotyczącej problemów z crawlowaniem wskazuje długie łańcuchy przekierowań jako czynnik negatywnie wpływający na efektywność crawlowania.

W sklepie ma to praktyczne znaczenie, ponieważ jeden produkt może mieć wiele historycznych URL-i. Jeśli każdy z nich przechodzi przez kolejne pośrednie adresy, crawler musi wykonać więcej pracy, zanim dotrze do strony końcowej.

Dochodzi do tego czas odpowiedzi serwera. Każdy etap redirectu jest osobną odpowiedzią HTTP, a następny adres wymaga kolejnego żądania. Przy pojedynczym adresie różnica może być mało widoczna. Przy dużej liczbie URL-i i rozbudowanej historii zmian nie ma powodu utrzymywać niepotrzebnych etapów.

Nie należy jednak wyciągać wniosku, że każde przekierowanie 301 jest błędem SEO. Jeżeli stary produkt został trwale przeniesiony i stary URL prowadzi bezpośrednio do właściwej nowej strony, jest to prawidłowy przypadek użycia przekierowania.

Problematyczny jest układ, w którym pośredni URL nadal wykonuje kolejne przekierowanie, mimo że znamy już końcowy adres.

Jak skrócić łańcuch przekierowań

Jeśli masz już pełną ścieżkę, poprawa zwykle polega na zmianie pierwszej reguły. Zamiast:

/stary-url → /pośredni-url → /aktualny-url

ustawiasz:

/stary-url → /aktualny-url

Pośredni URL może nadal istnieć jako osobny adres i mieć własne przekierowanie. Nie jest wtedy potrzebny jako element ścieżki pierwszego URL-a.

Przykład z konfiguracji sklepu:

/stary-produkt  → 301 → /produkt-po-zmianie
/produkt-po-zmianie → 301 → /nowy-produkt

Po uporządkowaniu:

/stary-produkt → 301 → /nowy-produkt
/produkt-po-zmianie → 301 → /nowy-produkt

W ten sposób oba stare adresy trafiają bezpośrednio do aktualnej strony.

Po zmianie reguły nie kończ audytu. Ponownie sprawdź każdy adres z listy i upewnij się, że odpowiedź końcowa jest prawidłowa. Jeśli celem jest istniejąca strona, powinna zwracać odpowiedź sukcesu, a nie kolejny redirect, błąd serwera czy stronę nieistniejącą.

Nie kieruj wielu niepowiązanych adresów na stronę główną tylko po to, aby uniknąć błędów 404. Przekierowanie powinno prowadzić do odpowiedniego zastępstwa. Jeżeli usunięty produkt nie ma sensownego odpowiednika, sytuację trzeba ocenić osobno zamiast tworzyć sztuczny łańcuch.

Przy okazji popraw również linki wewnętrzne. Jeżeli menu, breadcrumbs, filtry albo opisy produktów prowadzą do starego URL-a, użytkownik nadal będzie rozpoczynał ścieżkę od adresu wymagającego przekierowania. W przypadku większych sklepów przydaje się też analiza linków prowadzących do błędnych adresów, bo część niepotrzebnych redirectów może wynikać właśnie z nieaktualnych odnośników wewnętrznych.

Jak sprawdzić przekierowania po wdrożeniu zmian

Po poprawieniu reguł wykonaj ponowny test. Nie zakładaj, że skoro zmieniłeś jedną instrukcję na serwerze, problem został rozwiązany w całym sklepie.

Dla każdego poprawionego adresu sprawdź:

• kod odpowiedzi pierwszego URL-a,
• wartość nagłówka Location,
• liczbę kolejnych przekierowań,
• końcowy kod odpowiedzi,
• końcowy adres URL,
• zgodność końcowego adresu z właściwą stroną produktu lub kategorii.

Dobrze jest też sprawdzić warianty adresu. Sklep może mieć osobne reguły dla HTTP i HTTPS, www i bez www, końcowego ukośnika oraz różnych wariantów ścieżki. Łańcuch może być niewidoczny przy sprawdzeniu tylko jednego wariantu.

Przy większej zmianie struktury URL sprawdź także sitemapę. Powinna zawierać aktualne adresy stron, a nie stare URL-e wymagające przekierowania. Wewnętrzne linki również powinny prowadzić bezpośrednio do nowych adresów.

Jeśli sklep korzysta z Search Console, wykorzystaj narzędzie inspekcji URL do sprawdzenia konkretnych adresów. Przy większym audycie połącz dane z crawlera, logów serwera i listy przekierowań. Każde źródło pokazuje inną część problemu.

Przy okazji takiego przeglądu można znaleźć także problemy, które nie są samymi łańcuchami. Przykładowo przekierowanie może kończyć się błędem 404 lub 500. Jeśli crawler pokazuje takie przypadki, osobno sprawdź źródła błędów 500 w sklepie internetowym, zamiast traktować je jako zwykłe przekierowania.

Łańcuchy 301, 302, 307 i 308: co sprawdzać

Nie wszystkie odpowiedzi 3xx oznaczają dokładnie to samo. W sklepie najczęściej spotkasz 301 i 302, ale HTTP definiuje również między innymi 307 i 308.

Typ przekierowania	Znaczenie	Problem przy łańcuchu
301	Trwałe przeniesienie adresu	Kolejne 301 wydłużają ścieżkę do strony końcowej
302	Tymczasowe przekierowanie	Może być błędnym wyborem, jeśli zmiana adresu jest trwała
307	Tymczasowe przekierowanie z zachowaniem metody	Kolejne przekierowania komplikują obsługę żądania
308	Trwałe przekierowanie z zachowaniem metody	Niepotrzebne kolejne etapy zwiększają długość ścieżki

W przypadku zwykłej zmiany adresu produktu na stałe najczęściej analizujesz przekierowanie permanentne. Nie zmieniaj jednak typu statusu automatycznie tylko po to, żeby skrócić łańcuch. Najpierw ustal, czy zmiana adresu jest rzeczywiście trwała i jaki sposób obsługi żądania jest właściwy dla danej sytuacji.

HTTP rozróżnia między innymi przekierowania tymczasowe i permanentne. Statusy 307 i 308 dodatkowo jednoznacznie zachowują metodę żądania podczas przekierowania. W typowym audycie URL-i produktów najważniejsze pozostaje jednak ustalenie, czy użytkownik i crawler docierają do właściwego adresu bez zbędnych pośredników.

Jak uporządkować reguły przekierowań w sklepie

Jeśli sklep ma dużo historycznych zmian, nie poprawiaj reguł przypadkowo. Najpierw wyeksportuj istniejące przekierowania i zbuduj tabelę zawierającą co najmniej stary URL, aktualny cel, kod odpowiedzi oraz liczbę kroków.

Następnie grupuj adresy według końcowego celu. Jeśli kilkanaście starych URL-i prowadzi ostatecznie do tego samego produktu, sprawdź, czy wszystkie mają sens jako przekierowania do tej strony. Jeżeli któryś przechodzi przez pośrednika, zmień jego cel bezpośrednio na końcowy adres.

Przy większej liczbie zmian przydaje się także kontrola kolejności reguł. W zależności od konfiguracji serwera wcześniejsza reguła może przejąć żądanie przed regułą, która miała obsłużyć docelowy adres. Po zmianach testuj więc nie tylko pojedyncze URL-e, ale całe grupy podobnych adresów.

Jeśli sklep działa na WooCommerce, PrestaShop albo Shoperze, sprawdź również, czy platforma lub moduł SEO nie tworzy własnych przekierowań. Usunięcie wpisu z jednego miejsca może nie wystarczyć, jeśli drugi mechanizm nadal generuje kolejną odpowiedź 3xx.

Dobrą praktyką jest prowadzenie jednej aktualnej mapy starych i nowych URL-i przy większych migracjach. Dzięki temu kolejna zmiana struktury nie musi zaczynać się od odtwarzania historii z przypadkowo rozrzuconych reguł.

Jeżeli podczas porządkowania adresów wychodzi na jaw, że problem dotyczy nie tylko redirectów, ale całej struktury sklepu, sprawdzenie technicznej dostępności produktów w sklepie może pomóc ocenić, czy zmiany adresów nie pogłębiają innych problemów z dostępnością stron.

Co sprawdzić podczas audytu łańcuchów przekierowań

Zacznij od najstarszych adresów produktów i kategorii, zwłaszcza tych, które były wielokrotnie zmieniane. Sprawdź, czy pierwszy redirect wskazuje aktualny adres, czy tylko kolejny historyczny URL.

Następnie przeanalizuj reguły w miejscu, w którym są faktycznie wykonywane. Może to być konfiguracja serwera, .htaccess, panel CMS, moduł SEO albo własny kod aplikacji. Nie zakładaj, że jedna lista przekierowań pokazuje wszystkie reguły działające na stronie.

Na końcu przeprowadź kontrolę po wdrożeniu. Stary URL powinien prowadzić do właściwej strony, a aktualny URL powinien być dostępny bez kolejnego przekierowania. Zaktualizuj też linki wewnętrzne, sitemapę i inne miejsca, w których sklep nadal używa starego adresu.

Jeżeli takich przypadków jest dużo i nie wiadomo, od czego zacząć, audyt techniczny sklepu internetowego pozwala przejść od pojedynczego problemu z redirectem do szerszej kontroli adresów, linkowania i dostępności stron.

Łańcuch przekierowań jest najczęściej śladem wcześniejszych zmian w sklepie. Nie trzeba usuwać historii adresów, aby go uporządkować. Trzeba ustalić aktualny cel i zmienić stare reguły tak, aby prowadziły do niego bez zbędnych etapów. Po każdej większej zmianie URL warto ponownie sprawdzić ścieżki 3xx, ponieważ właśnie wtedy najłatwiej dopisać kolejny pośredni adres.