Search Console pokazuje „Strona z przekierowaniem”: który URL sprawdzić?

Przenosisz stronę usługi z /old-service na /services/design. Później Search Console umieszcza stary adres w kategorii „Strona z przekierowaniem”. Nowa strona otwiera się w przeglądarce. Czy stary adres też trzeba zaindeksować?

Zwykle ważniejsze jest to, czy stary adres prowadzi do strony, którą użytkownicy rzeczywiście mają znaleźć. Google opisuje ten stan jako niekanoniczny URL przekierowujący na inną stronę. Źródłowy URL nie jest indeksowany w tym stanie; adres docelowy może być zaindeksowany, ale nie musi. Inna pozycja raportu, „Błąd przekierowania”, oznacza problem napotkany przez Google podczas podążania za przekierowaniem, na przykład pętlę lub zbyt długi łańcuch.

Powyższy przykład służy ilustracji i nie pochodzi z analizy witryny klienta. Oto sposób sprawdzenia jednego ważnego adresu, zanim zmienisz przekierowania w całej witrynie.

Zapisz źródło i zamierzony adres docelowy

W Search Console otwórz raport indeksowania stron, wybierz „Strona z przekierowaniem”, a następnie jeden URL. Skopiuj pełny adres: http lub https, nazwę hosta, ścieżkę, końcowy ukośnik i ewentualne parametry zapytania. Jeśli raport podaje datę ostatniego crawlowania przez Google, również ją zanotuj.

Następnie zapisz zarówno URL z raportu (źródło), jak i adres, na który chcesz kierować użytkowników (cel). Przeniesienie starego adresu usługi na stronę zastępczą może być zamierzone. Adres kampanii płatnej kierujący użytkowników na niezwiązaną z nią stronę główną może natomiast wymagać sprawdzenia.

Sam fakt obecności adresu w raporcie nie dowodzi ani tego, że cel jest zaindeksowany, ani tego, że przekierowanie pogorszyło pozycje. Nie wskazuje też ustawienia, które utworzyło przekierowanie.

Otwórz adres bez logowania

Otwórz źródłowy URL w prywatnym oknie przeglądarki i zanotuj adres końcowy na pasku adresu. Czy prowadzi do oczekiwanej strony z właściwą treścią? Jeśli kieruje do logowania, niewłaściwej wersji językowej, niezwiązanej usługi albo błędu, zapisz co i kiedy się stało. Prywatne okno pokazuje ścieżkę tego użytkownika; Googlebot może otrzymać inną odpowiedź, na przykład gdy reguła zależy od user agenta.

Jeżeli końcowy adres jest nieoczekiwany, sprawdź trasę narzędziem przekierowań hostingu albo narzędziem do debugowania WWW, które pokazuje każdą odpowiedź i nagłówek Location. Przykładowy łańcuch:

/old-service → /services → /services/design

To tylko przykład. Jeśli któryś krok wraca do wcześniejszego adresu lub wskazuje nieprawidłowy albo pusty cel, zbadaj ten krok. Google wymienia wśród „Błędów przekierowania” pętle, zbyt długie łańcuchy, nieprawidłowe lub puste adresy i adresy, które ostatecznie stają się zbyt długie. Wpis „Strona z przekierowaniem” nie oznacza automatycznie jednego z tych błędów.

Na platformie przekierowania mogą być skonfigurowane w jej panelu, we wtyczce, na serwerze WWW lub w innej warstwie, takiej jak CDN. Reguły różnych warstw mogą ze sobą kolidować, więc przed zmianą prześledź trasę i sprawdź, do której warstwy należy każda reguła. Nie wklejaj prywatnych adresów, tokenów dostępu ani danych klientów do publicznego narzędzia debugującego.

Osobno sprawdź adres docelowy

W narzędziu do sprawdzania URL zobacz wynik z indeksu dla źródła i datę crawlowania. Następnie sprawdź zamierzony cel jako osobny URL. Raport źródła nie ustala stanu indeksowania celu. Jeśli cel znajduje się poza usługą, którą możesz sprawdzić, zweryfikuj jego publiczną dostępność i w razie potrzeby zapytaj właściciela. Możesz nie mieć wglądu w jego stan w Search Console; brak wyniku kontroli nie dowodzi, że adres nie jest zaindeksowany.

Według Google test na żywo podąża za przekierowaniem i sprawdza końcowy URL, nie pokazując, że podążył za przekierowaniem ani który adres końcowy sprawdził. Test pomaga więc ocenić bieżący dostęp, ale nie zastępuje sprawdzenia trasy od źródła do celu. Wynik na żywo nie gwarantuje indeksowania ani nie przewiduje kanonicznego URL wybranego przez Google. Porównaj go z zapisanymi przez Google danymi indeksu i ich datami, traktując je jako osobne obserwacje.

