Michał Borzyszkowski – pytania po semKRK#18

Podczas semKRK#18 jednym z prelegentów, którzy zaprezentowali się naszej publiczności był Michał Borzyszkowski – Ekspert SEO i programista z ponad 10 letnim doświadczeniem. Michał jest zafascynowany branżą SEO i technicznymi aspektami pozycjonowania. Posiada doświadczenie z projektami od małych lokalnych firm do ogromnych międzynarodowych korporacji. Udało nam się namówić Michała na krótki wywiad, podczas którego odpowiedział na pytania zadawane na czacie podczas trwania naszej konferencji!

Co myślisz o gotowych systemach do audytowania stron pod kątem SEO? Warto się nimi sugerować, czy nic nie zastąpi specjalisty?

Nie ma gotowego narzędzia, które zastąpiłoby specjalistę. Są narzędzia, które pomagają specjaliście w audycie, tzw. crawlery. I nawet one powinny być tylko częścią kompleksowego audytu SEO, bo np. nie zauważą one, że mikrodane są nieprawidłowe czy są przez Google indeksowane dziwne adresy URL, do których nie ma już linków na stronie (a to jest podstawą działania crawlerów – linki na stronie).

Ile czasu trwa standardowo audyt SEO? Chodzi o ilość godzin roboczych.

Zależy… od tego jak duży jest serwis, jakie doświadczenie ma audytujący, jakie problemy będa na serwisie, itd. Zazwyczaj w ciągu 4-6 godzin można wykonać pełen audyt SEO (bez wytycznych, samo wypisanie błędów i ich powodów).

Czy nie wystarczy zeskanować części serwisu zamiast skanować całość przez 6 dni?

A jaka jest gwarancja na to, że w tej części będą próbki wszystkich podstron w serwisie? Że w 15 czy 20 zagłębieniu struktury nie ma dziwnych adresów, do których crawler nie dojdzie na mniejszej próbce? Jest to ryzyko.

Chcesz zobaczyć wystąpienie Michała na semKRK?

Zapraszamy na naszą platformę!

Jakie 3 największe błędy znalazłeś na serwisach?

Standardowo – noindex na całej witrynie lub zablokowanie strony w robots. Z tym chyba każdy się choć raz spotkał.

Inny ciekawy błąd znalazłem, jak strona była zrobiona na autorskim CMS, gdzie każda sekcja podstrony (np. menu górne, menu boczne, stopka, produkty, opisy, itd.) była dostępna pod swoim unikalnym adresem URL. Znaleźć to się dało tylko ręcznie sprawdzając site/GSC (crawler tego nie wykrył ponieważ w kodzie nie było linków href do nich).

Trzeci błąd to brak jakiegokolwiek komunikatu błędu (HTTP 404, 500) dla podstron, które są wyłączone w serwisie. Google te wszystkie adresy pamięta i po wielu miesiącach tych błędnych, ale działających stron może być kilkakrotnie więcej niż poprawnych.

Jakie są błędy krytyczne?

Ja rozdzielam błędy na: krytyczne, ważne, średnio ważne i dodatkowe. Krytyczne to są takie, bez poprawy, których pozycjonowanie to strata pieniędzy ponieważ nie da się uzyskać zwrotu z inwestycji. Dla przykładu noindex na całej witrynie, brak podstron dedykowanych pod ofertę/usługę, powolny serwer, witryna napisana w technologii, którą Google nie indeksuje poprawnie.

Możesz powiedzieć co to były za błędne strony w GSC? Czy są to podstrony gdzie w url są dodawane parametry?

I tak i nie. Tak dodawane były parametry ale te parametry były spowodowane tym, że Google zaindeksował błędne adresu URL, które na stronie były kilka minut i były wynikiem działań programistycznych. Potem z kilkunastu linków zrobiło się kilkanaście tysięcy. Drugim przypadkiem było usunięcie parametru GET z linków na stronie ale nie zostało ustawione przekierowanie by Google sobie je usunął (i nie było canonicala). Trzeci błąd polegał na tym, że w breadcrumb na jednej części serwisu link źle się generował (zamiast linku był teksty warninga z PHP). Kumulując to z serwisu, który ma 6 tys. poprawnych adresów Google badał 66 tysięcy.

Jak uszeregujesz kluczowe elementy w audycie? Załóżmy, że masz wyjątkowo mało czasu, od czego zaczniesz i na czym się skupisz?

Jak mam wyjątkowo mało czasu to włączyłbym crawlera a potem przeklikał się po stronie i sprawdził GSC. Szukałbym dużych błędów bo poprawa tych jest szczególnie istotna.

Należy jednak pamiętać, że czasem 10 drobnych błędów może bardziej szkodzić niż 1 większy.

Czemu netpeak speaker ponad screaming frogiem i sitebulbem?

Sitebulb testowałem kilka lat temu i jak dla mnie był mylący. Pokazywał błędy gdzie ich nie było, a nie wskazywał tam gdzie były. Może już to poprawili. Co do Screaming Frog to tutaj już moja osobista preferencja, NetPeak bardziej mi wizualnie i funkcjonalnie pasuje.

Jaki crawler warto użyć w serwisie kilka mln urli oraz w jaki sposób dzielić audyt, by nie obciążać sprzętu przy crawlerze desktopowym (przy dużym crawlu)?

