Logi serwera w kontekście SEO

Logi serwera, a dokładniej, plik dziennika, to automatyczny zapis wszystkiego, co dzieje się z naszą stroną. To taka szczegółowa “księga gości”, zawierająca mnóstwo informacji. Przydatna w rozwiązywaniu wielu problemów, w tym także tych dotyczących SEO. Jak dostać się do logów, co (i jak) można z nich wyczytać oraz kiedy warto się nad tym pochylić? Odpowiedzi poniżej!

W tej części SEO Samodzielnych odpowiadamy na pytanie jak sprawdzić logi serwera. Wyjaśniamy też, jak przebiega analiza logów i wskazujemy na przesłanki mówiące o tym, że warto ją przeprowadzić. Wymieniamy też wszystkie najważniejsze i najczęściej spotykane problemy ze stroną, które można wyczytać z pliku dziennika.

Spis treści:

1. Czym są logi serwera?
2. Co zawierają logi serwera?
3. Analiza logów serwera w SEO
4. Jakich informacji może dostarczać analiza logów serwera?
5. Jak sprawdzić logi serwera?
6. Jak rejestrować logi serwera?
7. W jakich narzędziach analizować logi serwera?
8. Przeglądanie logów serwera w praktyce
9. Ogólna analiza logów serwera

Czym są logi serwera?

Logi serwera (plik dziennika lub rejestr zdarzeń) to dane zawierające rejestr wszystkich żądań trafiających do serwera lub strony internetowej. Generowanie i zapisywane automatycznie, bezpośrednio w bazach danych lub jako osobne pliki o rozszerzeniu .txt.

Logi serwera są chronologicznym zapisem informacji, który pozwala na śledzenie działania strony, tworzenie statystyk, odnajdywanie błędów, a nawet wykrywanie prób włamań. O rejestrze zdarzeń (logach serwera) można myśleć jak o obowiązkowej księdze gości. Każdy, kto uzyskuje lub chce uzyskać dostęp do zasobów serwera (klient), zostaje do niej automatycznie wpisany.

Żeby teorii stało się zadość, log jako taki jest automatycznym zapisem tworzonym nie tylko przez serwer, ale i przez absolutną większość systemów informatycznych. Dzienniki zdarzeń tworzą też Twój komputer czy smartfon (a właściwie ich systemy operacyjne). Niezależne pliki logów generują nawet niektóre działające w nich programy / aplikacje.

Co zawierają logi serwera?

Wpis w logach powstaje za każdym razem, gdy klient (np. Googlebot) wyśle żądanie na adres URL hostowany na serwerze. Zapisywane są w nim informacje o wymienionych przez serwer i klienta w trakcie nawiązanego połączenia danych (może być to pobrana strona, ale i wyłącznie zwrócony na dane żądanie kod błędu).

Z czasem logi serwera stają się więc spisem historii wszystkich odebranych przez serwer żądań, a także zwróconych na nie odpowiedzi. W zależności od konfiguracji logi serwera mogą zawierać różne informacje. W pojedynczym wpisie zwykle znaleźć można jednak:

• adres IP klienta,
• datę i czas zdarzenia,
• żądany w zdarzeniu adres URL,
• kod odpowiedzi HTTP,
• liczba obsłużonych przez serwer bajtów,
• user-agent, czyli aplikacja klienta (program nawiązujący połączenie),
• adres odsyłający (HTTP referer), jeśli klient został skądś przekierowany.

Taki indywidualny wpis zawarty w logach serwera (jeden wiersz logu) może wyglądać np. tak:

192.168.0.1 - - [22/Jun/2022:14:28:42 +0200] "GET /podstrona.html HTTP/1.0" 200 1000"-" "Googlebot/2.1 (+http://www.google.com/bot.html)" "www.example.com"

Rozpisując powyższe dane zawierane w logach na ten przykład:

• 192.168.0.1 - jest adresem IP, z którego zostało wysłane żądanie odebrane przez serwer,
• [22/Jun/2022:14:28:42 +0200] - to data, czas i przypisana do niego strefa czasowa żądania,
• "GET /podstrona.html HTTP/1.0" - to metoda HTTP żądanego przekazania danych (GET), żądany plik (podstrona.html) oraz wersja użytego protokołu HTTP,
• 200 - to kod statusu odpowiedzi serwera,
• 1000 - to liczba bajtów przesłanych w odpowiedzi serwera,
• "Googlebot/2.1 (+http://www.google.com/bot.html)" - to user-agent, aplikacja kliencka,
• “www.example.com” - to adres odsyłający, z którego przekierowano żądanie.

