Weryfikacja błędów na stronie raportowanych przez Search Console

Ogólna definicja SEO mówi o optymalizacji strony w taki sposób, by wyświetlała się jak najwyżej w wynikach wyszukiwania. Myślimy więc o optymalizacji treści – dodawaniu oryginalnych opisów, wprowadzaniu do tekstów słów kluczowych i odpowiednich znaczników. Nie zapominamy również o link buildingu. Coraz częściej (na szczęście) pojawiają się również kwestie techniczne – poprawa szybkości i bezpieczeństwa, przekierowania, linkowanie wewnętrzne i inne. I to właśnie w ramach tej ostatniej grupy znajduje się czynnik, od którego w wielu wypadkach warto rozpocząć działania pozycjonujące – a mianowicie weryfikacja i eliminacja błędów na stronie.

Skąd ten pomysł? Powód jest prozaiczny – co z tego, że mamy w swojej ofercie wysokiej jakości produkt, którego wszystkie zalety w jasny sposób opisaliśmy, a nasz blog to kopalnia wiedzy branżowej, jeśli dostęp do nich jest utrudniony przez wyskakujące co chwila błędy. Problemem nie zawsze są widoczne niedoróbki, takie jak kody odpowiedzi 5xx czy 4xx, bo one zwracają naszą uwagę, ale przede wszystkim podstrony “na pierwszy rzut oka” działające poprawnie, ale zawierające w kodzie elementy utrudniające prawidłowe indeksowanie przez wyszukiwarki. A bez wysokich wysokich pozycji w SERPach trudno wypromować swoje usługi w internecie. W jaki sposób odnaleźć błędy, które ograniczają naszą widoczność? Z pomocą przychodzi Google Search Console.

Raport Stan w Search Console – pomocnik w sprawdzaniu najistotniejszych błędów

Google chętnie informuje użytkowników swoich narzędzi o błędach utrudniających indeksowanie. Z pewnością niemal każdy właściciel strony posiadający Search Console dostał maila o treści Wykryto nowy problem. Nie zawsze wiąże się to z tragedią, ale każdą tego typu informację warto poddać weryfikacji.

Pierwszym miejscem, do którego należy się w takiej sytuacji skierować jest raport Stan. Jeśli według Google wszystko jest w porządku, naszym oczom ukazuje się obrazek podobny do tego:

Jeśli jednak pojawią się jakieś błędy na ekranie robi się czerwono. Poniżej wykresu pojawia się lista problemów z liczbą ich wystąpień.

Kliknięcie w element listy przeniesie nas do zestawienia maksymalnie 1000 podstron, na których znaleziono problem, wraz z datami ich wykrycia. Jakie błędy najczęściej pojawiają się w raporcie Stan? Dotyczą one nie tylko nieprawidłowych odpowiedzi serwera (innych niż 200), ale również występowania na stronie elementów blokujących indeksowanie.

Najczęściej spotykane błędy w raporcie Stan

Większość użytkowników Google Search Console widzi mniej więcej podobne komunikaty. W kontekście SEO ich efekt zwykle jest jeden – dana podstrona nie pojawia się w indeksie wyszukiwarki, więc nie znajdziemy jej w SERPach. Skupmy się więc na poszukiwaniu ich źródła.

Błąd serwera (5xx)

Błędy typu 5xx, a wśród nich najczęściej pojawiający się 500 – Internal Server Error, jednoznacznie wskazują, że treść jest niedostępna z powodu problemów z serwerem. Może się więc wydawać, że wina leży po stronie hostingu i jako jego użytkownik możemy jedynie skontaktować się z obsługą klienta i tam szukać pomocy. W niektórych przypadkach to prawda – doszło do przeciążenia usługi, trwają prace techniczne, lub serwery w sieci uległy awarii. Jednak gdy przyjrzymy się dokładniej raportom, często okazuje się że ten błąd dotyczy jedynie kilku podstron. Wówczas należy zacząć szukać problemu w ich konstrukcji. Powodów może być wiele, m.in.:

• niepoprawna konfiguracja uprawnień dostępowych do plików na serwerze,
• przekroczenie limitu czasu wykonywania skryptów  – przetwarzanie znajdujących się na stronie skryptów zajmuje więcej czasu, niż pozwalają na to mechanizmy bezpieczeństwa serwera,
• błędne reguły w pliku .htaccess.

Krótko mówiąc błąd 500 może zostać wywołany również przez niedociągnięcia programistyczne. Źle przygotowany kod (nawet jedna linijka lub niewielki skrypt) uniemożliwia poprawną interpretację całości, przez co wysyłka informacji do użytkownika wydłuża się w nieskończoność i kończy błędem z grupy 5xx. W tej sytuacji wsparcie doświadczonego webmastera będzie niezbędne. Jeśli przed pojawieniem się błędu były prowadzone prace – jak np. modyfikacja kodu (np. wdrożenie nowych funkcjonalności, czyszczenie, optymalizacja) lub, co jest popularne, instalacja wtyczek – być może wystarczy przywrócić zawartość sprzed zmian.

404 – Nie udało się odnaleźć przesłanego URL-a

Powód jest prosty – niedostępność podstrony, a zamiast treści serwer przesyła odpowiedź 404 (co oczywiście w tej sytuacji jest informacją poprawną). Błąd pojawia się w momencie wyłączenia dotychczas istniejącej podstrony lub przesłania do indeksacji adresu, pod którym treści nigdy nie było (np. z powodu nieprawidłowego linkowania wewnętrznego). Występuje bardzo często, gdy zachodzą zmiany struktury adresów URL na stronie. Koronnym przykładem jest tutaj migracja na inny CMS, który w odmienny sposób konstruuje URL-e, ale 404 zdarza się również, gdy optymalizujemy treści i zmienimy ręcznie adres podstrony.

Weryfikacja błędów tego typu jest dużo prostsza niż we wcześniejszym przypadku. Należy sprawdzić czy pod danym adresem wcześniej był dostępne treści. Jeśli tak i generowały one ruch na stronie – należy wprowadzić przekierowania 301 do nowego adresu lub treści podobnych, jeśli dotychczasowa zawartość nie jest dostępna. Jeśli źródłem błędów jest linkowanie wewnętrzne – należy je poprawić. Jeżeli pojedynczy błąd dotyczy podstrony mającej bardzo małe znaczenie, która nie generowała żadnego ruchu z wyników wyszukiwania, nie należy się nim zbytnio przejmować.

Pozorny błąd 404

Źródło tego błędu jest takie samo jak w przypadku “klasycznej” 404. Problem polega jednak na tym, że odpowiedź serwera jest niepoprawna – najczęściej 200, co może sugerować, że wszystko jest w porządku. Google ciągle uczy się rozumienia zawartości dostępnej w internecie i zauważa tego typu odstępstwa od reguły. Jeśli więc serwer zgłasza 200 – OK, ale na stronie nie ma żadnej zawartości (a na innych zwykle się pojawia) lub wyświetlany jest komunikat o braku treści – podstrona może zostać zakwalifikowana do grupy z pozornym błędem 404 i zaraportowana jako błąd.

Przesłany URL zawiera tag „noindex”

W tym wypadku Google Search Console informuje nas o tym, że zauważył sprzeczność. Z jednej strony dany URL został przesłany do indeksowania, ale z drugiej zostało ono zablokowane – przez użycie tagu “noindex” w nagłówku odpowiedzi HTTP lub HTML. W efekcie strona nie została zindeksowana.

W tej sytuacji należy rozpocząć ręczną weryfikację. Należy odwiedzić podane na liście podstrony i ocenić, czy powinny zostać zindeksowane. Jeśli nie – należy nie zgłaszać ich do indeksowania i zignorować błąd, jeśli tak – należy usunąć z nagłówka HTML lub meta tagów instrukcję “noindex”. Jeżeli wszystko wydaje się skonfigurowane poprawnie, należy zasięgnąć wsparcia web developera. Być może instrukcje ograniczające indeksowanie zostały umieszczone w nieprawidłowy sposób (lub w nieoczywistym miejscu) i bez wiedzy na temat budowy strony nie uda się ich odnaleźć.

