Łańcuch przekierowań. Jak go wykryć i skrócić do jednego kroku?

Łańcuch przekierowań powstaje wtedy, gdy stary adres nie prowadzi od razu do właściwej podstrony, tylko do kolejnego adresu, który znów odsyła dalej. Użytkownik zwykle niczego nie zauważa poza dłuższym oczekiwaniem. Robot Google widzi natomiast każdy przeskok osobno i przy każdym musi wysłać nowe żądanie do serwera.

Problem dotyczy przede wszystkim serwisów, które mają za sobą zmianę domeny, przejście na https, zmianę struktury adresów albo kilka przebudów oferty. Każda z tych zmian dokłada własne przekierowanie i po kilku latach z prostego odesłania robi się ciąg trzech, czterech albo pięciu kroków.

Ta instrukcja pokazuje, jak rozpoznać łańcuch na pojedynczym adresie i w całym serwisie, jak ustalić jego przyczynę, jak przepisać reguły tak, żeby każdy stary adres prowadził do celu jednym krokiem, oraz jak sprawdzić, czy poprawka zadziałała.

Czym jest łańcuch przekierowań i po czym go rozpoznać?

Przekierowanie to odpowiedź serwera, która zamiast treści strony zwraca informację: „ten adres jest teraz pod innym adresem”. Przeglądarka i robot wyszukiwarki odczytują ją i wysyłają drugie żądanie, już pod wskazany adres. Jeden taki krok jest czymś zwyczajnym i potrzebnym.

O łańcuchu mówi się wtedy, gdy kroków jest więcej niż jeden. Typowy przykład wygląda tak: adres http://przyklad.pl/oferta odsyła do https://przyklad.pl/oferta, ten do https://www.przyklad.pl/oferta, a ten do https://www.przyklad.pl/oferta/. Trzy przeskoki, z których każdy załatwia jedną drobną rzecz: protokół, przedrostek www i ukośnik na końcu.

Osobnym, groźniejszym przypadkiem jest pętla. Adres A odsyła do B, a B z powrotem do A. Przeglądarka pokazuje wtedy komunikat o zbyt wielu przekierowaniach i strona w ogóle się nie otwiera.

Objawy, które powinny zwrócić uwagę

Łańcucha nie widać gołym okiem, ale zostawia ślady. Pierwszym jest wyraźna zwłoka przed rozpoczęciem ładowania strony po kliknięciu starego linku, zwłaszcza na telefonie. Drugim jest adres w pasku przeglądarki, który po wejściu z zakładki lub starej wizytówki zmienia się na inny, niż został wpisany.

Trzeci ślad znajduje się w Google Search Console. W raporcie „Indeksowanie stron” pojawia się przyczyna „Błąd przekierowania” albo długa lista adresów z przyczyną „Strona zawiera przekierowanie”. Czwartym są uwagi o przekierowaniach w narzędziach mierzących szybkość strony.

Dlaczego łańcuch szkodzi stronie i jej widoczności?

Każdy przeskok to osobne połączenie z serwerem. Użytkownik czeka na pierwszą odpowiedź, potem na drugą, potem na trzecią, a dopiero po ostatniej zaczyna się pobieranie właściwej strony. Na szybkim łączu różnica bywa niewielka, na sieci komórkowej robi się odczuwalna. Ten czas wlicza się do pomiarów szybkości strony.

Druga sprawa to roboty wyszukiwarki. Dokumentacja Google podaje, że roboty domyślnie śledzą do 10 przeskoków przekierowania. To górna granica, a nie zalecenie. W tej samej dokumentacji Google radzi, żeby przekierowywać od razu do miejsca docelowego, a jeśli to niemożliwe, utrzymywać łańcuchy krótkie: najlepiej nie dłuższe niż 3 kolejne adresy i nie więcej niż 5.

