O tym jak śledziłem Google Bot'a przez trzy miesiące i co z tego wynikło

---

Co jakiś czas na forach dotyczących SEO i mniej lub bardziej merytorycznych grupach na Facebooku wybuchają zagorzałe dyskusje o tym, jak bot Google – którego pieszczotliwie nazwijmy BG – działa, co widzi, czego nie widzi, jak to wpływa na pozycjonowanie. Jakie linki odwiedza, a jakie nie. Dzisiaj przedstawię wnioski z mojego trzymiesięcznego eksperymentu.

Przez ostatnie trzy miesiące, niemalże dzień w dzień, BG wpadał do mnie niczym kumpel na piwo. Czasem sam:

[02/09/2018 18:29:49]: 66.249.76.136 /page1.html Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
[02/09/2018 19:45:23]: 66.249.76.136 /page5.html Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
[02/09/2018 21:01:10]: 66.249.76.140 /page3.html Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
[02/09/2018 21:01:11]: 66.249.64.72 /page2.html Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
[02/09/2018 23:32:45]: 66.249.64.72 /page6.html Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

a czasem zabierał kolegów:

[16/09/2018 19:16:56]: 64.233.172.231 /page1.html Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko; Google Search Console) Chrome/41.0.2272.118 Safari/537.36

[16/09/2018 19:26:08]: 66.249.69.235 /image.jpg Googlebot-Image/1.0
[27/08/2018 23:37:54]: 66.249.76.156 /page2.html Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Jedno jest pewne – bawiliśmy się przednio w różne gry:

• graliśmy w ganianego, kiedy to sprawdzaliśmy, jak bardzo BG lubi biegać po przekierowaniach 301, chodzić po obrazkach, czy też uciekać przed canonicalami
• bawiliśmy się w chowanego w ukrytych treściach (których, jak mówili jego rodzice, nie toleruje i unika)
• trenowaliśmy survival – zastawiałem pułapki i sprawdzałem, czy się w nie złapie
• stawiałem przeszkody o różnych poziomach trudności i sprawdzałem, czy nasz miły przyjaciel poradzi sobie z ich obejściem

Jedno jest pewne – nie rozczarowałem się. Zabawa była przednia. Bardzo się zaprzyjaźniliśmy. I wierzę, że nasza znajomość będzie dalej się rozwijać.

Ale do rzeczy!

Zbudowałem stronę testową z bardzo merytorycznymi treściami o interplanetarnym biurze podróży świadczącym loty na dotąd nie odkryte planety w naszej i sąsiadujących galaktykach. Content wydawał się merytoryczny, jednakże był to stek bzdur i nonsensu. Sam się zaskoczyłem, jak bardzo poniosła mnie fantazja.

Struktura eksperymentalnej strony wygląda mniej więcej tak:

Zadbałem o unikalny content oraz o to, aby każdy anchor/title/alt oraz inne badane współczynniki były globalnie unikalne (wymyślone słowa). Dla ułatwienia w opisie eksperymentu nie będę posługiwał się nazewnictwem anchor cutroicano matestito tylko anchor1 itp.

Podczas czytania tego artykułu proponuje mieć otwartą powyższą mapę strony w drugim oknie.

Cześć pierwsza: First Link Counts

Tym, co chciałem między innymi przetestować w opisywanym eksperymencie SEO, była zasada first link counts – czy można ją obejść i jak wpływa ona na pozycjonowanie.

Jest to problem przez wielu specjalistów nie dostrzegany, szczególnie dający się odczuć w sklepach internetowych, w których menu nawigacyjne w znaczący sposób zaburza strukturę strony.

W większości sklepów mamy statyczne (widoczne w źródle strony), rozwijane menu, przez co mamy na przykład 4 linki do kategorii głównych i ukrytych 25 linków do podkategorii. Przy odwzorowywaniu struktury strony, BG widzi za każdym razem wszystkie linki (na każdej podstronie, gdzie jest menu), przez co przy odwzorowywaniu struktury wszystkie podstrony są tak samo ważne i moc jest rozłożona równomiernie, co mniej więcej wygląda tak:

Najczęstsza, według mnie błędna struktura serwisów internetowych

W powyższym przykładzie nie można mówić o strukturze, bo wszystkie kategorie są podlinkowane ze wszystkich stron, gdzie jest menu. Zatem zarówno strona główna, jak i wszystkie kategorie i podkategorie mają taką samą ilość linków przychodzących i moc całego serwisu przepływa po nich z taką samą siłą. Zatem moc strony głównej (a ta najczęściej jest źródłem największej mocy ze względu na ilość linków przychodzących) w tym przykładzie jest dzielona na 24 kategorie i podkategorie,więc każda z nich otrzymuje 4% mocy strony głównej.