Blokada adresu URL w pliku robots.txt

Ta informacja może być błędem raportowanym jako Przesłany URL jest zablokowany przez plik robots.txt lub ostrzeżeniem Strona zindeksowana, ale zablokowana przez plik robots.txt. W pierwszym przypadku podstrona nie znajduje się w wynikach wyszukiwania – a została przesłana do indeksowania, w drugim może być dostępna.

Jeśli tego typu informacje się pojawią, należy odwiedzić podstronę i zapoznać się z jej zawartością. Jeżeli uznamy. że powinna być indeksowana – usuwamy blokadę dostępu z robots.txt. Gdy jednak nie chcemy, by treści znajdujące się na niej były dostępne dla robotów, a mimo to są indeksowane – należy użyć instrukcji “noindex” w nagłówku HTML lub odpowiedzi HTTP. Plik robots.txt to tylko sugestia – jeśli robot wyszukiwarki dotrze do zawartości zablokowanej w nim podstrony (np. na skutek jej podlinkowania) i nie znajdzie wspomnianej instrukcji – zindeksuje zawartość.

Błędy przekierowań

Informacja o tego typu błędzie pojawi się, gdy łańcuch przekierowań ulegnie zapętleniu, adresy URL w przekierowaniach generują błędy lub jest ich po prostu za dużo. Wejście na tego typu podstronę kończy się dla użytkownika zwykle komunikatem błędu lub zablokowaniem działania przeglądarki. Mechanizm ten stanowi również pewnego rodzaju zabezpieczenie – nienaturalnie długi łańcuch przekierowań może sugerować, że podstrona zawiera treści ukryte lub kieruje do zawartości potencjalnie niebezpiecznej. Dlatego też “profilaktycznie” usuwana jest z indeksu wyszukiwarki.

Choć opis ten może wydawać się skomplikowany, o błąd przekierowań nietrudno. Wystarczy błędna reguła w pliku .htaccess, która zapętli przekierowania. Dzieje się to np. w momencie przenoszenia zawartości strony do nowego katalogu lub podczas ręcznej zmiany adresów URL. Błędem jest również tworzenie przekierowania do podstrony, dla której również ustawiono przekierowanie. Do problemów tego typu może doprowadzić również próba zmiany adresu URL podstrony na taki, który prowadzi już do innych treści.

Doświadczenia z pracy z różnymi stronami prowadzą jednak do dodatkowego wniosku. Błąd przekierowań nie zawsze będzie w taki sposób raportowany. Źle konfigurując przekierowania możemy doprowadzić do błędów 404 (w wersji “łagodnej”) lub – w przypadkach ekstremalnych – do 5xx, gdy wprowadzone zamieszanie wydłuży czas oczekiwania na odpowiedź do wartości przekraczających ramy bezpieczeństwa dla serwera. Warto korzystać z przekierowań, gdyż są wartościowe dla SEO – ale należy robić to świadomie.

Wykluczono – katalog błędów SEO

Wszystkie omówione powyżej błędy – a także inne pojawiające się jako błąd lub ostrzeżenie mają jedną cechę wspólną – są konkretne. Albo treść w ogóle nie jest dostępna, albo coś uniemożliwia jej indeksowanie. Sekcja Wykluczono to wynik interpretacji danych przekazanych w prawidłowy sposób. Sztuczna inteligencja Google, pomimo swojego zaawansowania, ciągle się uczy. A nasze niektóre zachowania mogą jej w tym skutecznie przeszkodzić i doprowadzić do błędnych wniosków.

Dlatego też, na etapie rozważań typu “co jeszcze mogę zrobić dla SEO mojej strony”, albo w trakcie poszukiwania powodu, dla którego ważna podstrona nie znajduje się w indeksie, a błędów nie ma – należy rozpocząć wycieczkę po wykluczonych podstronach.

