Mobile-first 2026, dlaczego Google ocenia stronę z telefonu

Część przewodnika: Strona internetowa dla małej firmy 2026, kompletny przewodnik
Ten artykuł rozwija jeden wątek przewodnika: jak strona zachowuje się na telefonie i co z tego widzi Google.

Twoja firma ma stronę i wygląda ona dobrze na monitorze, na którym ją odbierałeś. Klient otwiera ją w autobusie, jedną ręką, na ekranie szerokim na kilka centymetrów. Widzi wtedy zupełnie inną stronę niż Ty. Google widzi tę samą co on.

To nie jest metafora. Google używa mobilnej wersji treści, pobranej agentem smartfonowym, do indeksowania i pozycjonowania. Nazywa to mobile-first indexing i pisze o tym wprost w dokumentacji (fakt, Mobile site and mobile-first indexing best practices, dokument aktualizowany 10 grudnia 2025, weryfikacja 16 lipca 2026).

Z tego nie wynika, że przestawienie strony na mobile podnosi pozycję. Google mówi coś innego: nie ma jednego sygnału page experience, a dobre wyniki nie gwarantują miejsca w wynikach. Wersja mobilna rozstrzyga coś wcześniejszego niż ranking. Decyduje o tym, co w ogóle trafia do indeksu.

Co dokładnie znaczy mobile-first indexing

Definicja Google mieści się w jednym zdaniu: wyszukiwarka używa mobilnej wersji treści serwisu, pobranej agentem smartfonowym, do indeksowania i pozycjonowania. Zasada dotyczy całego serwisu, nie pojedynczej podstrony. Dokumentacja dodaje, że wersja mobilna nie jest formalnie wymagana, ale jest bardzo mocno zalecana.

Przejście trwało lata i skończyło się niedawno. 3 czerwca 2024 Google zapowiedział ostatni krok: po 5 lipca 2024 resztę stron, wciąż odwiedzanych crawlerem desktopowym, zaczął pobierać wyłącznie Googlebotem Smartphone. W tym samym wpisie napisał, że treść w ogóle niedostępna z urządzenia mobilnego przestaje być indeksowalna (fakt, wpis Google Search Central z 3 czerwca 2024).

Dwie rzeczy warto od razu rozdzielić. Googlebot Desktop nadal bywa widoczny w logach serwera, bo Google używa go do wybranych funkcji, na przykład ofert produktowych i Google for Jobs. To jednak nie jest crawler, który buduje indeks Twojego serwisu (fakt, ten sam wpis).

Praktyczny wniosek bywa niewygodny. Jeśli oceniasz treść i strukturę strony, patrząc na wersję desktopową, oglądasz materiał, którego wyszukiwarka nie czyta. Wszystko, czego nie ma w mobilnym HTML, dla indeksu po prostu nie istnieje, choćby na monitorze wyglądało wzorowo.

Parytet treści, czyli najczęstszy realny problem

Responsywność rozwiązuje ten problem niejako przy okazji. Ten sam kod trafia pod tym samym adresem na każde urządzenie, więc treść jest z definicji ta sama. Google wymienia trzy dopuszczalne konfiguracje: responsywny układ, dynamic serving i osobne adresy URL, a responsywny zaleca jako najłatwiejszy do wdrożenia i utrzymania.

Kłopot zaczyna się tam, gdzie wersja mobilna jest osobna albo mocno okrojona motywem. Google formułuje to jednoznacznie: jeśli mobile ma mniej treści niż desktop, można spodziewać się spadku ruchu, bo wyszukiwarka wyciąga z takiej strony mniej informacji. Zamiast usuwać treść, dokumentacja radzi przenieść ją do akordeonów lub zakładek.

To ważna korekta starego mitu. Treść schowana w akordeonie nie jest karana. Problem jest inny: Google nie ładuje treści, która wymaga interakcji użytkownika, na przykład przesunięcia palcem, kliknięcia albo wpisania czegoś, żeby się w ogóle pojawić. Różnica leży między „zwinięte w HTML” a „doładowywane dopiero po dotknięciu”.

Poniżej lista rzeczy, które według dokumentacji Google mają się zgadzać w obu wersjach. To dobra ściąga na rozmowę z osobą, która utrzymuje Twoją stronę.

