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

Część przewodnika: SEO lokalne 2026, kompletny przewodnik dla małej firmy →
Ten artykuł rozwija jeden z wątków pełnego przewodnika.

W skrócie: Mobile-first indexing od lipca 2024. Google indeksuje TYLKO mobilną wersję strony, desktop dla algorytmu nie istnieje. 75 % wyszukiwań lokalnych = telefon.

• Klucz: strona projektowana mobile-first, nie ‘desktop + responsive’
• Cele: touch targets 44px+, font 16px+, nie pinch-zoom
• Tools: Mobile-Friendly Test, Lighthouse Mobile, real device testing

W 2026 75% wyszukiwań lokalnych idzie z telefonu. Klient szuka „pizza Kraków centrum” w drodze, „dentysta blisko mnie” w przerwie obiadowej, „domek na weekend” leżąc na kanapie. Twoja strona działa albo na telefonie, albo jej w ogóle nie ma.

Google to wie. Od 2024 indeksuje wyłącznie mobilną wersję strony, desktop dla algorytmu nie istnieje. Jeśli Twoja strona na telefonie ładuje się 6 sekund, ma drobny tekst i przyciski, które się klikają „na siłę”, tracisz pozycje rankingowe i klientów.

Co dokładnie znaczy mobile-first w 2026

To nie tylko „responsywność” (strona dostosowuje się do ekranu). W 2026 mobile-first to:

• PageSpeed mobile 90+ (nie tylko desktop). Google patrzy na mobile metryki
• LCP (Largest Contentful Paint) < 2,5s, pierwsze widoczne treści w 2,5 sekundy
• CLS (Cumulative Layout Shift) < 0,1, strona nie skacze podczas ładowania
• INP (Interaction to Next Paint) < 200ms, kliknięcie reaguje natychmiast
• Tap targets ≥ 48 px, przyciski, które łatwo kliknąć kciukiem
• Czcionka 16 px+, czytelne bez zoom
• Klikalne numery telefonu (tel: schema)
• Brak full-screen pop-upów (Google karze za interstitial intrusive content)
• Touch-first interactions, bez hover effects, które nie działają na mobile
• Optymalizowane formularze - inputmode, autocomplete, odpowiednie typy pól (tel, email, numeric)

Większość firm sprawdza tylko, czy strona „się składa” na telefonie. To za mało w 2026. Google ocenia całe doświadczenie mobile, nie tylko czy elementy nie wychodzą poza ekran.

Co realnie zmienia mobile-first index

Google ogłosił mobile-first indexing w 2018, ale do 2024 wciąż brał pod uwagę wersję desktop dla niektórych typów wyszukiwań. Od lipca 2024 to się skończyło. Googlebot Mobile jest jedynym crawlerem dla wszystkich nowych i większości starych domen.

Konsekwencje praktyczne:

1. Treść widoczna tylko na desktopie nie istnieje dla Google. Jeśli Twoja strona na desktop ma rozbudowane menu z 20 podstronami, ale mobile ma tylko 5. Google widzi tylko 5.

2. Zdjęcia i obrazy widoczne tylko na desktop nie są indeksowane. Jeśli ukrywasz galeriy na mobile (display: none), zdjęcia nie wchodzą do Google Image Search.

3. Schema.org renderowane tylko na desktop nie działa. JSON-LD musi być w mobilnej wersji HTML.

4. Strony bez wersji mobilnej dostają przekierowanie do indeksu. W praktyce, nie indeksowane wcale dla nowych podstron, stopniowo wyrzucane z indeksu dla starych.

Najczęstsze błędy mobile w 2026

1. Wolne ładowanie obrazów

Strony z 2 MB obrazów na home page = 5+ sekund na słabym 4G. Każda sekunda powyżej 3 = -20% osób, które przechodzą do kontaktu (dane Google 2024).

Co zrobić:

• WebP / AVIF zamiast JPEG / PNG (30-60% mniejsze)
• Lazy loading (loading="lazy") na wszystkich obrazach poniżej fold
• srcset z różnymi rozmiarami dla różnych szerokości ekranu
• fetchpriority="high" na hero image
• Kompresja przez TinyPNG / Squoosh / ImageOptim

Strony Lokal360 używają WebP, lazy loadingu i obrazów dopasowanych do rozmiaru ekranu, banner home schodzi z 4 MB do 80 KB.

2. Hamburger menu z 12 pozycjami

Klient na mobile nie szuka pełnej mapy strony. Chce wykonać 1-3 akcje: zadzwonić, zobaczyć ofertę, zarezerwować. Hamburger menu z 12 pozycjami w hierarchii 3 poziomów to UX horror.

Co zrobić:

• Maksymalnie 5-7 pozycji w głównym menu mobilnym
• Najważniejsze akcje (Telefon, Rezerwacja) jako przyciski poza menu
• Sticky bottom bar na mobile z 3 przyciskami: Telefon, Mapa, Rezerwacja

3. Formularze bez optymalizacji mobile

Klient na telefonie nie wpisze ręcznie 10-cyfrowego numeru bez wsparcia keyboardu. Pola muszą mieć:

• autocomplete="tel", telefon, podpowiada zapisany numer
• autocomplete="email", e-mail
• autocomplete="name", imię i nazwisko
• inputmode="tel", keyboard cyfrowy dla telefonu
• inputmode="email", keyboard z @ dla e-maila
• type="tel", type="email", type="number", odpowiednie typy

Bez tego formularz mobile jest 3× trudniejszy do wypełnienia, a liczba osób, które go kończą i się zgłaszają, spada o 40-60%.

