Prawdziwe miejsce docelowe – wyjaśnienie mylącego, ale często dokładnego, prawdziwego docelowego adresu URL dla przekierowań w raportach zasięgu Google Search Console

Jeśli jesteś zdezorientowany, gdy Google zgłasza przekierowania jako inne kategorie, takie jak „zablokowane przez robots.txt”, „soft 404”, „noindexed”, „404s” i inne, może to być Google po cichu śledzi przekierowanie i zgłasza stan zamiast tego prawdziwy docelowy adres URL. Mój post szczegółowo opisuje sytuację i podaje przykłady tego, co dzieje się na wolności.

Podczas intensywnej analizy stron internetowych z punktu widzenia SEO, bez wątpienia znajdziesz się głęboko w raportowaniu Google Search Console (GSC). GSC zawiera mnóstwo danych bezpośrednio z Google i może pomóc właścicielom witryn i SEO w uzyskaniu kluczowych informacji. To powiedziawszy, ważne jest, aby zrozumieć niuanse związane z raportowaniem GSC oraz sposób, w jaki Google określa informacje, które podaje w tych raportach. Jasne zrozumienie tego, co pokazują dane, jest ważne przy podejmowaniu działań mających na celu poprawę SEO.

I nie ma lepszego przykładu zamieszania w danych GSC niż przerażający prawdziwy docelowy adres URL dla przekierowań w raportowaniu pokrycia indeksu GSC (i narzędziu do sprawdzania adresów URL). Otrzymałem tak wiele pytań na ten temat od klientów, że postanowiłem napisać ten post, aby po prostu wskazać ludzi tutaj zamiast wyjaśniać to raz za razem.

Dołącz do mnie w przygodzie GSC, w której odkryjemy sekrety prawdziwego docelowego adresu URL. Niektórzy z was mogą już to wiedzieć, ale ja wiem, że niektórzy nie. A dla tych, którzy tego nie robią, wszystko to wkrótce nabierze sensu. Możesz nie być zadowolony z tego, jak to działa, ale przynajmniej zrozumiesz, dlaczego adresy URL są kategoryzowane w określony sposób w GSC (i za pomocą narzędzia do sprawdzania adresów URL).

Jaka jest przerażająca sytuacja z prawdziwym docelowym adresem URL w GSC dla przekierowań?
Podczas przeglądania stanu indeksowania przekierowywanych adresów URL w GSC Google zgłasza prawdziwy docelowy adres URL (nawet jeśli ten adres URL znajduje się poza Twoją własną witryną). Na przykład, jeśli przekierujesz adres URL na inny adres URL, który z jakiegoś powodu nie będzie indeksowany, GSC po cichu podąży za przekierowaniem i zgłosi stan ostatecznego miejsca docelowego. A to może być bardzo mylące dla właścicieli witryn i SEO, którzy nie wiedzą, że tak się dzieje.

Tak, oznacza to, że możesz zobaczyć adresy URL wyświetlane jako „zablokowane przez plik robots.txt”, „noindexed”, „soft 404”, „404” i inne (gdy sprawdzany adres URL faktycznie przekierowuje). Jak możesz sobie wyobrazić, wielu właścicieli witryn jest zdezorientowanych, gdy widzą „zablokowany przez plik robots.txt”, gdy wiedzą w 100%, że adres URL przekierowuje.

John Mueller z Google był o to wielokrotnie pytany i odpowiedział na to, co wyjaśniłem powyżej (i przyznaje, że może to być nieco mylące). Ponadto Barry napisał post opisujący, jak to się dzieje z narzędziem do sprawdzania adresów URL na podstawie komentarzy Johna. Mimo że zostało to udokumentowane, uważam, że nadal jest to bardzo zagmatwana sytuacja dla wielu właścicieli witryn i SEO (dlatego piszę ten post).

Oto mój tweet z linkiem do Johna wyjaśniającego, w jaki sposób Google po cichu śledzi przekierowania (i jak to się pokazuje w GSC):

Teraz, gdy wiesz, że tak się dzieje, możesz się zastanawiać, jak to właściwie wygląda w GSC. Omówię to dalej z przykładami tego, co dzieje się na wolności.

Przykłady Google dyskretnie śledzącego przekierowania i zgłaszającego prawdziwy stan docelowego adresu URL w GSC:
Poniżej przedstawię przykłady ze zrzutami ekranu raportów Google dotyczących prawdziwych docelowych adresów URL w porównaniu z przekierowaniami. Ponownie, dzieje się tak, gdy z jakiegoś powodu ostateczne docelowe adresy URL nie są indeksowane.