Google zwraca też uwagę, że łańcuchy spowalniają ładowanie stron, a nie wszystkie programy i przeglądarki obsługują długie ciągi przekierowań. W praktyce oznacza to, że część narzędzi, które pobierają podgląd linku albo sprawdzają stronę, może po drodze zrezygnować.

Trzeci skutek dotyczy porządku w serwisie. Wystarczy, że jedno ogniwo zacznie zwracać błąd albo zostanie usunięte podczas porządków na serwerze, a wszystkie stare linki prowadzące przez to ogniwo przestają działać.

Uważam, że łańcuch złożony z dwóch kroków nie jest powodem do niepokoju i nie wymaga pilnej interwencji. Skracanie ma największy sens tam, gdzie kroków jest trzy lub więcej, gdzie łańcuch dotyczy najważniejszych podstron albo gdzie w ciągu znajduje się przekierowanie tymczasowe.

Skąd biorą się łańcuchy? Najczęstsze przyczyny

Łańcuch prawie nigdy nie jest efektem jednej decyzji. Powstaje warstwami, gdy kolejne osoby dokładają własne reguły i nie sprawdzają tych, które już istnieją. Przed naprawą trzeba ustalić, które z poniższych źródeł występują w danym serwisie, bo każde naprawia się w innym miejscu.

• Osobne reguły dla https i dla www. Jedna reguła zmienia protokół, druga dodaje lub usuwa www. Adres w najstarszej postaci przechodzi przez obie po kolei.
• Ukośnik na końcu adresu. Serwer albo system zarządzania treścią dodaje lub usuwa końcowy ukośnik osobnym przekierowaniem, już po ujednoliceniu domeny.
• Kilka zmian adresu tej samej podstrony. Podstrona zmieniała nazwę dwa lub trzy razy i za każdym razem dopisano przekierowanie tylko z poprzedniej wersji na następną.
• Zmiana domeny nałożona na starsze przekierowania. Stara domena odsyła do nowej adres w adres, a nowa domena ma własne przekierowania po późniejszej przebudowie.
• Przekierowania ustawione w kilku miejscach naraz. Część reguł jest w panelu hostingu, część w pliku .htaccess, część we wtyczce, a część w usłudze pośredniczącej typu CDN. Każde miejsce działa niezależnie.
• Linki wewnętrzne prowadzące do starych adresów. Menu, stopka albo treść wpisów nadal wskazują adresy, które same są przekierowaniami.

Jak sprawdzić pojedynczy adres w przeglądarce i w wierszu poleceń?

Zanim zacznie się szukać w całym serwisie, należy nauczyć się odczytywać łańcuch na jednym adresie. Do tego wystarcza przeglądarka Chrome, bez instalowania czegokolwiek. Dobrym pierwszym adresem do testu jest strona główna wpisana w najstarszej postaci, czyli z http:// i bez www.

1. W przeglądarce Chrome należy otworzyć nową kartę, a następnie narzędzia dla deweloperów: klawiszem F12 albo przez menu z trzema kropkami, pozycję „Więcej narzędzi” i dalej „Narzędzia dla deweloperów”.
2. W otwartym panelu wybiera się kartę „Sieć” (w wersji angielskiej „Network”).
3. Trzeba zaznaczyć pole „Zachowaj dziennik” (w wersji angielskiej „Preserve log”). Bez tego lista żądań czyści się przy każdym przeskoku i łańcucha nie widać.
4. W pasku adresu wpisuje się pełny testowany adres razem z http:// i zatwierdza klawiszem Enter.
5. Na liście żądań należy odszukać pierwsze wiersze. Te, które w kolumnie „Stan” (w wersji angielskiej „Status”) mają kod 301, 302, 307 lub 308, to kolejne ogniwa łańcucha. Pierwszy wiersz z kodem 200 jest stroną docelową.
6. Po kliknięciu wiersza z przekierowaniem, w części „Nagłówki”, w nagłówkach odpowiedzi znajduje się pole location. Pokazuje ono adres, do którego odsyła dane ogniwo.