4. Tylko numery klikalne, nie całe sekcje

Klient chce kliknąć cały kafelek „Zadzwoń: 888 699 533”, nie tylko cyferki. Cały element (z ikonką telefonu, tekstem, numerem) musi być wewnątrz <a href="tel:+48888699533">.

Bonus: dodaj wokół data-action dla GA4/GTM tracking, będziesz wiedział, ile telefonów wygenerowała strona.

5. Pop-up cookie banner blokujący 70% ekranu

Google karze duże pop-upy mobile (Mobile Interstitials Policy). Banner musi:

• Być dyskretny (max 15% wysokości ekranu)
• Mieć opcję „Akceptuj wszystkie” i „Tylko niezbędne” w jednej linii
• Pamiętać wybór (nie pojawiać się przy każdym powrocie)
• Nie blokować zawartości głównej

6. Ukryta zawartość na mobile (display: none)

Często deweloperzy ukrywają „nieistotne” elementy na mobile, żeby uprościć layout. Problem: Google indeksuje mobile, więc ukryta treść = nieindeksowana treść.

Co zrobić:

• Pokaż całą treść na mobile, ale z lepszą strukturą (accordions, tabs)
• Nigdy nie używaj display: none na zachęcie do kontaktu, formularzach, ważnych tekstach SEO
• Jeśli musisz ukryć (np. dekoracyjne elementy), używaj visibility: hidden lub aria-hidden="true" zamiast display: none

7. Hover effects bez fallback dla touch

Nawigacja oparta na hover (rozwijane menu po najechaniu) nie działa na touch. Jeśli klient nie może otworzyć menu kliknięciem, podstrony są niedostępne.

Co zrobić:

• Menu rozwijane na klik (toggle), nie hover
• Hover jako bonus dla desktop, nie jako jedyny mechanizm
• Tap targets dla wszystkich rozwijanych elementów

Jak zweryfikować swoją stronę

Test 1. PageSpeed Insights mobile

pagespeed.web.dev → wpisz URL → zakładka „Mobile”.

• 90+ ✓ w porządku
• 80-89 średnio, można poprawić
• poniżej 80 ✗ problem, działania konieczne

Test 2. Mobile-Friendly Test

search.google.com/test/mobile-friendly → wpisz URL.

Wynik „Page is mobile-friendly” = OK. Cokolwiek innego = działanie konieczne.

Test 3. Real User Metrics w Search Console

Google Search Console → „Core Web Vitals” → „Mobile”. Pokazuje, ile URL-i jest „Good”, „Needs improvement”, „Poor” na podstawie rzeczywistych użytkowników.

Test 4, własny telefon w warunkach realnych

Wyłącz WiFi, użyj danych mobilnych (4G), tryb prywatny:

• Czas ładowania (zegar, powyżej 4 sek = problem)
• Łatwość kliknięcia w przyciski (próbuj kciukiem, nie palcem wskazującym)
• Czytelność tekstu bez zoom
• Działanie formularzy
• Otwieranie menu

Ten test wykrywa rzeczy, których automatyczne narzędzia nie zauważają.

Kiedy WordPress przestaje wystarczać

Dla małej firmy, która zaczyna teraz, WordPress wymaga 5+ wtyczek tylko żeby osiągnąć podstawową szybkość mobile:

• WP Rocket (cache), 50 USD/rok
• ShortPixel / Imagify (optymalizacja obrazów), 9 USD/mies
• Asset CleanUp (usuwanie nieużywanego CSS/JS), 39 USD/rok
• Cloudflare APO (CDN), 5 USD/mies
• Premium hosting (Kinsta, WP Engine), 30-100 USD/mies

Plus własna praca nad usuwaniem niepotrzebnych wtyczek, audytem motywu, testowaniem.

Strony statyczne (HTML/CSS bez frameworków, generowane przez Astro / Hugo / Eleventy) dają natywne 99/100 PageSpeed mobile bez żadnych wtyczek. Bez kosztów subskrypcji. Bez ryzyka, że kolejna aktualizacja wtyczki coś popsuje.

Pakiety stron Lokal360 startują od 1 299 zł. Realizacja w 5-7 dni roboczych. PageSpeed 99/100 mobile standardowo, bez dłubania przy wtyczkach.

Więcej: WordPress vs strona statyczna 2026, PageSpeed jako ranking factor.

Plan działania, jeśli masz wolny mobile

1. Pomiar. PageSpeed Insights mobile, Search Console Core Web Vitals, własny telefon
2. Analiza, najczęstsze przyczyny: wolne obrazy, ciężki JS, hamburger UX, brak schema mobile
3. Decyzja:
   • PageSpeed mobile 60-80 → optymalizacja warta zachodu (1-2 dni, 500-1500 zł)
   • PageSpeed mobile poniżej 50, WordPress z wieloma wtyczkami → migracja na statyczną tańsza długoterminowo
4. Wdrożenie, wg listy „Najczęstsze błędy” wyżej
5. Mierzenie. Search Console Core Web Vitals aktualizuje się co 28 dni z rzeczywistych danych

Powiązane wpisy

• PageSpeed jako ranking factor 2026
• Core Web Vitals 2026
• Dlaczego strona ładuje się wolno
• WordPress vs strona statyczna 2026
• Audyt SEO strony, checklist 2026
• 30-dniowy plan local SEO
• Strona w 7 dni, jak to robię

Zostaw numer w formularzu, sprawdzę bezpłatnie Twoją stronę pod kątem mobile-first i powiem konkretnie, co poprawić, czy warto optymalizować obecną, czy migrować na nową. W 24h, bez zobowiązań.