Google Mobile Friendly Test: co sprawdzał i jak dziś ocenić stronę mobilną

Google Mobile-Friendly Test był bezpłatnym narzędziem Google, które oceniało, czy pojedynczy adres strony da się wygodnie obsługiwać na telefonie. Wskazywał między innymi tekst trudny do odczytania, elementy dotykowe położone zbyt blisko siebie i treść szerszą niż ekran.

Test użyteczności mobilnej nie był audytem całego SEO. Wynik dla jednego adresu nie oceniał jakości treści, linków prowadzących do domeny, konwersji ani wszystkich elementów serwisu. Właściciel strony powinien traktować dawny raport jako diagnozę mobilnego widoku testowanego adresu, a nie certyfikat widoczności w Google.

Warto rozdzielić trzy pojęcia. Responsywność oznacza, że układ strony dostosowuje się do szerokości ekranu. Użyteczność mobilna dotyczy tego, czy osoba korzystająca z telefonu może czytać treść i wykonać zadanie. Mobile-first indexing oznacza, że Google przede wszystkim wykorzystuje mobilną wersję treści do indeksowania i rankingu.

Google zaleca responsywny projekt, w którym strona udostępnia ten sam kod HTML pod tym samym adresem, ale może wyświetlać układ dostosowany do ekranu. Z perspektywy właściciela firmy oznacza to konieczność sprawdzenia nie tylko wyglądu strony głównej, lecz także szablonów i interakcji, z których korzystają klienci. Przydatne będzie również omówienie optymalizacji on-page, bo diagnoza mobilna obejmuje część technicznych elementów strony.

Google Mobile-Friendly Test nie działa od 1 grudnia 2023 roku, kiedy Google wycofał test, jego API i raport Mobile Usability w Search Console. Google podał, że mobilna użyteczność pozostaje ważna dla użytkowników, a do jej oceny można wykorzystywać między innymi Lighthouse.

Starsze poradniki mogą nadal pokazywać nieaktualny adres narzędzia, zrzuty ekranu lub przycisk w Search Console. Nie da się dziś odtworzyć wyniku dawnego testu w jego pierwotnej postaci. Jeśli strona z poradnika prowadzi do niedostępnego narzędzia, przejdź do Lighthouse i symulacji urządzeń w Chrome DevTools.

Nie należy szukać starego statusu "przyjazna dla urządzeń mobilnych" w raportach Search Console. Google usunął raport Mobile Usability, a inspekcja adresu URL służy innym celom: pokazuje dane o stronie znanej Google i pozwala wykonać test na żywo pod kątem indeksowania.

Dawne narzędzie można więc zastąpić zestawem kontroli, a nie jednym nowym testem o identycznym wyniku. Lighthouse bada wybrane aspekty strony, Device Mode pomaga ocenić zachowanie układu, a inspekcja URL sprawdza widok Google. Właściciel witryny powinien dodać do tego sprawdzenie działania na telefonie, szczególnie jeśli strona zawiera koszyk, formularz lub menu rozwijane.

Jeśli poza diagnozą potrzebujesz stałej pracy nad widocznością i techniczną kondycją serwisu, prowadzenie działań pozycjonowania SEO może objąć analizę problemów oraz zaplanowanie kolejnych napraw.

Lighthouse ocenia wydajność, dostępność, dobre praktyki i SEO, Chrome DevTools symuluje widok urządzenia, a Search Console pokazuje dane o indeksowanej wersji adresu. Te narzędzia odpowiadają na różne pytania i nie zastępują wzajemnie swoich wyników.

Tabela pokazuje, którego narzędzia użyć zależnie od problemu, który chcesz sprawdzić. Inspekcja URL wymaga dostępu do usługi Search Console dla danej witryny.

Wniosek: dobierz narzędzie do pytania diagnostycznego, a ocenę obsługi uzupełnij testem na telefonie.

W Chrome otwórz stronę, wybierz "Inspect" lub "Zbadaj" z menu kontekstowego i przejdź do panelu Lighthouse. Uruchom audyt mobilny dla danego adresu i sprawdź osobno zalecenia, które dotyczą wydajności, dostępności oraz SEO. Błąd audytu jest wskazówką do weryfikacji, a nie automatycznym dowodem, że konkretna zmiana w kodzie rozwiąże problem.

Aby włączyć symulację, otwórz DevTools i wybierz przycisk "Toggle device toolbar" na pasku narzędzi. Wybierz urządzenie z listy albo tryb Responsive, a następnie zmień szerokość widoku. Device Mode może symulować viewport, obciążenie procesora i sieci, ale działa na komputerze, a nie na procesorze telefonu. Chrome zaleca użycie prawdziwego urządzenia, gdy zachowanie strony zależy od sprzętu lub przeglądarki.