Analiza logów serwera w SEO

W teorii analiza logów serwera pozwala prześledzić aktywność każdego klienta (przeglądarki, aplikacji czy bota), który uzyskał lub chciał uzyskać dostęp do zasobów strony. Wraz z reakcją serwera na zapytanie. W praktyce jednak analiza logów serwera pod pozycjonowanie skupia się głównie na analizie żądań botów internetowych oraz ogólnych statystyk.

Zwykle logi serwera sprawdza się gdy mamy problemy z indeksowaniem, w celu poszukiwania ich źródeł. Można też wspierać się nimi w wychwytywaniu i blokowaniu niechcianych botów, analizie struktury strony pod kątem dystrybucji crawl budget, a także w wychwytywaniu powstałych w niej błędów.

Na ich podstawie tworzyć można też statystyki kodów odpowiedzi zwracanych wyszukiwarce. Sporadycznie wykorzystuje się je również w walce z atakami na strony. Logi serwera można weryfikować też okresowo, dla upewnienia się, że wszystko jest w porządku, co jest szczególnie zalecane przy bardzo dużych serwisach.

Część błędów wykazywanych przez analizę logów serwera można wychwycić w Google Search Console, w raporcie Statystyki indeksowania. Raport ten jest co prawda ograniczony objętościowo i czasowo (wyłącznie do kilku ostatnich miesięcy). Mimo to i tak polecamy go wykorzystywać.

Raport Statystyki indeksowania sprawdza się świetnie jako pierwszy krok - przed właściwą analizą lub jako sprawdzany okresowo dodatkowy wskaźnik. Taki papierek lakmusowy, mówiący, czy wszystko jest w porządku, czy może jednak warto przyjrzeć się bliżej rejestrom.

Jakich informacji może dostarczyć analiza logów serwera?

Logi serwera mówią wiele, ale nie powiedzą Ci wszystkiego. Co więc można z nich wyciągnąć? Poniżej spisaliśmy chyba wszystkie przydatne w SEO informacje, jakich może dostarczyć analiza logów serwera.

Listę tę możesz potraktować jak spis treści książki pt. “logi”. Jeśli nie ma na niej tego, czego potrzebujesz, to prawdopodobnie nie znajdziesz tego poprzez analizę rejestru zdarzeń serwera.

Analiza logów serwera może wykazać:

• Czy i jak często Googlebot odwiedza Twoją stronę,
• Jakie adresy i z jaką częstotliwością odwiedza Googlebot,
• Czy wizyty Googlebota przebiegają poprawnie,
• Które katalogi i podstrony są odwiedzane przez Google wyjątkowo rzadko,
• A które najczęściej,
• Czy budżet indeksacji nie jest marnowany na nieistotne adresy URL,
• Lub na adresy zawierające w sobie parametry sesji,
• Jakie wyszukiwarki odwiedzają Twój serwis,
• Które wersje strony (mobile / desktop) i jak często są przez nie crawlowane,
• Jakie kody odpowiedzi zwraca serwer,
• Adresy zwracające błędy (kody błędów HTTP),
• Łańcuchy oraz pętle przekierowań,
• Zbyt często odwiedzane zasoby statyczne,
• Nagłe zmiany w dynamice indeksowania oraz ich przyczyny,
• Występowanie problemów z działaniem serwera lub strony (z wydajnością lub konfiguracją).

Jak sprawdzić logi serwera?

Zanim zaczniemy przeglądanie logów serwera, musimy się najpierw do nich jakoś dostać. Jak to zrobić? To zależy, ale logi to pliki przechowywane na serwerze, potrzebujemy więc dostępu do plików swojego serwera (np. przez Filezilla).

Jeśli nie mamy dostępu ani bezpośrednio do plików serwera, ani do panelu, to o kopię logów do analizy musimy poprosić. Zwracamy się do kogokolwiek, kto może nam je udostępnić. Może być to dostawca hostingu, web developer lub zespół IT (w zależności od tego, na jaką skalę działamy).

Dla przykładu załóżmy, że mamy dostęp do serwera przez FTP, co jest zdecydowanie najczęstsze. Gdzie szukać odpowiednich plików? Poniżej ścieżki katalogów dla najpopularniejszych konfiguracji:

• Apache - /var/log/access_log
• Nginx - logs/access.log
• IIS:- %SystemDrive%\inetpub\logs\LogFiles

W tym miejscu trzeba jednak wspomnieć, że nawet gdy mamy niezbędne dostępy, pobieranie kopii logów nie zawsze jest takie proste. Logi serwera mogą być niedostępne lub nawet zablokowane w konfiguracji serwera (nierejestrowane). Mogą też być ograniczone i zawierać wyłącznie ostatnie dane (nadpisywane).

Co więcej, dodatkowe problemy z pozyskaniem logów mogą pojawić się też przy wykorzystaniu CDN (content delivery network). Logi serwera mogą być również zbierane lub przechowywane w niestandardowych formatach oraz, o czym szczególnie warto pamiętać… mogą naprawdę sporo ważyć.

Zgodnie z tym wszystkim, warto przygotować się na to, że przeglądanie logów serwera może wcześniej wymagać współpracy z dostawcą hostingu / deweloperem lub zespołem IT.

Jak rejestrować logi serwera?

Nawiązując do przeszkód w pozyskiwaniu logów serwera, wtrącamy jeszcze dwa słowa na temat zbierania danych. Gdy okaże się, że logów nie ma, są zbyt szybko nadpisywane lub niepoprawne, a będziemy chcieli zacząć je poprawnie rejestrować. Czego warto wówczas dopilnować?

Przede wszystkim, upewniamy się, że logi serwera będą zawierać wszystkie najważniejsze, podstawowe dane o zdarzeniach (patrz: “Co zawierają logi serwera?”).

Drugą kwestią jest okres przechowywania logów. Użyteczny okres analizy mieści się zwykle pomiędzy 6 a 36 miesiącami. Konkretną wartość musicie określić jednak sami, w zależności od Waszych potrzeb i możliwości. Gdzieś trzeba wyznaczyć granicę, bo przestrzeń dyskowa nie jest za darmo.

Trzecia sprawa to agregacja logów z usług zewnętrznych (np. CDN-y), które dobrze jest uwzględnić dla uzyskania pełnego obrazu sytuacji w analizach.

No i ostatnie, ale równie ważne: ochrona danych osobowych i inne mogą dotyczyć logów przepisy prawa. Zwykle dostawca hostingu ma już w tej kwestii przepracowane rozwiązania. W razie wątpliwości polecamy jednak zwrócić się po poradę prawną do kogoś z odpowiednimi kwalifikacjami.

W jakich narzędziach analizować logi serwera?

Przejdźmy do praktyki. Nie będziemy zabraniać oczywiście i przeglądania manualnego, ale wiadomo, że logi serwera najefektywniej jest przeglądać w narzędziach. A w jakich najlepiej? My polecamy przede wszystkim Screaming Frog SEO Log File Analyser.

Pozwala on na szybkie i sprawne przeglądanie logów serwera. Generuje przejrzyste statystyki zdarzeń oraz umożliwia sortowanie danych m.in. wg. kodów odpowiedzi, adresów IP czy aplikacji klienckich. W wersji darmowej pozwala on na analizę 1000 linijek zdarzeń, w wersji płatnej nie ma limitu.

Zaawansowane, szczegółowe analizy można prowadzić też w Excelu lub Google Sheets. Za pomocą odpowiednich formuł, makr oraz z pomocą wtyczek, ale temat zbyt złożony, więc nie będziemy się w to zagłębiać.

Na potrzeby SEO absolutnej większości serwisów analiza z Log File Analyserem Screaming Frog będzie o wiele bardziej niż wystarczająca. Excela użyjemy tutaj co najwyżej do prostych porównań wyeksportowanych danych lub dodatkowego sortowania.

Jeśli chcecie analizować logi serwera w innych narzędziach, proszę bardzo: Deepcrawl, Ryte BotLogs, Semrush Log File Analyzer, Oncrawl Log Analyzer, Splunk - to tylko kilka popularniejszych. Do wyboru, do koloru :)

Przeglądanie logów serwera w praktyce

Wiemy już, czym są logi serwera oraz czego można w nich tak właściwie szukać, a także jak się do nich dostać oraz w jakich narzędziach je analizować. Zostaje więc czysta praktyka. Poniżej przygotowaliśmy zestawienie najczęstszych zagadnień do analizy logów wraz z praktycznymi instrukcjami weryfikacji.