Element	Co ma się zgadzać	Co idzie nie tak w praktyce
Treść główna	Równoważna na mobile i desktop	Motyw ukrywa sekcje „dla czytelności”
Nagłówki	Te same, jasne i sensowne	Mobile gubi H2 na rzecz ikon
Metadane	title i meta description równoważne	Osobny szablon mobilny z krótszym tytułem
Dane strukturalne	Ten sam JSON-LD, z mobilnymi adresami	Schema wstrzykiwana tylko w desktopie
Tagi robots	Identyczne w obu wersjach	noindex zostawiony na wersji mobilnej
Obrazy	Ten sam alt, ta sama jakość, stabilne adresy	Miniatury niskiej jakości i zmienne URL-e
Zasoby	Dostępne dla Google, bez disallow	Robots.txt blokuje CSS albo JS wersji mobilnej

Najgroźniejsza pozycja z tej listy to tagi robots. noindex na wersji mobilnej oznacza, że Google może nie zaindeksować strony w ogóle, mimo że desktop wygląda poprawnie. Podobnie działa blokada zasobów w robots.txt, bo wyszukiwarka nie wyrenderuje tego, czego nie może pobrać.

Czym sprawdzić telefon, skoro test Google zniknął

Tu trzeba naprostować rzecz, którą powtarza wiele poradników. Test optymalizacji mobilnej, raport Mobile Usability w Search Console oraz Mobile-Friendly Test API zostały wycofane 1 grudnia 2023. Informacja wisi dziś jako dopisek nad starym wpisem, który to narzędzie zapowiadał (fakt, Google Search Central).

Zniknięcie narzędzia nie oznacza, że temat przestał się liczyć. Google w dokumentacji page experience nadal pyta wprost, czy treść dobrze wyświetla się na urządzeniach mobilnych, i poleca Lighthouse z Chrome, między innymi do oceny mobile usability (fakt, Understanding page experience).

W praktyce zostają trzy sprawdzenia. Lighthouse w trybie mobilnym pokazuje przyczyny problemów w warunkach laboratoryjnych. Raport Core Web Vitals w Search Console pokazuje dane rzeczywistych użytkowników. Trzecie jest najprostsze i najczęściej pomijane: własny telefon.

Test na własnym telefonie warto zrobić uczciwie. Wyłącz WiFi, wejdź na danych mobilnych, w trybie prywatnym, i przejdź całą ścieżkę klienta: znajdź informację, otwórz menu, kliknij telefon, wypełnij formularz. To wykrywa rzeczy, których automat nie zgłosi, bo formalnie nic nie jest zepsute (obserwacja z audytów stron).

Dotyk i czytelność, czyli co ekran robi z Twoją ofertą

Krążąca po branży liczba „44 na 44 piksele, wymóg Google” nie ma pokrycia w dokumentacji wyszukiwarki. Google nie publikuje progu w pikselach jako wymogu Search. Testowalne kryteria podaje za to WCAG 2.2, i to na nie warto się powoływać w rozmowie z wykonawcą.

Kryterium 2.5.8 Target Size (Minimum) na poziomie AA wymaga celu dotykowego co najmniej 24 na 24 piksele CSS, z wyjątkami, wśród których jest wystarczający odstęp między mniejszymi elementami. Kryterium 2.5.5 Target Size (Enhanced) na poziomie AAA podnosi próg do 44 na 44 pikseli CSS (fakt, WCAG 2.2, weryfikacja 16 lipca 2026).

Drugie kryterium, o którym mało kto pamięta, dotyczy czytelności. 1.4.10 Reflow na poziomie AA wymaga, aby treść dawała się przedstawić bez utraty informacji i bez przewijania w dwóch kierunkach przy szerokości odpowiadającej 320 pikselom CSS. To jest realny test dla cennika w tabeli albo mapy dojazdu.

Praktyczne konsekwencje są prozaiczne. Dwa przyciski sklejone ze sobą przy krawędzi ekranu to loteria dla kciuka. Tekst wymagający rozsuwania palcami zniechęca szybciej niż wolne ładowanie. Nawigacja otwierana wyłącznie najechaniem kursorem nie ma odpowiednika na ekranie dotykowym, więc podstrony po prostu stają się nieosiągalne.

Szybkość na telefonie, bez obietnicy pozycji

Szybkość jest częścią tej układanki, ale nie jest przełącznikiem rankingu. Google pisze w FAQ dokumentacji page experience, że nie ma jednego sygnału page experience, że Core Web Vitals są używane przez systemy rankingowe i że dobre wyniki w raportach nie gwarantują wysokiej pozycji (fakt, ta sama dokumentacja).

