Na telefonie strona zwykle przegrywa nie przez jeden wielki błąd, ale przez kilka drobnych niedopatrzeń: za małe przyciski, treść wystającą poza ekran, zbyt ciężkie zdjęcia i układ, który rozpada się przy 360 px. Dawny test mobile friendly Google został wycofany, ale potrzeba sprawdzenia wersji mobilnej nie zniknęła, bo od niej zależą UX, konwersja i to, jak strona jest rozumiana przez wyszukiwarkę. Poniżej pokazuję, jak dziś podchodzę do takiego audytu, jakich narzędzi używam i co naprawiam w pierwszej kolejności.
Najważniejsze rzeczy, które sprawdzam w wersji mobilnej
- Viewport musi być ustawiony tak, by przeglądarka nie renderowała strony jak szerokiego desktopu.
- Układ nie może wymuszać poziomego przewijania ani zoomowania, żeby odczytać treść.
- Przyciski, linki i formularze powinny dać się obsłużyć kciukiem bez frustracji.
- Mobilna i desktopowa wersja powinny pokazywać tę samą kluczową treść, a nie dwa różne serwisy.
- Wyniki z narzędzi Google i realnego telefonu muszą się zgadzać choćby w najważniejszych obszarach.
Jak działa test mobile friendly i co naprawdę sprawdza
W praktyce nie traktuję tego jako jednego testu, tylko jako zestaw pytań: czy strona mieści się w szerokości ekranu, czy da się ją obsłużyć kciukiem, czy nie trzeba zoomować i czy mobilna wersja pokazuje tę samą treść co desktop. Google używa wersji mobilnej do indeksowania i rankingu, więc na telefonie nie wystarczy, że strona „jakoś się otwiera”. Jeśli mobilny widok ukrywa część treści, blokuje zasoby albo zmienia znaczenie nagłówków, efekt w SEO i UX jest zwykle gorszy niż sugeruje sam wygląd. Najlepszy skrót myślowy jest prosty: dobry wynik oznacza nie tylko ładny ekran, ale też brak tarcia przy realnym użyciu.
Ja zwykle rozbijam ocenę na trzy poziomy: układ, interakcję i indeksowalność. Układ odpowiada za to, czy content nie rozjeżdża się na małym ekranie. Interakcja mówi, czy użytkownik może wygodnie kliknąć, wpisać dane i wrócić do treści bez walki z interfejsem. Indeksowalność sprawdza, czy robot widzi to samo, co użytkownik, i czy nic ważnego nie jest ukryte przed crawlem. Praktyka zaczyna się jednak od wyboru narzędzia, bo każde pokazuje inny wycinek problemu.
Jakie narzędzia zastępują dawny test i kiedy używać każdego z nich
Po wycofaniu starego narzędzia nie ma jednego magicznego zamiennika. Ja łączę kilka narzędzi, bo każde daje inny rodzaj odpowiedzi: jedno pokazuje renderowanie, inne performance, a jeszcze inne stan indeksacji. To oszczędza zgadywanie i szybciej prowadzi do konkretnej poprawki.
| Narzędzie | Co daje | Kiedy się przydaje | Ograniczenie |
|---|---|---|---|
| PageSpeed Insights | Pokazuje dane laboratoryjne i terenowe, a przy okazji podpowiada, co spowalnia mobile. | Gdy podejrzewasz problem z szybkością, stabilnością układu lub ogólnym doświadczeniem użytkownika. | Nie zastąpi ręcznego sprawdzenia na ekranie telefonu. |
| URL Inspection w Search Console | Pokazuje, jak Google widzi konkretny adres i czy może go zindeksować. | Gdy chcesz sprawdzić wersję renderowaną i stan indeksacji ważnej podstrony. | To nie jest pełny audyt UX, tylko wgląd w to, co widzi Google. |
| Lighthouse w Chrome | Ocena performance, SEO, dostępności i kilku klasycznych problemów mobilnych. | Gdy pracujesz nad frontendem i chcesz szybko wychwycić regresje. | To nadal test laboratoryjny, a nie realny telefon w ręku użytkownika. |
| Tryb urządzeń w DevTools | Pozwala symulować różne szerokości, orientacje i warunki widoku. | Gdy dopracowujesz CSS, breakpoints i zachowanie komponentów. | Nie pokaże wszystkich różnic między emulacją a rzeczywistym sprzętem. |
W praktyce zaczynam od DevTools, potem wchodzę w PageSpeed Insights, a na końcu sprawdzam URL Inspection dla podstron, które są już ważne biznesowo lub indeksacyjnie. Taki układ pozwala mi szybko wyłapać błąd, a nie tylko odczytać wynik. Gdy mam już zestaw narzędzi, przechodzę do krótkiej, powtarzalnej procedury.
Jak przejść audyt mobilny krok po kroku
Najgorszy błąd to patrzenie tylko na zrzut ekranu. Dobra kontrola mobilna musi sprawdzić zachowanie strony podczas przewijania, kliknięć, obracania ekranu i wczytywania treści. Ja używam zawsze tej samej kolejności, bo dzięki temu nic mi nie umyka.
- Otwieram stronę w Chrome i zwężam okno do szerokości ok. 360-390 px, żeby zobaczyć, czy layout nie łamie się na typowym telefonie.
- Włączam emulację urządzenia i przełączam widok między pionem a poziomem, bo niektóre błędy widać dopiero przy obrocie ekranu.
- Sprawdzam, czy w kodzie jest poprawny viewport, zwykle w formie
, bo bez niego przeglądarka potrafi zasymulować szeroki desktop. - Przechodzę przez kluczowe ścieżki: menu, wyszukiwarkę, formularz, przycisk CTA, cookie banner i wszystkie elementy sticky.
- Testuję bloki specjalne, które często psują mobile w treściach technicznych: tabele, galerie, osadzone wideo i długie fragmenty kodu.
- Odpalam PageSpeed Insights albo Lighthouse i zapisuję to, co naprawdę boli: za duże zasoby, słabe wyniki LCP, CLS albo INP, zbyt małe elementy klikane i konflikty układu.
- Jeśli podstrona jest ważna dla SEO, sprawdzam ją w URL Inspection i porównuję to, co widzę w przeglądarce, z tym, co widzi Google.
Na blogu technologicznym szczególnie pilnuję długich kodów, tabel porównawczych i przyklejonych nagłówków, bo to właśnie one najczęściej psują odczucie na małym ekranie. Sama procedura nie wystarczy jednak, jeśli architektura strony od początku utrudnia responsywność.
Responsive design czy osobna wersja mobilna
Jeżeli buduję nowy frontend, prawie zawsze wybieram responsive design. Jeden kod HTML, jeden adres i kilka sensownych breakpointów upraszczają utrzymanie, zmniejszają ryzyko rozjazdów i ułatwiają zachowanie spójnej treści. Inne podejścia mają sens, ale zwykle tylko wtedy, gdy stoją za nimi mocne ograniczenia legacy albo bardzo specyficzne wymagania produktu.
| Podejście | Plusy | Minusy | Kiedy ma sens |
|---|---|---|---|
| Responsive design | Najprostsze utrzymanie, jedna wersja treści, łatwiejsze testowanie. | Wymaga porządnego CSS i dyscypliny w projektowaniu komponentów. | Nowe projekty, portale contentowe, większość sklepów i aplikacji webowych. |
| Dynamic serving | Można serwować różne HTML-e dla różnych urządzeń bez zmiany adresu. | Łatwo o błędne wykrywanie urządzenia i trudniejsze debugowanie. | Gdy trzeba zachować jeden URL, ale backend musi podać inny markup. |
| Osobne adresy mobilne | Pełna kontrola nad układem i treścią na mobile. | Więcej pracy przy utrzymaniu, większe ryzyko niespójności i duplikacji. | Stare serwisy, które trudno przebudować od zera. |
Najważniejsze nie jest to, który model brzmi nowocześniej, tylko czy treść na mobile pozostaje kompletna i czy nie gubi się kontekst. Jeśli wersja mobilna skraca artykuł, chowa kluczowe sekcje albo usuwa fragmenty oferty, to z punktu widzenia użytkownika i wyszukiwarki robi się z tego pół-produkt. Dopiero wtedy opłaca się polować na błędy, które psują wynik i codzienną wygodę użytkownika.
Co najczęściej psuje wynik na telefonie
Większość problemów powtarza się zaskakująco podobnie. Zwykle nie chodzi o jedną spektakularną awarię, tylko o zestaw drobnych decyzji projektowych, które na desktopie wyglądają niegroźnie, a na telefonie robią bałagan.
- Brak poprawnego viewportu - przeglądarka zachowuje się tak, jakby strona miała szerokość desktopu, więc wszystko jest miniaturowe i trudne do czytania.
- Sztywne szerokości w pikselach - pojedyncza kolumna, szeroka tabela albo obrazek potrafią wymusić poziome przewijanie.
- Za małe elementy klikalne - Lighthouse flaguje tap targets mniejsze niż 48 x 48 px; w praktyce warto też pilnować co najmniej kilku pikseli odstępu między nimi.
- Zbyt ciasna typografia - przy dłuższych akapitach i kodzie najlepiej trzymać bazowy rozmiar tekstu na poziomie około 16 px i sensowną wysokość linii.
- Sticky header lub cookie banner - gdy przykrywa CTA albo zasłania połowę widoku, użytkownik zaczyna walczyć z interfejsem zamiast korzystać z treści.
- Za ciężkie zasoby - duże zdjęcia, fonty i skrypty uderzają w LCP, INP i ogólną płynność interakcji.
- Różne treści na desktopie i mobile - jeśli mobilna wersja chowa ważne sekcje, Google często widzi mniej niż użytkownik na dużym ekranie.
Warto pamiętać o jednym kompromisie: nie każde ukrycie treści jest błędem. Akordeony, zakładki i sekcje zwijane są w porządku, jeśli treść nadal istnieje w DOM i da się do niej dojść bez sztucznego klikania tylko po to, by „odkryć” podstawową informację. Dla stron technicznych szczególnie pilnuję też tabel i bloków kodu, bo to one najczęściej psują czytelność mimo poprawnego ogólnego layoutu.
Co sprawdzam ostatni raz przed publikacją
Na końcu robię krótki test na prawdziwym telefonie, a nie tylko w emulacji. To zwykle wystarcza, żeby zobaczyć rzeczy, których nie pokaże nawet dobrze skonfigurowany lab: zbyt nisko umieszczony przycisk, banner zasłaniający ekran, za długi blok kodu albo formularz, który po wpisaniu danych przeskakuje o kilka pikseli.
- Otwieram stronę w pionie i poziomie.
- Sprawdzam przewijanie jedną ręką i obsługę kciukiem.
- Testuję menu, wyszukiwarkę, formularze i główne CTA.
- Patrzę na wykresy, tabele, code blocki i embedowane media.
- Porównuję treść mobilną z desktopową, żeby nic ważnego nie zniknęło.
- Jeśli strona jest duża, wracam do PageSpeed Insights i pilnuję, czy wyniki mieszczą się w zielonym zakresie dla LCP, CLS i INP.
Jeśli strona przechodzi ten krótki audyt, zwykle znaczy to, że naprawdę nadaje się na telefon, a nie tylko wygląda dobrze na zrzucie ekranu. W praktyce wygrywa serwis, który daje się obsłużyć bez zoomu, bez nerwów i bez zgadywania, gdzie kliknąć następny element.
