Łańcuchy przekierowań: jak je wykryć i naprawić

Ktoś klika stary link do twojej strony zaczynający się od http://. Serwer najpierw odsyła go na HTTPS, a potem drugi raz na adres z www. W badaniu 1000 domen wybranych z pierwszych 100 tys. rankingu Tranco spośród 683 osiągalnych domen znalazłem 327, w których co najmniej jeden wariant adresu miał dwa przekierowania lub więcej.

Ten wynik opisuje przetestowane adresy, a nie odsetek rzeczywistych wizyt dotkniętych problemem. Pokażę, skąd biorą się łańcuchy, jak sprawdzić je na własnej stronie i jak skierować stare adresy prosto do właściwego celu. Wyniki oraz skrypty znajdziesz w pakiecie badania.

Co to jest łańcuch przekierowań?

Łańcuch powstaje wtedy, gdy żądanie przechodzi przez co najmniej dwa kolejne przekierowania HTTP, zanim dotrze do strony docelowej. Kod 301 oznacza trwałe przeniesienie, ale w łańcuchu mogą też występować inne kody 3xx. Aby go skrócić, skieruj stary URL bezpośrednio na właściwy adres końcowy i popraw linki wewnętrzne.

Typowy przykład to http://example.com → https://example.com → https://www.example.com. To dwa przeskoki, a każdy z nich jest osobną rozmową przeglądarki z serwerem, zanim przyjdzie pierwszy fragment właściwej strony. Pętla przekierowań to inny problem: żądanie wraca na wcześniej odwiedzony adres i może zakończyć się błędem „too many redirects”.

327 z 683 osiągalnych domen miało wariant wieloetapowy

Sprawdziłem cztery wersje strony głównej każdej domeny: HTTP i HTTPS, z www i bez. Spośród 683 domen osiągalnych w warunkach testu w 327 co najmniej jeden wariant wymagał dwóch lub więcej przekierowań. Wykres liczy łańcuchy, a nie domeny: 190 z 483 zaobserwowanych wieloetapowych łańcuchów najpierw zmieniało protokół, a następnie www.

Adresy http:// wciąż mają znaczenie. Mogą występować w starych linkach, zakładkach i materiałach drukowanych, a roboty wyszukiwarek również mogą je odkryć. Wpisanie samej domeny nie jest dobrym testem ścieżki HTTP, bo współczesna przeglądarka może od razu spróbować HTTPS.

Częstą przyczyną jest rozdzielenie ustawień. Hosting albo CDN wymusza HTTPS, a osobna reguła dodaje lub usuwa www. Każde ustawienie może mieć sens, ale razem tworzą dwa przeskoki. Sprawdź, która warstwa zwraca każdą odpowiedź, a potem uzgodnij reguły z końcowym adresem.

Dlaczego dodatkowe przekierowania wydłużają drogę do strony

Każde przekierowanie oznacza kolejne żądanie HTTP przed pobraniem dokumentu docelowego. Zwiększa to opóźnienie, szczególnie na połączeniach o dużym RTT. Zmiana hosta może też wymagać dodatkowej obsługi DNS lub TLS, gdy nie da się wykorzystać istniejącego połączenia.

Te żądania występują przed pobraniem końcowego HTML, więc optymalizacja obrazów i skryptów nie usuwa ich kosztu sieciowego. Od Lighthouse 13 przekierowania są uwzględniane w diagnostyce Document request latency, a wcześniejszy osobny audyt redirects został wycofany. Potwierdzają to informacje o Lighthouse 13.

Googlebot zwykle radzi sobie z krótkimi łańcuchami, ale samo podążanie za nimi nie gwarantuje indeksowania. Przy migracjach Google zaleca przekierowanie prosto do adresu docelowego. Skracanie łańcuchów upraszcza analizę adresów, ogranicza zbędne żądania i porządkuje sygnały kanoniczne.

Dwa adresy strony głównej tworzą drugi problem

W próbie 124 witryny zwracały stronę główną zarówno z www, jak i bez niego, bez przekierowania między tymi adresami. W 85 przypadkach test nie wykrył canonicala wskazującego wersję preferowaną.

Google potrafi wybrać adres kanoniczny na podstawie innych sygnałów nawet bez znacznika rel="canonical". Jeśli oba adresy pokazują tę samą stronę, wybierz jeden preferowany host i przekieruj na niego drugi. Linki wewnętrzne, sitemapę i canonicale trzymaj na tym samym hoście. Więcej wyjaśniam w artykule o canonical, sitemapie i robots.txt.

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

Łańcuch rzadko powstaje celowo. Zwykle to dwie rozsądne decyzje podjęte w różnych miejscach albo w różnym czasie:

• przełącznik HTTPS w panelu i osobna reguła www,
• wtyczka w CMS-ie i reguła na serwerze,
• przeprowadzka na nową domenę, gdzie stary adres HTTP przekierowuje przed przejściem nowej domeny na HTTPS,
• reguła ukośnika na końcu adresu uruchamiana po przekierowaniu HTTPS.

Ustal, która warstwa tworzy każdy przeskok, a następnie skieruj adres źródłowy bezpośrednio do celu. Czasem wystarczy jedna reguła, a czasem potrzebujesz kilku spójnych ustawień w CDN, serwerze i CMS-ie.

Jak sprawdzić przekierowania w minutę

