Definicja mobile-first index i jej znaczenie dla SEO
Mobile-first index to model, w którym Google do oceny i rankingu treści używa wersji strony pobranej przez robota udającego smartfon, a nie przeglądarkę na komputerze. W skrócie: to, jak Twoja strona działa i wygląda na telefonie, decyduje o pozycjach w wynikach wyszukiwania. Google zaczął skanować strony jako smartfon w 2016 roku, a 31 października 2023 roku ogłosił, że przejście na indeksowanie mobilne jest zakończone. Zmiana wymusiła nowe podejście do tworzenia i optymalizacji stron internetowych, w którym punktem wyjścia jest ekran telefonu.
Mechanizm indeksacji mobilnej w praktyce
Googlebot na smartfony pobiera Twoją stronę i analizuje 4 obszary:
- zawartość tekstową dostępną w kodzie widoku na telefon, bo to on trafia do indeksu,
- strukturę HTML oraz elementy interfejsu, niezależnie od tego, czy masz osobny szablon mobilny, czy projekt elastyczny,
- dostępność zasobów, czyli plików CSS, JavaScript i obrazów, które robot musi pobrać, żeby wyrenderować stronę,
- dane strukturalne, meta-title i meta-description, które według Google powinny być takie same w obu wersjach.
Jeśli mobilna wersja strony różni się od desktopowej, np. ma mniej treści albo inne nagłówki, możesz stracić widoczność w Google, bo wyszukiwarka ocenia tylko to, co dostała na smartfonie. Dokumentacja Google wprost ostrzega, że przy celowo okrojonej zawartości mobilnej trzeba spodziewać się spadku ruchu. Wyjątek dotyczy bardzo małej grupy stron, które na urządzeniach przenośnych w ogóle nie działają: te Google nadal próbuje skanować starym robotem desktopowym.
Weryfikacja typu indeksacji w Google Search Console
Typu robota nie musisz już sprawdzać, bo w październiku 2023 roku Google usunął tę informację z ustawień Search Console, a każdą stronę działającą na telefonach odwiedza głównie Googlebot na smartfony. Zamiast dawnych kroków masz do dyspozycji trzy miejsca:
- raport "Statystyki indeksowania", otwierany z menu Ustawienia usługi, z historią pobierania przez Google; według pomocy przydaje się głównie przy ponad 1000 adresach,
- narzędzie do sprawdzania adresów URL, które pokaże stan indeksowania pojedynczej podstrony,
- raport "Indeksowanie stron", następca dawnego "Pokrycia", z listą zindeksowanych i pominiętych URL-i oraz przyczyną wykluczenia.
Sekcji "Użyteczność mobilna", do której odsyłały starsze poradniki, nie znajdziesz, bo Google wycofał ją 1 grudnia 2023 roku. Tego samego dnia zniknął test optymalizacji mobilnej. Właścicielom mniej niż 500 podstron pomoc Search Console podpowiada nawet, że zamiast raportu wystarczy im wyszukiwanie z operatorem site:.
Wymogi techniczne i projektowe dla wersji mobilnej
Strona dobrze oceniana na smartfonach ma tę samą treść co wersja na komputer, czytelne litery, duże pola dotyku i szybki pierwszy widok. Konkretne progi wyglądają tak:
- projekt elastyczny (responsywny) - ten sam kod HTML pod tym samym adresem, a układ dopasowuje się do ekranu przez media queries w CSS; Google nazywa tę konfigurację najłatwiejszą we wdrożeniu i utrzymaniu,
- pełna treść na telefonie - nie usuwaj tekstów, nagłówków ani sekcji obecnych na komputerze, możesz je za to schować w akordeonie albo na kartach,
- wielkość czcionek - Lighthouse zaliczy audyt, gdy co najmniej 60% tekstu ma 12 px lub więcej, a mniejsze litery są według tej dokumentacji trudne do przeczytania na telefonie,
- odpowiednia wielkość elementów klikalnych - przyciski i linki o wymiarach 48 x 48 px nigdy nie oblewają audytu Lighthouse, a 8 px odstępu między nimi to dobry punkt wyjścia,
- brak poziomego przewijania - układ nie może wychodzić poza szerokość ekranu, pomaga max-width: 100% dla obrazów i kontenerów,
- szybkość ładowania - raport Core Web Vitals uznaje stronę za dobrej jakości przy LCP do 2,5 s, INP do 200 ms i CLS do 0,1,
- testy w narzędziach Google - Lighthouse i PageSpeed Insights, bo test optymalizacji mobilnej już nie działa.
Najczęstsze uchybienia w projektowaniu mobilnym
Najczęściej pozycje i użytkowników kosztują: drobny tekst, ciasno ułożone linki, ciężkie grafiki, różnice w treści między wersjami i okna zasłaniające całą stronę. Lista z konkretnymi progami:
- zbyt mała czcionka, która wymaga powiększania, czyli poniżej 12 px dla większości tekstu,
- linki umieszczone zbyt blisko siebie, co utrudnia trafienie palcem; Lighthouse zgłasza element mniejszy niż 48 x 48 px, gdy co najmniej 25% jego obszaru w promieniu 48 px od środka nachodzi na inny,
- ciężkie elementy graficzne w pełnej rozdzielczości z wersji na komputer, które wydłużają ładowanie przez sieć komórkową,
- brak danych strukturalnych w wersji mobilnej albo ich niekompletność w porównaniu z widokiem na komputer; przy wyborze kolejności Google zaleca zacząć od Breadcrumb, Product i VideoObject,
- treści we Flashu - wyszukiwarka Google przestała je obsługiwać pod koniec 2019 roku i pomija je na stronach,
- okna zakrywające całą zawartość, które według Google utrudniają interpretację treści i mogą obniżać pozycję w wynikach; zamiast nich lepiej użyć banera zajmującego niewielki fragment ekranu.
Narzędzia diagnostyczne do oceny mobilności strony
Do sprawdzenia wersji mobilnej służy 5 rodzajów bezpłatnych narzędzi:
- Lighthouse - audyt w Chrome DevTools z kategoriami wydajność, ułatwienia dostępu, sprawdzone metody i SEO; to do niego Google odsyła po wycofaniu testu optymalizacji mobilnej,
- PageSpeed Insights - pomiar szybkości z osobnymi wynikami dla telefonu i komputera, z danymi od realnych użytkowników, gdy jest ich wystarczająco dużo,
- Search Console - raport Core Web Vitals z osobnym widokiem dla urządzeń mobilnych i listą adresów o stanie Słabej jakości albo Wymagana poprawa,
- testery responsywności - Responsively.app, Screenfly albo wbudowane w przeglądarki narzędzia dla programistów,
- Chrome DevTools Device Mode - symulacja różnych urządzeń z możliwością spowolnienia sieci.
Zastosowanie responsywnego frameworka lub szablonu
Projekt elastyczny dopasowuje się do różnych ekranów bez oddzielnej wersji mobilnej, a Google opisuje go jako jedną z 3 konfiguracji, obok dynamicznego wyświetlania treści i osobnych adresów URL. Gotowe biblioteki, takie jak Bootstrap, Foundation albo Tailwind CSS, mają wbudowane punkty przełamania i komponenty pod telefony. Subdomena typu m.domena.pl wymaga dodatkowych zabiegów: tych samych tagów robots meta, odpowiednika dla każdej podstrony i oddzielnych powiązań hreflang dla obu wariantów.
Zachowanie pełnej treści w wersji mobilnej
Cały tekst musi być w kodzie przeznaczonym na smartfony, bo indeksowana jest wyłącznie ona. Akordeony i karty są dozwolone, Google sam je proponuje zamiast usuwania opisów, pod warunkiem że zawartość jest w HTML od początku. Kłopot pojawia się, gdy treść wczytuje się dopiero po kliknięciu, przesunięciu palcem albo wpisaniu znaków, bo takiego leniwego ładowania robot nie uruchomi. Szczególnie zadbaj o opisy produktów, specyfikacje techniczne i dane kontaktowe.
Kompresja i optymalizacja zasobów multimedialnych
Lżejsze zasoby skracają ładowanie na telefonie, a próg dobrego LCP w raporcie Core Web Vitals wynosi 2,5 s. Wgraj grafiki w formacie WebP lub AVIF z sensownym poziomem kompresji, usuń zbędne wtyczki i skrypty śledzące, a JavaScript wczytuj tylko tam, gdzie jest potrzebny. Atrybut loading="lazy" stosuj do obrazów poniżej pierwszego ekranu, ale nie do zdjęcia widocznego od razu, bo web.dev odradza leniwe ładowanie obrazu LCP. Pliki statyczne możesz rozsyłać przez CDN i ograniczyć liczbę żądań HTTP, łącząc je tam, gdzie to możliwe.
Testowanie na fizycznych urządzeniach mobilnych
Symulator nie zastąpi telefonu, dlatego sprawdź stronę na iPhonie i na smartfonie z Androidem: menu, nawigację i formularze. Zwróć uwagę na czas ładowania przez wolniejsze połączenie, zachowanie strony w pionie i w poziomie oraz gesty, takie jak przesunięcie, powiększanie dwoma palcami i przewijanie. Dane z realnych wizyt pokaże Ci zestawienie Core Web Vitals, które dzieli adresy na grupy podobnych podstron.
Systematyczne monitorowanie i reagowanie na problemy
Po wycofaniu sekcji Użyteczność mobilna problemy z wersją na telefon śledzisz w Search Console, w raportach Core Web Vitals i Indeksowanie stron. Porównuj liczbę zindeksowanych adresów i ruch organiczny z urządzeń mobilnych, a po każdej aktualizacji CMS albo zmianie szablonu sprawdź kilka głównych podstron w Lighthouse. Tabela raportu Core Web Vitals pokazuje najwyżej 200 wierszy, więc przy dużej stronie filtruj ją według rodzaju błędu.
