Łańcuch przekierowań a SEO: ile skoków to za dużo?

Łańcuch przekierowań to dwa lub więcej przekierowań z rzędu między adresem URL, o który ktoś poprosił, a stroną, która w końcu odpowiada kodem 200. Google dokumentuje, że Googlebot podąża za maksymalnie 10 skokami, zaleca przekierowywanie prosto do celu końcowego i wymienia długie łańcuchy jako obciążenie indeksowania. Nie mówi, że niszczą pozycje, i mówi, że przekierowania trwałe nie powodują utraty PageRank. Uczciwe podsumowanie brzmi więc: łańcuchy to problem opóźnień i wydajności indeksowania, który warto tanio naprawić, a nie katastrofa SEO.

Większość łańcuchów nie powstaje celowo. Ktoś dodaje regułę HTTPS, ktoś inny regułę www, narzędzie marketingowe opakowuje link w tracker, a każdy skok osobno jest rozsądny. Poniżej: jak warstwy się nawarstwiają, ile kosztuje każdy skok, które twierdzenia SEO wytrzymują zestawienie z dokumentacją Google oraz jak prześledzić i spłaszczyć łańcuch. Na początek słownik kodów statusu: rodzaje przekierowań URL to mapa. Jeśli łańcuch zapętla się na sobie, potrzebujesz zamiast tego jak naprawić pętlę przekierowań.

Czym jest łańcuch przekierowań

Łańcuch przekierowań powstaje, gdy URL A przekierowuje do B, a B przekierowuje do C, zamiast by A wskazywał bezpośrednio na C. Każda strzałka to osobna odpowiedź HTTP, a klient wykonuje dla każdej nowe żądanie. Jedno przekierowanie jest normalne; "łańcuch" zaczyna się od dwóch.

Wielokrotne przekierowania i skoki przekierowań opisują to samo z różnych stron: liczbę przekierowań między żądaniem a stroną końcową. Pętla przekierowań to łańcuch, który nigdy się nie kończy, bo wraca do odwiedzonego adresu. Łańcuch natomiast się kończy; po prostu dojście do końca trwa zbyt długo.

Jak powstają łańcuchy przekierowań

Łańcuchy się nawarstwiają, bo każda warstwa wymusza własną preferencję. Zwykłe warstwy, w kolejności, w jakiej żądanie je spotyka:

• Schemat. http:// trafia na https://, zwykle w regule serwera lub proxy.
• Host. Apex trafia na www lub odwrotnie, w innej regule, która odpala po regule schematu.
• Ścieżka. Normalizator ukośnika końcowego lub małych liter przepisuje /Promo/ na /promo.
• Opakowanie kampanii lub śledzenia. Tracker kliknięć reklamy, przepisywacz linków platformy e-mail lub krótki link stoi przed wszystkim innym.
• Mapa dziedziczona. Przekierowanie z dawnego redesignu, którego nikt nie przekierował ponownie.

Połącz je, a zwykłe http://example.com/Promo/ może wymagać czterech skoków: do HTTPS, potem do www, potem do znormalizowanej ścieżki, potem przez starą regułę redesignu do działającej strony. Krótkie linki dołączają na początku. Jeden jest uprawnionym skokiem. Szkoda zaczyna się, gdy jego cel nie jest końcowym adresem URL. Wklej http://example.com/promo jako cel, a Twój link stoi na czele łańcucha, który zbudowała niewidoczna dla Ciebie witryna docelowa. Czy skracacze URL szkodzą SEO omawia stronę rankingową tego pytania; krótka odpowiedź to: jeden czysty skok jest w porządku, a nawarstwiony jest do naprawy po Twojej stronie.

Łańcuchy łatwo przeoczyć, bo przeglądarki je ukrywają: pasek adresu pokazuje końcowy adres URL i strona się ładuje, więc nic nie wygląda źle. Ujawniają się też tylko dla wariantu żądania, który uruchamia każdą regułę, zwykle najstarszego linku http:// na najstarszych drukowanych materiałach.

Za iloma skokami podąża Googlebot?

