Co dokładnie znaczy mobile-first

Google zapowiedział tę zmianę w 2016 roku, a pierwsze witryny zaczął przenosić w 2018. Mechanizm jest prosty: zamiast robota reprezentującego przeglądarkę na komputerze, stronę odwiedza i renderuje Googlebot na smartfony. To, co ten robot zobaczy, staje się materiałem do indeksowania, oceny treści i ustalania pozycji — również dla użytkowników szukających na komputerze.

Dwa nieporozumienia warto od razu wyprostować. Pierwsze: mobile-first nie oznacza, że Google przestaje pobierać wersję komputerową. Odwiedza ją nadal, tylko rzadziej i nie ona jest podstawą. Drugie: to nie jest kara ani preferencja dla stron mobilnych. To zmiana źródła danych.

Warto też pamiętać, jak długo to trwa. Serwisy uruchomione od połowy 2019 roku były indeksowane w ten sposób od początku, bez żadnego przejścia. Jeśli Twoja strona istnieje od tamtego czasu, prawdopodobnie nigdy nie była indeksowana inaczej.

Na jakim etapie jest przenoszenie witryn

Historia terminów jest tu pouczająca. Google najpierw zapowiedział, że wszystkie strony przejdą na mobile-first do września 2020 roku. Potem przesunął ten termin na marzec 2021. A pod koniec zeszłego roku po prostu zdjął datę końcową, tłumacząc, że część witryn wciąż nie jest gotowa i napotyka problemy techniczne, których nie da się rozwiązać na sztywnym harmonogramie.

Stan na dziś jest więc taki: zdecydowana większość serwisów jest już indeksowana mobilnie, ale nie wszystkie i Google nie podaje, kiedy to się domknie. Praktyczny wniosek jest jeden — nie zakładaj niczego na podstawie ogólnych zapowiedzi, sprawdź swoją stronę.

Zdejmowanie terminu nie zmienia natomiast kierunku. Nie ma scenariusza, w którym ktoś na tym poprzestanie i wróci do indeksowania wersji komputerowej. Jeśli Twój serwis należy do tej mniejszości, która wciąż jest indeksowana po staremu, warto to traktować jako czas pożyczony na przygotowania, a nie jako trwały stan.

Gdzie to sprawdzić

Są dwa miejsca w Search Console, które odpowiadają na to pytanie wprost, i warto znać oba.

• Ustawienia usługi — sekcja dotycząca indeksowania pokazuje, który robot jest głównym robotem indeksującym dla Twojej witryny. Jeśli widnieje tam robot na smartfony, przejście się dokonało.

• Sprawdzanie adresu URL — dla konkretnej podstrony zobaczysz, którym agentem Google ją pobrał, a w zrzucie wyrenderowanego kodu HTML dokładnie to, co robot z niej odczytał. To najważniejsze narzędzie w całej tej analizie.

Do tego dochodzi test optymalizacji mobilnej, który odpowiada na inne pytanie — czy strona da się wygodnie obsłużyć na telefonie — oraz raport o obsłudze na urządzeniach mobilnych w Search Console, zbierający problemy z czcionką, odstępami i elementami klikalnymi dla całego serwisu.

Sam mam prostą zasadę przy audytach: porównuję wyrenderowany kod HTML z narzędzia do sprawdzania adresu z tym, co widzę w przeglądarce na komputerze. Wszystko, co jest po prawej i nie ma go po lewej, jest treścią, która nie istnieje.

Różnice, które kosztują pozycje

Najdroższy błąd to skrócona wersja mobilna. Bardzo długo dobrą praktyką było upraszczanie widoku na telefonie: krótszy opis, mniej zdjęć, ukryta tabela parametrów, wycięta sekcja z opiniami. Przy mobile-first indexing każde takie cięcie jest usuwaniem treści z indeksu.

Druga kategoria to metadane i znaczniki. Sprawdzam, czy tytuły i opisy są takie same w obu wersjach, czy dane strukturalne są obecne w wersji mobilnej, czy nie wkradł się tam znacznik zakazujący indeksowania i czy adresy kanoniczne prowadzą tam, gdzie powinny. Zdarza się, że wersja mobilna serwuje własny, przypadkowy kanoniczny — i to wystarczy, żeby wypadła z indeksu.

