Jak sprawdzić, czy strona jest responsywna?

Strona jest responsywna, gdy na każdym ekranie pokazuje tę samą treść pod tym samym adresem, a układ sam dopasowuje się do szerokości okna. Sprawdzisz to w kilka minut w przeglądarce i na telefonie, a narzędzia Google pokażą, jak wersję mobilną widzi robot. Poniżej znajdziesz kolejne kroki, narzędzia, które zastąpiły wycofany Test optymalizacji mobilnej, oraz błędy, które najczęściej psują stronę na telefonie.

Co to znaczy, że strona jest responsywna?

Strona responsywna (RWD, Responsive Web Design) wysyła ten sam kod HTML pod tym samym adresem na każde urządzenie, a wygląd dopasowuje do ekranu. Na komputerze menu może stać w poziomie, a na telefonie schować się pod ikoną. Treść, ceny i przyciski zostają te same.

W praktyce responsywność poznasz po trzech rzeczach:

• nie musisz przewijać strony w bok, żeby przeczytać tekst,
• tekst da się czytać bez powiększania palcami,
• przyciski, menu i pola formularza wygodnie obsłużysz kciukiem.

Responsywność to cecha szablonu, a nie pojedynczej podstrony. Jeśli szablon działa dobrze, poprawny układ dostaje cały serwis. Jeśli ma błąd, ten sam problem powtarza się na setkach adresów.

Czym strona responsywna różni się od wersji mobilnej?

Strona responsywna to jedna wersja dla wszystkich ekranów. Wersja mobilna w dawnym rozumieniu to osobny serwis albo osobny kod dla telefonów. Google opisuje trzy sposoby obsługi urządzeń mobilnych i zaleca responsywność, bo najłatwiej ją wdrożyć i utrzymać.

Rozwiązanie	Adres i kod	Co to oznacza dla Ciebie
Strona responsywna	ten sam adres i ten sam HTML na każdym urządzeniu, układ dopasowany w CSS	jedna wersja do utrzymania, rozwiązanie zalecane przez Google
Dynamiczne wyświetlanie	ten sam adres, ale serwer wysyła inny HTML zależnie od urządzenia	dwie wersje kodu do pilnowania; telefon może dostać mniej treści niż komputer
Osobne adresy (np. m.domena.pl)	inny adres i inny HTML dla telefonu	wersje trzeba łączyć znacznikami rel=canonical i rel=alternate; adres desktopowy jest kanoniczny

Osobna wersja mobilna nie jest błędem, ale wymaga pilnowania dwóch wersji. Każda różnica w treści, linkach albo danych strukturalnych przenosi się na to, jak Google widzi Twoją stronę. Przy nowym serwisie albo przebudowie szablonu najprościej więc wybrać responsywność.

Dlaczego responsywność ma znaczenie dla pozycji w Google?

Bo Google ocenia Twoją stronę po wersji, którą widzi na telefonie. W ramach indeksowania mobile-first Google używa mobilnej wersji treści do indeksowania i ustalania pozycji. Jeśli na telefonie brakuje opisu, linków albo danych strukturalnych, które są na komputerze, Google może ich nie uwzględnić.

Sama responsywność nie jest przy tym osobnym punktem w rankingu. W opisie wrażeń z korzystania ze strony Google podsuwa właścicielom pytanie kontrolne, czy treść dobrze wyświetla się na urządzeniach mobilnych. Zaznacza też, że poza wskaźnikami Core Web Vitals pozostałe aspekty tych wrażeń nie podnoszą bezpośrednio pozycji. Google stara się pokazać najtrafniejszą treść nawet wtedy, gdy strona jest niewygodna.

Wniosek jest praktyczny: responsywność nie wypchnie słabej treści na pierwszą stronę wyników, ale zła wersja mobilna może sprawić, że dobra treść nie zadziała. Wersja na telefon to jeden z elementów widoczności w Google Search. W modelu Search Ecosystem™ łączy ją z obszarem User Experience, czyli z pytaniem, czy klient po wejściu na stronę zrobi kolejny krok.

Jak sprawdzić responsywność strony w przeglądarce?

Najszybciej: zwężaj okno przeglądarki na komputerze i patrz, co dzieje się z treścią. Ten test zajmuje kilka minut i wyłapuje większość błędów szablonu.