Błąd czy wykluczenie?

Otwierając listę wykluczeń, można stwierdzić, że w pewnym sensie duplikuje ona elementy klasyfikowane jako błędy lub ostrzeżenia. Google w swojej pomocy informuje niejasno – “wydaje nam się, że tak powinno być”. Pewności jednak nie ma.

Algorytmy Google analizują celowość naszych działań. Kluczem do tego, co jest w sekcji błąd, a co w wykluczeniu, będzie więc m.in. obecność podstrony w mapie witryny lub jej zgłoszenie do indeksowania. Gdy z jednej strony jasno informujemy o tym, że zależy nam na indeksowaniu, a z drugiej nakładamy tag “noindex” – dla Google zwykle wygląda to na błąd. Jeśli w kodzie strony znajduje się adres kanoniczny lub przekierowanie, robot często zakłada, że umieściliśmy go tam świadomie i wyklucza daną podstronę z indeksu.

Pozostaje również pewien margines – często bardzo duży – sytuacje, w których algorytmy nie zgadzają się z naszą instrukcją (“bo tak i koniec”) lub mają pełną dowolność co do decyzji o zindeksowaniu danej podstrony. Suma możliwych błędów ludzkich, które z punktu widzenia maszyny mają sens i tego co potrafi (lub nie) sztuczna inteligencja to twardy argument, żeby jednak czasem odwiedzić listę Wykluczono.

Tag “noindex” i blokada w robots.txt

W tym miejscu najbardziej widoczna jest różnica między błędem i ostrzeżeniem, a wykluczeniem. Gdy nasze zachowania sugerują że chcemy zindeksować podstronę – została przesłana – Google zaczyna sypać błędami. Jeśli jednak zablokowaliśmy podstronę i nic innego nie wskazuje na to, że może zależeć nam na jej obecności w wynikach wyszukiwania, jest ona wykluczona.

Kiedy warto zaglądać do tej sekcji? Na przykład, gdy korzystamy z rozbudowanych narzędzi do SEO. W jednym miejscu przypadkiem zaznaczymy “nie indeksuj”, podstrona lub cała kategoria podstron otrzyma atrybut “noindex” i wypadnie z regularnie aktualizowanej mapy strony. Jeśli nie mamy w zwyczaju ręcznego zgłaszania dodanych lub zmienianych treści – naszej pomyłki nie zauważymy. A interesującej nas strony w SERPach nie będzie.

404 – jawny i pozorny

Błąd 404 dla Google Search Console również nie musi być błędem w jego nomenklaturze. Wystarczy że w żaden sposób nie sugerujemy chęci zindeksowania podstrony – czyli nie umieścimy jej w mapie XML. Brak tego elementu, połączony z brakiem wcześniej wspomnianego zwyczaju indeksowania ręcznego – powoduje że Google stwierdza “OK – nie zależy Ci na tej podstronie”. Błąd 404 – także ten pozorny – nie ma dla Ciebie żadnego znaczenia.

Przekierowania i canonicale – przyjaciele pozycjonowania?

O tym, jak stosować przekierowania i adresy kanoniczne na stronach, by działały one dobrze dla SEO, pisane jest wiele artykułów i toczy się wiele dyskusji. Tak czy inaczej – jedno lub drugie (w zależności od szkoły) może nam pomóc. Chyba, że nie umiemy z nich korzystać. Niemal wszyscy są zgodni, że zwykle lepiej żeby ich nie było, niż żeby zostały wprowadzone źle.

Źle wprowadzone przekierowanie jest widoczne i łatwiej je zidentyfikować. Po prostu na ekranie pojawi się treść inna niż zamierzona. Wówczas cofamy zmiany. Gorzej z adresami kanonicznymi, które działają na roboty, ale nie na to co widzi użytkownik.

