„Strona zawierająca przekierowanie” w Search Console: kiedy to problem

Co znaczy status „Strona zawierająca przekierowanie”

Ten status widać w raporcie Indeksowanie stron w Google Search Console, w tabeli „Dlaczego strony nie są indeksowane”. Pomoc Search Console opisuje go tak: to niekanoniczny adres URL, który przekierowuje do innej strony, więc sam nie będzie indeksowany. Adres docelowy może trafić do indeksu albo nie, zależnie od tego, jak oceni go Google.

Status leży w grupie „Nie zindeksowano”, którą Google opisuje jako strony niezindeksowane, ale niekoniecznie z powodu błędu. W praktyce znaczy to tyle: Google znalazł adres, odwiedził go, zobaczył przekierowanie i poszedł dalej. Tak ma działać poprawne przekierowanie stałe. Jest ono dla Google sygnałem, że nowy adres ma zastąpić stary w wynikach, choć adres docelowy musi jeszcze sam trafić do indeksu.

Dlatego sama liczba adresów z tym statusem niewiele mówi. Po migracji sklepu może ich być kilka tysięcy i wszystko jest w porządku. Liczy się to, które adresy są na liście i dokąd prowadzą.

Kiedy ten status jest normalny

Na liście spokojnie mogą być adresy, które przekierowują celowo i jednym krokiem na właściwą stronę. Mogą to być na przykład:

• stare adresy po zmianie struktury serwisu, platformy sklepu albo domeny, przekierowane na nowe odpowiedniki;
• wersja z http:// kierująca na https://;
• wersja z www kierująca na wersję bez www albo odwrotnie;
• adres bez ukośnika na końcu kierujący na adres z ukośnikiem albo odwrotnie;
• usunięte produkty i wpisy przekierowane na najbliższy odpowiednik, na przykład nowszy model albo kategorię.

W takich przypadkach nic nie trzeba robić. Google nie zindeksuje adresu oznaczonego tym statusem i przy celowym przekierowaniu tak powinno być. Po migracji takie adresy potrafią wisieć w raporcie miesiącami, mimo że przekierowania działają. To też nie jest powód do niepokoju, dopóki adresy docelowe są w indeksie.

Kiedy trzeba zareagować

Status staje się sygnałem problemu, gdy na liście jest coś, czego się nie spodziewasz. Sprawdź zwłaszcza te sytuacje:

Ważna strona przekierowuje, choć nie powinna

Strona usługi, kategoria albo popularny produkt jest na liście, bo jakaś reguła wysyła ją gdzie indziej. Przyczyną bywa wtyczka do przekierowań w WordPressie z regułą obejmującą zbyt wiele adresów, zmiana adresu strony bez sprawdzenia skutków albo przekierowanie zależne od kraju czy języka odwiedzającego. Googlebot odwiedza strony głównie z adresów w USA, więc przekierowanie według lokalizacji może go odsyłać na inną wersję serwisu niż polskich klientów.

Wiele adresów kieruje na stronę główną

Po migracji kusi, żeby wszystkie stare adresy bez odpowiednika przekierować na stronę główną. Google pisze w dokumentacji przenoszenia witryn, że takie przekierowanie może zostać potraktowane jak błąd soft 404. Wtedy, naszym zdaniem, stary adres nie przekaże swojej wartości, a klient z dawnego linku ląduje na stronie, której nie szukał. Lepiej kierować na najbliższy odpowiednik albo zwrócić prawdziwy błąd 404 lub 410.

Przekierowujące adresy są w mapie witryny

Google traktuje adresy z mapy witryny jako sugestię, które strony mają być kanoniczne. Adres oznaczony tym statusem Google uznał za niekanoniczny, więc taki wpis w mapie wysyła sprzeczny sygnał. W mapie powinny być tylko adresy docelowe, które odpowiadają kodem 200. Jedyny wyjątek to czas migracji: Google pisze wprost, że ostrzeżenia o przekierowujących adresach w starej mapie są wtedy normalne i można je zignorować.