1. Otwórz stronę i powoli zwężaj okno aż do szerokości telefonu. Układ powinien przechodzić w jedną kolumnę, a tekst i zdjęcia nie mogą wychodzić poza ekran.
2. Patrz na dolną krawędź okna. Poziomy pasek przewijania na zwykłej podstronie to najpewniejszy znak, że coś jest szersze niż ekran: najczęściej tabela, obrazek albo osadzony film.
3. W Chrome otwórz narzędzia dla programistów (F12) i włącz pasek urządzeń (Ctrl+Shift+M, na Macu Cmd+Shift+M). Wybierzesz tam gotowe modele telefonów albo wpiszesz własną szerokość.
4. Sprawdź szerokość 320 pikseli CSS. Standard dostępności WCAG 2.2 wymaga, żeby przy tej szerokości treść dało się czytać bez przewijania w dwóch kierunkach (kryterium 1.4.10, poziom AA).
5. Powiększ stronę do 200% (Ctrl i plus). Według tego samego standardu tekst powinien dać się powiększyć do 200% bez utraty treści i funkcji (kryterium 1.4.4).
6. Przejdź tak przez kilka typów podstron: stronę główną, kategorię, kartę produktu albo usługi, wpis na blogu, koszyk i formularz kontaktowy.

Emulator w przeglądarce dobrze pokazuje układ, ale nie zastąpi telefonu w dłoni. Nie sprawdzisz w nim, jak strona zachowuje się pod kciukiem, z klawiaturą ekranową na pół ekranu i na urządzeniu, którego używa Twój klient.

Jak sprawdzić stronę na prawdziwym telefonie?

Weź telefon do ręki i przejdź ścieżkę klienta: od wejścia z Google do wysłania zapytania albo zakupu. Najlepiej na dwóch urządzeniach, z Androidem i z iOS, w pozycji pionowej i poziomej.

• Tekst czytasz bez powiększania palcami, a wiersze nie są ucięte.
• Przyciski i linki trafiasz kciukiem za pierwszym razem. WCAG 2.2 przyjmuje jako minimum pole 24 na 24 piksele CSS albo odpowiedni odstęp między elementami (kryterium 2.5.8, poziom AA).
• Menu otwiera się i zamyka, a z każdej podstrony wrócisz do oferty i kontaktu.
• Formularz działa z klawiaturą ekranową: pola nie chowają się pod nią, a przy numerze telefonu pojawia się klawiatura numeryczna.
• Okienka z ciasteczkami, newsletterem albo czatem nie zasłaniają treści i dają się zamknąć jednym dotknięciem.
• Strona działa po obróceniu telefonu. WCAG 2.2 wymaga, żeby treść nie była zablokowana w jednej orientacji, chyba że ta orientacja jest niezbędna (kryterium 1.3.4).
• Na telefonie widać tę samą treść co na komputerze: opisy, ceny, opinie, tabele.

Jeśli klient na telefonie nie widzi ceny, nie trafia w przycisk albo nie może wysłać formularza, tracisz zapytanie, zanim ktokolwiek oceni Twoją ofertę.

Czym zastąpić Test optymalizacji mobilnej Google?

Narzędziem do sprawdzania adresów URL w Search Console albo testem wyników z elementami rozszerzonymi. Dawnego Testu optymalizacji mobilnej i raportu obsługi na urządzeniach mobilnych w Search Console już nie ma. Google wycofał je pod koniec 2023 roku, a 1 grudnia 2023 usunął wzmianki o nich ze swojej dokumentacji.

Narzędzie	Co pokazuje	Kiedy użyć
Sprawdzanie adresu URL w Search Console, test na żywo	zrzut ekranu mobilnej wersji strony, pobrany kod HTML, zasoby strony i komunikaty konsoli JavaScript	gdy masz dostęp do usługi w Search Console i chcesz zobaczyć stronę oczami Google
Test wyników z elementami rozszerzonymi	kod strony po wyrenderowaniu, sprawdzany domyślnie jako smartfon	gdy nie masz dostępu do Search Console albo sprawdzasz cudzą stronę
PageSpeed Insights	szybkość i stabilność układu osobno dla telefonu i komputera	gdy strona wygląda dobrze, ale wolno się wczytuje albo układ skacze

Zrzut w narzędziu do sprawdzania adresów URL powstaje tylko w teście na żywo zakończonym powodzeniem i pokazuje mobilną wersję strony. Sprawdzisz tak wyłącznie adresy z usługi, która jest otwarta w Search Console. Do pozostałych stron Google poleca narzędzia bez wymogu własności, na przykład test wyników z elementami rozszerzonymi. Ten test domyślnie udaje smartfon i ocenia kod po wyrenderowaniu, czyli stronę po wykonaniu skryptów.