Googlebot domyślnie podąża za maksymalnie 10 skokami przekierowań. Wynika to wprost z dokumentacji robota Google. Dodaje ona, że poszczególne produkty Google mogą stosować inne limity, a narzędzie do inspekcji adresów URL w ogóle nie podąża za przekierowaniami. Google nie precyzuje, co dzieje się z dłuższym łańcuchem, więc załóż, że cel po prostu nie jest osiągany.

Dziesięć to pułap, a nie zalecenie. Wytyczne Google dotyczące przenoszenia witryn mówią, by przekierowywać bezpośrednio do celu końcowego, a gdy to niemożliwe, utrzymywać łańcuch krótkim, "idealnie nie więcej niż 3 i mniej niż 5", bo łączenie w łańcuch dodaje opóźnienia dla użytkowników, a nie wszyscy agenci użytkownika obsługują długie łańcuchy. Zapamiętaj to: cel jednego skoku, tolerancja kilku i twardy stop na dziesięciu.

Przeglądarki mają własne limity. Chrome rezygnuje po 20 i zwraca ERR_TOO_MANY_REDIRECTS, czyli objaw opisany w poradniku o pętlach przekierowań. Standard HTTP również nie ustala liczby: RFC 9110 mówi tylko, że klienci powinni wykrywać cykliczne przekierowania i interweniować.

Ile każdy skok kosztuje w opóźnieniu

Każdy skok kosztuje co najmniej jedną rundę sieciową. Skok do innej nazwy hosta kosztuje więcej. Klient rozwiązuje nową nazwę, otwiera połączenie TCP i kończy uzgadnianie TLS, zanim cokolwiek wyśle. Własny audyt Lighthouse oblewa stronę z dwoma lub więcej przekierowaniami i mówi, że dodatkowa podróż może opóźnić zasób "o setki milisekund".

Oto arytmetyka, jako ilustracja, a nie benchmark. Załóżmy rundę 100 ms, co jest zwyczajne dla połączenia mobilnego przy średnim sygnale. Skok do nowego hosta z DNS, TCP i uzgadnianiem TLS 1.3 przed żądaniem łatwo kosztuje trzy do czterech rund, czyli 300 do 400 ms. Skok, który ponownie wykorzystuje otwarte połączenie z tym samym hostem, kosztuje jedną, czyli 100 ms. Czteroskokowy łańcuch z dwoma nowymi połączeniami zużywa wtedy mniej więcej 900 ms, zanim zacznie się prawdziwa strona, wobec około 450 ms dla jednego płaskiego przekierowania.

Urządzenia mobilne pogarszają sprawę z prostego powodu: ograniczeniem jest opóźnienie, a nie przepustowość. Odpowiedzi przekierowań są maleńkie, więc cały czas to rundy, a szybszy abonament nic dla nich nie robi. Usunięcie skoku bywa tańsze niż zmniejszenie obrazu. O tym, ile powinien kosztować pojedynczy skok po stronie serwera, zobacz jak przekierowania mieszczą się poniżej 15 ms.

Łańcuchy gubią też dane. Każdy skok to miejsce, w którym reguła przepisywania może zgubić ciąg zapytania, a wycięty utm_source to zwykły sposób, w jaki parametry UTM znikają z analityki.

Link equity i budżet indeksowania: co dokumentuje Google

Najpierw link equity. Dokumentacja Google dotycząca przenoszenia witryn stwierdza, że "301 and other permanent redirects don't cause a loss in PageRank". Gary Illyes z Google powiedział to samo o przekierowaniach 30x w 2016, ale to był wpis społecznościowy, a nie dokumentacja. Stara reguła kciuka, że każdy skok przekierowania wycieka stały procent wartości, to więc folklor. Żadne źródło Google nie podaje procentu, a liczby takie jak 15 procent zobaczysz powtarzane we wpisach SEO bez cytowania. Jeśli ktoś Ci ją poda, poproś o źródło.