Dalej idzie zdanie, które warto zapamiętać przed wydaniem pieniędzy na optymalizację: pogoń za idealnym wynikiem wyłącznie dla SEO może nie być najlepszym użyciem czasu. Google dodaje też, że poza Core Web Vitals pozostałe aspekty page experience nie podnoszą bezpośrednio pozycji, choć czynią stronę wygodniejszą w użyciu.

Sens optymalizacji mobilnej jest więc inny, niż sprzedaje się go w ofertach. Klient na słabym zasięgu ma szybko zobaczyć ofertę, bez irytacji otworzyć menu i nie kliknąć w przesunięty przycisk. Metryki i progi rozkłada wpis o Core Web Vitals 2026.

Jeśli chcesz zrozumieć, co naprawdę pokazuje wynik z PageSpeed Insights i czym różnią się dane laboratoryjne od terenowych, zacznij od wpisu PageSpeed jako ranking factor. Diagnozę konkretnej wolnej strony prowadzi krok po kroku dlaczego strona ładuje się wolno.

Formularze, w których kciuk nie przeszkadza

Formularz na telefonie jest miejscem, gdzie strona najczęściej traci klienta bez śladu w statystykach. Nikt nie zgłosi, że rezygnował, bo klawiatura pokazała litery zamiast cyfr. Zwykle po prostu zamknie kartę i zadzwoni gdzie indziej albo nie zadzwoni wcale (opinia).

Podstawa jest opisana normą, nie przeczuciem. Kryterium WCAG 2.2 o numerze 1.3.5 Identify Input Purpose na poziomie AA wymaga, aby cel pola zbierającego dane o użytkowniku dał się ustalić programowo. W HTML robi to atrybut autocomplete, z wartościami takimi jak tel, email czy name.

Drugi atrybut, inputmode, podpowiada przeglądarce, jaką klawiaturę pokazać. inputmode="tel" daje klawiaturę numeryczną, inputmode="email" klawiaturę ze znakiem małpy. Do tego dochodzą właściwe typy pól, czyli type="tel" i type="email". To trzy linijki kodu, nie projekt.

Osobna sprawa to numer telefonu. Klient chce dotknąć całego kafelka „Zadzwoń”, nie samych cyferek. Cały element, razem z ikoną i etykietą, powinien mieścić się wewnątrz odnośnika tel:. To zwykły schemat URI, nie dane strukturalne, więc mylenie go ze schema.org niczego nie da.

Wyskakujące okna i banery zgód

Cookie banner zasłaniający większość ekranu telefonu to nie jest drobiazg estetyczny. Google w dokumentacji o natrętnych oknach radzi używać wąskich banerów zamiast pełnoekranowych interstitiali i nie zasłaniać całej strony, chyba że wymaga tego prawo (fakt, Avoid intrusive interstitials and dialogs).

Warto zwrócić uwagę na ostrożny język Google. Dokumentacja nie mówi o karze, tylko o tym, że natrętne okna utrudniają wyszukiwarkom zrozumienie treści, co może przełożyć się na słabe wyniki w wyszukiwarce. Drugi argument jest prostszy: użytkownik, któremu trudno korzystać ze strony, raczej na nią nie wróci.

Minimum przyzwoitości jest proste. Baner zajmuje ułamek ekranu, ma czytelne opcje wyboru, zapamiętuje decyzję i nie wraca przy każdym wejściu. Treść główna zostaje widoczna od razu, a nie po zamknięciu dwóch nakładek.

Ile kosztuje uporządkowanie strony pod telefon

Uczciwa odpowiedź brzmi: zależy, czy poprawiamy istniejącą stronę, czy budujemy nową. Audyt ma sens jako pierwszy krok, bo pokazuje, czy problem leży w parytecie treści, w szablonie, czy w wydajności. Poniżej ceny startowe usług stron internetowych.

Zakres	Cena startowa
Audyt strony (szybkość, SEO, UX)	490 zł netto
Strona-wizytówka	1 299 zł netto
Strona firmowa	2 499 zł netto

Nie da się z góry powiedzieć, czy tańsza będzie naprawa, czy budowa od zera. Strona z okrojoną wersją mobilną wpisaną w motyw bywa droższa w łataniu niż w przepisaniu (szacunek, zależny od konkretnego przypadku). Pełny zakres i warianty są w cenniku, a porównanie technologii rozkłada wpis WordPress vs strona statyczna.

Kiedy to nie jest Twój priorytet

Nie każda firma musi rzucać wszystko i zajmować się wersją mobilną. Jeśli Twoja strona jest responsywna, przechodzi ręczny test na telefonie i ma tę samą treść co desktop, to prawdopodobnie masz mobile-first załatwiony. Kolejne punkty w Lighthouse nie są wtedy najlepszym miejscem na budżet.

Podobnie, gdy klienci przychodzą wyłącznie z polecenia albo z jednego kontraktu B2B, a strona pełni rolę wizytówki dla osoby, która już Cię zna. Wersja mobilna ma wtedy działać poprawnie, ale walka o ostatnie milisekundy nie zwróci się w żaden mierzalny sposób.

Trzeci przypadek to strona, która ma poważniejszy problem niż mobile. Brak treści odpowiadającej na pytania klientów, pusty Profil Firmy w Google albo formularz, który nie dochodzi na skrzynkę, kosztują więcej niż drobne przesunięcie układu. Kolejność napraw ustala audyt SEO strony.

Poza tymi wyjątkami zasada jest prosta. Skoro Google czyta Twoją stronę z telefonu, a klient podejmuje decyzję z telefonem w ręku, to wersja mobilna nie jest wariantem strony. Jest stroną. Reszta to podgląd dla Ciebie na monitorze.

Jeśli nie masz pewności, co Twoja strona pokazuje Googlebotowi Smartphone, sprawdzę to i powiem wprost, czy warto poprawiać obecną, czy budować nową. Odzywam się zwykle w ciągu doby, bez zobowiązań.

Najczęstsze pytania

Co oznacza mobile-first indexing w Google?

Google używa mobilnej wersji treści strony, pobranej agentem smartfonowym, do indeksowania i pozycjonowania. Po 5 lipca 2024 Google pobiera wszystkie strony do wyszukiwarki crawlerem Googlebot Smartphone. Treść w ogóle niedostępna z urządzenia mobilnego przestaje być indeksowalna.

Czy responsywna strona wystarczy do mobile-first?

Responsywność rozwiązuje główny problem, bo ten sam kod i ten sam adres trafiają do każdego urządzenia, więc parytet treści powstaje sam z siebie. Google zaleca właśnie responsywny układ jako najłatwiejszy do wdrożenia i utrzymania. To jednak nie zwalnia z testu na prawdziwym telefonie: rozmiar celów dotykowych, czytelność, formularze i szybkość trzeba sprawdzić osobno.

Jak sprawdzić stronę na telefonie, skoro Test optymalizacji mobilnej zniknął?

Test optymalizacji mobilnej i raport Mobile Usability w Search Console zostały wycofane 1 grudnia 2023. Google w dokumentacji page experience poleca Lighthouse z Chrome, między innymi do oceny mobile usability. Do tego dochodzi raport Core Web Vitals w Search Console oraz ręczny test na własnym telefonie, na danych mobilnych.

Czy mogę pokazać na telefonie mniej treści niż na komputerze?

Google zaleca, aby treść główna była równoważna w obu wersjach, bo indeksowanie opiera się na wersji mobilnej. Jeśli mobile ma mniej treści, Google uprzedza, że można spodziewać się spadku ruchu. Zamiast usuwać treść, można ją przenieść do akordeonów lub zakładek.

Czy osobna wersja mobilna, na przykład m.przyklad.pl, jest błędem?

Google nadal wspiera trzy konfiguracje: responsywny układ, dynamic serving i osobne adresy URL. Responsywny układ jest zalecany jako najprostszy w utrzymaniu, ale osobne adresy nie są zakazane. Wymagają za to pilnowania parytetu treści, metadanych, danych strukturalnych i tagów robots w obu wersjach, co w praktyce oznacza więcej pracy.

Jak duże mają być przyciski na telefonie?

WCAG 2.2 podaje testowalne kryteria. Poziom AA wymaga celu dotykowego co najmniej 24 na 24 piksele CSS, z wyjątkiem między innymi wystarczającego odstępu między elementami. Poziom AAA podnosi próg do 44 na 44 pikseli CSS. Google nie publikuje własnego progu w pikselach jako wymogu wyszukiwarki.