Oczekiwana struktura strony:

Prawidłowa struktura strony uwzględniająca hierarchie

W tym przykładzie moc strony głównej jest dzielona na 4 i każda z głównych kategorii dostaje po 25% mocy strony głównej i w części przekazuje je podkategorią. Takie rozwiązanie daje też lepsze możliwości linkowania wewnętrznego, np. pisząc artykuł na sklepowego bloga i chcąc podlinkować jedną z podkategorii, link ten zostanie uwzględniony przez BG przy crawlowaniu strony. W pierwszym przypadku nie zostanie – ze względu na zasadę first link counts. Skoro link do podkategorii znajdowałby się wcześniej w menu strony, to ten w artykule zostanie zignorowany.

Podczas naszego eksperymentu SEO zacząłem od następujących czynności:

• Najpierw, na stronie page1.html podałem link do podstrony docelowej page2.html jako klasyczny link dofollow z anchorem: anchor1
• Następnie, w tekście na tej samej podstronie zamieściłem lekko zmodyfikowane odnośniki w celu weryfikacji, czy BG zechce po nich poskakać.

W tym celu przetestowłem następujące rozwiązania:

• Do strony głównej serwisu przydzieliłem jeden link zewnętrzny dofollow na frazę z anchorem typu URL (zatem żadne linkowanie zewnętrzne na określone frazy do strony głównej i podstron nie wchodzi w grę) – przyspieszyło to indeksowanie serwisu
• Poczekałem do momentu, kiedy page2.html zaczęła rankować na frazę z pierwszego linku dofollow (anchor1) pochodzącego z page1.html. Ta wymyślona fraza, ani żadna, którą testowłem nie znajduje się na stronie docelowej. Złożyłem, że jeśli inne linki będą działać to również page2.html będzie wyświetlać się w wynikach wyszukiwania na inne frazy z innych linków. Potrwło to ok. 45 dni. W tym miejscu udało mi się uzyskać pierwszy istotny wniosek:

Nawet strona, na której słowo kluczowe nie występuje w treści, ani w opisach meta title, ale jest podlinkowana badanym anchorem może z powodzeniem wyświetlać się w wynikach wyszukiwania wyżej niż strona, która zawiera to słowo, a która nie jest podlinkowana przy użyciu tego słowa kluczowego.

Co więcej, strona główna (page1.html) która zawierała badaną frazę, była najmocniejszą stroną w serwisie (podlinkowana z 78% podstron), a mimo to była niżej w wynikach wyszukiwania na badaną frazę niż podstrona (page2.html) podlinkowana badaną frazą.

Poniżej cztery przetestowane przeze mnie rodzaje linków występujących za pierwszym linkiem dofollow prowadzących do strony page2.html

Link do strony z kotwicą

Pierwszym z dodatkowych linków występujących w kodzie za linkiem dofollow był link z kotwicą (hashtagiem). chciałem sprawdzić, czy mimo tego, że link prowadzi do tej strony (page2.html), ale url jest zmieniony page2.html#testowyhash przy użyciu anchora anchor2 BG przejdzie przez link i zaindeksuje page2.html również pod frazą anchor2. Niestety BG, mimo upływającego czasu, nie chciał zapamiętać tego powiązania i nie przekazał mocy do podstrony page2.html na powyższą frazę, a co za tym idzie – w wynikach wyszukiwania na frazę anchor2 w dniu pisania tego tekstu występuje tylko podstrona page1.html – tam, gdzie znajdziemy to słowo w kotwicy linku. Przy wyszukiwaniu frazy testowyhash również nasza domena nie pojawia się w wynikach wyszukiwania.

Link do strony z parametrem

BG na początku zainteresowł się, czym jest ten śmieszny zlepek tekstu dolepiony do url:

page2.html?parameter=1

i anchor w linku: anchor3. Na początku testu zaciekawiony BG sprawdzł co 2-3 dni, o co może mi chodzić. Czy to jakaś zagadka? Aby uniemożliwić zaindeksowanie zduplikowanej treści pod innymi URLami canonical page2.html wskazywł na samą siebie. Zarejestrowłem w logach w sumie 8 przejść BG przez ten adres jednak wnioski są dość smutne:

• po dwóch tygodnia częstotliwość wizyt BG mocno zmalała, tak aby po 45 dniach obrazić się ostatecznie i więcej nie przejść przez ten link
• zarówno page2.html nie zaindeksowała się pod frazą anchor3 jak i parametr z url parametr1 również nie został zaindeksowany
• według search console ten link nie istnieje (nie jest zliczony w linkach prowadzących), ale jednocześnie fraza anchor3 występuje na liście fraz zakotwiczonych

Link do strony z przekierowania

Chciałem zmusić BG, aby trochę mocniej pobiegał po mojej stronie i tak: regularnie co kilka dni wchodził w link dofollow z anchorem: anchor4 na stronie page1.html prowadzący do page3.html, która przekierowuje z kodem odpowiedzi 301 na stronę page2.html. Niestety, tak jak w przypadku strony z parametrem, po 45 dniach nadal strona page2.html nie rankuje w wynikach wyszukiwania na frazę anchor4, która występowała w przekierowanym linku na page1.html.

Jednakże, w Google Search Console w sekcji tekst zakotwiczenia anchor4 jest widoczny i zaindeksowany. Co może wskazywać na to, że z czasem to przekierowanie zacznie działać tak, jakbym tego oczekiwał, czyli aby strona page2.html była widoczna w wynikach wyszukiwania na frazę anchor4 mimo tego, że jest to drugi link do tego samego miejsca docelowego w obrębie tej samej strony.

Link do strony przy wykorzystaniu powiązania kanoniczego

Na stronie page1.html umieściłem odnośnik do page5.html (link follow) z anchorem: anchor5. Natomiast na stronie page5.html znajdował się unikalny content oraz w części head wskazanie kanoniczne na page2.html

Test przyniósł następujące wnioski:

1. link na frazę anchor5 wskazujący na page5.html przekierowującą kanonicznie na page2.html nie został przeniesiony na stronę docelową (tak samo jak w pozostałych przypadkach)
2. strona page5.html została zaindeksowana mimo wskazania kanonicznego
3. strona page5.html nie pokazuje się w wynikach wyszukiwania na frazę anchor5
4. strona page5.html rankuje na frazy użyte w tekście na tej stronie, co wskazuje, że BG cłkowicie zignorowł wskazanie kanoniczne

Idąc dalej wysunąłbym tezę, że traktowanie rel=canonical do zapobiegania zaindeksowania niektórych treści (np. przy filtrowaniu) może po prostu nie działać.

Część druga: Crawl budget

Przy budowaniu strategii SEO najbardziej zależy mi na tym, aby BG tańczył tak, jak mu zagram, a nie odwrotnie. W tym celu weryfikuje procesy SEO na poziomie logów serwerowych (logi dostępowe i logi z błędami), co daje mi bardzo dużą przewagę. Dzięki temu wiem o każdym ruchu BG oraz o tym, jak reaguje na zmiany, których dokonuję w projekcie (przebudowy strony, wywracanie do góry nogami linkowania wewnętrznego, czy sposób wyświetlania informacji) w ramach działań SEO.

Jednym z moich zadań w czasie pracy nad projektem jest taka przebudowa struktury strony, aby BG odwiedzał tylko te URL, które będzie mógł zaindeksować, a my będziemy tego chcieli. W skrócie: w indeksie Google powinny się znajdować tylko strony, na których nam zależy z punktu widzenia SEO. Z drugiej strony BG powinien chodzić tylko po stronach, które chcemy, aby były w indeksie Google, co nie dla wszystkich jest oczywiste, np. jeśli w sklepie mamy zaimplementowane filtrowanie po kolorach, cenach, rozmiarach i odbywa się to poprzez manipulowanie parametrami w url np.

example.com/buty/sandalki/?color=red&size=40&price=200-250

może się okazać, że takie rozwiązanie – które pozwala BG chodzić po takich dynamicznych URL’ach – powoduje, że bot zamiast crawlować stronę:

example.com/buty/sandalki/

poświęca czas na przeczesywanie takich dynamicznie stworzonych URL (i możliwe, że ich indeksowanie), które nic nie wnoszą do pozycjonowania, a wręcz przeciwnie – mogą zostać uznane za treści niskiej jakości (thin content), co będzie skutkowało obniżeniem rankingu podstrony lub jeśli problem jest globalny – obniżeniem pozycji całej domeny.

W ramach naszego eksperymentu chciałem sprawdzić metody rzeźbienia struktury bez używania rel=”nofollow”, blokowania BG w pliku robots.txt, czy też zamieszczania części kodu html w niewidzialnych dla bota ramkach (zablokowany iframe) – stare, piękne czasy… kiedyś to było.

Przetestowłem trzy rodzaje linków zbudowanych w oparciu o js.

Link javascriptowy z eventem onclick

Prosty link zbudowany w oparciu o javascript:

anchor6

BG bez problemu przeszedł do podstrony page4.html i zaindeksował w wynikach wyszukiwania całą stronę page4.html. Podstrona nie rankuje w wynikach wyszukiwania na frazę anchor6 oraz ta fraza nie znajduje się w sekcji Teksty zakotwiczenia w Google Search Console. Świadczy to o tym, że link nie przeniósł mocy dalej.

Czyli podsumowując:

• klasyczny link javascriptowy pozwala google crawlować stronę i indeksować napotkane strony
• nie przenosi mocy – jest neutralny

Link javascriptowy z zewnętrzną funkcją

Podniosłem poprzeczkę i ku mojemu zaskoczeniu, BG pokonał przeszkodę niespełna 2h od publikacji linku.

anchor7

Do obsługi tego linku użyłem zewnętrznej funkcji, której zadaniem było zczytanie URL z data i przekierowanie – miałem nadzieję tylko użytkownika – do strony docelowej page9.html. Tak jak w poprzednim przypadku, strona page9.html została w pełni zaindeksowana.

Co ciekawe, mimo braku innych linków przychodzących page9.html była trzecią najczęściej odwiedzaną stroną przez BG w całym serwisie – zaraz po page1.html i page2.html

Tą metodę stosowałem już wcześniej do rzeźbienia struktur serwisów. Jak widać jest już nieskuteczna. W SEO nic nie trwa przecież wiecznie oprócz e-weblinka i panoramy firm.

anchor8

Link javascriptowy z kodowaniem

Nie dałem za wygraną i uznałem, że musi być sposób, aby skutecznie zamknąć przed BG drzwi. Stworzyłem więc prostą funkcję kodującą dane algorytmem base64, a sam odnośnik wyglądał tak:

W rezultacie BG nie był w stanie wykonać kodu javascriptowego, który odkodowywał zawartość atrybutu data-url oraz wykonywał przekierowanie. Zatem – eureka! Mamy sposób na kształtowanie struktury serwisu bez używania rel=nofollow tak, aby bot nie pełzł gdzie mu się żywnie podoba! W takim przypadku nie marnujemy crawl budgetu, co jest szczególnie ważne w przypadku dużych serwisów), a BG tańczy do muzyki, którą mu zagramy. Niezależnie, czy funkcja wprowadzona była na tej samej stronie w sekcji head czy też w zewnętrznym pliku js – w logach serwerowych, jak i w Search Console brak śladu po bocie.

Część trzecia: Ukryte treści

W ostatnim teście chciałem sprawdzić, czy treści znajdujące się na przykład w ukrytych zakładkach będą uwzględniane przez BG i indeksowane, czy też – tak jak od pewnego czasu powtarzają branżowi specjaliści – Google renderuje stronę i ignoruje ukryty tekst.

Cóż, chciałem to albo potwierdzić albo obalić. W tym celu w obrębie strony page12.html ze ścianą tekstu na ponad 2000 znaków ukryłem w arkuszu stylów CSS blok tekstowy zawierający ok 20% tekstu (400 znaków) i dodałem przycisk pokaż więcej, którego działania raczej tłumaczyć nie muszę. W obrębie ukrytego tekstu znajdował się link do page13.html z anchorem anchor9.

Co do tego, że bot jest w stanie wyrenderować stronę – nie ma wątpliwości. Obserwujemy to zjawisko zarówno w Google Search Console, jak i w narzędziu Google Insight Speed. Jednak moje testy wykazały, iż blok tekstu pokazywany po kliknięciu w przycisk “pokaż więcej” był w pełni zaindeksowany. Frazy użyte w tekście rankowały w wynikach wyszukiwania oraz BG podążał za ukrytymi w tekście linkami. Co więcej, anchory linków z ukrytego bloku tekstu są uwzględnione w Google Search Console w części Tekst zakotwiczenia i co może niektórych cieszyć strona page13.html zaczęła również wyświetlać się wynikach wyszukiwania na frazę anchor9.

Jest to szczególnie istotne w sklepach internetowych gdzie często treści znajdują się w ukrytych zakładach. Mamy teraz pewność, że BG widzi treści w ukrytych zakładkach, indeksuje je i przenosi moc z linków tam zawartych dalej.

I to na tyle. Jeśli myślisz, że ten eksperyment przyda Ci się w Twojej pracy proszę udostępnij ten post – niech inni też mają na zielono.