Łańcuchy nadal nie są darmowe. Udokumentowane są dwa efekty. Po pierwsze, wydajność indeksowania: wytyczne Google o budżecie indeksowania dla dużych witryn mówią wprost, by unikać długich łańcuchów przekierowań, które negatywnie wpływają na indeksowanie. Po drugie, opóźnienie dla użytkownika, opisane wyżej, które zasila sygnały doświadczenia ze strony. Budżet indeksowania ma znaczenie głównie dla bardzo dużych lub szybko zmieniających się witryn; witryna ze 200 stronami raczej nie odczuje problemu budżetu indeksowania z kilku łańcuchów, choć odwiedzający nadal odczują koszt szybkości.

Jest też niuans indeksowania. Google używa przekierowań trwałych jako sygnału kanoniczności dla celu. To, który adres zostanie pokazany, zależy częściowo od tego, czy każde przekierowanie było tymczasowe, czy trwałe. Łańcuch mieszający skoki 301 i 302 czyni ten sygnał mniej wyraźnym, co jest dobrym powodem, by ustalić kody raz. Canonical a przekierowanie 301 omawia, jak te sygnały na siebie oddziałują.

Moje stanowisko: nie panikuj z powodu equity, naprawiaj łańcuchy dla szybkości i higieny indeksowania i nie obiecuj wzrostu pozycji ze spłaszczenia jednego. Nikt nie udokumentował takiego wzrostu. Szybsze ładowanie i mniej zmarnowanych pobrań to to, co możesz zmierzyć.

Jak wykrywać łańcuchy przekierowań

Zacznij od curl, bo drukuje każdy skok tam, gdzie przeglądarka je ukrywa. Pierwsze polecenie pokazuje wiersz statusu i Location każdej odpowiedzi:

curl -sIL http://example.com/Promo/ | grep -E '^HTTP|^[Ll]ocation'

Czysty wynik to jedno 3xx, a potem 200. Łańcuch pokazuje najpierw dwa lub więcej wierszy 3xx. Aby uzyskać liczbę i czas spędzony w przekierowaniach, poproś curl o jego własne liczby:

curl -sL -o /dev/null \
  -w 'hops: %{num_redirects}\nfinal: %{url_effective}\nredirect time: %{time_redirect}s\ntotal: %{time_total}s\n' \
  http://example.com/Promo/

Dwa zastrzeżenia. -I wysyła żądanie HEAD, a kilka serwerów odpowiada na HEAD inaczej niż na GET, więc jeśli wynik wygląda zbyt czysto, powtórz bez -I i odrzuć treść przez -o /dev/null -D -. I przetestuj wariant najgorszego przypadku, ten, który uruchomi każdą regułę: http://, bez www, wielkie litery w ścieżce, ukośnik końcowy. Testowanie tylko adresu kanonicznego to sposób, w jaki łańcuchy przetrwają. Wolę przetestować brzydkie warianty z nadmiarem, niż zaufać czystemu.

W przeglądarce otwórz narzędzia deweloperskie, przejdź do panelu Network, zaznacz "Preserve log", aby wcześniejsze skoki przetrwały nawigację, i przeładuj. Każde przekierowanie pojawia się jako osobny wiersz 301 lub 302. Nasz sprawdzacz linków pokazuje ten sam łańcuch bez terminala.

Aby sprawdzić całą witrynę, robot desktopowy taki jak Screaming Frog lub Sitebulb ma raport łańcuchów przekierowań, który wymienia każdy łańcuch ze wszystkimi skokami i kodami statusu. Dla linków długowiecznych umieść to samo śledzenie w zaplanowanym zadaniu, jak w monitorowaniu przekierowań linków.

Jak spłaszczyć łańcuch przekierowań

Spłaszczenie oznacza, że każdy dawny adres URL wskazuje prosto na końcowy adres URL. Kroki, po kolei:

1. Wybierz postać kanoniczną: schemat, host, politykę ukośnika końcowego i wielkość liter. Zapisz ją.
2. Prześledź każdy stary adres URL i zapisz jego końcowy cel.
3. Przepisz każdą regułę tak, by celowała w ten końcowy cel, a nie w następną regułę.
4. Zaktualizuj linki wewnętrzne, mapy witryny i znaczniki rel="canonical" na końcowy adres URL, aby roboty i użytkownicy w ogóle przestali wchodzić do łańcucha.
5. Uruchom śledzenie ponownie i potwierdź najwyżej jeden skok.

