Jak sprawdzić wersję mobilną strony po wyłączeniu Google Mobile-Friendly Test
Sprawdzenie wersji mobilnej strony po wyłączeniu Google Mobile-Friendly Test najlepiej zrobić czterema metodami naraz: Lighthouse (w Chrome DevTools albo przez PageSpeed Insights) daje szczegółowy audyt w emulacji telefonu, tryb urządzenia w DevTools pokazuje stronę przy szerokości 360–430 px, prawdziwy telefon wyłapuje to, czego nie widać w emulacji, a nasz test optymalizacji mobilnej w kilka sekund i bez rejestracji analizuje kod strony: meta viewport, media queries, stałą szerokość, mały tekst i małe przyciski — oraz pokazuje zrzut ekranu iPhone’a.
Poniżej: co dokładnie wyłączył Google, czego używać zamiast tego, lista kontrolna na 15 minut i gotowe poprawki najczęstszych problemów.
Co się stało z Google Mobile-Friendly Test
W grudniu 2023 roku Google wyłączył jednocześnie trzy rzeczy: sam test optymalizacji mobilnej, jego API i raport „Obsługa na urządzeniach mobilnych” w Search Console. Stary adres search.google.com/test/mobile-friendly przekierowuje teraz na stronę o Lighthouse — to oficjalny następca.
Zniknęło narzędzie, a nie wymaganie. Google nadal indeksuje strony robotem smartfonowym, więc wygoda na telefonie jest tak samo ważna jak wcześniej. Po prostu nie ma już gotowego werdyktu Google „strona jest zoptymalizowana / nie jest” i trzeba sprawdzać samodzielnie.
Czym sprawdzać teraz: porównanie metod
| Metoda | Co pokazuje | Wykonuje JavaScript | Kiedy używać |
|---|---|---|---|
| Lighthouse w Chrome DevTools | Audyt w emulacji telefonu: wydajność, dostępność, SEO, sprawdzone praktyki, w tym brak meta viewport | Tak, prawdziwa przeglądarka | Szczegółowa analiza jednej strony, także za logowaniem lub na localhost |
| PageSpeed Insights | Ten sam Lighthouse w chmurze plus dane prawdziwych użytkowników Chrome (LCP, INP, CLS), jeśli Google ma ich wystarczająco dużo | Tak | Szybkość i Core Web Vitals na telefonach |
| Tryb urządzenia w DevTools | Strona przy wybranej szerokości ekranu, z opcjonalnym spowolnieniem sieci i procesora | Tak | Wypatrzenie elementów wychodzących poza ekran, nachodzących na siebie lub nieklikalnych |
| Prawdziwy telefon | Prawdziwy dotyk, klawiatura, czcionki systemowe, paski przeglądarki | Tak | Ostateczne sprawdzenie formularzy, menu i wyskakujących okien |
| Nasz test mobilny | 8 sprawdzeń HTML i CSS z jawnymi wagami, ocena 0–100, zrzut iPhone’a | Nie | Szybki test dowolnego adresu, bez instalowania czegokolwiek |
Tryb urządzenia włącza się w DevTools ikoną telefonu i tabletu albo skrótem Ctrl+Shift+M (na Macu Cmd+Shift+M). Szczegóły znajdziesz w dokumentacji Chrome.
Jak sprawdzić wersję mobilną strony krok po kroku
- Zacznij od kodu. Przepuść stronę przez test optymalizacji mobilnej: brak viewport, kontener o szerokości 960–1200 px albo zablokowane powiększanie widać od razu, jeszcze przed otwarciem przeglądarki.
- Obejrzyj stronę w DevTools. Włącz tryb urządzenia i ustaw 360 px (popularne wąskie Androidy) oraz 390–430 px (nowsze iPhone’y). Przewiń całą stronę: czy pojawia się poziomy pasek przewijania, ucięty tekst, nachodzące bloki?
- Uruchom Lighthouse w trybie mobilnym. Karta Lighthouse → Device: Mobile → Analyze page load. Czytaj konkretne uwagi ze wskazaniem elementów, a nie tylko wyniki punktowe.
- Sprawdź szybkość w PageSpeed Insights. Jeśli nad raportem jest sekcja z danymi prawdziwych użytkowników, to właśnie widzi Google. Jeśli jej nie ma, strona ma za mały ruch z Chrome i trzeba kierować się wynikami laboratoryjnymi.
- Otwórz stronę na prawdziwym telefonie. Wypełnij formularz, otwórz menu, zamknij wyskakujące okno, obróć ekran. Emulacja nie powie, że kciuk nie trafia w krzyżyk albo że klawiatura zasłania pole formularza.
- Przetestuj różne typy podstron. Strona główna zwykle jest dopracowana, a problemy kryją się w kartach produktów, starych artykułach z szerokimi tabelami i szablonach bloga.
- Porównaj treść wersji mobilnej i desktopowej. Teksty, nagłówki, linki, dane strukturalne i atrybuty alt powinny być w obu.
Najczęstsze problemy i jak je naprawić
Brak meta viewport
Bez tego tagu telefon układa stronę na szerokość ok. 980 px i ją pomniejsza — cały tekst robi się drobny. Dodaj do <head>:
<meta name="viewport" content="width=device-width, initial-scale=1">Nie dodawaj user-scalable=no ani maximum-scale=1: blokada powiększania utrudnia życie osobom słabowidzącym, a nasze narzędzie odejmuje za nią punkty.
Stała szerokość bloków
Klasyka starych szablonów to width: 960px na kontenerze — na telefonie gwarantowane przewijanie w poziomie. Zamiast tego ogranicz szerokość od góry:
.container { max-width: 1200px; width: 100%; margin: 0 auto; padding: 0 16px; box-sizing: border-box; }
img, video, iframe { max-width: 100%; height: auto; }Szerokie tabele
Tabela z sześcioma kolumnami nie zmieści się w 360 px. Najprościej pozwolić jej przewijać się wewnątrz własnego bloku, zamiast psuć całą stronę:
<div class="table-wrap"><table>…</table></div>
.table-wrap { overflow-x: auto; -webkit-overflow-scrolling: touch; }Jeśli kolumn jest dużo, a dane są ważne, na wąskich ekranach lepiej zamienić wiersze w karty za pomocą media query.
Mały tekst i małe przyciski
Tekst główny ustaw na ok. 16 px, a rozmiary podawaj w rem. Dla elementów dotykowych kryterium WCAG 2.2 (2.5.8) wymaga co najmniej 24×24 CSS px, a wytyczne Material Design zalecają ok. 48×48 z odstępami między sąsiednimi linkami:
html { font-size: 100%; } /* domyślnie 16px */
body { font-size: 1rem; line-height: 1.5; }
.nav a, button { min-height: 48px; padding: 12px 16px; display: inline-flex; align-items: center; }Media queries dla wąskich ekranów
Układ wielokolumnowy na telefonie powinien złożyć się do jednej kolumny:
.grid { display: grid; grid-template-columns: repeat(3, 1fr); gap: 24px; }
@media (max-width: 768px) {
.grid { grid-template-columns: 1fr; }
}Wyskakujące okna na cały ekran
Zgodnie z zaleceniami Google nie należy zasłaniać całej strony reklamą pełnoekranową, chyba że wymaga tego prawo (zgoda na cookies, weryfikacja wieku). Zapis do newslettera czy instalację aplikacji lepiej pokazać jako niewielki pasek, który nie przeszkadza w czytaniu.
Przestarzałe technologie
Flash, aplety Javy i ramki nie działają na telefonach. Zastąp je wideo HTML5, zwykłym układem i osobnymi podstronami.
Dlaczego to ważne: indeksowanie mobile-first
Google używa mobilnej wersji treści, pobranej robotem smartfonowym, do indeksowania i ustalania pozycji. Nie znaczy to, że strona bez responsywnego układu wypadnie z wyników: Google pisze wprost, że wersja mobilna nie jest wymagana, ale jest bardzo zalecana. Praktyczny wniosek jest inny: do indeksu trafia to, co widzi telefon. Jeśli wersja mobilna ma okrojony tekst, ukryte linki albo brak danych strukturalnych, wyszukiwarka też ich nie dostaje. Więcej w artykule o indeksacji mobile-first.
Core Web Vitals na telefonach
Wygoda to także szybkość. Google zaleca, aby LCP (wczytanie głównej treści) mieścił się w 2,5 sekundy, INP (reakcja na działania) był poniżej 200 milisekund, a CLS (przesunięcia układu) poniżej 0,1. Na telefonach te wartości prawie zawsze są gorsze niż na komputerze: słabszy procesor, wolniejsza sieć. Patrz na kartę mobilną w PageSpeed Insights i raport Core Web Vitals w Search Console, który rozdziela adresy mobilne i desktopowe. Co oznacza każda metryka — w artykule Core Web Vitals, a od czego zacząć przyspieszanie — w tekście o prędkości ładowania strony.
Jak sprawdzić stronę w naszym teście mobilnym
Wpisz adres w teście optymalizacji mobilnej. Narzędzie pobiera HTML z User-Agentem telefonu z Androidem, czyta do sześciu arkuszy stylów z Twojej domeny i wykonuje osiem sprawdzeń. Każde ma stałą liczbę punktów, a wagi są pokazane na stronie:
| Sprawdzenie | Punkty | Czego szuka |
|---|---|---|
| Meta viewport | 30 | Czy tag istnieje i ma width=device-width |
| Responsywny CSS | 20 | Media queries zależne od szerokości; flex, grid czy clamp bez nich dają część punktów |
| Stała szerokość | 10 | Reguły i style inline z width powyżej 480 px |
| Ryzyko przewijania w poziomie | 10 | Szerokie atrybuty width, obrazy bez max-width, układ na zagnieżdżonych tabelach |
| Rozmiar czcionki | 10 | Czcionka bazowa poniżej 12 px, wiele reguł poniżej 11 px |
| Obszary dotyku | 10 | Linki i przyciski z bardzo małą czcionką lub rozmiarem poniżej 24 px w stylach inline |
| Powiększanie | 5 | Czy nie ma user-scalable=no albo maximum-scale poniżej 2 |
| Przestarzałe wtyczki | 5 | Flash, Java, ramki |
Obok listy problemów jest zrzut ekranu w emulacji iPhone’a: jeśli widać na nim ucięty tekst albo pasek przewijania, ufaj zrzutowi bardziej niż punktom. Sygnały wyskakujących okien i waga strony są pokazywane jako wskazówki i nie wpływają na ocenę. Bez konta masz 15 testów dziennie, z darmowym kontem 45, a w Pro bez limitu.
Co jeszcze się przyda
- Zrzut ekranu strony — w trybie mobilnym i desktopowym, aby pokazać problem programiście albo porównać „przed i po”. Jak czytać takie zrzuty — w artykule o zrzucie ekranu strony online.
- Analiza szybkości — waga HTML, obrazów, CSS i JS oraz czas ładowania: ciężkie obrazy to częsta przyczyna wolnej wersji mobilnej.
- Search Console — raport Core Web Vitals z podziałem na strony mobilne i desktopowe.