SEO mobilne w 2026: pozycjonowanie w indeksie Mobile-First

TL;DR: Mobile-first indexing jest w 100% uruchomione od lipca 2024. Strona, którą Google faktycznie indeksuje i na której bazuje ranking, to Twoja wersja mobilna — przeszukiwana przez agenta na smartfonie. Test, którego prawie nikt nie uruchamia: otwórz Google Search Console, rozdziel topowe zapytania według urządzenia i sprawdź, gdzie zapytania notują wyraźnie słabsze wyniki na mobile niż na desktopie. W tej luce ukrywa się brakujący ruch.

Mobile-first indexing w minutę

W czerwcu 2024 Google ogłosiło ostatni etap wieloletniej migracji: od 5 lipca 2024 pozostałe serwisy, które nadal były indeksowane przez desktopowego Googlebot’a, przełączają się na crawling przy użyciu Googlebot Smartphone. Zawartość, która nie jest dostępna na urządzeniach mobilnych, nie podlega już indeksowaniu. Temat zamknięty.

Co to oznacza w praktyce: Google używa mobilnej wersji Twoich treści, przeszukiwanej przez agenta na smartfonie, do indeksowania i rankingu. W kontekście wyszukiwania wersja mobilna jest wersją kanoniczną. Ranking na desktopie jest konsekwencją indeksowania mobile.

Jeszcze jedno rozróżnienie, które warto mieć na radarze: „mobile-friendly” nie mówi nic o tym, czy rankujesz dobrze. Oznacza wyłącznie, że nie dostajesz kary za interstitiale. To całkiem inne rzeczy, a właśnie tutaj większość porad dotyczących mobile SEO myli pojęcia.

Testu prawie nikt nie robi: luka w rankingu mobile vs desktop

Ignorowałem wymiar „Device” w Google Search Console dłużej, niż powinienem. Jest dokładnie tam, w raporcie wyników wyszukiwania: jeden klik od widoku domyślnego, a przez lata traktowałem to jak przypis. Błąd. W SEOJuice, gdy przeprowadzamy audyty mobile dla nowych stron, podział urządzeń porównawczy prawie zawsze jako pierwszy pokazuje lukę, o której właściciel serwisu zwykle nawet nie miał pojęcia.

Co zrobić. Otwórz GSC, przejdź do Search results, kliknij „New”, dodaj filtr porównania i wybierz „Device: Mobile vs Desktop”. Dostaniesz Average Position obok siebie dla tych samych zapytań. Posortuj po zapytaniach z największą negatywną różnicą dla mobile: tych, gdzie pozycja na mobile jest istotnie gorsza niż na desktopie.

Mała, jednolita luka we wszystkich zapytaniach to szum. Mobile SERP-y mają inną strukturę, a pozycja może „dryfować” o 1–2 miejsca tylko dlatego, jak Google formatuje wyniki na mniejszych ekranach. Szukasz jednak czegoś konkretnego: zapytania, dla którego na desktopie jesteś na #4, a na mobile na #9. Taki wzorzec sygnalizuje problem w samej wersji mobilnej tej podstrony. Treść i linki są te same. To nie jest to samo wykonanie na mobile: szybkość, brak fragmentów treści lub błąd renderowania kosztują Ci pozycje w tym zapytaniu — i są niewidoczne, dopóki nie spojrzysz na podział według urządzeń.

Ten audyt jest darmowy, zajmuje dziesięć minut i wskazuje konkretnie, które strony wymagają prac typowo pod mobile. Większość serwisów w ogóle go nie uruchamia. Ci, którzy to robią, zwykle znajdują przynajmniej jedno zapytanie o dużym ruchu z luką rzędu 3–5 pozycji, o której wcześniej nie wiedzieli.

Mobile Core Web Vitals: te same progi, ale trudniejszy test

Poprawka, która potyka wielu specjalistów SEO, bo kilka głośnych poradników dalej robi to źle: aktualne trzy Core Web Vitals to LCP (Largest Contentful Paint — dobrze, jeśli 2,5 sekundy lub mniej), INP (Interaction to Next Paint — dobrze, jeśli 200 ms lub mniej) oraz CLS (Cumulative Layout Shift — dobrze, jeśli 0,1 lub mniej). Progi odnoszą się do 75. percentyla realnych danych z „field” (pomiary w prawdziwym świecie).

INP zastąpiło FID (First Input Delay) w 12 marca 2024. Jak ujęła to ekipa Chrome: „Po latach pracy jesteśmy w końcu gotowi uczynić Interaction to Next Paint (INP) stabilnym metryką Core Web Vital. To znaczący krok w sposobie, w jaki mierzymy responsywność interakcji, adresujący wiele ograniczeń First Input Delay (FID).” FID został całkowicie usunięty z narzędzi Chrome do września 2024. Jeśli jakiś poradnik nadal wymienia FID jako Core Web Vital, to jest ponad dwa lata do tyłu. To ważne, bo FID i INP mierzą różne rzeczy: FID mierzyło tylko opóźnienie do momentu, w którym przeglądarka zaczyna obsługiwać input, a INP mierzy pełne opóźnienie interakcji aż do kolejnego renderu. Surowsze i bardziej reprezentatywne.

Dlaczego wyniki CWV na mobile regularnie zawodzą, gdy na desktopie jest już „dobrze”: testy laboratoryjne symulują średni model Androida na 4G z włączonym throttlingiem CPU. Twój MacBook z serii M uruchamiający Chrome DevTools nie jest takim urządzeniem. Strona, która renderuje się u Ciebie w 1,8 sekundy na laptopie, może dojść do 3,2 sekundy na prawdziwym Moto G przy sygnale 4G. Ta sama baza kodu, to samo hostowanie. To właśnie kara za throttling sprawia, że wyniki na mobile rozjeżdżają się względem desktopu.

(Będę tu szczery: dokładne mnożniki throttlingu, które stosuje Chrome DevTools, zmieniały się między wersjami, a dane z prawdziwego CrUX mogą w obie strony różnić się od wyników lab — zależnie od realnej dystrybucji urządzeń wśród Twoich użytkowników. Traktuj dane z „field” z PageSpeed Insights (szczególnie zakładka mobile) jako sygnał nadrzędny. Wyniki lab są przydatne do wykrywania regresji, ale mniej jako jedyne źródło prawdy.)

Gdzie sprawdzić dane „field” dla mobile: PageSpeed Insights pobiera dane CrUX segmentowane według urządzeń. Raport Core Web Vitals w Google Search Console pokazuje mobile jako osobny kubeł, oddzielony od desktopu. Podstrona, która ma „dobry” wynik w segmencie desktop, a „słaby” w segmencie mobile, wymaga prac pod mobile. Nasz przewodnik do audytu Core Web Vitals pokazuje, jak czytać i jak działać na podstawie każdej metryki. Dla kontekstu punktacji Lighthouse: jak Lighthouse liczy Twój wynik SEO wyjaśnia, jak metryki laboratoryjne przekładają się na realny output z audytu.

Renderowanie na mobile, parytet i pułapka JS/SPA

Google jest jednoznaczne w kwestii parytetu treści: „Do indeksowania wykorzystuje się tylko tę treść, która jest widoczna na stronie mobilnej.” Różnice w designie są w porządku. Akordeony, sekcje rozwijane, zakładki — treść ukryta za nimi i tak trafia do indeksu. Nie indeksuje się natomiast treści, których w ogóle nie ma w DOM wersji mobilnej, ani treści, które wymagają interakcji użytkownika, by się pojawiły. Jeśli szablon na desktopie pokazuje szczegóły produktu w bocznym panelu, który zwija się na mobile i nigdy nie renderuje się realnie w DOM mobile, to w indeksie tego nie ma.

Sytuacja z SPA jest bardziej subtelna. Google przetwarza aplikacje JavaScript w trzech etapach: crawling, rendering, indexing. Strony trafiają do kolejki renderowania; w dokumentacji Google jest notatka, że strona „może pozostać w tej kolejce przez kilka sekund, ale to może trwać dłużej”, a gdy zasoby pozwolą, headless Chromium ją renderuje. Na throttlowanym CPU w telefonie wolne „hydration” dokładnie dokłada opóźnienie do kolejki. Jeśli mobile crawl Googlebota trafi na Twoje SPA i główna treść wyświetli się dopiero 4–5 sekund w trakcie hydration, istnieje realna szansa, że zrenderowany snapshot jest niekompletny. Na Twojej maszynie deweloperskiej, gdzie działa ta sama aplikacja, nie widać tego efektu. Hydratuje się poniżej sekundy.

Test jest prosty: w Search Console otwórz URL Inspection dla dowolnej strony, co do której podejrzewasz problem. Kliknij „Test live URL”, potem „View tested page” i przełącz na zakładkę HTML. To jest HTML, który zachwycił Googlebot. Porównaj go z tym, co widzisz w przeglądarce. Brak treści w body albo znaczne jej ucięcie w widoku inspekcji oznacza problem z renderowaniem. Opcje naprawy (server-side rendering, static generation, prerenderowanie treści „above the fold”) omawiamy w naszym przewodniku SEO dla SPA.

Viewport, tap targets i nachalne interstitiale

To są podstawowe mechaniki. Warto potwierdzić raz; nie warto przesadnie się nad nimi rozwodzić.

Meta tag viewport: <meta name="viewport" content="width=device-width, initial-scale=1"> w Twoim <head>. Bez niego przeglądarki mobilne renderują stronę w szerokości desktopu i pomniejszają widok (zoom out). Trzydziestosekundowa poprawka, jeśli tego brakuje.

Tap targets: Przyciski i linki powinny mieć co najmniej 48 CSS pikseli wysokości i szerokości oraz odpowiedni odstęp między elementami. Lighthouse flaguje cele zbyt małe albo umieszczone zbyt blisko siebie (własne minimum WCAG jest niższe, ale 48px to bezpieczny próg na przejście Lighthouse). To mniej kwestia bezpośredniego wpływu na ranking, a bardziej zachowania użytkowników — sygnały typu bounce, które wracają do systemów oceniających.

Nachalne interstitials: Google ma udokumentowany sygnał degradacji dla stron, które na wejściu na mobile pokazują pełnoekranowy popup, zanim użytkownik dostanie dostęp do treści. Pop-upy wychwytywane na intencję zamknięcia, banery cookie wymagane prawem oraz opóźnione nakładki po kilku sekundach zaangażowania są OK. Pełnoekranowy „subskrybuj, zanim przeczytasz”, odpalany przy wczytaniu strony — nie.

Lista kontrolna audytu: mobile vs desktop

Wersja referencyjna audytu dla tej luki. Kolumna „Symptom” to to, co widzisz w GSC lub analityce; reszta pokazuje, jak to zdiagnozować i naprawić.

Różnice w keywordach i SERP: mobile vs desktop

Na mobile w SERP jest mniej wyników organicznych powyżej linii widoczności („above the fold”), więcej wpisów w lokalnym „pack” i więcej intencji typu „near me”. Użytkownicy mobile częściej kierują się zapytaniami lokalnymi oraz transakcyjnymi. Jeśli masz podstrony wrażliwe na lokalizację, które dobrze rankują na desktopie, ale nie konwertują ruchu mobile, sprawdź, czy lokalny pak nie spycha Twojego wyniku organicznego całkowicie poniżej linii widoczności. To problem układu SERP — naprawa to lokalna optymalizacja.

Mobile SEO triage w 20 minut

W kolejności wpływu. Uruchom te kroki raz, a będziesz dokładnie wiedzieć, gdzie powinien pójść Twój czas.