Liczba wierszy z kodem zaczynającym się od cyfry 3 to długość łańcucha. Przy każdym należy zanotować adres początkowy, kod i adres z pola location. Te notatki będą podstawą do przepisania reguł.

Pułapka: przekierowanie, które wykonuje sama przeglądarka

Jeżeli serwis ma włączony mechanizm HSTS, przeglądarka sama zamienia http na https, zanim wyśle żądanie. W panelu widać wtedy kod 307 z dopiskiem o przekierowaniu wewnętrznym. Tego kroku nie wykonuje serwer i nie da się go usunąć regułą. Robot, który odwiedza adres po raz pierwszy, dostanie zwykłą odpowiedź serwera, dlatego wynik z przeglądarki trzeba potwierdzić drugą metodą.

Sprawdzenie poleceniem curl

Polecenie curl pokazuje dokładnie to, co odpowiada serwer, bez pamięci podręcznej i bez udziału przeglądarki. Jest dostępne w terminalu systemów macOS i Linux oraz w wierszu polecenia aktualnych wersji systemu Windows. Wystarczy przepisać jeden wiersz, podstawiając własny adres:

curl -sIL http://przyklad.pl/oferta

W odpowiedzi pojawia się kilka bloków nagłówków, po jednym na każdy krok. Każdy blok zaczyna się od wiersza z kodem, na przykład HTTP/2 301, a adres kolejnego kroku znajduje się w wierszu location:. Ostatni blok powinien mieć kod 200. Ile bloków z kodem 301 lub 302 poprzedza ten ostatni, tyle ogniw ma łańcuch.

Test należy powtórzyć dla czterech postaci tego samego adresu: z http:// i bez www, z http:// i z www, z https:// bez www oraz z https:// i www. Dodatkowo każdą z nich sprawdza się z ukośnikiem na końcu i bez niego. Dopiero taki komplet pokazuje, które reguły działają osobno.

Jak znaleźć łańcuchy w całym serwisie?

Ręczne sprawdzanie adresu po adresie ma sens przy kilkunastu podstronach. W większym serwisie potrzebne są dwa źródła: raport Google Search Console, który pokazuje to, co widzi robot Google, oraz program przechodzący po serwisie link po linku.

Raport „Indeksowanie stron” w Google Search Console

1. Po zalogowaniu do Google Search Console należy wybrać właściwą usługę, a w menu po lewej stronie raport „Strony” w części dotyczącej indeksowania. Otwiera się raport „Indeksowanie stron”.
2. Pod wykresem znajduje się lista przyczyn, dla których strony nie są indeksowane. Trzeba odszukać na niej wiersze „Błąd przekierowania” oraz „Strona zawiera przekierowanie”.
3. Kliknięcie wiersza „Błąd przekierowania” otwiera stronę ze szczegółami i listą przykładowych adresów. Według pomocy Google ta przyczyna obejmuje zbyt długi łańcuch przekierowań, pętlę przekierowań, przekierowanie, które przekroczyło maksymalną długość adresu URL, oraz nieprawidłowy lub pusty adres w łańcuchu.
4. Listę adresów należy pobrać przyciskiem eksportu w prawym górnym rogu i każdy adres sprawdzić poleceniem curl albo w karcie „Sieć”.
5. Następnie otwiera się wiersz „Strona zawiera przekierowanie”. Sama obecność adresów na tej liście jest prawidłowa: to stare adresy, które odsyłają dalej. Listę warto jednak przejrzeć, bo właśnie tu widać, ile starych adresów nadal jest odwiedzanych przez robota.

Trzeba pamiętać o ograniczeniu tego raportu. Strona ze szczegółami pokazuje przykładową listę adresów, a nie wszystkie. Pomoc Google sama odsyła w tym miejscu do narzędzi diagnostycznych, które pokazują przebieg przekierowania. Raport odpowiada więc na pytanie „czy problem istnieje”, a nie „gdzie dokładnie są wszystkie ogniwa”.

