Mobile-Friendly Test: Jak zawstydzić Googlebota? Case Study

Michał | 23/01/2015 | 0 komentarzy

Mobile-Friendly Test: Jak zawstydzić Googlebota? Case Study

Celem tego testu było sprawdzanie, czy witryna nie będąca optymalnie zbudowana pod urządzenia mobilne może otrzymać w wynikach wyszukiwania, plakietkę Na komórki.

Nikogo nie namawiam do łamania wskazówek Google dla webmasterów. Celowe próby manipulacji wyszukiwarką mogą skończyć się nałożeniem kary. Działania miały cel edukacyjny i weryfikacyjny.

Testowy zestaw startowy:

  • Nieużywana domena – semthusiast.com (rejestracja 04/2014);
  • darmowy szablon HTML/CSS Magazine na licencji Creative Commons Attribution 2.5;
  • Podejrzenia i obserwacje SERPów mobilnych

Jak stworzyć witrynę przyjazną dla urządzeń mobilnych (w SERPach)?

Użyty do testów darmowy szablon HTML/CSS nie jest przystosowany dla urządzeń przenośnych. Nie jest responsywny i ma 1024 pikseli szerokości.

Test zgodności z urządzeniami przenośnymi pokazywał następujące błędy:

  • Mała czcionka utrudnia czytanie tekstu
  • Okno robocze urządzenia przenośnego nie jest ustawione
  • Treść szersza niż ekran
  • Linki zbyt blisko siebie

 

Jak zatem zawstydzić (oszukać) smartfonowego Googlebota?

Podejście pierwsze

Prosty trik z wykorzystaniem warstwy w znaczniku DIV wypełnianej treścią przez wykonywany JavaScript. W tym przypadku jest to darmowy, open-source’owy kod do wyświetlania informacji o używaniu ciasteczek (ang. cookies) – można go pobrać ze strony Sitebeam Cookie Consent i dostosować do własnych oczekiwań. Utworzona warstwa dopasowuje się do urządzenia, na którym jest wyświetlana strona. Dzięki temu w teście zgodności dla urządzeń mobilnych dostajemy status strona przyjazna dla urządzeń przenośnych (patrz zrzut ekranu po prawej). Co więcej, wynik pobierania jako Komórkowy GoogleBot: Smartfon jest podobny (ponownie screen po prawej).

UWAGA! Test zgodności dla urządzeń mobilnych wykonywany jest dla strony, nie dla witryny – jeśli chcesz, aby wszystkie podstrony były mobile-friendly kod JS musisz wkleić na każdej podstronie. To umożliwi obejście kryteriów sprawdzanych przez GoogleBota i w efekcie ocenę pozytywną w narzędziu do testowania zgodności dla mobile. Z obserwacji także innych stron, podpowiem, że status „Przystosowana” zwracany przez narzędzie nie zawsze jest gwarancją otrzymania tej etykiety – w tym przypadku również tak było. Po pierwszej indeksacji (desktopowy GoogleBot) brak jest etykiety:

Brak etykiety po zastosowaniu JS
Brak etykiety po zastosowaniu JS

Podejście drugie

Postanawiam wprowadzić drobną modyfikację i rozszerzyć test:

  • Wersję angielską zostawiam bez zmian w kodzie
  • Do szablonu wersji polskiej /pl/ dodaję dodany metatag viewport w postaci:
    <meta name=”viewport” content=”width=device-width, initial-scale=1.0″ />

Metatag ten ustawia tzw. obszar widoczny i informuje przeglądarkę o sposobie sterowania wymiarami strony i jej skalowania. Jest to zatem mały krok w kierunku optymalizacji witryny pod kątem urządzeń mobilnych. Dodatkowo parametr width=device-width sprawia, że szerokość strony ma odpowiadać szerokości ekranu urządzenia – strona staje się zatem pseudo-responsywna. Na obu wersjach pozostałe trzy błędy nie zostały poprawione:

  • Mała czcionka utrudnia czytanie tekstu
  • Treść szersza niż ekran
  • Linki zbyt blisko siebie

 

Korzystamy z funkcji w Narzędziach dla webmasterów: Indeksowanie > Pobierz jako Google i wybieramy GoogleBot-Smartfon. Czekamy na przeindeksowanie w SERPach. Mija kilka dni i tym razem, po przeindeksowaniu mamy sukces:

Sukces! Mamy stronę mobile-friendly
Sukces! Mamy stronę mobile-friendly

Nasza witryna dostała etykietę „Na komórki”, co oznacza, że Google uznało ją za przyjazną i łatwą w użyciu na urządzeniach przenośnych. Co więcej, etykieta widnieje dla obu wersji językowych – polskiej i angielskiej! Nie ma potrzeby używania metatagu obszaru widocznego!
Sprawdziłem logi pod kątem aktywności GoogleBota – zarówno tego domyślnego (desktop, smartfony), jak i Googlebot-Mobile (różne typy urządzeń przenośnych). W logach widać odwiedziny następujących robotów:

  • DESKTOP: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
  • SMARTFON: Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

ani śladu Googlebot-Mobile (dla telefonów starszej generacji), czyli:

  • (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

Postanowiłem odczekać jeszcze kilka dni, aby zebrać dane w panelu narzędzi dla webmasterów – tutaj też nie widać żadnych problemów:

Nie wykryto żadnych problemów z obsługą.
Obsługa na urządzeniach przenośnych jest OK ;-)

Nie ma co – nasza witryna jest przyjazna pod kątem urządzeń przenośnych. Koniec, kropka ;-)

WNIOSKI