Pracę z Screaming Frog Log File Analyser zaczynamy od zaimportowania do programu naszego pliku logów. Po prostu przeciągamy plik, folder plików lub skompresowany folder na obszar roboczy. Następnie wybieramy interesujący nas okres i obszar analizy w prawym górnym rogu.

Podstrony zwracające 404

Jeden z najłatwiejszych elementów do wychwycenia, czyli podstrony i inne zasoby zwracające 404. W otwartym projekcie analizy (pliku logów wgranym do Analysera Screaming Frog) wchodzimy w zakładkę “Response codes”. W “Filter” zaraz pod zakładką wybieramy “Client error 4xx”, a następnie sortujemy zakres danych - klikając na “Last response codes” w tabeli.

Listę możemy wyeksportować do pliku .csv celem dalszej analizy. Po kliknięciu na konkretny adres, w zakładce dolnej “Events” możemy też sprawdzić historię kodów zwracanych na żądania danego adresu.

Pozostaje sprawdzać skąd wzięły się znalezione w logach 404-ki i szukać rozwiązań. Może coś przestało działać, podstrona wygasła lub została ukryta (np. skończyły się produkty w sklepie internetowym)? A może coś zostało usunięte i nieprzekierowane, albo właśnie przekierowanie kieruje na nieprawidłowy lub usunięty adres?

Zanim podejmiemy kroki w celu przywrócenia adresów lub ustawienia przekierowań, zwróćmy jednak uwagę, czy podstrony zwracające 404 znajdują się w indeksie oraz jak często są odwiedzane. Jeśli są niezaindeksowane, a odwiedziny były jednorazowe, to najpewniej nie ma się czym przejmować.

Weryfikacja przekierowań

Zostajemy w obrębie zakładki “Response codes”, ale filtrujemy dane według “3xx”. Naszym oczom ukazuje się lista zwracanych przez serwer kodów przekierowań oraz ich typów. Szczególną uwagę zwracamy na przekierowania 302, szczególnie jeśli ich nie stosowaliśmy, trzeba będzie poprawić je na 301.

Tutaj idealnie jeśli dysponujemy listą stworzonych na naszej stronie przekierowań - wówczas możemy wyeksportować listę adresów do pliku i porównać ją z naszymi intencjonalnymi przekierowaniami. Wówczas zostaną nam tylko te, o których nie wiedzieliśmy, lub których nie ustawialiśmy - do indywidualnej weryfikacji.

Wszelkie podejrzane logi serwera dotyczące przekierowań możemy prześledzić też ręcznie. Wystarczy wejść pod docelowy adres żądania zwracającego kod 3xx.

Analiza nietypowych kodów HTTP

Tutaj proces wygląda analogicznie do powyższych. Ustawiamy właściwe filtrowanie, sortujemy, przeglądamy i szukamy “dziury w całym”. Nie będziemy się tutaj rozpisywać, bo w tym temacie mamy cały artykuł, który podlinkowaliśmy na początku artykułu.

Określanie najważniejszych podstron

Nie zawsze najważniejsze według nas podstrony w serwisie są odbierane za takowe przez roboty Google. Toteż, do zoptymalizowania struktury i wzmocnienia linkowania wewnętrznego warto poznać perspektywę wyszukiwarki, a w tym logi serwera są niezastąpione.

Do analizy wybieramy zakres wszystkich botów Google - “All Googlebots” w prawym górnym rogu. Wchodzimy w URLs i sortujemy malejąco wg. liczby zdarzeń, czyli “Num Events”. W ten sposób mamy listę najczęściej odwiedzanych przez Googlebota podstron - najistotniejszych w naszym serwisie w oczach wyszukiwarki.

Poza samymi URL-ami polecamy przyjrzeć się przede wszystkim dwóm elementom: kodom odpowiedzi oraz “Time of last response”, czyli dacie ostatnich odwiedzin. Takie najważniejsze podstrony powinny być odwiedzane często, więc data powinna być niedawna. Nie powinny też zwracać niczego innego niż 200 lub 301.

Adresy najistotniejsze dla Google mogą być punktem wyjścia do strategii linkowania wewnętrznego celem usprawniania indeksacji. To one będą też na szczycie listy przy migracji strony.

Listę tę można też odwrócić (sortując malejąco), by znaleźć podstrony odwiedzane przez boty najrzadziej (tutaj mogą pojawić się tzw. orphan pages), a istotne biznesowo, więc warte dodatkowego podlinkowania.

Przy dużych serwisach o rozbudowanej strukturze analizę tę można również rozbić na katalogi (zakładka Directories).