Jeżeli cel nie jest zaindeksowany, sprawdź podany dla niego powód. Na przykład celowo ustawiony noindex na stronie docelowej to inna kwestia niż poprawnie przekierowujący adres źródłowy. Zajmij się przyczyną dotyczącą celu. Usunięcie działającego przekierowania wyłącznie w celu wyczyszczenia wpisu źródła nie rozwiązuje problemu noindex na stronie docelowej.

Zostawić czy poprawić?

Jeśli stary adres celowo i niezawodnie prowadzi do odpowiedniej strony zastępczej, którą użytkownicy mają znaleźć, sam stan nie jest powodem do usunięcia przekierowania. Działający stary adres pomaga również osobom korzystającym z istniejących linków. Google może nadal trafiać na stary adres przez linki lub inne źródła odkrywania. Wpis pozostający w raporcie nie wskazuje źródła odkrycia ani nie dowodzi, że aktualna mapa witryny nadal go zawiera.

Jeśli ważna strona nieoczekiwanie przekierowuje do niewłaściwego celu, znajdź i popraw odpowiedzialną regułę. Strona produktu kierująca do niezwiązanej strony głównej to inna sytuacja niż stary URL prowadzący do swojej strony zastępczej. Jeśli usunięta strona nie ma odpowiedniego zamiennika, odpowiedź 404 Not Found albo 410 Gone może być właściwa. Przekierowanie niezwiązanych usuniętych stron do strony głównej może zostać potraktowane jako soft 404.

Przy trwałym przeniesieniu wskazówki Google traktują stałe przekierowania, takie jak 301 i 308, jako sygnały, że celem powinien być adres kanoniczny. Przekierowania tymczasowe, takie jak 302 i 307, mają inną semantykę. Google wymienia przekierowania po stronie serwera jako pierwsze wśród metod, które najprawdopodobniej poprawnie zinterpretuje. Wybierz typ zgodnie z planowanym czasem przeniesienia; kanoniczny URL wybrany przez Google może różnić się od preferowanego.

Skieruj własne linki na zamierzoną stronę

Jeśli aktualna mapa witryny lub link wewnętrzny nadal używa starego URL, w odpowiednich miejscach zaktualizuj go do zamierzonego celu. Na przykład po przeniesieniu /old-service na /services/design kontrolowany przez Ciebie link nawigacyjny może prowadzić bezpośrednio do /services/design. Zachowaj przekierowanie dla starych linków, których nie możesz zmienić. Nie usuwaj go tylko dlatego, że zmieniła się Twoja nawigacja.

Takie porządki dają użytkownikom bezpośrednią ścieżkę i wyraźniej wskazują Google preferowany adres. Nie gwarantują indeksowania ani nie wymagają zastąpienia każdego starego linku w internecie. Search Console może zgłaszać adresy odkryte poza aktualną mapą witryny.

Sprawdź ponownie jedną trasę i zapisz wynik

Po poprawce ponownie sprawdź trasę od źródła do celu i jeszcze raz zbadaj cel. Zanotuj źródło, końcowy URL, zaobserwowane odpowiedzi lub kroki przekierowania, zmianę i datę. Jeśli naprawiono rzeczywisty problem, Search Console oferuje weryfikację, aby Google mogło go sprawdzić ponownie. Weryfikacja nie gwarantuje indeksowania celu ani aktualizacji raportu w określonym dniu.

Do osobnego przeglądu strony głównej narzędzie SEOHabit do sprawdzania SEO witryny oferuje po rejestracji pierwszą kontrolę ograniczoną do strony głównej. Ta pierwsza kontrola nie wymaga potwierdzenia własności witryny, ale kontrole ciągłe już tak. Narzędzie nie wyjaśni, dlaczego Google wybrało konkretny cel przekierowania; do tej kwestii użyj Search Console i rzeczywistej trasy przekierowania.

Przekierowanie może być zamierzoną drogą, a nie usterką. Zacznij od dokładnego adresu z raportu, sprawdź, dokąd prowadzi, i zbadaj stronę, którą ludzie rzeczywiście mają znaleźć.

Źródła: raport indeksowania stron Google (https://support.google.com/webmasters/answer/7440203), pomoc dotycząca sprawdzania URL (https://support.google.com/webmasters/answer/9012289) oraz wskazówki dotyczące przekierowań (https://developers.google.com/search/docs/crawling-indexing/301-redirects).