Linki wewnętrzne prowadzą przez przekierowania

Menu, stopka, okruszki albo linki w treści wskazują stare adresy, a serwer za każdym razem przekierowuje. Google zaleca w takiej sytuacji poprawić własne linki, bo przekierowania spowalniają użytkowników. Każdy dodatkowy krok to też dodatkowe zapytanie dla robota.

Adres kanoniczny wskazuje stronę, która przekierowuje

Strona ma tag rel="canonical" z adresem, który sam przekierowuje dalej. Dokumentacja Google nie opisuje tego przypadku osobno, ale to dwa sygnały, które się wzajemnie podważają. Tag kanoniczny powinien wskazywać adres końcowy.

Przekierowanie tymczasowe przy trwałej zmianie

Strona przeniosła się na stałe, a serwer odpowiada kodem 302 albo 307. Google pokazuje wtedy w wynikach raczej stary adres niż nowy. Więcej o tym w części o rodzajach przekierowań.

Jak to sprawdzić krok po kroku

1. W Search Console otwórz raport Indeksowanie stron. Pod wykresem znajdziesz tabelę „Dlaczego strony nie są indeksowane”.
2. Kliknij wiersz „Strona zawierająca przekierowanie”. Zobaczysz wykres dla tego statusu i listę przykładowych adresów.
3. Wyeksportuj listę przyciskiem eksportu i przejrzyj ją pod kątem adresów, których się tam nie spodziewasz: stron ofertowych, kategorii, najważniejszych artykułów.
4. Dla każdego podejrzanego adresu sprawdź, dokąd prowadzi i ile kroków ma łańcuch. W przeglądarce zrobisz to w narzędziach dla programistów, w zakładce Sieć. Szybciej sprawdzi to programista jednym poleceniem, które pokazuje każde przekierowanie HTTP i jego kod odpowiedzi.
5. Adres docelowy wklej w pole wyszukiwania na górze Search Console, czyli w narzędzie do sprawdzania adresów URL. Sprawdź, czy jest w Google i który adres Google wybrał jako kanoniczny. Przycisk „Sprawdź URL wersji opublikowanej” uruchomi test aktualnej wersji. Jeśli test się uda, „Wyświetl przetestowaną stronę” i karta „Zrzut ekranu” pokażą, jak strona wygląda teraz.
6. Jeśli serwis ma więcej niż kilkaset stron, przejdź go programem do crawlowania, na przykład Screaming Frog. Dostaniesz listę przekierowań, łańcuchów i linków wewnętrznych, które program znajdzie podczas crawlowania. Stare adresy, do których nic nie linkuje, dodaj do skanowania z listy migracji albo z Search Console. Darmowa wersja Screaming Frog skanuje do 500 adresów naraz.

Przykład polecenia dla programisty:

curl -sSIL https://twojadomena.pl/stary-adres/ | grep -iE "^HTTP|^location"

Wynik to lista kolejnych kodów odpowiedzi i adresów dla żądania HEAD. Przekierowań przez meta refresh i JavaScript polecenie nie pokaże, te sprawdzisz w przeglądarce. Jedno przekierowanie 301 i na końcu kod 200 to stan, do którego dążysz.

Rodzaje przekierowań i jak traktuje je Google

Dla Google nie wszystkie przekierowania znaczą to samo. Różnica decyduje o tym, który adres zobaczysz w wynikach wyszukiwania.

Google zaleca przekierowania stałe po stronie serwera wszędzie tam, gdzie to możliwe. Kody 307 i 308 to dla Google odpowiedniki 302 i 301. Według dokumentacji przekierowania stałe nie powodują utraty PageRanku, czyli wartości z linków prowadzących do starego adresu.

Przy trwałej zmianie od razu ustaw 301 albo 308. John Mueller z Google mówił, że wyszukiwarka z czasem rozpoznaje długo utrzymywane przekierowania tymczasowe jako stałe, ale zanim to nastąpi, w wynikach może zostać stary adres.

