Opublikowano

SEO WordPressa – obsługa błędów

SPIS TREŚCI:

Załóżmy, że struktura naszego portalu WWW jest przejrzysta, a nawigacja intuicyjna. Użytkownicy i roboty indeksujące bez skrępowania konsumują nasze treści. Żyjemy sobie w poczuciu dobrze wykonanej pracy, a tam, gdzieś daleko, przy próbie wejścia na naszą stronę, niektórzy widzą biały ekran i komunikat o błędzie. To oznacza, że do naszego serwisu prowadzą nieprawidłowe odnośniki lub dzieje się coś niedobrego z infrastrukturą sieciową.

Standardowe komunikaty serwera to same starty

W błędach nie ma nic dziwnego – zepsute odnośniki się zdarzają, podobnie jak awarie i przestoje w komunikacji. Problemem jest lakoniczny komunikat o błędzie. Biały ekran i czarny tekst nikomu nic nie mówią. Czasami w przypadku serwerów współdzielonych pojawi się strona usługodawcy. W obydwu przypadkach wszyscy tracą. Roboty indeksujące są w kropce – co najwyżej zostaną przekierowane na stronę usługodawcy. Użytkownicy są zirytowani i zamykają kartę przeglądarki. A my, tracimy ruch na portalu. Dlaczego tak się dzieje?

Komunikacja między przeglądarką, a serwerem wygląda jak zwykła rozmowa. Przeglądarka wysyła serwerowi różne zapytania (tzw. żądania), a serwer odpowiada. Jeśli pojawią się problemy, to serwer zwraca informację pod postacią komunikatu wraz z numerem ewentualnego błędu. Anglojęzyczne komunikaty wraz z numerem błędu są kompletnie nieprzydatne dla gości i robotów.

Standardowa strona błędu 404 wygenerowana przez serwer Apache
Jest to ekstremalny przykład strony błędu 404. Coraz rzadziej możemy takie oglądać. Powoli zastępują je strony prowadzące do portalu WWW usługodawcy lub standardowe strony błędu wykorzystywanego CMSa i motywu.

Co nam mówi serwer?

Serwery generują mnóstwo komunikatów, ale nie wszystkie są związane z błędami. Właściwie każda pomyślna odpowiedź serwera to też komunikat. Dlatego odpowiedzi zostały podzielone na grupy i przyporządkowano im konkretne numery. Większość komunikatów, z którymi się stykamy pochodzi z grupy 4xx – dotyczą błędów aplikacji na serwerze (przykł. WordPress); oraz z grupy 5xx – dotyczą błędów serwera. Proponuję zapoznać się z najczęstszymi błędami.

Błędy z grupy 4xx

Błędy poniżej dotyczą aplikacji zainstalowanej na serwerze:

  • 400 (Bad Request) – Błędne żądanie wysłane do serwera – dotyczy to błędów po stronie klienta, a nie serwera, przykładowo literówka w zapytaniu.
  • 401 (Unauthorized) – Dostęp do żądanego obszaru portalu WWW wymaga zalogowania/uwierzytelnienia.
  • 402 (Payment Required) – Zapytanie wysłane do serwera nie może zostać przetworzone ponieważ wymaga upoważnienia.
  • 403 (Forbidden) – Wczytanie żądanej strony WWW zostało zablokowane – oznacza to, że serwer przyjął żądanie, ale nie może zwrócić wyników chociażby z powodów bezpieczeństwa.
  • 404 (Not Found) – Żądana strona nie została odnaleziona na serwerze.

Błędy z grupy 5xx

Przyjrzyjmy się teraz popularnym błędom generowanym przez serwer. Dotyczą one głównie błędnej konfiguracji urządzeń lub innych problemów infrastruktury sieciowej:

  • 500 (Internal Server Error) – Ogólny błąd serwera – przyczyn jest bardzo dużo.
  • 501 (Not Implemented) – Serwer nie obsługuje funkcjonalności, o której mowa w podesłanym do niego żądaniu – może to wynikać z tego, że nie została wdrożona.
  • 502 (Bad Gateway) – Serwer pośredniczący w komunikacji napotkał problem podczas komunikacji z serwerem docelowym.
  • 503 (Service Unavailable) – Błąd wydajności serwera, dotyczy to przeważnie jego przeciążenia.
  • 504 (Gateway Time-out) – Serwer pośredniczący w komunikacji nie doczekał się odpowiedzi od serwera docelowego – został przekroczony zdefiniowany limit czasowy na otrzymanie odpowiedzi.