Podsumowanie testu w punktach:

  • GoogleBot Smartfon nie jest doskonały
    Jak widać powyżej łatwo go oszukać za pomocą JavaScriptu. Metoda nie do końca mieści się w kategorii Ukryty tekst i linki. Nie umieszcza tekstu poza ekranem o nie chowa go za obrazem, co jest stosunkowo łatwo algorytmicznie wykryć. Nakładamy warstwę DIV, która „emuluje” responsywność. Google pisze o podobnym błędzie (reklama pełnoekranowa)na stronie dla deweloperów.
  • Responsywność nie jest kluczem do sukcesu
    Umiejętność dopasowania się witryny do szerokości urządzenia, czyli nasza pseudo-responsywność, uzyskana dzięki metatagowi <meta name=”viewport” /> prawdopodobnie nie ma w narzędziach diagnostycznych większej wagi, aniżeli pozostałe kryteria oceny pod kątem przystosowania pod urządzenia mobilne. Zastosowanie dopasowującej się do szerokości urządzania warstwy DIV wystarczy, aby oszukać także GoogleBota dla smartfonów.
  • Weryfikacja kilkukrotna
    Zanim otrzymamy etykietę świadczącą o „przyjazności mobilnej” GoogleBot kilka razy odwiedzi naszą witrynę, aby potwierdzić ten fakt – w moim przypadku były to 4 wizyty w ciągu 5 dni. Dwa razy używałem funkcji Pobierz jako Google. Robot smartfonowy, aby zrenderować stronę pobierał także grafiki, pliki Javascript oraz style kaskadowe CSS.

OK, ale co nam to daje?

Wyświetlanie się etykiety może wpłynąć pozytywnie na współczynnik klikalności w wynikach wyszukiwania użytkowników korzystających ze smartfonów czy tabletów, ale również negatywnie na współczynnik odrzuceń i powrót do SERPów wszystkich, którzy poczuli się oszukani i których strona rozczarowała swoim wyglądem i brakiem dobrego user experience. Na chwilę obecną nie jestem jednak w stanie określić jakości ruchu z wyszukiwarki, bowiem domena jest świeża i bez ruchu. Nie rankowała też wcześniej w SERPach.

Domniemany wpływ czynników behawioralnych na ranking Google powoli staje się faktem, a kreatywne próby zwiększenia CTRów w sposób inny niż perswazyjne tytuły czy opisy, wdrożone dane strukturalne i rich snippety zawsze były elementem SEO. Biorąc pod uwagę fakt, że mobile już dawno przestał być pieśnią przyszłości czy modnym trendem, a obecnie jest wręcz koniecznością, możemy spodziewać się także innych, bardziej zaawansowanych technik oszukiwania smartfonowego GoogleBota.

Pomimo, że takie działania manipulują nie tylko robotami indeksującymi (w zasadzie tymi odpowiedzialnymi za renderowanie), ale też użytkownikami wyszukiwarki powyższa metoda w obecnej chwili wydaje się być w miarę bezpieczna – przynajmniej w odróżnieniu od cloakingu. Nie serwujemy przecież innej treści w zależności od klienta, a „jedynie” źle wyświetlamy warstwę DIV. To na pewno rozwiązanie na krótką metę – nowy użytkownik może nigdy nie stać się powracającym ;-) Niewątpliwie troska o satysfakcję użytkownika i zgodność z wytycznymi Google dla webmasterów przyniesie w dłuższej perspektywie więcej korzyści, a na pewno pozwoli spać spokojnie.

Aktualizacja 28/12/2015

Po kwietniowej aktualizacji Google związanej z wynikami mobilnymi, nazywanej przez branżę Mobilegeddon, dostosowanie stron do prawidłowego wyświetlania się na urządzeniach mobilnych miało być jednym z ważniejszych czynników wpływających na ranking strony. Po 6 miesiącach, koncern z Mountain View wytacza kolejne działa w celu „poprawy jakości wyników mobilnych”.

Najpierw, powołując się na własne analizy dotyczące satysfakcji (frustracji?) użytkowników, którzy zamiast treści aplikacji lub strony internetowej otrzymują inwazyjne reklamy typu interstitial, wprowadza update wymierzony właśnie w witryny, które umieszczać te formy promocji zmuszające do pobrania i instalacji aplikacji. Natomiast w w końcu października dochodzi wykrywanie i usuwanie niejawnych przekierowań na urządzeniach mobilnych.

Powyższe update’y nie zmieniły jednak sytuacji testowanej domeny, na której wyświetlam warstwę DIV. Póki co, witryna ma się dobrze i nadal jest oznaczona etykietą „Na Smartfony”. Co to oznacza? Wyskakujące na cały ekran powiadomienia dotyczące m.in. zapisów do newslettera szybko nie znikną ;-)

Metoda z DIVem nadal działa.
Metoda z DIVem nadal działa.

Gdzie więc troska o użytkownika?

Moim zdaniem, pod płaszczykiem tej szlachetnej troski, Google realizuje raczej swoją strategię uzależniania użytkowników mobilnych od swoich usług, skutecznego zabezpieczania się przed spadkiem wyszukiwań (wykonywanych bezpośrednio w tych aplikacjach, zamiast w wyszukiwarce), czyli de facto wpływów z AdWords. Kolejna teoria spiskowa? Nie sądzę.

Wystarczy pomyśleć o 80% udziale Androida w rynku systemów operacyjnych dla urządzeń przenośnych, płatnościach Android Pay oraz projektach typu App Indexing (indeksowanie treści aplikacji), AMP – Accelerated Mobile Pages (technologia optymalizująca wydajność stron mobilnych), FI (połączenie telefoniczne przez Wi-Fi) czy nawet trybie Oszczędzania danych w Chrome. Wszystko to obsługiwane lub kierowane przez serwery Google ;-)

Sharing is caring:
  •  
  •  
  •  
  •  
  •  
  •  

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *