W tym poradniku dowiesz się, jak zoptymalizować stronę pod urządzenia mobilne w 7 krokach. Mobile SEO to dostosowanie strony do smartfonów tak, żeby Googlebot Smartphone widział tę samą treść, linki i dane co użytkownik desktopu, a człowiek na telefonie mógł ją wygodnie przeczytać. Kroki: konfiguracja, viewport, parytet treści, meta i dane strukturalne, obrazy i Core Web Vitals, nakładki, test w Lighthouse.
Poradnik jest dla właściciela strony i początkującego SEO-wca. Dokumentacja, progi i nazwy narzędzi są aktualne na październik 2026, czyli po wycofaniu Testu optymalizacji mobilnej i po wydaniu Lighthouse 13.
Mobile SEO w skrócie: definicja, zakres i 7 kroków
Mobile-first indexing to sposób działania Google, w którym wyszukiwarka indeksuje i ocenia mobilną wersję strony, pobraną crawlerem udającym smartfon. Według dokumentacji Google Search Central o mobile-first indexing wersja mobilna nie jest warunkiem obecności w wynikach, ale Google „bardzo mocno” ją zaleca.
Googlebot ma dwie odmiany: Googlebot Smartphone i Googlebot Desktop. Dokumentacja Googlebota (aktualizacja 3.02.2026) podaje, że większość żądań crawlowania wykonuje crawler mobilny, a obie odmiany słuchają tego samego tokenu Googlebot w robots.txt, więc nie da się zablokować jednej bez drugiej.
Mobile SEO nie zależy od tego, skąd przychodzą twoi użytkownicy. Według Statcounter we wrześniu 2026 roku w Polsce desktop miał 56,07% odsłon, smartfony 43,31%, a tablety 0,62%. Strona z przewagą ruchu desktopowego i tak jest oceniana przez Google w wersji mobilnej, więc braki w wersji mobilnej odbijają się na wynikach dla wszystkich urządzeń.
Optymalizacja strony mobilnej obejmuje 7 kroków:
- Wybór konfiguracji: responsive, dynamic serving albo osobne URL-e.
- Meta viewport i układ bez poziomego przewijania.
- Ta sama treść, nagłówki i linki na mobile i desktopie.
- Te same meta robots, title, meta description i dane strukturalne.
- Obrazy i Core Web Vitals z danych mobilnych.
- Nakładki, pop-upy i elementy dotykowe.
- Test w Lighthouse, Chrome DevTools i Google Search Console.
Krok 1. Wybierz konfigurację strony mobilnej
Dokumentacja Google Search Central opisuje trzy konfiguracje strony mobilnej i wprost rekomenduje responsive web design jako „najłatwiejszy do wdrożenia i utrzymania”. Przy responsive design treść i metadane są identyczne na każdym urządzeniu, więc większość problemów z mobile-first indexing w ogóle nie występuje.
| Konfiguracja | URL | HTML | Co trzeba pilnować |
|---|---|---|---|
| Responsive web design (zalecana przez Google) | ten sam | ten sam, układ zmienia CSS | meta viewport, media queries, rozmiar obrazów |
| Dynamic serving | ten sam | różny, zależny od user-agenta | nagłówek Vary: user-agent, parytet treści i metadanych |
| Osobne URL-e (np. m.domena.pl) | różny | różny | canonical i alternate, hreflang w obrębie wersji, przekierowania, weryfikacja obu wersji w GSC |
Przy osobnych URL-ach dokumentacja Google wymaga, żeby strona desktopowa miała canonical na siebie, a wersja mobilna była wskazana jako alternate. Mechanikę adresu kanonicznego opisałem we wpisie o canonical. Moim zdaniem w 2026 roku osobna wersja m. nie ma sensu przy nowej stronie: podwaja liczbę rzeczy, które mogą się rozjechać.
Krok 2. Ustaw meta viewport i usuń poziome przewijanie
Meta viewport mówi przeglądarce, żeby dopasowała szerokość strony do ekranu. Według poradnika web.dev o podstawach responsive design każda strona optymalizowana pod różne urządzenia musi mieć w <head> tag:
<meta name="viewport" content="width=device-width, initial-scale=1">Web.dev odradza w meta viewport parametry minimum-scale, maximum-scale i user-scalable, bo blokują powiększanie strony. Dokumentacja Lighthouse oblewa stronę z initial-scale mniejszym niż 1, bo takie ustawienie włącza podwójne stuknięcie do powiększenia i opóźnienie dotyku o 300 ms.
Układ strony mobilnej nie może wymuszać przewijania w poziomie. Web.dev zaleca szerokości w procentach, flexbox albo grid zamiast stałych pikseli, obrazy z max-width: 100%, breakpointy ustawione tam, gdzie łamie się treść (nie pod konkretne modele telefonów), i 70–80 znaków w linii tekstu.
Krok 3. Zachowaj tę samą treść, nagłówki i linki
Parytet treści to najważniejsza zasada mobile-first indexing: Google indeksuje tylko to, co jest w wersji mobilnej. Dokumentacja Google Search Central zaleca tę samą główną treść i te same nagłówki na obu wersjach, a akordeony i zakładki uznaje za dopuszczalny sposób oszczędzania miejsca na małym ekranie.
Lazy loading głównej treści jest dopuszczalny tylko bez interakcji. Dokumentacja Google ostrzega, że Googlebot nie wczyta treści, która pojawia się dopiero po przesunięciu, kliknięciu albo wpisaniu czegoś. Przycisk „Pokaż więcej opinii” ładujący opinie przez JavaScript oznacza, że tych opinii nie ma w indeksie.
Menu mobilne powinno prowadzić do tych samych podstron co menu desktopowe. Wycięcie kategorii z menu „hamburgera” zmienia linkowanie wewnętrzne widziane przez Googlebota Smartphone. Dokumentacja Google dodaje też, żeby nie blokować w robots.txt plików CSS, JavaScript i obrazów potrzebnych do wyrenderowania strony.
Krok 4. Ujednolij meta robots, title i dane strukturalne
Metadane strony mobilnej muszą odpowiadać desktopowym. Dokumentacja Google Search Central wymienia cztery obszary:
- Meta robots: te same dyrektywy na obu wersjach, bez
noindexaninofollowtylko na mobile. - Title i meta description: równoważne na mobile i desktopie.
- Dane strukturalne: te same typy, w pierwszej kolejności Breadcrumb, Product i VideoObject, z mobilnymi URL-ami przy osobnej wersji m.
- Obrazy: te same teksty alt, podpisy i nazwy plików; inne URL-e obrazów na mobile mogą przejściowo obniżyć ruch z Grafiki Google.
Krok 5. Odchudź obrazy i sprawdź Core Web Vitals na mobile
Core Web Vitals to trzy metryki doświadczenia strony mierzone u prawdziwych użytkowników, osobno dla mobile i desktopu. Według pomocy Google do raportu Core Web Vitals próg dobrego wyniku to LCP do 2,5 s, INP do 200 ms i CLS do 0,1, liczone na 75. percentylu odsłon.
Wersja mobilna wypada w Core Web Vitals gorzej niż desktop. Web Almanac 2025 (dane CrUX z lipca 2025) podaje, że dobre Core Web Vitals ma 48% witryn na mobile i 56% na desktopie, a dobre LCP 62% witryn na mobile i 74% na desktopie. Raport Core Web Vitals w Google Search Console pokazuje wynik mobilny jako osobny wykres.
Obrazy to najczęstszy ciężar strony mobilnej. W audycie bynajmniej.pl z 14.10.2026 crawl Screaming Frog znalazł 6 obrazków powyżej 2 MB, m.in. PNG-i wygenerowane w ChatGPT w 2025 roku po 2,5–3,7 MB, oraz 26 obrazków powyżej 100 KB. Na telefonie z mobilnym internetem taki obrazek w nagłówku wpisu to prosty sposób na słabe LCP.
Obrazy na stronie mobilnej potrzebują trzech poprawek: kompresji i formatu WebP albo AVIF, atrybutów width i height (rezerwują miejsce i ograniczają CLS) oraz wariantów rozmiaru w srcset, żeby telefon nie pobierał grafiki szerokiej na 2500 px. WordPress generuje srcset sam dla obrazków wstawionych przez bibliotekę mediów.
Krok 6. Ogranicz nakładki i powiększ elementy dotykowe
Pełnoekranowe nakładki szkodzą stronie mobilnej najbardziej, bo na małym ekranie zasłaniają całą treść. Dokumentacja Google o natrętnych interstitialach odradza nakładki na całą stronę i przekierowania na osobną stronę zgody, a zaleca małe banery. Nakładki wymagane prawem, np. weryfikacja wieku, są wyjątkiem, ale Google radzi pokazywać je nad treścią, a nie zamiast niej.
Elementy dotykowe muszą być na tyle duże, żeby trafić je palcem. Audyt tap targets w Lighthouse oznacza przycisk lub link mniejszy niż 48 × 48 px, jeśli co najmniej 25% obszaru w promieniu 48 px od jego środka nachodzi na inny element klikalny. Lighthouse podaje 8 px odstępu jako punkt startowy, nie gwarancję zaliczenia.
Czego nie robić przy mobile SEO:
- Nie ukrywaj treści na mobile „dla przejrzystości”. Web.dev ostrzega, że usuwanie treści na małych ekranach szkodzi użytkownikom, a Google tej treści nie zaindeksuje.
- Nie blokuj powiększania przez
user-scalable=no. - Nie stawiaj reklamy na całą szerokość nad treścią. Dokumentacja Google odsyła w tym miejscu do Better Ads Standard.
- Nie traktuj poradników z 2017 roku jak instrukcji. Kto w 2026 roku dalej optymalizuje Flasha pod smartfony, ma większy problem niż mobile SEO.
Krok 7. Przetestuj wersję mobilną w Lighthouse i Search Console
Test optymalizacji mobilnej i raport „Obsługa na urządzeniach mobilnych” w Google Search Console już nie działają. Stary adres pomocy raportu (support.google.com/webmasters/answer/9063469) przekierowuje 301 na stronę Lighthouse, co sprawdziłem 14.10.2026. Wiele wpisów o mobile SEO w polskim SERP dalej odsyła do Testu optymalizacji mobilnej. Strona Google o page experience (aktualizacja 22.09.2026) wskazuje Lighthouse jako narzędzie do sprawdzania użyteczności mobilnej.
Lighthouse 13, wydany 10.10.2025 według notatek wydania Chrome for Developers, zmienił audyty mobilne. Audyt czytelności czcionek (font-size, próg: co najmniej 60% tekstu od 12 px) usunięto bez zamiennika, a audyt viewport przeniesiono do insightu „Optimize viewport for mobile”. Przy starszych instrukcjach warto o tym pamiętać, bo szukanych audytów w raporcie po prostu nie ma.
| Narzędzie | Co sprawdza w mobile SEO |
|---|---|
| Lighthouse (Chrome DevTools, tryb mobile) | viewport, tap targets, wydajność w symulacji telefonu |
| PageSpeed Insights | dane polowe CrUX z 28 dni dla mobile i Lighthouse |
| Chrome DevTools, Device Mode | układ na różnych szerokościach, poziome przewijanie, breakpointy |
| Google Search Console, Narzędzie do sprawdzania adresów URL | wyrenderowany HTML i zrzut strony widziany przez Googlebota Smartphone |
| Google Search Console, raport Core Web Vitals | grupy URL-i z wynikami LCP, INP i CLS na mobile |
| Screaming Frog SEO Spider (user-agent Googlebot Smartphone) | porównanie treści, linków i meta robots z crawlem desktopowym |
Narzędzie do sprawdzania adresów URL w Google Search Console polecam jako pierwszy test parytetu treści: „Testuj wersję opublikowaną” pokazuje HTML po wyrenderowaniu przez Googlebota Smartphone. Jeśli w wyrenderowanym HTML brakuje opisu produktu albo opinii, Google tej treści nie widzi. Mobile to też jeden z kroków w moim poradniku jak zrobić audyt SEO.
Mobile SEO a wyszukiwarki AI
Wyszukiwarki AI czytają HTML, a nie wygląd strony na telefonie, więc dla nich liczy się treść dostępna bez interakcji. W audycie bynajmniej.pl cała treść wpisów jest w HTML bez JavaScriptu, a TTFB wynosi około 190 ms przy HTML o wadze 116 KB. Strona, która pokazuje treść Googlebotowi Smartphone dopiero po kliknięciu „Czytaj dalej”, ryzykuje, że boty AI też tej treści nie dostaną.
FAQ: mobile SEO
Co to jest mobile SEO?
Mobile SEO to optymalizacja strony pod smartfony: responsywny układ, ta sama treść i metadane co na desktopie, szybkie ładowanie i brak natrętnych nakładek. Mobile SEO wynika z mobile-first indexing, czyli oceniania stron przez Google w wersji mobilnej.
Jak sprawdzić, czy strona jest dostosowana do urządzeń mobilnych?
Stronę mobilną sprawdzisz w Lighthouse w Chrome DevTools (tryb mobile) i w PageSpeed Insights. Test optymalizacji mobilnej Google został wycofany, a raport „Obsługa na urządzeniach mobilnych” w Search Console już nie istnieje.
Czy strona responsywna wystarczy do mobile SEO?
Strona responsywna rozwiązuje parytet treści i metadanych, bo HTML jest ten sam na każdym urządzeniu. Responsywny układ nie gwarantuje jednak dobrych Core Web Vitals na mobile ani braku natrętnych pop-upów.
Czy Google indeksuje wersję desktopową strony?
Google indeksuje wersję mobilną większości stron, a większość żądań wykonuje Googlebot Smartphone. Googlebot Desktop nadal istnieje, ale ma ten sam token w robots.txt.
Czy pop-up na telefonie obniża pozycje w Google?
Google zaleca unikanie pełnoekranowych nakładek i zastępowanie ich małymi banerami, bo zasłaniają treść użytkownikom i wyszukiwarce. Nakładki wymagane prawem, np. weryfikacja wieku, są wyłączone z tej zasady.

Członek zarządu i współwłaściciel agencji IF.PL, w SEO od ponad 20 lat (m.in. Gazeta.pl, Wirtualna Polska, Polska Press). Na bynajmniej.pl piszę z pomocą AI: temat, dane i testy są moje, AI pomaga ubrać to w słowa.


Dodaj komentarz