1. Audyt luki w GSC według urządzeń. Wyniki wyszukiwania, porównanie urządzeń, sortuj po największej negatywnej różnicy dla mobile. Oznacz każde zapytanie z luką 3+ pozycje i zanotuj URL-e.
2. PageSpeed Insights na stronach z luką. Wprowadź oznaczone URL-e w zakładkę mobile. Najpierw sprawdź dane field w CrUX, potem wyniki lab. Zanotuj, która z metryk — LCP, INP lub CLS — nie spełnia progu.
3. Sprawdzenie rendered-HTML w URL Inspection. Dla najbardziej ruchliwych stron z luką, szczególnie jeśli wdrażasz React, Vue lub Angular SPA, uruchom URL Inspection i potwierdź, że treść w body jest obecna w renderowanym HTML. Jeśli jej brakuje, napraw renderowanie jako pierwsze — optymalizacja szybkości jest sprawą drugorzędną.
4. Trzy mechaniczne poprawki. Potwierdź istnienie meta viewport, sprawdź tap targets w Lighthouse i upewnij się, że interstitial przy wejściu nie odpala się na mobile. Godzina, żeby zweryfikować to na całej stronie — i łatwo to delegować.

Cel jest prosty: ustalić, jaki problem masz, zanim zaczniesz naprawiać niewłaściwy. Nasza checklista audytu SEO hygiene obejmuje szerszą warstwę techniczną, jeśli po tym triage chcesz zrobić bardziej kompleksowy przegląd.

Urządzenia mobilne odpowiadają za około połowę całego ruchu w sieci na świecie — około 50–52% w danych StatCounter z maja 2026 (samo mobile: 50,3%, mobile i tablet razem: 51,8%). Jakąkolwiek liczbę przyjmiesz: wersja mobilna Twojej strony to główny „surface” komercyjny i jedyna, którą Google rankuje.

Uruchom darmowy audyt SEO, aby zobaczyć Twoje luki mobile vs desktop i które problemy mobilne zabierają Ci pozycje.

Najczęściej zadawane pytania

Co to jest mobile-first indexing?

Mobile-first indexing oznacza, że Google crawluje i indeksuje Twoją stronę przy użyciu agenta Googlebot Smartphone, a treści z Twojej wersji mobilnej są wykorzystywane do rankingu. Wdrożenie jest zakończone: od lipca 2024 dotyczy to 100% indeksowanych serwisów. Treści, które pojawiają się wyłącznie na wersji desktopowej, są dla Google niewidoczne.

Czy Google rankuje osobno mobile i desktop?

Istnieje jeden indeks zbudowany na bazie Twojej strony mobilnej. Układ SERP różni się w zależności od urządzenia, więc średnie pozycje mogą się różnić o jedno lub dwa miejsca. Duża luka per zapytanie (np. #4 na desktop i #9 na mobile) zwykle oznacza konkretny problem w wersji mobilnej tej podstrony.

Jak sprawdzić moje pozycje na mobile?

Google Search Console → Search results → kliknij „New” → porównanie urządzeń → Mobile vs Desktop, pokazując Average Position. Sortuj po największej negatywnej różnicy dla mobile. Trackery rankingu, które wspierają segmentację według urządzeń, mogą też pokazać ten widok na poziomie keywordu — co przydaje się do monitorowania w czasie.

Czy szybkość strony na mobile to czynnik rankingowy?

Tak. Mobile Core Web Vitals (LCP, INP i CLS) zasilają sygnały jakości doświadczenia na stronie, a ponieważ indeksowana jest wersja mobilna, szybkość na mobile wpływa na Twoje pozycje dla wszystkich użytkowników wyszukiwarki. Test na throttlowanych urządzeniach, którego używa Google, sprawia, że nawet ta sama strona często wypada gorzej na mobile niż na desktop — mimo braku różnic w kodzie stricte dla mobile.

Powiązana lektura:

• Core Web Vitals w 2026: co się zmieniło i jak audytować
• SPA SEO: najlepsze praktyki — jak sprawić, by aplikacje JavaScript były indeksowalne
• Checklist audytu SEO hygiene: unikaj utraty ruchu
• Co tak naprawdę mierzy wynik Lighthouse SEO