Sztuczka po stronie serwera to połączenie schematu i hosta w jednej regule. W nginx wygląda to tak, z użyciem $request_uri, aby ścieżka i ciąg zapytania przetrwały:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate and key directives go here
    return 301 https://www.example.com$request_uri;
}

Żądanie http://example.com/page trafia teraz na https://www.example.com/page w jednym skoku, tam gdzie dwie reguły dałyby dwa. Ustawianie przekierowania w .htaccess i jak przekierować adres URL opisują odpowiedniki dla Apache i na poziomie aplikacji.

Najpierw testuj z 302. Przeglądarki agresywnie buforują 301, więc błąd się utrzymuje. Gdy łańcuch ma jeden skok, przełącz się na kod trwały. HSTS też pomaga: gdy przeglądarka zobaczy nagłówek Strict-Transport-Security, wewnętrznie podnosi http:// do https://, więc powracający odwiedzający w ogóle pomijają ten skok. Nic nie robi dla robotów ani odwiedzających po raz pierwszy, więc uzupełnia regułę jednego skoku, a jej nie zastępuje.

Jeśli łańcuchy ciągle wracają, przyczyną jest proces, a nie składnia; zapobieganie gniciu linków opisuje nawyk audytu, który powstrzymuje piętrzenie się starych map.

Jak wygląda poprawnie zachowujące się przekierowanie krótkiego linku

Krótki link powinien być dokładnie jednym skokiem od sluga do końcowej strony kanonicznej i niczym więcej. Żądanie trafia na domenę skracacza. Odpowiedzią jest 3xx z celem w Location. Cel odpowiada bezpośrednio 200. Bez pośredniego skracacza, bez trackera, który przekierowuje ponownie, bez celu, który skacze do www lub do HTTPS, bo wkleiłeś starą postać.

Kod zależy od zastosowania.

• 302 (lub 307) dla śledzonych, edytowalnych linków w kampaniach, postach społecznościowych, e-mailach i kodach QR. Pozwala później zmienić cel i sprawia, że każde kliknięcie dociera do warstwy przekierowań, więc analityka pozostaje kompletna.
• 301 (lub 308), gdy przeniesienie jest trwałe i chcesz, by cel był traktowany jako kanoniczny, na przykład adres vanity, który na stałe zastępuje stary adres.

Przekierowania 301 a 302 opisują pułapkę buforowania, która sprawia, że domyślne 302 ma sens. Dwa nawyki utrzymują łańcuch na jednym skoku. Zawsze wklejaj końcowy adres URL jako cel, po jednorazowym załadowaniu go i skopiowaniu adresu z paska, i uruchom powyższe liczenie curl na nowych linkach przed startem. Jeśli chcesz, by ten cel był zapisany raz i edytowalny bez ponownego druku, zacznij od darmowej przestrzeni roboczej Elido i prześledź swój pierwszy link poleceniami z tego wpisu.

Strony trzecie mogą dodawać skoki, których nie kontrolujesz. Tracker kliknięć platformy reklamowej lub opakowanie linków dostawcy poczty stoi przed Twoim krótkim linkiem, czy tego chcesz, czy nie, co jest najlepszym argumentem za utrzymaniem własnej części ścieżki do jednego skoku. Domena marki nie dodaje skoku, jak wyjaśniają własne domeny dla krótkich linków.

Ten wpis należy do klastra inżynierii. Pełną mapę kodów statusu znajdziesz w rodzajach przekierowań URL, a warstwę przekierowań za krótkim linkiem w jak działają skracacze URL.

Powiązane na blogu

• Pętla przekierowań: jak znaleźć i naprawić ERR_TOO_MANY_REDIRECTS
• Rodzaje przekierowań URL: 301, 302, 307, 308 i więcej
• Przekierowania 301 a 302: którego powinny używać krótkie linki
• Czy skracacze URL szkodzą SEO? Uczciwa odpowiedź
• Canonical a przekierowanie 301: jak wybrać właściwy sygnał
• Jak przekierować adres URL: sześć sposobów i kiedy który jest właściwy