Jeśli wprowadzimy błędny (ze względu na zawartość, nie kod) canonical, Google może mimo wszystko uznać go za poprawny. Podstrona z odwołaniem do innej nie zostanie zindeksowana, gdyż sami określiliśmy, że oryginalna treść znajduje się w zupełnie innym miejscu (pozycja Alternatywna strona zawierająca prawidłowy tag strony kanonicznej). Jeśli więc część produktów i kategorii pomimo unikalnej zawartości i braku blokad nie indeksuje się – warto sprawdzić tą część raportu Stan i adresy kanoniczne. Ekstremalnym przypadkiem jest ustawienie adresów kanonicznych wszystkich podstron do strony głównej lub serwisu zewnętrznego. W większości przypadków Google ignoruje wówczas canonicale, bo zauważa brak sensu. Istnieje jednak niewielka szansa, że zaakceptuje naszą decyzję – a efektem będą problemy z indeksowaniem witryny.

Inne “błędy” na naszych stronach

Zdarzają się jednak sytuacje, gdy na podstronie nie ma błędów, nie zablokowaliśmy indeksowania, a widnieje ona nadal na liście adresów wykluczonych. Wówczas nasuwa się jedyny wniosek – Google uznało podstronę za mało wartościową lub duplikację innych treści w ramach naszej witryny (pozycja Duplikat, użytkownik nie oznaczył strony kanonicznej).  W jaki sposób rozwiązać ten problem? Dodać do niej unikalną zawartość i odpowiednio podlinkować. Gdy algorytmy wyszukiwarki stwierdzą, że może być przydatna użytkownikom, powinna pojawić się w SERPach.

Nie wszystko jest błędem

W ramach raportu Stan, zakładki Wykluczono znaleźć można również pozycje takie jak Strona zeskanowana, ale jeszcze nie zindeksowana oraz Strona wykryta – obecnie nie zindeksowana. Oznacza to, że roboty Google odnalazły daną podstronę, ale jeszcze nie dodały jej do indeksu. Proces indeksowania wymaga czasu – warto monitorować sytuację.

Na kłopoty narzędzie do sprawdzania adresów URL

Komunikaty prezentowane przez Google Search Console w raporcie mogą być nieczytelne. Czasem na liście pojawia się również informacja Przesłany URL zawiera błędy indeksowania. Najlepszym rozwiązaniem w takiej sytuacji jest ręczne sprawdzenie działania danej podstrony, a następnie próba ręcznego zindeksowania lub weryfikacji w narzędziu do sprawdzania adresów URL.

Wystarczy wkleić adres URL w pasku górnym narzędzia i wcisnąć klawisz Enter. Narzędzie wyświetla stan indeksu Google, a także umożliwia test wersji opublikowanej. Jeżeli podstrona nie jest dostępna z powodu błędów, zostaną one wyświetlone, przykładowo:

Na tej podstawie można podjąć próbę eliminacji kluczowych błędów. Po ich usunięciu warto odczekać ok. godzinę i podjąć ponowną próbę ręcznego indeksowania – naniesione zmiany nie zawsze są widoczne dla Google od razu.

Weryfikacja błędów wyświetlania na urządzeniach mobilnych

Innym raportem, do którego warto zajrzeć, jest Obsługa na urządzeniach mobilnych, w sekcji ulepszenia. Ze względu na trendy wśród użytkowników Google wysoko ceni treści dostępne dla użytkowników smartfonów i tabletów. Błędy utrudniające korzystanie z wersji mobilnej strony podnoszą współczynnik odrzuceń i pośrednio wpływają negatywnie na widoczność i ruch w witrynie.

Na powyższym zrzucie ekranu widać najpopularniejsze niedociągnięcia dotyczące wersji mobilnej. Wynikają one głównie z niedopasowania szablonu strony do potrzeb wyświetlaczy urządzeń mobilnych. Niedopasowanie stylów skutkuje zbyt szerokim blokiem treści, który wymaga przewijania poziomego. Jest to niewygodne dla użytkownika. Wymiary obszaru widocznego powinny być dostosowane do różnego typu ekranów – monitorów, tabletów lub smartfonów.

Kolejny istotny błąd, na który należy zwrócić uwagę, to rozmiar czcionki. Małe litery na niewielkim ekranie o wysokiej rozdzielczości nie będą widoczne. Należy zadbać o ustawienie odpowiedniego skalowania.

Zły dobór wymiarów i odstępów pomiędzy poszczególnymi częściami funkcjonalnymi strony może skutkować zbyt ciasnym rozmieszczeniem elementów klikalnych. W efekcie użytkownik będzie mieć problem z trafieniem w interesujący go przycisk bez kliknięcia sąsiednich. Zwykle wywołuje to irytację i z czasem opuszczenie strony. Narzędzia Google Search Console zwracają uwagę na tego typu nieprawidłowości.

Osobnym problemem jest stosowanie technologii nieobsługiwanych przez przeglądarki instalowane na urządzeniach mobilnych. Głównym przykładem jest tutaj technologia Flash. Tego typu treści będą niedostępne dla użytkowników smartfonów i tabletów. Biorąc pod uwagę to, jak często je używamy, warto zrezygnować z rozwiązań dla nich niedostępnych.

Dane strukturalne w Google Search Console

Użytkownicy Google Search Console mają możliwość sprawdzenia błędów związanych z danymi strukturalnymi znajdującymi się na ich stronie – w raporcie Produkty. Dzięki temu zyskujemy informacje, których z zalecanych przez Google znaczników Schema brakuje na naszych stronie, a które zostały zdefiniowane błędnie.

Przeglądając błędy warto skorzystać z narzędzia do testowania danych uporządkowanych i zweryfikować zasadność wprowadzenia brakujących elementów. Priorytetowo należy wdrożyć poprawki dotyczące usług wymaganych, następnie zalecanych i na końcu opcjonalnych, przydatnych naszej witrynie.

Podsumowanie – stosuj zasadę ograniczonego zaufania

Dla wielu użytkowników zawartość maili związanych z błędami na stronie bywa zaskakująca. Przede wszystkim nie należy się nimi przesadnie przejmować – w większości wypadków strona działa, należy jednak wykonać na niej kosmetyczne poprawki, które usprawnią indeksowanie zawartości.

Raport Stan to miejsce, które warto sprawdzać regularnie, zwłaszcza po wdrożeniu większych zmian na stronie. Nagle może bowiem się okazać, że do robotów Google docierają sprzeczne sygnały – z jednej strony chcemy by podstrony były indeksowane, ale z drugiej mają one nadane atrybuty zabraniające dostępu do treści. Większość tego typu błędów to nie problemy typowo techniczne wynikające z wadliwego kodu, a jedynie z niepoprawnego doboru ustawień wtyczek lub atrybutów w nagłówku podstrony. Kilka drobnych zmian może pomóc w przywróceniu treści do indeksu Google. Z drugiej strony komunikaty Google Search Console mogą pomóc właścicielom bardzo dużych serwisów w identyfikacji poważnych błędów występujących na części podstron, których samodzielna weryfikacja wymagałaby wiele czasu.

Przeglądając raporty pamiętajmy, że dane w nich dotyczą momentu wizyty robotów Google na stronie. Jeśli w zestawieniu widoczne są błędy 500, a witryna działa bez problemów, być może crawlery trafiły na nią w momencie prac technicznych lub aktualizacji. Jeśli jesteśmy niemal pewni, że komunikaty nie są zgodne z prawdą, warto wybrać opcję Sprawdź poprawkę. Nastąpi wówczas ponowna weryfikacja błędów i jeśli okaże się, że rzeczywiście wszystko jest w porządku – błędy znikną z wykresu.

Autor: Bartek Tomczyk, Specjalista SEO w Delante. W swoich działaniach łączy optymalizację treści i techniczne SEO. Pracując ze stronami na rynku krajowym i zagranicznym dopasowuje ich zawartość do potrzeb użytkownika – by była naturalna, czytelna i dostępna możliwie jak najszybciej. Na co dzień pasjonat nowych technologii, głównie w zakresie komunikacji, internetu i odnawialnych źródeł energii.