Komunikaty są dosyć ogólne, ale pozwalają administratorom skierować wzrok we właściwą stronę i rozpocząć szukanie przyczyn. Niektóre błędy są wykorzystywane w różnych sytuacjach. Za przykład może posłużyć błąd 402, który mówi o „braku opłaty”. W przypadku serwerów urzędu skarbowego oznacza, że jakiś podmiot nie został upoważniony do przesyłania elektronicznych dokumentów (głównie e-Deklaracji).

Pozostałe komunikaty

Serwery potrafią także informować o dobrych nowinach, ale siłą rzeczy nie muszą być wyświetlane. Są to głównie komunikaty informacyjne – z grupy 1xx, jak i potwierdzające prawidłowe obsłużenie żądania – z grupy 2xx. Osobna, bardzo ważna z perspektywy pozycjonowania grupa, to komunikaty dotyczące przekierowań 3xx. Dwa najważniejsze to:

  • 301 (Moved Permanently) – strona (jakiś dokument/plik) została przeniesiona w inne miejsce i jest dostępna pod nowym adresem; każde pytanie o nią powinno być kierowane pod nowy adres. Ten komunikat jest szczególnie istotny w kontekście optymalizacji i przekierowań do nowych adresów z zachowaniem mocy linków.
  • 302 (Found) – strona (jakiś dokument/plik) została odnaleziona, ale znajduje się pod innym adresem; każde pytanie o nią powinno być kierowane w pod stary adres. To nie jest dobry komunikat z perspektywy pozycjonowania.

Strony WWW z obsługą błędów

Komunikaty o błędach to doskonała okazja, aby wyświetlić naszą treść wraz z odnośnikami do innych obszarów serwisu. W ten sposób użytkownik nie pozostaje na lodzie, może podjąć próbę przejścia na stronę główną lub gdziekolwiek indziej. Wszystko zależy od tego, co znajdzie się na takiej stronie – możemy na niej umieścić logotyp, menu, a nawet mapę witryny dla użytkowników. Robot indeksujący także skorzysta z dedykowanej strony i będzie mógł podążać za odnośnikami. Oczywiście wszystko zależy od rodzaju błędu. Jeśli są to poważne problemy z działaniem serwera, to dalsza nawigacja jest wykluczona.

Nie wszystkie komunikaty wymagają dedykowanej strony z obsługą błędu. Wystarczy, że skupimy się na tych, które pojawiają się najczęściej. Są to z reguły błędy aplikacji i serwera: 404, 500, 503 i 504. W praktyce wystarczy jednak przygotować starannie stronę z obsługą błędu 404.

Budowa tego typu stron wymaga od nas podstawowej znajomości HTML i CSS. Tworzymy je podobnie jak statyczne strony HTML. Wewnątrz możemy umieścić kod PHP (skopiowany z plików wykorzystywanego motywu), na przykład odpowiedzialny za menu . Nazwa pliku powinna korespondować z numerem błędu, zaś dokument powinien być zapisany w rozszerzeniu shtml (przykł. 404.shtml).

W ten sposób możemy utworzyć szablon dla wielu stron błędów, a następnie zmodyfikować nieznaczenie jego treść i wygenerować pozostałe dokumenty. Tak przygotowany zestaw stron przesyłamy do głównego katalogu naszej aplikacji bądź do katalogu wykorzystywanego motywu.

Jeśli nie chcemy sobie brudzić rąk i zajmować się kodem HTML/CSS to warto skorzystać z dedykowanych wtyczek. Tego typu narzędzia wykorzystują standardowe strony WWW WordPressa, generowane po stronie panelu admina. Po utworzeniu takich stron, wtyczka osadza w nich odpowiednią treść. Zakres konfiguracji zależy od wykorzystywanej wtyczki.

Przykład niestandardowej strony z obsługa błędu 404.
Niestandardowa strona błędu zawiera komunikat, dyskretną wyszukiwarkę, grafikę na wesoło plus menu. Poza kadrem znajduje się logotyp i lista kategorii.

Ku obsłudze błędów!

Niezależnie od naszych kompetencji programistycznych warto rozważyć przygotowanie kilku stron obsługujących popularne błędy. W ten sposób wykorzystamy kolejny element naszego portalu WWW do pozycjonowania – przy okazji ułatwimy odwiedzającym interakcję z naszym serwisem.

Opublikowano