Długość łańcucha przekierowań dla narzędzi i robotów

Postanowiłem bardzo skrupulatnie sprawdzić test Sebastiana Heymanna na temat łańcucha przekierowań, a przy okazji rozszerzyć go o dodatkowe testy różnych narzędzi – pomijając aspekty związane z crawl budget. SEO to nieustannie testy, weryfikacje, analizy i wyciąganie wniosków… i wracamy do początku zdania 🙂 Zainteresowałem? Zapraszam do lektury, a jak chcesz pominąć wszystkie testy i wnioski, to zapraszam do podsumowania 😉

Środowisko testowe nie jest wybitne ale uważam, że wystarczające. Do testów wykorzystałem darmowy hosting, na którym:

1. Postawiłem WordPress
2. Zainstalowałem darmową wtyczkę – Redirection – którą osobiście polecam!
3. Ustawiłem na dobry początek 30 przekierowań

Zacząłem przeprowadzać testy na różnych dostępnych narzędziach online oraz robotach i przeglądarkach na komputerze dla porównania wyników. W niektórych sytuacjach, gdy nie byłem w stanie jednoznacznie ustalić, czy test przebiegł pomyślnie, korzystałem z pomocy skryptu PHP (z testu nr 2).

Liczenie zawsze rozpoczynałem od zera. Logika podpowiada żeby zaczynać od 1 -> 2 -> 3 ale właśnie, to jest błąd. Dlaczego? Odniosę się tutaj do konwencji kodowania.

W programowaniu często zaczynamy liczyć od zera. Jest to szczególnie powszechne w C, C++, Python, Java, czy JavaScript. Na przykład, jeśli mam listę elementów, to pierwszy element będzie miał indeks 0, a drugi będzie miał indeks 1, itd. Rozpoczynając od 0 mogę logicznie i konsekwentnie indeksować każdy krok w łańcuchu przekierowań, co ułatwia śledzenie i analizę. Dlatego postanowiłem wykorzystać tą technikę w testach aby zapobiegać przesunięciu indeksu tablicy, gdy każde przekierowanie jest jak krok w procesie. Dla wzrokowców:

• 0 -> 1 = pierwsze przekierowanie
• 1 -> 2 = drugie przekierowanie
• 2 -> 3 = trzecie przekierowanie

Test 1: Test wyników z elementami rozszerzonymi

Na sam początek postanowiłem sprawdzić, jak wypadnie narzędzie do testowania elementów rozszerzonych od Google oraz samo narzędzie od schema.org w kontekście łańcucha przekierowań. Łącznie przeprowadziłem 6 testów:

• 2x – sprawdzanie działania narzędzia indeksującego Google na smartfony
• 2x – sprawdzanie działania narzędzia indeksującego Google na komputery
• 2x – walidator Schema.org

Celem tego testu było zrozumienie jak długo Rich Results Tool i walidator Schema.org potrafi podążać za łańcuchami przekierowań, zwłaszcza w kontekście różnych urządzeń. Spodziewałem się podobnych wyników ale chciałem mieć pewność.

Wszystkie testy zakończyły się tym samym wynikiem – obydwa narzędzia, Rich Results Tool wraz z walidatorem Schema.org, osiągnęły limit 5 przekierowań i po tym rezygnują z dalszego sprawdzania.

Test 2: Przeglądarka: Edge

Przeglądarka: Edge, wersja 121.0.2277.128, 64 bit

Żeby mieć większy zakres porównawczy postanowiłem sprawdzić każdą przeglądarkę po kolei zaczynając od Edge. Interesujące jest, że przeglądarka Edge bez problemu doszła na koniec łańcucha przekierowań osiągając 30 stron. Muszę przyznać, że się zdziwiłem. W takim razie, tak jak przypuszczałem, przeglądarki mogą różnie obsługiwać przekierowania, tzn. mieć różną określoną maksymalną ilość przekierowań. Postanowiłem więc wspomóc się prostym skryptem w PHP, który w pasku adresu wskaże dokładnie ile jest możliwych przekierowań

<?php
$liczba_odwiedzin = $_GET["odwiedzin"] ?? 0;
$nastepna_liczba = $liczba_odwiedzin + 1;
$ostatnie_przekierowanie = $_SERVER['PHP_SELF'] . '?odwiedzin=' . $nastepna_liczba;
header('Location:' . $ostatnie_przekierowanie);
exit;
?>

Wystartowałem z adresem /index.php?odwiedzin=0. Przeglądarka Edge na początku doszła do 19 przekierowań, następnie do 38, później 57… 76… i zakończyłem na 95. Później uruchamia skrypt od nowa i tak w kółko, bo za każdym razem w pasku adresu parametr ?odwiedzin=xx zwiększał się o 19. Każde kolejne przekierowanie prowadziło do dłuższego czasu oczekiwania na przetworzenie, proporcjonalnie do liczby odwiedzin.