Jakie błędy najczęściej psują stronę na telefonie?

Większość problemów bierze się z kilku powtarzalnych usterek szablonu i treści.

• Brak znacznika meta viewport. Bez niego przeglądarka telefonu pokazuje stronę jak pomniejszony widok z komputera. W kodzie źródłowym strony szukaj wpisu name="viewport" z wartością width=device-width, initial-scale=1.
• Sztywne szerokości. Tabela, baner albo osadzona mapa o stałej szerokości w pikselach wypycha stronę poza ekran i wymusza przewijanie w bok.
• Treść wycięta z wersji mobilnej. Opisy kategorii, opinie albo linki ukryte na telefonie mogą zniknąć także dla Google. Google zaleca na telefonie i komputerze tę samą treść, te same dane strukturalne, te same znaczniki meta robots oraz te same opisy alt obrazów.
• Treść wczytywana dopiero po kliknięciu. Google nie wczytuje treści, która wymaga działania użytkownika. Treść główna musi być na stronie bez klikania.
• Zablokowane zasoby. Jeśli robots.txt blokuje pliki, z których składa się strona, Google może zobaczyć ją inaczej niż klient. Google prosi, żeby pozwolić mu pobierać zasoby strony.
• Okienka zasłaniające treść. Baner ciasteczek, zapis do newslettera albo czat na pół ekranu, którego nie da się łatwo zamknąć.
• Ciasne elementy do kliknięcia. Linki w stopce, filtry i ikony ustawione tak blisko siebie, że kciuk trafia w sąsiedni element.

Czy responsywność to to samo co szybkość strony?

Nie. Responsywność dotyczy układu na różnych ekranach, a szybkość tego, jak sprawnie strona się wczytuje i reaguje. Pojęcia łatwo pomylić, bo w Core Web Vitals jest wskaźnik INP, który Google opisuje jako miarę „responsiveness”, czyli szybkości reakcji strony na kliknięcie albo dotknięcie.

W dokumentacji Core Web Vitals Google podaje trzy wskaźniki i progi dobrego wyniku:

Wskaźnik	Co mierzy	Dobry wynik
LCP (Largest Contentful Paint)	wczytywanie strony	do 2,5 s od początku ładowania
INP (Interaction to Next Paint)	reakcję na działanie użytkownika	poniżej 200 ms
CLS (Cumulative Layout Shift)	stabilność układu	poniżej 0,1

Responsywny szablon może być wolny, a szybka strona może się rozjeżdżać na telefonie. Sprawdzaj obie rzeczy osobno. Jak czytać te wskaźniki, opisujemy we wpisie o Core Web Vitals i PageSpeed Insights.

Co zrobić teraz?

1. Zwęź okno przeglądarki na pięciu najważniejszych typach podstron i zanotuj każde przewijanie w bok.
2. Przejdź na telefonie ścieżkę klienta od wejścia na stronę do wysłania zapytania albo zakupu.
3. W Search Console sprawdź na żywo kilka kluczowych adresów i obejrzyj zrzut wersji mobilnej.
4. Porównaj treść na telefonie i na komputerze: opisy, linki, dane strukturalne.
5. Zgłaszaj błędy jako poprawki szablonu, a nie pojedynczych podstron.

Responsywność to warunek wstępny, a nie cel. Gdy strona poprawnie wyświetla się na telefonie, kolejnym krokiem jest optymalizacja pod urządzenia mobilne: szybkość, wygoda formularzy i treść ułożona pod mały ekran.

Najczęstsze pytania.

Czy strona na WordPressie jest automatycznie responsywna?

Motyw może być responsywny, a strona i tak rozjeżdża się na telefonie przez wtyczki, szerokie tabele, suwaki albo elementy dodane ręcznie. Dlatego test robi się na gotowej stronie, a nie na podstawie opisu motywu.

Czy Google karze strony, które nie są responsywne?

Osobnej kary za brak responsywności nie ma. Google indeksuje jednak wersję mobilną, więc uboga albo nieczytelna wersja na telefon może osłabić stronę w wynikach, a przede wszystkim zniechęca klientów.

Na jakich szerokościach ekranu testować stronę?

Najpierw najwęższy ekran z wymagań WCAG, czyli 320 pikseli CSS. Potem modele, z których naprawdę wchodzą Twoi klienci: ich listę pokazuje Google Analytics w danych o urządzeniach.