Przejście po serwisie programem do audytu

Pełny obraz daje program, który odwiedza wszystkie podstrony po linkach, tak jak robot wyszukiwarki, i zapisuje kod odpowiedzi każdego adresu. Takie programy mają osobne zestawienie łańcuchów przekierowań z kolumnami: adres początkowy, liczba kroków, adres końcowy oraz podstrona, na której znajduje się link do adresu początkowego.

Ta ostatnia kolumna jest najcenniejsza. Pokazuje, które linki we własnym serwisie prowadzą do przekierowań i w którym miejscu trzeba je poprawić. Do programu należy wczytać także listę starych adresów: z dawnej mapy witryny, z eksportu Search Console i z zestawienia linków przychodzących. Stare adresy nie są już podlinkowane w serwisie, więc samo przejście po linkach ich nie znajdzie.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przejmę sprawę: sprawdzę wszystkie stare adresy, rozpiszę łańcuchy i przygotuję reguły, które prowadzą do celu jednym krokiem.

Jak przygotować mapę przekierowań i skrócić łańcuch w pliku .htaccess?

Naprawa zaczyna się od arkusza, a nie od edycji plików. W arkuszu potrzebne są dwie kolumny: stary adres i adres docelowy. Do pierwszej kolumny trafiają wszystkie adresy początkowe oraz wszystkie ogniwa pośrednie znalezionych łańcuchów. Do drugiej wpisuje się zawsze adres końcowy w ostatecznej postaci: z właściwym protokołem, z www lub bez, z ukośnikiem na końcu lub bez niego, dokładnie tak, jak odpowiada strona z kodem 200.

Zasada jest jedna: każdy stary adres wskazuje bezpośrednio adres końcowy. Jeżeli podstrona nazywała się kolejno „stara-oferta”, „oferta-nowa” i „oferta”, to w arkuszu są dwa wiersze i oba prowadzą do „oferta”. Żaden wiersz nie może prowadzić do adresu, który sam występuje w pierwszej kolumnie.

Jedna reguła dla protokołu i dla www

Na serwerach Apache i LiteSpeed reguły zapisuje się w pliku .htaccess w głównym katalogu strony. Najczęstszy łańcuch, czyli osobny krok dla https i osobny dla www, znika po zastąpieniu dwóch reguł jedną. Poniższy fragment wysyła każdą nieprawidłową postać adresu od razu do wersji z https i www:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.przyklad\.pl$ [NC]
RewriteRule ^(.*)$ https://www.przyklad.pl/$1 [R=301,L]

Warunek pierwszy wychwytuje żądania bez szyfrowania, warunek drugi żądania pod inną nazwą domeny niż docelowa. Dopisek [OR] oznacza, że wystarczy spełnienie jednego z nich. Adres docelowy jest wpisany w całości, dlatego serwer nie musi wykonywać drugiego kroku. W serwisie, który ma działać bez www, w obu miejscach wpisuje się nazwę domeny bez tego przedrostka.

Na niektórych hostingach, zwłaszcza za usługą pośredniczącą, zmienna %{HTTPS} zawsze ma wartość „off”, co kończy się pętlą. W takiej sytuacji właściwy warunek podaje pomoc techniczna dostawcy i należy o niego zapytać, zamiast zgadywać.

Stare adresy podstron prowadzone prosto do celu

Reguły dla starych adresów podstron umieszcza się nad regułą ogólną i również podaje w nich pełny adres końcowy. Dzięki temu nawet żądanie w najstarszej postaci, bez https i bez www, trafia do celu jednym krokiem:

RewriteRule ^stara-oferta/?$ https://www.przyklad.pl/oferta/ [R=301,L]
RewriteRule ^oferta-nowa/?$ https://www.przyklad.pl/oferta/ [R=301,L]

Kolejność prac przy zmianie pliku powinna wyglądać następująco.