Czym różni się „Błąd przekierowania”

W tym samym raporcie może pojawić się drugi status: „Błąd przekierowania”. Ten oznacza już awarię. Według pomocy Search Console chodzi o jeden z czterech przypadków:

• za długi łańcuch przekierowań;
• pętla, czyli adres A kieruje na B, a B z powrotem na A;
• adres, który po kolejnych przekierowaniach przekracza dopuszczalną długość;
• błędny albo pusty adres gdzieś w łańcuchu.

Google podaje, że jego roboty domyślnie śledzą do 10 kolejnych przekierowań. W dokumentacji przenoszenia witryn zaleca jednak kierować od razu na adres końcowy, a jeśli się nie da, ograniczyć łańcuch najlepiej do 3 kroków i trzymać go poniżej 5. Długie łańcuchy spowalniają użytkowników, a część przeglądarek i programów ich nie obsługuje.

Pętle mogą powstać wtedy, gdy kilka reguł działa naraz: jedna w ustawieniach serwera, druga we wtyczce, trzecia w panelu sklepu albo w usłudze typu Cloudflare. Na przykład serwer przekierowuje na wersję z www, a CDN z powrotem na wersję bez www. Naprawa polega na zostawieniu jednej reguły dla każdej zmiany. Przy Cloudflare pętlę potrafi też wywołać tryb szyfrowania SSL/TLS „Flexible”. Cloudflare zaleca wtedy tryb „Full” lub wyższy albo usunięcie przekierowania na HTTPS z serwera.

Jak naprawić typowe przypadki

• Przekierowujące adresy w mapie witryny. Zastąp je adresami docelowymi. Jeśli mapę generuje wtyczka albo platforma sklepu, sprawdź jej ustawienia i gotowy plik: nie powinno w nim być starych adresów ani niekanonicznych wersji, na przykład z parametrami.
• Linki wewnętrzne do przekierowań. Zacznij od szablonu: menu, stopki i okruszków, bo jedna poprawka zmienia linki na wszystkich stronach. Potem popraw linki w treści, zaczynając od najczęściej odwiedzanych stron.
• Łańcuch A → B → C. Ustaw przekierowanie z A od razu na C. Zostaw też przekierowanie z B na C, bo do B mogą prowadzić linki z zewnątrz.
• Pętla. Znajdź wszystkie miejsca, w których ustawiono przekierowania (serwer, wtyczka, CMS, CDN), i usuń reguły, które się dublują albo wykluczają.
• Tymczasowe zamiast stałego. Przy trwałej zmianie zamień 302 i 307 na 301 albo 308.
• Niezamierzone przekierowanie ważnej strony. Usuń regułę, przywróć stronę z kodem 200 i poproś o zindeksowanie w narzędziu do sprawdzania adresów URL.
• Wszystko na stronę główną. Przypisz staremu adresowi najbliższy odpowiednik. Jeśli go nie ma, zwróć 404 albo 410.

Co dalej po poprawkach

Jeśli poprawiłeś „Błąd przekierowania”, otwórz ten status w raporcie i kliknij „Sprawdź poprawkę”. Google ponownie sprawdzi adresy z listy. Według pomocy Search Console weryfikacja trwa zwykle do około dwóch tygodni, a czasem znacznie dłużej. Postęp pokaże przycisk „Sprawdź szczegóły”.

Przy statusie „Strona zawierająca przekierowanie” na koniec nie ma czego weryfikować, bo adresy przekierowujące nadal przekierowują. Zmiana, której szukasz, to adresy docelowe w indeksie i brak na liście stron, które nie powinny się na niej znaleźć.

Po migracji nie usuwaj przekierowań zbyt wcześnie. Google zaleca trzymać je jak najdłużej, zwykle co najmniej rok. Przez ten czas Google przenosi sygnały na nowe adresy, w tym linki z innych stron, które dalej wskazują stare. Tę część pracy przy migracji opisujemy szerzej przy migracji strony.