Zablokowany przez plik robots.txt:
Adres URL jest przekierowywany poza witrynę na adres URL zablokowany przez plik robots.txt. Google zgłasza przekierowujący adres URL jako „zablokowany przez plik robots.txt”, ponieważ ostateczna lokalizacja docelowa jest w rzeczywistości niedozwolona.

Skręt na zablokowany przez robots.txt:
Ten adres URL przekierowuje najpierw do adresu URL śledzenia, który jest blokowany przez plik robots.txt. Ostateczne miejsce docelowe nie jest zablokowane, ale Google nie może śledzić pierwszego przekierowania, aby znaleźć ostateczny docelowy adres URL, ponieważ jest to niedozwolone. Po prostu wie, że pierwszy adres URL w łańcuchu jest zablokowany i zgłasza to w GSC. Poniżej możesz zobaczyć, jak drugi krok pokazuje, że adres URL jest faktycznie blokowany przez plik robots.txt (i to jest raportowane w GSC).

Miękki 404:
Adres URL przekierowuje do strony, która jest miękkim 404 (produkt jest niedostępny). Google zgłasza, że ​​przekierowany adres URL jest miękkim 404 (ponieważ prawdziwy docelowy adres URL jest postrzegany jako miękki 404).

Oto strona, do której przekierowuje adres URL (z produktem „aktualnie niedostępnym”). Stąd miękkie 404:

Nieindeksowany:
Tak, zgadłeś. Adres URL przekierowuje do strony, która nie jest zindeksowana. Google zgłasza przekierowujący adres URL jako nieindeksowany w raportach dotyczących zasięgu:

Zindeksowane, nieindeksowane:
Na pierwszy rzut oka możesz pomyśleć, że przekierowanie jest zgłaszane jako „zindeksowane, nie zindeksowane”. Nie prawda! To ostateczny docelowy adres URL, który nie jest indeksowany przez Google. Google zgłasza „Zindeksowane, nie zindeksowane” dla prawdziwego docelowego adresu URL.

Ostateczny docelowy adres URL rzeczywiście nie jest indeksowany:

404:
Jak Google może zobaczyć przekierowanie jako błąd 404? Nie. To prawdziwy docelowy adres URL, który zawiera błędy 404 i to jest raportowane w GSC.

404 ze zmianą nazwy domeny:
To tylko odmiana sytuacji 404, aby wyjaśnić, jak to działa podczas zmiany nazw domen. Adres URL w starej domenie przekierowuje do adresu URL w nowej nazwie domeny, ale adres URL nigdy nie został przeniesiony (błędy 404). Tak więc Google zgłasza, że ​​przekierowany adres URL to 404.

Przepraszamy, więcej zamieszania z przekierowaniami:
Gdy adres URL przekierowuje do strony, która jest rozpoznawana z kodem odpowiedzi nagłówka 200 i jest indeksowana, narzędzie do sprawdzania adresów URL informuje dokładnie o przekierowaniu (i mówi, że początkowy adres URL jest przekierowaniem i nie jest indeksowany), ale Google pokazuje kod kanoniczny jako prawdziwy docelowy adres URL (do którego prowadzi przekierowanie). Porozmawiaj o mylących, zwłaszcza w oparciu o wszystko, co wyjaśniłem powyżej, z innymi przykładami, w których przekierowania są zgłaszane jako coś innego niż przekierowanie…

Możliwe rozwiązanie w GSC, aby wyjaśnić zamieszanie:
Więc jak to może być bardziej intuicyjne? Myślę, że gdyby GSC rzeczywiście przekazał komunikat, że raportuje prawdziwy docelowy adres URL, może to wyjaśnić zamieszanie dla właścicieli witryn i SEO. Poniżej wyśmiewałem się, jak to może wyglądać w GSC. Jeśli Daniel Waisberg czyta (a mam nadzieję, że tak), dodaj to!

Podsumowanie: wyjaśnienie zamieszania związanego z przekierowaniami i raportowaniem docelowego adresu URL.
Mam nadzieję, że ten post pomógł ci zrozumieć, w jaki sposób Google po cichu śledzi przekierowania i zgłasza prawdziwe docelowe adresy URL w GSC. Wiem, że jest to mylący temat dla wielu właścicieli witryn i SEO, i jestem pewien, że doprowadziło to do wielu momentów, w których można było zaskakiwać. Pamiętaj tylko, że od teraz GSC raportuje prawdziwe docelowe adresy URL, gdy adres URL przekierowuje. Nie zdziw się więc, gdy zauważysz przekierowania w innych kategoriach w raportowaniu zasięgu GSC (lub podczas korzystania z narzędzia do sprawdzania adresów URL). I kto wie, może zespół produktowy GSC zrealizuje przesłanie, które wyśmiewałem powyżej…

GG