W Search Console wpisz pełny adres URL w pasku inspekcji na górze ekranu i uruchom test na żywo. Możesz otworzyć "Wyświetl przetestowaną stronę", aby sprawdzić wyrenderowany HTML i zasoby. Dane z indeksu i wyniki testu na żywo to odrębne widoki; test na żywo nie potwierdza, że strona jest już zaindeksowana ani jaką wersję kanoniczną Google wybierze.

Rzetelny test mobilny obejmuje ważne typy stron, różne szerokości widoku i pełne czynności użytkownika. Szerokości wybierz na podstawie urządzeń widocznych w analityce albo typowych rozmiarów, z których korzystają klienci; traktuj je jako scenariusze testowe, a nie oficjalne progi Google.

Zacznij od adresu, który realizuje cel biznesowy: strony usługi, karty produktu, koszyka lub formularza kontaktowego. Dla każdej ścieżki zapisz adres, wybraną szerokość, czynność oraz wynik. Taki zapis pozwala powtórzyć ten sam test po wdrożeniu poprawki.

Sprawdź po kolei:

1. Otwórz stronę w Chrome DevTools i włącz Device Mode. W trybie Responsive zmieniaj szerokość, a następnie sprawdź stronę na fizycznym telefonie.
2. Otwórz menu i przejdź do najważniejszej podstrony. Sprawdź, czy menu można zamknąć i czy nie blokuje przewijania treści.
3. Przewiń stronę od góry do dołu. Poszukaj poziomego przewijania, uciętych nagłówków, nachodzących na siebie elementów i treści ukrytej poza ekranem.
4. Dotknij przycisków, linków, filtrów i elementów rozwijanych. Potwierdź, że właściwa akcja wykonuje się po pojedynczym dotknięciu.
5. Wypełnij formularz poprawnymi danymi, a potem powtórz próbę z brakującym lub błędnym polem. Sprawdź, czy błąd pojawia się przy polu, wskazuje sposób poprawy i nie kasuje już wpisanej treści.
6. Podczas wpisywania do formularza sprawdź, czy klawiatura ekranowa nie zasłania aktywnego pola ani przycisku wysłania.
7. Zamknij baner zgód, czat i pasek promocyjny, a następnie sprawdź, czy te elementy nie zasłaniają treści lub przycisku działania.
8. Otwórz raport Lighthouse i inspekcję URL w Search Console dla tego samego adresu. Zapisz oddzielnie wynik audytu i stan indeksowania.

Wizualne dopasowanie nie wystarcza, jeśli najważniejsza akcja nie działa. Testy wykonuj na kilku rodzajach podstron, bo błąd w szablonie produktu może występować na wielu kartach, a błąd formularza może dotyczyć wyłącznie strony kontaktowej.

Perspektywa KC Mobile. Z naszych wdrożeń wynika, że część usterek ujawnia się dopiero po rozwinięciu menu, wybraniu wariantu produktu albo wywołaniu błędu formularza. Zalecamy sprawdzać pełną drogę do kontaktu lub zakupu, a nie tylko pierwszy ekran.

Najpierw napraw problem, który uniemożliwia czytanie strony lub wykonanie działania, a dopiero później mniej uciążliwe niedogodności. Raport Lighthouse ułatwia wskazanie obszaru do kontroli, ale przyczyny błędu trzeba potwierdzić w kodzie i podczas korzystania ze strony.

Tabela łączy objaw z możliwą przyczyną, skutkiem dla klienta i pierwszym krokiem diagnostycznym. Przyczyny są hipotezami do sprawdzenia, ponieważ ten sam objaw może wynikać z różnych elementów strony.

Wniosek: diagnozę zacznij od objawu widocznego dla użytkownika, a działanie naprawcze dobierz po potwierdzeniu przyczyny.

Jeśli inspekcja URL zgłasza problem z pobraniem lub renderowaniem strony, sprawdź widok "Wyświetl przetestowaną stronę" i listę załadowanych zasobów. Ustal, czy Google może pobrać CSS, skrypty i obrazy potrzebne do wyświetlenia istotnej treści. Google zaleca, aby zasoby strony były dostępne dla robota i aby podstawowa treść nie wymagała kliknięcia lub wpisania danych przez użytkownika.

Jeśli Lighthouse wskazuje problem wydajności, otwórz konkretne zalecenie i sprawdź, który zasób je wywołał. Ciężki obraz można zoptymalizować lub dostarczyć w odpowiednim rozmiarze, ale zmiana serwera nie rozwiąże problemu, jeśli głównym obciążeniem jest skrypt zewnętrzny. Wprowadzaj zmiany pojedynczo i porównuj raporty w zbliżonych warunkach.