Najszybciej zrobisz to w narzędziu do sprawdzania przekierowań. Wklej cztery wersje adresu: http://, http://www., https:// i https://www.. Narzędzie pokaże każdy przeskok z kodem odpowiedzi i nagłówkiem Location.

W Chrome otwórz DevTools → Network i zaznacz Preserve log. Otwórz adres z jawnym protokołem, np. http://example.com, a następnie sprawdź kody odpowiedzi i nagłówki Location. Automatyczne przejście na HTTPS, zapisane w pamięci przekierowania 301 i HSTS mogą ukrywać ścieżkę HTTP, więc porównaj wynik z testem w terminalu:

curl -sSIL --max-redirs 10 http://example.com | grep -iE "^(HTTP|location)"

Licz odpowiedzi 3xx, a nie końcowe 200. Docelowy URL powinien działać bez przekierowania, a pozostałe warianty powinny mieć najwyżej jeden przeskok. Opcja -I wysyła żądanie HEAD, na które część serwerów odpowiada inaczej niż na GET. Przed zmianą konfiguracji sprawdź oba typy żądań oraz reprezentatywne podstrony i parametry URL.

301 czy 302: które przekierowanie wybrać?

301 i 308 oznaczają trwałe przeniesienie, a 302 i 307 tymczasowe. Google traktuje przekierowania trwałe jako mocniejsze sygnały wyboru adresu, ale żaden kod nie gwarantuje indeksacji wskazanego URL-a.

Przy formularzach i API liczy się także metoda żądania. Kod 308 ją zachowuje, a po 301 część klientów może zamienić POST na GET. Opisuje to dokumentacja MDN dla HTTP 301.

Jeśli zmiana HTTP na HTTPS albo preferowanego hosta jest trwała, zastosuj 301 lub 308. Kod 302 albo 307 służy do zmian tymczasowych. Przy przejściowej niedostępności serwisu odpowiedniejszy może być 503 Service Unavailable, a nie przekierowanie wszystkich adresów.

Jak skrócić łańcuch przekierowań do jednego przeskoku

1. Wybierz jeden adres docelowy. Z www albo bez, dla SEO to bez znaczenia, więc wybierz hosta używanego przez większość twoich linków.
2. Przekieruj każdy stary URL bezpośrednio do właściwego celu. Zachowaj ścieżkę i istotne parametry, jeśli nadal wskazują tę samą treść.
3. Użyj 301 albo 308, gdy zmiana jest trwała.
4. Przetestuj ponownie wszystkie cztery wersje. Każda inna niż docelowa powinna robić dokładnie jeden przeskok.

W nginx poniższe bloki są przykładem przekierowania wersji HTTP i gołej domeny na https://www.example.com:

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

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

W Apache zastosuj jedną regułę, która sprawdza protokół i host:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]

Jeśli TLS kończy się na CDN-ie albo reverse proxy, sprawdź, co widzi origin, zanim zmienisz regułę. Niezgodność schematu między CDN-em i originem może utworzyć pętlę. W Cloudflare sprawdź reguły Single Redirect, Always Use HTTPS i tryb SSL/TLS, a potem przetestuj także podstrony.

Po przekierowaniu popraw linki, sitemapę i canonicale

Twoja strona powinna od razu wskazywać końcowy adres. Popraw linki wewnętrzne, sitemapę XML, znaczniki canonical i adnotacje hreflang, aby nie prowadziły do URL-a, który natychmiast przekierowuje.

Gdy HTTPS działa poprawnie, rozważ HSTS. Przeglądarka, która zna już politykę, może przejść na HTTPS przed wysłaniem żądania, ale inni klienci nadal mogą poprosić o http://. Zanim włączysz preload, przeczytaj jak działa HSTS.

Badanie ujawniło ograniczenie CometWeb Insight: sprawdzanie tylko wejścia HTTP bez www mogło pomijać łańcuchy w pozostałych wariantach. Rozszerzyłem kontrole hosta w module Crawl i dodałem testy obejmujące cztery warianty adresu strony głównej. Analiza całej witryny może też znaleźć linki wewnętrzne prowadzące do przekierowywanych URL-i. Po sprawdzeniu strony głównej darmowym narzędziem możesz poznać CometWeb Insight.

Na koniec

Stronę główną łatwo sprawdzić, ale to dopiero początek. Zbadaj również podstrony i upewnij się, że linki wewnętrzne, mapa XML, canonicale oraz hreflang prowadzą bezpośrednio do właściwych adresów.

Na początek sprawdź cztery wersje strony głównej w narzędziu do przekierowań. Jeśli któryś wariant ma dwa przeskoki lub więcej, ustal, która warstwa odpowiada za każdy z nich, popraw konfigurację w środowisku testowym i sprawdź ponownie reprezentatywne podstrony. Celem jest bezpośredni, poprawny adres docelowy.

Najczęstsze pytania

Źródła

1. Google: How HTTP status codes affect Google's crawlers.
2. Google Search Central: Redirects and Google Search.
3. Google Search Central: Site moves with URL changes.
4. Chrome for Developers: Co nowego w Lighthouse 13.
5. Lista HSTS preload.
6. CometWeb: łańcuchy przekierowań na 1000 popularnych domen.
7. WordPress: instalacja WordPressa w osobnym katalogu.