Trzecia to linkowanie wewnętrzne. Menu zwinięte na telefonie do trzech pozycji oznacza, że robot dostaje z tej strony trzy linki zamiast trzydziestu. Nawigacja fasetowa, paginacja i linki w stopce często wyglądają na telefonie zupełnie inaczej i to zmienia mapę serwisu, którą buduje Google.

Lazy loading, zakładki i skrypty

Odrębny temat, bo tu najłatwiej stracić treść nieświadomie.

Doładowywanie obrazów i sekcji przy przewijaniu jest jak najbardziej dopuszczalne, ale musi być zrobione tak, żeby robot je wywołał. Robot nie klika i nie przewija w sposób, w jaki robi to użytkownik. Jeśli treść pojawia się dopiero po zdarzeniu przewijania obsługiwanym własnym skryptem, prawdopodobnie nie zostanie zobaczona. Bezpieczne są mechanizmy oparte na atrybutach obsługiwanych natywnie przez przeglądarkę oraz doładowanie treści w kodzie strony, z ukryciem jej wizualnym.

Treść w zakładkach i rozwijanych sekcjach to inna sytuacja. Google potwierdzał wielokrotnie, że taką treść indeksuje normalnie i nie obniża jej znaczenia — o ile znajduje się ona w kodzie strony. Jeśli natomiast rozwinięcie zakładki dociąga treść zapytaniem do serwera, wracamy do problemu z akapitu powyżej.

Przy serwisach opartych w całości na JavaScripcie warto poświęcić chwilę na sprawdzenie, ile z treści widać w wyrenderowanym kodzie, a nie tylko czy strona się wyświetla. To dwie różne rzeczy.

Osobne adresy mobilne

Serwisy z osobną wersją pod adresem z przedrostkiem mobilnym mają dziś trudniej niż strony responsywne, ale nie jest to sytuacja bez wyjścia.

Trzy rzeczy muszą być spełnione. Zawartość obu wersji musi być równoważna — ta sama treść, te same znaczniki, te same dane strukturalne. Powiązania między wersjami muszą być zadeklarowane: wersja komputerowa wskazuje mobilną jako alternatywną, mobilna wskazuje komputerową jako kanoniczną. I obie wersje muszą być dostępne dla robota, bez blokad w pliku robots.txt.

Jeśli planujesz przebudowę, warto z tego układu wyjść. Responsywność nie jest wymogiem rankingowym, ale usuwa całą klasę problemów: nie ma dwóch zestawów treści do synchronizowania i nie ma ryzyka, że jedna wersja rozjedzie się z drugą przy okazji zwykłej aktualizacji.

Czym mobile-first nie jest

Na koniec rozdzielenie, które w rozmowach z klientami muszę robić najczęściej. Indeksowanie mobilne dotyczy tego, skąd Google bierze treść. Wygoda korzystania ze strony to osobna grupa sygnałów rankingowych.

Do tej drugiej grupy należą Core Web Vitals, przystosowanie do urządzeń mobilnych, bezpieczne połączenie i brak nachalnych okien przesłaniających treść. Na urządzeniach mobilnych ten zestaw sygnałów działa od zeszłego roku. Na komputerach jego wdrożenie ruszyło pod koniec lutego i Google potwierdził jego zakończenie na początku marca, więc od tego momentu wygoda korzystania ze strony jest brana pod uwagę również w wynikach desktopowych — z pomiarem prowadzonym osobno dla obu typów urządzeń.

Praktycznie oznacza to dwie odrębne listy zadań. Na pierwszej: zapewnić, że wersja mobilna zawiera pełną treść, znaczniki i linki. Na drugiej: poprawić szybkość i stabilność strony na obu typach urządzeń. Pierwsza decyduje, czy Google w ogóle ma co oceniać. Druga wpływa na to, jak ocenia — i jest zdecydowanie słabszym czynnikiem niż sama zawartość.