1. Pobranie aktualnego pliku .htaccess na dysk i zachowanie go pod inną nazwą jako kopii.
2. Przejrzenie pliku i wypisanie wszystkich istniejących przekierowań, także tych dodanych przez wtyczki i przez panel hostingu.
3. Usunięcie reguł, które dublują się z nowymi, przede wszystkim osobnych reguł dla https i dla www.
4. Wstawienie nowych reguł na początku pliku, przed blokiem dodanym przez system zarządzania treścią.
5. Wysłanie pliku na serwer i natychmiastowe sprawdzenie, czy strona główna otwiera się poprawnie.
6. Sprawdzenie poleceniem curl wszystkich czterech postaci adresu oraz kilku starych adresów z arkusza.

Błąd składni w tym pliku potrafi wyłączyć całą stronę, a serwer odpowiada wtedy kodem 500. Dlatego kopia sprzed zmian jest obowiązkowa, a po każdej edycji stronę sprawdza się od razu. Dokładną składnię i najczęstsze pomyłki omawiam we wpisie o tym, jak ustawić przekierowanie 301 w pliku .htaccess.

Na serwerach nginx plik .htaccess nie działa. Reguły zapisuje się w konfiguracji serwera, do której na hostingu współdzielonym zwykle ma dostęp tylko dostawca. Zasada pozostaje ta sama: jedna odpowiedź z kodem 301 i pełnym adresem docelowym.

Jak skrócić łańcuch w WordPressie i we wtyczkach?

W WordPressie przekierowania powstają w trzech miejscach: w ustawieniach adresu witryny, w mechanizmie, który sam poprawia postać adresu, oraz we wtyczkach. Każde z nich trzeba sprawdzić osobno, bo reguła z pliku .htaccess nie zastąpi błędnego ustawienia w panelu.

1. W panelu administracyjnym należy otworzyć „Ustawienia”, a następnie „Ogólne”. Pola „Adres WordPressa (URL)” oraz „Adres witryny (URL)” powinny zawierać adres w ostatecznej postaci, z https i z www lub bez, zgodnie z regułą na serwerze.
2. Jeżeli pola wymagają poprawy, przed zmianą wykonuje się kopię zapasową bazy danych. Pomyłka w tych polach może odciąć dostęp do panelu, a przywrócenie go wymaga wtedy edycji bazy lub pliku konfiguracyjnego.
3. W „Ustawieniach” otwiera się „Bezpośrednie odnośniki” i sprawdza, czy wybrana struktura kończy się ukośnikiem. Od tego zależy, którą postać adresu WordPress uzna za właściwą i do której będzie odsyłał.
4. We wtyczce do przekierowań albo w module przekierowań wtyczki SEO należy otworzyć listę reguł i porównać ją z arkuszem. Każdą regułę, której adres docelowy sam jest przekierowany, poprawia się tak, żeby wskazywała adres końcowy.
5. Reguły, które powtarzają się w pliku .htaccess i we wtyczce, zostawia się tylko w jednym miejscu. Radzę wybrać jedno miejsce dla wszystkich przekierowań i trzymać się go przy każdej kolejnej zmianie.
6. Na koniec czyści się pamięć podręczną wtyczki przyspieszającej stronę i sprawdza kilka adresów poleceniem curl.

Wtyczki do przekierowań często same dodają regułę przy każdej zmianie adresu wpisu lub strony. To wygodne, ale właśnie tak powstają łańcuchy po trzeciej i czwartej zmianie tej samej podstrony. Po każdej zmianie adresu należy otworzyć listę reguł i poprawić starsze wpisy dotyczące tej podstrony.

Osobną sprawą są stare adresy zapisane w treści. Jeżeli serwis przechodził z http na https albo zmieniał domenę, w bazie danych zostają tysiące linków i adresów obrazków w dawnej postaci. Każdy z nich uruchamia przekierowanie przy każdym wyświetleniu strony. Poprawia się je narzędziem do wyszukiwania i zamiany w bazie danych, zawsze po wykonaniu kopii zapasowej.

Na serwerach z dostępem do WP-CLI służy do tego polecenie wp search-replace. Pierwsze uruchomienie powinno mieć dopisek --dry-run, który tylko pokazuje liczbę zmian i niczego nie zapisuje:

wp search-replace 'http://przyklad.pl' 'https://www.przyklad.pl' --dry-run

Dopiero gdy liczby wyglądają wiarygodnie, polecenie uruchamia się bez tego dopisku. Ręczna zamiana zapytaniem w bazie danych jest ryzykowna, ponieważ potrafi uszkodzić ustawienia wtyczek i motywu zapisane w specjalnym formacie. Wymienione narzędzie ten format obsługuje.

Co poprawić poza samymi przekierowaniami?

Skrócenie reguł na serwerze usuwa łańcuch dla starych linków z zewnątrz. Nie zmienia jednak tego, że własny serwis nadal może wysyłać użytkowników i roboty pod adresy, które wymagają przekierowania. Dopóki tak jest, robot Google będzie te adresy odwiedzał, a raport w Search Console pozostanie długi.

Linki wewnętrzne

Każdy link w menu, stopce, treści i przyciskach powinien prowadzić wprost do adresu, który odpowiada kodem 200. Zestawienie z programu do audytu pokazuje, na których podstronach znajdują się linki do przekierowań. W pierwszej kolejności poprawia się elementy powtarzane na każdej podstronie, czyli menu i stopkę, bo jedna zmiana usuwa problem z całego serwisu.

Szczególną uwagę trzeba zwrócić na końcowy ukośnik. Link zapisany bez ukośnika w serwisie, który używa adresów z ukośnikiem, uruchamia przekierowanie przy każdym kliknięciu. Jak uporządkować całą strukturę odnośników, wyjaśniam we wpisie o tym, jak ułożyć linki wewnętrzne w serwisie.

Mapa witryny, tagi kanoniczne i hreflang

Mapa witryny powinna zawierać wyłącznie adresy końcowe. Adres, który jest przekierowaniem, nie powinien się w niej znaleźć. Po zmianach należy otworzyć plik mapy w przeglądarce i sprawdzić kilka losowych adresów, a następnie przesłać mapę ponownie w raporcie „Mapy witryn” w Search Console.

To samo dotyczy tagu kanonicznego i znaczników hreflang. Jeżeli tag kanoniczny wskazuje adres, który odsyła dalej, Google dostaje dwie sprzeczne wskazówki. W kodzie strony należy odszukać wiersz z rel="canonical" i porównać adres z tym, co widać w pasku przeglądarki po pełnym załadowaniu strony. Oba powinny być identyczne co do znaku.

Jak sprawdzić, czy naprawa zadziałała?

Kontrola ma dwa etapy. Pierwszy odbywa się od razu po zmianach i polega na ponownym pomiarze. Drugi trwa kilka tygodni i polega na obserwacji tego, co zgłasza Google.

1. Ponowne sprawdzenie poleceniem curl wszystkich postaci adresu strony głównej i co najmniej kilkunastu starych adresów z arkusza. Przed blokiem z kodem 200 powinien pojawić się dokładnie jeden blok z kodem 301.
2. Ponowne przejście po serwisie programem do audytu, razem z listą starych adresów. Zestawienie łańcuchów powinno być puste, a liczba linków wewnętrznych prowadzących do przekierowań bliska zeru.
3. W Google Search Console należy wpisać jeden z naprawionych adresów w pasku „Sprawdź dowolny URL” u góry ekranu, a następnie użyć przycisku „Test wersji opublikowanej”. Test przechodzi przez przekierowanie i sprawdza stronę docelową. Pomoc Google zaznacza, że wynik nie informuje wprost o tym, że przekierowanie nastąpiło.
4. W raporcie „Indeksowanie stron” otwiera się wiersz „Błąd przekierowania” i klika przycisk „Sprawdź poprawkę”. Należy to zrobić dopiero po naprawieniu wszystkich wystąpień, bo jeśli choć jedno pozostanie, weryfikacja się zatrzyma.
5. Postęp widać na stronie ze szczegółami problemu. Według pomocy Google weryfikacja zajmuje zazwyczaj do 2 tygodni, a w niektórych przypadkach znacznie dłużej. O wyniku przychodzi powiadomienie.

Jeżeli weryfikacja zakończy się niepowodzeniem, na stronie problemu należy kliknąć „Sprawdź szczegóły”. Pokazuje się lista adresów, które nadal nie przeszły kontroli. Po ich naprawieniu uruchamia się kolejną próbę przyciskiem „Rozpocznij nową weryfikację”.

Lista „Strona zawiera przekierowanie” nie zniknie i nie powinna. Stare adresy mają prawo odsyłać dalej. Z czasem, gdy robot rzadziej trafia na linki do nich, lista się skraca, ale jej obecność nie jest błędem.

Co zrobić, gdy łańcuch nie znika, i jakich błędów unikać?

Zdarza się, że reguły są przepisane, a pomiar nadal pokazuje kilka kroków. Najczęściej winne jest miejsce, o którym nikt nie pamiętał, albo zapamiętana stara odpowiedź.

Pamięć przeglądarki i usług pośredniczących

Przeglądarki zapamiętują przekierowania stałe na długo. Po zmianie reguł ta sama przeglądarka może nadal pokazywać stary przebieg. Dlatego kontrolę wykonuje się poleceniem curl albo w oknie incognito. Jeżeli przed serwerem działa usługa CDN, w jej panelu trzeba wyczyścić pamięć podręczną i przejrzeć jej własne reguły przekierowań oraz ustawienie wymuszające https.

Przekierowania ustawione poza plikiem .htaccess

Panel hostingu ma często osobną zakładkę z przekierowaniami domen oraz przełącznik wymuszający https. Rejestrator domeny bywa źródłem jeszcze jednego kroku, jeśli stara domena jest przekierowana na poziomie rejestratora. Każde z tych miejsc należy otworzyć i porównać z arkuszem. Gdy nie wiadomo, skąd pochodzi dany krok, pomaga odpowiedź z polecenia curl: nagłówek server w każdym bloku wskazuje, która usługa wysłała odpowiedź.

Błędy, które pogarszają sprawę

• Usuwanie starych przekierowań zamiast ich przepisania. Stary adres bez przekierowania zwraca błąd 404 i traci cały ruch z dawnych linków. Dokumentacja Google radzi utrzymywać przekierowania jak najdłużej, zwykle co najmniej rok.
• Kierowanie wszystkich starych adresów na stronę główną. Każdy stary adres powinien prowadzić do swojego odpowiednika, a nie do jednego wspólnego miejsca.
• Przekierowanie tymczasowe w miejscu stałego. Przy trwałej zmianie adresu właściwy jest kod 301 lub 308. Różnice opisuję we wpisie o tym, czym różnią się przekierowania 301 i 302.
• Zmiany bez kopii pliku i bez natychmiastowego testu. Jedna literówka w regule potrafi wyłączyć serwis albo stworzyć pętlę.
• Poprawienie reguł bez poprawienia linków. Serwis, który sam linkuje do starych adresów, wciąż wysyła roboty przez przekierowania.
• Dopisywanie kolejnej reguły bez sprawdzenia istniejących. Każda nowa zmiana adresu wymaga poprawienia wszystkich starszych reguł, które wskazywały poprzedni adres.

Ostatni punkt jest najważniejszy na przyszłość. Arkusz z mapą przekierowań należy zachować i uzupełniać przy każdej zmianie adresu. Przy większej przebudowie przydaje się też plan opisany we wpisie o tym, jak przeprowadzić migrację strony bez utraty pozycji w Google.

Najczęstsze pytania

Ile przekierowań z rzędu obsługuje robot Google?

Według dokumentacji Google roboty domyślnie śledzą do 10 przeskoków przekierowania, przy czym roboty poszczególnych produktów mogą mieć inne limity. Google zaleca jednak przekierowanie od razu do miejsca docelowego. Jeśli to niemożliwe, łańcuch powinien być krótki: najlepiej do 3 kolejnych adresów i nie więcej niż 5.

Czy łańcuch złożony z dwóch przekierowań trzeba naprawiać?

Nie jest to pilne. Dwa kroki mieszczą się w zaleceniach Google i nie blokują indeksowania. Skrócenie do jednego kroku nadal ma sens ze względu na czas ładowania i porządek w regułach, zwłaszcza na najczęściej odwiedzanych podstronach, ale można to zaplanować przy okazji innych prac.

Czy przekierowanie 301 obniża pozycję strony w wynikach wyszukiwania?

Dokumentacja Google dotycząca przenoszenia witryn stwierdza, że przekierowania 301 i inne przekierowania stałe nie powodują utraty PageRank. Sam poprawny pojedynczy krok nie jest więc zagrożeniem. Kłopoty biorą się z długich ciągów, z pętli, z przekierowań tymczasowych użytych przy trwałej zmianie oraz z odsyłania do stron o innej tematyce.

Jak długo należy utrzymywać stare przekierowania?

Google radzi utrzymywać je najdłużej, jak to możliwe, zwykle przez co najmniej rok. Uważam, że przekierowań z adresów, do których prowadzą linki z innych serwisów, nie należy usuwać w ogóle. Poprawnie zapisana reguła nie obciąża serwera w zauważalny sposób, a jej brak oznacza błąd 404 dla każdego, kto kliknie dawny link.

Czym różni się łańcuch od pętli przekierowań?

Łańcuch ma koniec: po kilku krokach serwer zwraca stronę z kodem 200. Pętla końca nie ma, ponieważ adresy odsyłają do siebie nawzajem. Przeglądarka przerywa wtedy ładowanie i pokazuje komunikat o zbyt wielu przekierowaniach, a w Search Console adres trafia do przyczyny „Błąd przekierowania”. Pętlę naprawia się w pierwszej kolejności, bo strona jest po prostu niedostępna.

Dlaczego przeglądarka pokazuje stare przekierowanie mimo zmiany reguł?

Przekierowania stałe są zapamiętywane przez przeglądarkę i przy kolejnej wizycie nie są ponownie pobierane z serwera. Stan faktyczny pokazuje polecenie curl albo okno incognito. Jeśli i tam widać stary przebieg, należy wyczyścić pamięć podręczną wtyczki, serwera oraz usługi CDN i sprawdzić, czy nowa wersja pliku rzeczywiście znalazła się na serwerze.

Czy po skróceniu łańcucha trzeba prosić Google o ponowne zindeksowanie?

Nie jest to wymagane, ponieważ robot sam odwiedzi adresy ponownie. Proces można przyspieszyć: w raporcie „Indeksowanie stron” służy do tego przycisk „Sprawdź poprawkę”, a dla pojedynczych, najważniejszych adresów docelowych przycisk „Poproś o zindeksowanie” w narzędziu do sprawdzania adresów URL. Obowiązuje tam dzienny limit próśb, dlatego nie ma sensu zgłaszać w ten sposób setek adresów.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Porządkowanie przekierowań wymaga cierpliwości i dostępu do kilku miejsc naraz: serwera, panelu strony i Search Console. Chętnie wezmę to na siebie od początku do końca. Zbiorę wszystkie stare adresy, sprawdzę, którędy dziś prowadzą, przygotuję mapę przekierowań, przepiszę reguły tak, żeby każdy adres trafiał do celu jednym krokiem, poprawię linki w serwisie i dopilnuję, żeby Google potwierdził naprawę.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, co widzę po pierwszym sprawdzeniu i od czego najlepiej zacząć.