Test 3 i 4: Przeglądarki: Opera i Chrome

Przeglądarka:

• Opera, wersja: 107.0.5045.21, 64 bit
• Chrome, wersja 122.0.6261.69, 64-bitowa

W skrócie: Wyniki identyczne dla Edge, Opera i Chrome, tzn. 19 pełnych przekierowań przekierowań. Teoretycznie 20 przekierowanie powinno dojść do skutku ale nie doszło, dlatego napisałem “pełnych przekierowań”. po czym wyświetla błąd err_too_many_redirects.

Żeby być pewnym, to wyłączyłem przekierowania powyżej 20 – błąd. Wyłączyłem więc przekierowanie z 19 strony na 20. Strona numer 19 została wyświetlona natychmiastowo, werdykt: 19 pełnych przekierowań dla wszystkich 3 przeglądarek. Spowodowane zapewne jest tym, że Edge, Opera i Chrome bazują na projekcie open-source Chromium i mają podobne (identyczne?) ustawienia.

Test 5: Przeglądarka: Firefox

Przeglądarka: Firefox, wersja 123.0, 64 bity

Sytuacja podobna do poprzedniego testu ale Firefox zwrócił 20 przekierowań i to max jaki jest możliwy do osiągnięcia. Oczywiście bez modyfikowania ustawień 😉 Firefox jest znany z bardzo dużych możliwości personalizacji ustawień. Z ciekawości sprawdziłem czy mogę zmienić maksymalną liczbę przekierowań i… zmieniłem! Jak?

1. Wpisałem about:config w pasku adresu
2. Następnie wyszukałem “redirect” z pośród kilkunastu wierszy wybrałem: network.http.redirection-limit
3. Zmieniłem limit na 3

Dla tego limitu zrobiło 3 przekierowania. Później jeszcze kilka testów i faktycznie można zmodyfikować maksymalną liczbę łańcuchów przekierowań obsługiwanych przez Firefox – w sumie interesujące.

Test 6: Internet Archive Wayback Machine

Ciekawość doprowadziła mnie do przetestowania strony archive.org

Co to jest archive.org?

To organizacja non-profit zajmująca się archiwizacją treści internetowych oraz innych materiałów cyfrowych. Umożliwia użytkownikom przeglądanie zarchiwizowanych wersji stron internetowych. Archive.org gromadzi również różnorodne zasoby, takie jak książki, nagrania dźwiękowe, filmy, zdjęcia i inne dostępne do publicznego użytku.

Jak długo archive.org obsługuje łańcuch przekierowań?

Archive.org przeskakuje 15x dla już zapisanego adresu i próbując przekierować na 16 stronę ostatecznie wyrzuca informację

This page is unavailable for archiving. The server returned code: because server does not respond

Dla adresu, który jest sprawdzany ale nie istnieje w archiwum Wayback Machine maksymalny limit to 4 przekierowania. Może nie powinienem wykorzystywać tego fajnego narzędzia w tak trywialny sposób ale bardzo mnie to ciekawiło.

Uznajmy ten test za dygresję 😀

Test 7: URL Inspection Tool

W Google Search Console jest narzędzie do sprawdzania adresów URL, które ma własny User-Agent i postanowiłem sprawdzić też tutaj jak daleko google zajdzie. Czy osiągnie 20 przekierowań, czy mniej. Szybki test wykazał, że adres jest sprawdzany jednocześnie przez 2 boty.

1. Mobilny
2. Komputerowy

To by się zgadzało, ponieważ w dokumentacji google są zapisane 2 boty:

• Mobile
  Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Google-InspectionTool/1.0;)
• Desktop
  Mozilla/5.0 (compatible; Google-InspectionTool/1.0;)

Natomiast zaciekawiło mnie, że skanowanie odbywało się z 3 różnych IP. Tak wygląda statystyka:

W obydwu przypadkach narzędzie zrobiło 6 przekierowań.

Test 8: Bingbot

Pomyślnie 3x udało mi się sprawdzić łańcuch przekierowań dla Bingbot

Liczenie standardowo zaczynam od zera. Bingbot przeskakuje 6 razy i zatrzymuje się na 7 stronie. W takim razie bingbot robi 6 pełnych przekierowań, bo 7 przekierowanie nie dochodzi do skutku.

Podobnie jak u googlebota, strona była sprawdzana z trzech różnych adresów IP ale user-agent zawsze ten sam:

• 40.77.167.48
• 52.167.144.179
• 52.167.144.238

Adres IP bingbota można sprawdzić w oficjalnym narzędziu: https://www.bing.com/toolbox/verify-bingbot. Myślę że to byłoby na tyle w sprawie bingbot 🙂

Test 9 i 10: Screaming Frog i Xenu

W teście nie mogło zabraknąć żaby! Dwukrotny test przy użyciu skryptu PHP oraz zwykłego przekierowania 301 wykazał, że SF robi 10 pełnych przekierowań po czym wyrzuca błąd “404 Too Many Redirects”.

Natomiast – mniej znany soft – Xenu bez żadnego problemu przeszedł test 100 przekierowań i zajęło to 42 sekundy. Zainteresowało mnie to, więc postanowiłem sprawdzić przy pomocy PHP jaki ma limit. Musze przyznać, że nie spodziewałem się tysiąca przekierowań zaczynając od /index.php?odwiedzin=0 i kończąc na /index.php?odwiedzin=1000

Tak, dokładnie Xenu obsługuje maksymalnie 1000 przekierowań 🙂

Test 11: 301 + Meta refresh / javascript

Czy można zmanipulować łańcuch przekierowań aby zwiększyć jego “żywotność”?

Po powyższych testach zadałem sobie właśnie takie pytanie, więc na podstawie powyższych testów robię kolejne. Postanowiłem wypróbować kombinacje różnych przekierowań, a jest ich kilka:

1. Przekierowanie 3xx – do tej pory wszystkie testy przeprowadzałem z przekierowaniem 301
2. Przekierowanie przy pomocy tagu meta refresh (przekierowanie HTML)
   • Ten znacznik działa, bo działać musi jednak trzeba wspomnieć, że jest przestarzały i W3C.org nie zaleca używania przekierowań meta refresh
3. Przekierowanie w JavaScript

Przekierowania w 3xx są po stronie serwera, natomiast przekierowanie HTML i JavaScript jest wykonywane bezpośrednio po stronie klienta – na urządzeniu użytkownika, a nie na serwerze jak to ma miejsce z 3xx (301, 302, 307, 308).

Usunąłem przekierowanie 301 ze strony nr 20 na 21. W zamian na stronie nr 20 najpierw dałem przekierowanie html 0 sekund na stronę nr 21, gdzie kolejne przekierowania były bez zmian, czyli ustawione 301.

<meta http-equiv="Refresh" content="0;url=""/>

Po tym zmieniłem przekierowanie HTML na JavaScript

<script type="text/javascript">
    location.href="";
</script>

Za każdym razem sprawdziłem w konsoli DevTools jaki zostanie zwrócony kod HTTP. Wychodzi na to, że w obydwu przypadkach serwer najpierw zwraca kod odpowiedzi HTTP – w moim przypadku – 200 (OK). Po otrzymaniu tej odpowiedzi, przeglądarka wykonuje dalej przekierowanie na podstawie instrukcji zawartych w tagu meta refresh strony.

W skrócie: Dodanie meta refresh lub location.href na limicie łańcucha przekierowań pozwoliło go “zresetować”, dzięki czemu mogłem osiągnąć kolejne 20 przekierowań – łącznie 40. Muszę przyznać, że widzę tutaj małe pole do nadużyć.

Ciekawostka: Odpaliłem w przeglądarce “adres zero” i do strony nr 19 referrer nie był przekazywany. Dopiero po “zresetowaniu” łańcucha każde kolejne przekierowanie wskazywało referrer strony nr 20, czyli tam gdzie nastąpił “reset”.

Ciekawostka 2: Ten trik działa na googlebot 🙂

Test 12: Googlebot

Przyszedł czas na najważniejszą część badania, czyli ile wynosi prawdziwy limit googlebota?

Chciałem się upewnić, więc test przeprowadziłem wielokrotnie na przestrzeni kilku dni. Wynik był zawsze taki sam – googlebot robi 20 przekierowań!

Jak wspomniałem na samym początku: SEO to nieustannie testy, weryfikacje, analizy i wyciąganie wniosków… i wracamy do początku zdania 🙂. Z resztą Sebastian Heymann kiedyś wspomniał w talk show organizowanym przez Senuto – “SEO Kawka #15 – Sebastian Heymann o Testach w SEO”, że sprawdza to, co ludzie mówią na konferencjach i robi kontr-testy. Zdecydowanie polecam cały odcinek ale fragment, o którym wspominałem zaczyna się na początku (dokładnie w tym miejscu) 🙂

Idąc tym tokiem rozumowania postanowiłem sprawdzić, czy faktycznie maksymalna długość łańcucha przekierowań wynosi 21 według badania, które przeprowadził. Niestety ale pomylił się w liczeniu (zdarza się najlepszym!)

Limit wynosi 20 przekierowań (na dzień publikacji tego badania – marzec 2024), ponieważ ostatnia przekierowana strona nie jest już uznawana za kolejne przekierowanie, bo dalszych przekierowań przeglądarka po prostu nie robi. Podejrzewam, że Sebastian błędnie odczytał informacje zawarte we wtyczce Redirection. Plugin wskazuje kolejny link, który powinien być, a nie że nastąpiło przekierowanie, dlatego wcześniej wspominałem o “pełnych przekierowaniach”. Nie jest to jakiś straszny błąd, bo to pomyłka tylko o 1 przekierowanie.

Co do samego crawl budgetu w kontekście łańcucha przekierowań. W dokumentacji google można znaleźć informację o tym by unikać długich łańcuchów przekierowań, które mają negatywny wpływ na crawlowanie, no dobra ale…

Co to jest “łańcuch przekierowań” według Google?

Niestety nie jest jasno określone ile to jest “długi łańcuch”. Czy to już jest 3 przekierowania, czy dopiero zaczyna się po 10 przekierowaniach, a może to jest łączny czas przekierowań liczony w (mili)sekundach?

Bazując na pierwszym moim teście, gdzie sprawdzałem jak długo będą podążały narzędzia Rich Results Tool i walidator Schema.org, chyba można przyjąć bezpieczną granicę 5 przekierowań, a 6+ to już łańcuch. Jednak aby się przekonać czy mam rację oraz jak Google definiuje “długi łańcuch przekierowań” należałoby przeprowadzić kolejne badanie, a następnie patrzeć jaki ma wpływ na crawl czy indeksowanie (nowe case study? – może kiedyś :P).

W 2020 roku na platformie reddit John Mueller wypowiedział się na temat wielu przekierowań, o to co napisał:

Po przetłumaczeniu tego na język polski:

Nie ma to znaczenia. Jedyną rzeczą, na którą chciałbym zwrócić uwagę, jest to, że masz mniej niż 5 przeskoków dla adresów URL, które są często crawlowane. W przypadku wielu przeskoków głównym efektem jest to, że jest to nieco wolniejsze dla użytkowników. Wyszukiwarki po prostu podążają za łańcuchem przekierowań (dla Google: do 5 przeskoków w łańcuchu na próbę indeksowania).

To stwierdzenie jest o tyle ciekawe, ponieważ jak wykazałem w pierwszym badaniu – walidator schema oraz test wyników z elementami rozszerzonymi od Google robią 5 pełnych przekierowań.

Warto także wziąć pod uwagę jeszcze jedną kwestię związaną z radą od Muellera. Mianowicie w protokole HTTP/1.0 istniał określony limit przekierowań, który wynosił 5. Informacja ta znajduje się w specyfikacji. Zatem chyba można uznać, że “łańcuch przekierowań” według Google zaczyna się po 5 przekierowaniu, mimo iż googlebot jest wstanie obsłużyć znacznie więcej.

Optymalizować, czy nie optymalizować przekierowań?

Nie przeprowadzałem testów czy przekierowania bezpośrednio przekładają się na crawl budget. Jednak jestem święcie przekonany, że im krótsze przekierowania, tym lepiej dla ogólnej wydajności strony, jak i crawl budgetu. Każde przekierowanie to cenny czas dla googlebota i czytelników strony, dlatego jeśli tylko mam możliwość, to profilaktycznie optymalizuję przekierowania i zostawiam te najkrótsze. To że teraz google nic z tym nie robi, nie znaczy że w przyszłości też tak będzie. Poza tym optymalizacja przekierowań korzystnie wpływa na UX oraz wydajność serwera. W szczególności jeśli do przekierowań na wordpressie używana jest wtyczka Redirection, która do obsługi przekierowań używa języka PHP, a nie bezpośrednio na serwerze (np. htaccess). Nie widzę więc powodów by tworzyć kolejne, dusić niepotrzebnie serwer i wydłużać czas przekierowania w formacie:

• A -> B -> C

Zdecydowanie wolę krótkie A -> C, dlatego odpowiadając na zadane pytanie: optymalizować przekierowania!

Oczywiście każdy ma prawo się ze mną nie zgadzać 🙂 Na poparcie mam jeszcze jeden mały case. Miałem okazję sprawdzić dlaczego jedna strona długo się ładuje. Problemem okazała się zbyt duża liczba przekierowań we wtyczce Redirection – właściwie ponad 1300 przekierowań. Po kilkukrotnym wyłączeniu i włączeniu tej wtyczki. Strona analogicznie przyspieszała i spowalniała praktycznie za każdym razem.

Rozwiązanie: przeniesienie wszystkich przekierowań z wtyczki, która robi przekierowania z poziomu PHP na przekierowanie serwerowe spowodowało, że strona przyspieszyła (znacząco!), a przekierowania nadal istniały 🙂

Podsumowanie – łańcuch przekierowań dla rożnych narzędzi i robotów