Log File Analyser a SEO

Content ułożony, backlink jest, above the fold załatany, anchory w linkowaniu wewnętrznym poprawione, to pozostaje już chyba tylko odcinać kupony, hm? Rzućmy okiem do logów serwerowych w kontekście SEO.

Logi, jakie możecie wygenerować w panelach klienckich swoich serwerów, albo po prostu pobrać z FTP’a, zawierają cenne informacje, nie tylko w kontekście backendowym, kontekście bezpieczeństwa, ale i SEO. W logach zapisywane są bowiem wszystkie ślady aktywności – także crawlerów – w tym rzecz jasna Googlebota. Logi możecie analizować ręcznie, na piechotę, ale operacyjnie to strata czasu, więc proces warto byłoby zautomatyzować – w naszym przypadku Screaming Frogiem Log File Analyserem.

Po zaimportowaniu logów, widok podstawowy Log File Analysera zawiera:

A: Podsumowanie zaimportowanego loga – liczbę aktywności botów w nim odnotowanym, liczbę błędów, średnią wielkość pobranych danych

B: Graficzną prezentację ilościową zdarzeń, aktywności botów

C: Rozkład kodów odpowiedzi serwera, tj. „dwusetek”, „trzysetek” i grup błędów, tj. 400 i 500,

D: Graficzny przekrój aktywności wszystkich botów – Googlebota desktopowego, Googlebota mobilnego, Yandexa, Binga i Baidu

Co z tym teraz zrobić? Przechodzimy do zakładki URLs: to widok, w którym spędzicie najwięcej czasu. Z tego widoku w łatwy sposób dowiecie się np., które podstrony są wywoływane najczęściej przez boty, z jaką częstotliwością i poznacie ich statusy.

Sprawdzicie, np. że Wasza strona nie ma pliku robots.txt, o który przy każdej sesji uporczywie upomina się Googlebot, albo że 20 linków wewnętrznych, które są często odwiedzane przez Googlebota zwracają błąd 404. Dzięki rejestracji odpowiedzi serwera możecie podejmować decyzje, czy podstrony z błędami 404 nie powinny być np. przekierowane na inne zasoby, np. odpowiadające im podstrony w architekturze informacji albo stronę główną.

Informację na temat błędów 404, od jakich odbijają się boty, możecie wykorzystać w dowolny sposób. W sklepach internetowych to może być świetna okazja do odzyskania części ruchu, ale i nierzadko – linkjuice’u, bo zdarza się, że błąd 404 nie wynika z błędów w architekturze informacji, czyli z linkowania wewnętrznego, a z braku dostępności do zasobów, kiedy źródłem bota jest zewnętrzna aktywność – np. link.

Rzecz jasna – błędy 404 wynikające z linkowania zewnętrznego do zasobów, które nie istnieją, są do wyłapania np. w Ahrefs, ale też nie wszystkie, bo przecież to też tylko narzędzie, więc nadal mamy do czynienia z danymi mocno pofragmentowanymi. Z kolei praca na danych, jakie dostarcza crawler samego Screaming Froga oraz dane z logów przeanalizowanych przez Screaming Froga SEO Log File Analysera pozwala na wyeliminowanie w zasadzie większości istniejących błędów 404 – kwestia próbki. Im większa, tj. próbka z 30 dni, a nie 2-3 dób, tym dokładniejsze dane.

Z tego widoku, tj. widoku URLs wyjmiecie także informację, które URL’e odbijają robota 301-ką. A to, dlaczego robot crawluje zasoby waszej strony, serwisu, sklepu korzystając z przekierowań 301, może być wypadkową tego, że np. zmieniliście adresację podstrony XYZ, ale w architekturze informacji nadal wisi stary link, „odbijany” właśnie 301-ką. A z kolei jako, że przekierowanie 301 nie przenosi mocy 1 do 1, to po prostu szkoda linkjuice’u. Odbijanie 301 linków wewnętrznych zdarza się często po wpięciu SSL’a, gdzie część adresów jest nadal wymuszana „na sztywno” na http i przekierowana 301-ką na https.

Z logów wyjmiecie też ciekawe niuanse, jak np. próby pozyskania linków w waszych serwisów przez osoby trzecie. I tak np. w jednym z analizowanych logów, na jednej ze stron klienckich odnotowaliśmy dużą aktywność robota na wynikach wewnętrznej wyszukiwarki, które wyglądały tak:

http://domena.pl/search.html?q=www.ymwears.cn
http://domena.pl/search/?q=www.ymwears.cn
http://domena.pl/search/?query=www.ymwears.cn
http://domena.pl/search?q=www.ymwears.cn

Jest to footprint, który pewnie w jakichś dziurawych skryptach pozwala na wygenerowanie aktywnego linka wychodzącego. Lata temu działało to z powodzeniem wobec części silników, na jakich stały strony rządkowe .gov – linki były generowane dynamicznie, były to linki dofollow, więc do podlinkowania zaplecza wystarczały w zupełności.

Skąd dowiedziałem się o takiej próbie pozyskania linków ze strony klienta? W logach widzę wzmożoną aktywność zarówno Google bota mobilnego, jak i desktopowego na tych adresach – skąd w ogóle Googlebot zna te adresy, skoro nawet ja nie miałem o nich pojęcia? Zajrzałem do Ahrefs i nie widzę, żeby pojawił się do tak wygenerowanych podstron backlink z serwisów zewnętrznych, więc co prawdopodobne – albo te adresy były pingowane, albo linkowane serwisami, które mają zablokowany dostęp do botów Ahrefsa i Majestica – no bo aktywność bota na tak wygenerowanych adresach nie wzięła się z niczego.

Dane w Log File Analyserze możecie filtrować ze względu na boty, a w kolejnych zakładach znajdziecie też informacje uzupełniające – dane o user agentach, najczęściej crawlowanych zasobach (zakładka Directories), a także adresach IP hostów poruszających się po Waszej stronie i kilka innych.

Czy analiza logów to wobec tego must have każdej kampanii SEO? Kwestia zasobów, priorytetów i wyzwań. Im większy site, tym analiza logów może okazać się cenniejszym zasobem informacji. Ten materiał to rzecz jasna wstęp do pracy na logach, a nie poradnik how-to, bo w tym zbyt wiele byłoby kontekstów i akapitów „to zależy”. Logi w kontekście SEO to przede wszystkim doskonała mapa „rozjazdowa” crawlera, która pozwala na optymalizowanie crawl budgetu, aby wycisnąć ostatnie soki z każdej sesji Googlebota na Waszych stronach.

Tymczasem dzięki za uwagę, mówił do Was Adrian Pakulski Paq, do następnego, cześć.