Crawler desktopowy nie powinien obciążać komputera – jeśli tak jest to po prostu trzeba kupić lepszy komputer. Jedynie przy podliczaniu serwisu (jak już cały przeszedł) może pojawić się spowolnienie na kilka minut. 

Co do wyboru Crawlera – to już dowolna opcja. Plus crawlerów desktopowych nad online jest taki, że te pierwsze nie mają limitu ilości podstron crawlowanych. W sensie takim, że w narzędziach online płaci się za 100,000 lub 1ml przeanalizowanych urli, a za kolejne znów trzeba zapłacić.

Jakie macie sposoby na automatyzacja site i wyciągać te dane szybciej i więcej?

Dane… dane? Wyciągamy błędy, które potem analizujemy. A sama natura istnienia błędów powoduje, że trudno zautomatyzować audyt aby był skuteczny. Jeśli chodzi o przyspieszenie audytowania na ogromnych serwisach to z pomocą przychodzi crawler oraz sama wyszukiwarka i polecenie inurl w site.

Czy istnieje narzędzie do sprawdzania jaki link na stronie nie działa? Tak aby nie trzeba było ręcznie przeklikiwac całej strony? 

Tak, crawler internetowy. Każdy testowany przeze mnie crawler w błędach wskazywał zarówno niedziałające linki jak i takie linki co działają po przekierowaniu. Potem wystarczy tylko wyciągnąć listę stron, na których te linki widnieją.

Jak audytować strony w dużej mierze oparte o JS?

No i tu jest problem. Niektóre crawlery potrafią sobie z JS poradzić jednak tutaj będzie trzeba się głównie skupić na analizie ręcznej, site i GSC. Przy analizie ręcznej zamiast na źródło dokumentu patrzmy na kod w webdeveloperze. 

Jeśli w site i GSC jest bardzo mało danych a strona istnieje już długo to można użyć to jako mocny argument dla klienta za tym by zmienić stronę. Wszakże nie da się pozycjonować czegoś czego Google nie widzi – nie będzie tak, że pomiędzy 2 i 4 wynikiem będzie pusta przestrzeń zarezerwowana na naszą stronę.

Czy metodyka audytu różni się w przypadku stron opartych o popularne CMS-y (np. WordPress) a rozwiązaniach autorskich?

Metodyka jest ta sama. Natomiast wiele popularnych systemów jest w podstawowej wersji zoptymalizowana pod wyszukiwarki internetowe więc jest mniej tych błędów a audyt trwa krócej. 

Jak długo sprawdzałeś 3mln podstron?

Jeśli chodzi o 3 mln podstron z wskazanego przykładu to ich wszystkich nie sprawdzałem. Problem był tutaj z szybkością strony więc nie było potrzeby ich wszystkich weryfikować. 

Jeśli miałbym je sprawdzać to sprawdziłbym po kilka lub kilkanaście podstron danego typu (produkt, kategoria, marka, model, itd.) to zazwyczaj wystarcza. 

Jeśli pytanie jest o to ile crawlerowi zajęło przejście przez witrynę to on przez to nie przeszedł. Prędzej czy później serwer się wieszał, mógłbym ustawić 1 zapytanie na minutę ale wtedy program chodziłby 5,7 lat.

Serwis wielojęzyczny, domena .com/de czy .de? Inaczej, czy budować autorytet każdej domeny osobno czy postawić na .com i wersję językowe?

Dla Google nie ma większego znaczenia. Ma to czasem znaczenie dla CTR (np. niemcy jeszcze jakiś czas temu aktywnie unikali klikania w strony, które nie były niemieckie, w domenie .de). Może to też mieć znaczenie w administracji wewnątrz firmy.

Osobiście ja wolę osobne domeny. Łatwiej tym mi zarządzać.

Czy nie lepiej weryfikować indeksacje przez GSC zamiast przez site?

W site mamy polecenie inurl, które możemy w różnych konfiguracjach łączyć ze sobą. W GSC niestety możemy tylko jeden filtr na fragment URL’a ustawić na raz. Dodatkowo w GSC mamy dostęp do maksymalnie 1000 URL. 

Site w Google jest łatwiejszy, szybszy i posiada więcej danych.

Skąd wiedziałeś że chodzi o szybkość w wykrytych ale niezaindeksowanych?

Kilka rzeczy:

• liczba stron do zaindeksowania w GSC od kilku miesięcy się nie zmniejszała
• crawler bardzo szybko powodował, że hosting przestawał działać (gdzie na tych samych ustawieniach na 95% stron działa poprawnie)
• przeanalizowałem zakładkę w GSC “Ustawienia > Statystyki indeksowania” i porównałem dane z innym równie dużym serwisem

Po tym wniosek mógł być tylko jeden.

Odnośnie GSC, a co z analizą robotów indeksujących? Jeśli boty marnują na analizę HTML 80%, a na mobile niecałe 6%? To też chyba warto sprawdzić.

Przez HTML rozumiem “Wersja na komputery” (bo HTML a mobile w Statystykach indeksowania to dwa różne raporty). 

Kilkukrotnie zagłębiałem się w ten temat i nie znalazłem tam nic ciekawego co by można było użyć. Ale jeśli różnica jest 80 do 6 to warto to dokładniej sprawdzić. Obawiam się jednak, że wymagałoby to analizy logów na serwerze a to już ogromne poświęcenie czasu.

Wybrane prezentacje z semKRK#18 znajdziesz tutaj:

Zobacz prezentacje!