Wpływ na sprzedaż lub liczbę zapytań ocenisz przez sprawdzenie ścieżki do celu, a nie samego wyniku punktowego. Jeżeli przycisk kontaktu jest widoczny i działa, problem może mieć mniejszy wpływ na konwersję niż blokada formularza. Zapisuj, czy klient może znaleźć ofertę, wypełnić pola, zobaczyć komunikat potwierdzający i przejść do kolejnego kroku.

Sam wynik testu mobilnego nie gwarantuje wzrostu ani spadku pozycji, ponieważ Google ocenia strony z użyciem wielu sygnałów. Mobile-first indexing opisuje sposób, w jaki Google przede wszystkim pobiera i wykorzystuje mobilną wersję treści, a nie osobny wynik testu użyteczności.

Google wskazuje, że systemy rankingowe uwzględniają różne aspekty doświadczenia strony, ale nie istnieje jeden sygnał page experience. Mobilna użyteczność może pomóc osobom korzystającym ze strony i jest częścią szerszej oceny jakości doświadczenia. Dobry wynik w Lighthouse ani w raporcie Core Web Vitals nie gwarantuje wysokiej pozycji.

W diagnozie rozdziel trzy pytania:

• Czy osoba korzystająca z telefonu może wygodnie przeczytać treść i wykonać działanie?
• Czy Googlebot może pobrać i wyrenderować mobilną zawartość?
• Czy konkretny adres znajduje się w indeksie Google?

Na pierwsze pytanie odpowiadają Device Mode i test na telefonie. Drugie możesz częściowo sprawdzić w inspekcji URL, uruchamiając test na żywo i otwierając wyrenderowaną stronę. Trzecie wymaga sprawdzenia danych indeksu w Search Console. Te wyniki opisują odrębne sytuacje.

W inspekcji URL sprawdź adres kanoniczny wybrany przez Google w danych indeksu. Test na żywo nie przewiduje wyboru adresu kanonicznego, więc nie traktuj go jako potwierdzenia kanoniczności. Przy analizie widoczności wykorzystaj raport skuteczności Search Console oraz szerszą strategię optymalizacji on-page.

Po wykryciu problemu napraw najpierw blokadę kontaktu lub zakupu, a następnie błędy wspólnego szablonu występujące na wielu stronach. Priorytet wyznacz na podstawie skutku dla klienta, liczby dotkniętych adresów i tego, czy istnieje proste obejście problemu.

Pracuj w tej kolejności:

1. Zapisz adres, urządzenie lub szerokość widoku, czynność i dokładny objaw.
2. Ustal, czy przyczyna leży w treści, CSS, JavaScript, wtyczce, integracji czy elemencie zewnętrznym.
3. Sprawdź, czy problem dotyczy jednego adresu, czy wspólnego szablonu wielu podstron.
4. Popraw źródło problemu, a nie tylko element widoczny na jednym ekranie.
5. Powtórz tę samą czynność na tym samym adresie i widoku. Następnie sprawdź pozostałe typy stron objęte zmianą.
6. Ponownie uruchom Lighthouse albo inspekcję URL, jeśli zmiana dotyczyła wydajności, renderowania lub dostępu Google.

Tabela pomaga ustalić kolejność prac na podstawie wpływu problemu.

Wniosek: rozwiąż najpierw problem, który blokuje działanie klienta lub powtarza się na największej liczbie ważnych stron.

Po wdrożeniu zapisuj wynik przed i po poprawce dla tych samych adresów oraz warunków testu. Jeśli strona ma dynamiczne elementy, uwzględnij stan po załadowaniu skryptów, otwarte menu i błędny formularz. Do sprawdzenia tego, jak mobilne problemy łączą się z indeksowaniem, możesz przeczytać poradnik o mobile-first indexing.

Jeśli problem obejmuje wiele podstron, wydajność i widoczność organiczną, zespół może potrzebować diagnozy całego serwisu oraz kolejności prac. Pozycjonowanie SEO dla strony firmowej może obejmować analizę techniczną, treści i priorytety napraw wspierających widoczność. Zakres działań dobiera się do rodzaju błędów i celów witryny.

• Test optymalizacji mobilnej: jak sprawdzić stronę i znaleźć problemy
• Google Search Quality Guidelines na Twojej stronie: praktyczna checklista SEO
• Dlaczego strona nie rośnie w Google? Diagnoza krok po kroku
• Czy warto stosować emoji w SEO? Gdzie pomagają, a gdzie szkodzą