Marnowanie crawl budget

Zostajemy w obrębie podstron najczęściej odwiedzanych przez boty. Tym razem szukamy jednak w niej adresów, które nie powinny być odwiedzane, duplikatów, błędów czy zasobów, które wyszukiwarka mogłaby spokojnie pomijać. Innymi słowy, szukamy URL-i, które nie powinny być skanowane przez Google, a mimo to są odwiedzane i rejestrowane przez logi serwera.

Tutaj szczególną uwagę zwracamy na adresy zwracające kody 3xx, bo duża liczba odwiedzin botów może na nich sugerować występowanie pętli przekierowań. Podobnie jeśli trafi się jakieś 404 - może być to efekt zepsutych lub nieprawidłowych linków (wewnętrznych lub zewnętrznych).

Szczególnie w sklepach internetowych (ale nie tylko) warto przyglądnąć się też adresom z dodatkowymi parametrami. Te nie powinny być indeksowane i często są efektem błędnie skonfigurowanej paginacji podstron kategorii. Zdarzyć może się np. odwiedzanie przez Google nieistniejących podstron paginacji, ze względu na dodane do nich automatycznie linki wewnętrzne.

Odsiewanie niechcianych botów

Wracamy do przeglądu danych wg. “All bots” (prawy górny róg) i przechodzimy do zakładki “User Agents”. W tym miejscu szukamy wpisów pustych i wszystkiego, co wygląda podejrzanie. Mogą tutaj pojawić się szkodliwe boty, boty podszywające się pod wyszukiwarki oraz boty monitorujące z narzędzi SEO.

Adresy IP danych botów odczytujemy klikając na wybrany wpis User-Agent i wchodząc w dolną zakładkę “Events”. Blokować ruch możemy właśnie po adresacji lub według nazw, w .htaccess. Zablokować możemy też wszystkie żądania pochodzące od hostów z ukrytym User-Agent (bez nagłówka identyfikacyjnego).

Powolne podstrony

Logi serwera są też świetnym źródłem wiedzy o tym, jak sprawnie działa nasza strona. Wiadomo, PageSpeed ma znaczenie, ale dedykowane mu narzędzia pokazują uśrednione wyniki. Sytuacja, w której to tylko kilka podstron działa wyraźnie wolniej wcale nie jest rzadkością. Jak je znaleźć?

Wchodzimy w zakładkę “URLs” i sortujemy dane malejące wg. średniego czasu odpowiedzi “Average Response Time”. To samo możemy zrobić też, w zakładce “Events”, by wyłapać długie czasy odpowiedzi serwera na indywidualne żądania.

Przegląd prawidłowych podstron

Tutaj wracamy do analizy wg. kodów odpowiedzi, ale tym razem przyglądamy się podstronom poprawnym, czyli zwracającym kod 200. Przy niewielkich serwisach można po prostu przejrzeć URL-e w poszukiwaniu czegoś nietypowego. Niepotrzebnych w indeksie plików lub podstron.

Przy stronach większych polecamy jednak posłużyć się porównaniem wyeksportowanych danych z własną listą adresów, np. pochodzącą z pliku sitemap. Czasem zdarza się, że Googlebot otrzymuje poprawne odpowiedzi serwera na nigdy nieistniejące lub usunięte adresy. To samo może dotyczyć adresów z parametrami.

Ogólna analiza logów serwera

Szczegółowo logi serwera można analizować na setki sposobów (zauważcie, że obracaliśmy się właściwie w zakresie trzech-czterech zakładek programu do analizy logów). Pamiętajmy jednak, że czasem warto spojrzeć też na ogólne trendy.

Dużo powiedzieć mogą już same wykresy w zakładce “Overview” w Screaming Frog Log File Analyser, a szczególnie widoczne w nich nagłe wzrosty lub spadki. Widząc je, możemy zawężać analizę do poszczególnych dni i szukać przyczyn zmian. W ten sposób można znaleźć np. problemy techniczne z serwerem, wpływ aktualizacji Google na widoczność strony czy ataki na serwis.

Tak czy inaczej, logi serwera zbierać i prześwietlać warto. Jakby nie patrzeć, jest to najbardziej pierwotne źródło danych o tym, jak wyszukiwarka odbiera naszą stronę. To też właściwie nieskończone źródło możliwości w kontekście znajdowania kolejnych optymalizacji i usprawnień. Powodzenia w analizach!