Indeksowanie Mobile-First

TL;DR — Indeksowanie mobile-first oznacza, że Google patrzy na mobilną wersję Twojej strony — a nie na wersję na komputery — aby zdecydować, o czym jest Twoja strona i jak ją pozycjonować. To nie jest osobny „indeks mobilny” i nie jest to wzmocnienie pozycji. Jedyna rzecz, na którą musisz zwrócić uwagę: wszystko, co chcesz, aby Google zobaczył, musi znajdować się na Twojej mobilnej stronie, ponieważ to właśnie tę wersję indeksuje.

Czym jest indeksowanie mobile-first

Gdy Google indeksuje Twoją witrynę, najczęściej odwiedza ją jako smartfon — używając mobilnego robota o nazwie Googlebot smartphone. To, co widzi na mobilnej wersji Twojej strony, jest tym, co indeksuje i pozycjonuje. To jest indeksowanie mobile-first w jednym zdaniu: Google używa mobilnej wersji Twoich treści do indeksowania i pozycjonowania.

Nazwa może mylić, więc od razu wyjaśnię dwie rzeczy:

• Nie ma osobnego „indeksu mobilnego”. Google ma jeden indeks. Indeksowanie mobile-first zmieniło tylko która wersja Twojej strony jest brana pod uwagę — kiedyś domyślnie była to wersja na komputery, teraz jest to wersja mobilna.
• To nie jest wzmocnienie pozycji. Bycie objętym indeksowaniem mobile-first nie podnosi Twoich pozycji. Zmienia tylko to, którą wersję Twoich treści Google czyta.

Dlaczego to ważne: to, co jest na wersji mobilnej, ma znaczenie

Oto część, która faktycznie wpływa na Twoją witrynę. Jeśli coś istnieje na Twojej stronie na komputery, ale nie na Twojej stronie mobilnej — akapit tekstu, obraz, link, jakieś dane strukturalne — Google może po prostu tego nie zobaczyć, ponieważ indeksuje wersję mobilną.

Typowy przykład z życia: witryna pokazuje pełny artykuł na komputerze, ale skraca go na urządzeniach mobilnych, aby „zachować porządek”. Przy indeksowaniu mobile-first przycięte treści mogą nigdy nie zostać zaindeksowane. Rozwiązanie nie jest skomplikowane — upewnij się, że ważne rzeczy są również w wersji mobilnej.

Indeksowanie mobile-first to nie to samo co „mobile-friendly”

Te dwa pojęcia są ciągle mylone. Indeksowanie mobile-first dotyczy której wersji Google indeksuje. Przyjazność mobilna dotyczy tego, jak użyteczna jest Twoja strona na telefonie — celów dotykowych, czytelnego tekstu, braku poziomego przewijania. To osobne koncepcje. Strona może być indeksowana mobile-first i nadal być nieporęczna na telefonie, i odwrotnie. Ten artykuł dotyczy tylko pierwszego z tych pojęć.

Co powinieneś właściwie zrobić

Dla prawie wszystkich odpowiedzią jest responsywny design — jeden zestaw HTML, który dostosowuje się do rozmiaru ekranu. Dzięki temu Twoje wersje mobilna i na komputery są domyślnie tymi samymi treściami i nie musisz utrzymywać dwóch wersji w synchronizacji. To również zalecane przez Google rozwiązanie.

Jeśli używasz czegoś starszego — na przykład osobnej mobilnej witryny na własnych URL-ach (m.example.com) — to nadal działa, ale jest bardziej kruche i wymaga więcej uwagi.

Chcesz pełny obraz — zweryfikowaną oś czasu, dokładne zasady parytetu, jak Google radzi sobie z pułapką leniwego ładowania, jak porównują się opcje konfiguracji i gdzie Bing się różni? Przełącz się na zakładkę Zaawansowane.

TL;DR — Indeksowanie mobile-first = Google używa mobilnej wersji treści strony, indeksowanej przez Googlebot smartphone, do indeksowania i pozycjonowania. Jeden indeks, brak możliwości rezygnacji, to nie jest wzmocnienie pozycji. Obowiązująca zasada to parytet treści: „tylko treści pokazane na mobilnej stronie są używane do indeksowania”, więc każdy tekst, dane strukturalne, obrazy, tekst alternatywny lub linki, które chcesz zaindeksować, muszą znajdować się w mobilnym HTML. To różni się od przyjazności mobilnej / doświadczenia strony. Responsywny design to zalecana konfiguracja Google; dynamiczne serwowanie i osobne URL-e działają, ale są bardziej ryzykowne. Uważaj na pułapkę leniwego ładowania przy interakcji. Oś czasu: ogłoszone w listopadzie 2016 → domyślne dla nowych witryn w 2019 → ostatnia partia w maju 2023 → uznane za zakończone w październiku 2023. Bing nie dokonał tego samego przejścia — pozostaje niezależny od urządzenia z jednym indeksem.

Definicja, precyzyjnie

Własne ujęcie Google: Google używa mobilnej wersji treści witryny, przeszukiwanej za pomocą agenta smartfonowego, do indeksowania i rankingu. W swoim dokumencie dotyczącym najlepszych praktyk mobile-first jest jeszcze bardziej dosadny co do konsekwencji: “Only the content shown on the mobile site is used for indexing.” (tłumaczenie) „Tylko treść wyświetlana w mobilnej wersji witryny jest wykorzystywana do indeksowania.”

W moim przewodniku Ahrefs na temat indeksowania mobile-first definiuję to w ten sam sposób — indeksowanie mobile-first oznacza, że Google używa mobilnej wersji treści witryny do indeksowania i rankingu — i dodaję dwa wyjaśnienia, które eliminują większość zamieszania: “There is only one index and you can’t opt out of mobile-first indexing.” (tłumaczenie) „Istnieje tylko jeden indeks i nie można zrezygnować z indeksowania mobile-first.” Nie jest to również wzmocnienie rankingu. Zmienia to, którą wersję czyta Google, a nie jak dobrze ją rankuje.

Googlebot to głównie przeszukiwarka smartfonowa

To jest mechanizm leżący u podstaw całej sprawy. Google: “For most sites Google Search primarily indexes the mobile version of the content. As such the majority of Googlebot crawl requests will be made using the mobile crawler, and a minority using the desktop crawler.” (tłumaczenie) „W przypadku większości witryn Google Search indeksuje przede wszystkim mobilną wersję treści. W związku z tym większość żądań przeszukiwania Googlebota będzie realizowana przez przeszukiwarkę mobilną, a mniejszość przez przeszukiwarkę desktopową.” Istnieją dwa podtypy — Googlebot Smartphone (“a mobile crawler that simulates a user on a mobile device” (tłumaczenie) „przeszukiwarka mobilna, która symuluje użytkownika na urządzeniu mobilnym”) i Googlebot Desktop — ale to smartfonowy wykonuje teraz większość pracy.

Google czasami nadal przeszukuje za pomocą desktopowego user-agenta, ale wersja, która ma znaczenie dla indeksowania, to ta mobilna.

Parytet treści to zasada nr 1

Jeśli zapamiętasz jedną rzecz z tej strony, niech to będzie: to, co jest w Twojej mobilnej wersji witryny, jest tym, co zostaje zaindeksowane. Dokument Google wymienia to jako pierwszy wymóg — “Make sure that your mobile site contains the same content as your desktop site” (tłumaczenie) „Upewnij się, że Twoja mobilna witryna zawiera tę samą treść co wersja desktopowa” — a kluczowym argumentem jest to, że “only the content shown on the mobile site is used for indexing.” (tłumaczenie) „tylko treść wyświetlana w mobilnej wersji witryny jest wykorzystywana do indeksowania.”

John Mueller powiedział to tak jasno, jak to możliwe na Pubcon Pro Virtual 2020: “anything that you want to have indexed, it needs to be on the mobile site,” (tłumaczenie) „cokolwiek chcesz mieć zaindeksowane, musi znajdować się w mobilnej wersji witryny” oraz “we will only index the mobile content in the future.” (tłumaczenie) „w przyszłości będziemy indeksować tylko treści mobilne.” Jeśli coś jest dostępne tylko na desktopie, zaplanuj, że Google tego nie zobaczy.

Warto jednak zauważyć pewien niuans — parytet nie oznacza identyczności bajt po bajcie. Jak ująłem to w moim przewodniku Ahrefs na temat indeksowania mobile-first: “any important content must be present on mobile.” (tłumaczenie) „wszelka ważna treść musi być obecna w wersji mobilnej.” Możesz mieć bardziej uproszczony układ mobilny; po prostu nie możesz pominąć treści, danych strukturalnych, obrazów, tekstu alternatywnego ani linków, które faktycznie chcesz zaindeksować.

I jeszcze jeden mit do obalenia: ukryta treść w zakładkach/akordeonach jest w porządku. Przed erą mobile-first treść ukryta za interfejsem użytkownika ze względów UX była dyskontowana. To już nieaktualne — Google nie dyskontuje już treści ukrytych w celu poprawy doświadczenia użytkownika. Więc mobilny akordeon zawierający pełną treść jest w porządku; treść jest w HTML i zostaje zaindeksowana.

Elementy parytetu, które faktycznie bolą

Poza samym tekstem, dokument najlepszych praktyk Google wymienia konkretne rzeczy, które należy utrzymać jako równoważne w obu wersjach:

• Dane strukturalne. “Make sure that your mobile and desktop sites have the same structured data.” (tłumaczenie) „Upewnij się, że witryny mobilna i desktopowa mają te same dane strukturalne”. Jeśli Twój znacznik jest dostępny tylko na desktopie, Twoje rozszerzone wyniki mogą zniknąć.
• Obrazy i tekst alternatywny. “Make sure that the mobile site has the same alt text for images as the desktop site.” (tłumaczenie) „Upewnij się, że witryna mobilna ma ten sam tekst alternatywny obrazów co wersja desktopowa”. Usuwanie obrazów lub tekstu alternatywnego na mobile szkodzi wyszukiwarce obrazów.
• Tytuły i meta opisy. “Make sure that the title element and the meta description are equivalent across both versions of your site.” (tłumaczenie) „Upewnij się, że element tytułu i metaopis są równoważne w obu wersjach witryny”.
• Nagłówki. “Use the same clear and meaningful headings on the mobile site as you do on the desktop site.” (tłumaczenie) „Używaj tych samych jasnych i znaczących nagłówków w witrynie mobilnej i desktopowej”. Okrojony szablon mobilny, który usuwa H2/H3 lub spłaszcza je do zwykłego tekstu, osłabia strukturę strony dla indeksowania, nie tylko jej czytelność.
• Dane strukturalne wideo. “Use the same video structured data on both your mobile site and desktop site.” (tłumaczenie) „Używaj tych samych danych strukturalnych wideo w witrynie mobilnej i desktopowej”. Jeśli strona zawiera znacznik VideoObject na desktopie, umieść ten sam znacznik na mobile — w przeciwnym razie wersja mobilna (ta, którą Google faktycznie indeksuje) go nie ma.
• Meta tagi robots. “Use the same robots meta tags on the mobile site and the desktop site.” (tłumaczenie) „Używaj tych samych metatagów robots w witrynie mobilnej i desktopowej”. To klasyczny przypadek przypadkowego wyindeksowania: noindex, który istnieje tylko w szablonie mobilnym, spowoduje wyindeksowanie strony, ponieważ Google indeksuje wersję mobilną.
• Linki wewnętrzne. Zachowaj nawigację i kluczowe linki w mobilnym HTML. Nie ukrywaj ich za interakcjami, które muszą się uruchomić, zanim linki się załadują.

Pułapka leniwego ładowania / interakcji użytkownika

Konkretny, częsty wzorzec awarii. Google: “Don’t lazy-load primary content upon user interaction. Google won’t load content that requires user interactions (for example, swiping, clicking, or typing) to load.” (tłumaczenie) „Nie ładuj leniwie głównej treści po interakcji użytkownika. Google nie załaduje treści wymagającej interakcji, takiej jak przesunięcie, kliknięcie lub pisanie”. Jeśli Twoja główna treść pojawia się dopiero po dotknięciu “załaduj więcej”, przesunięciu karuzeli lub kliknięciu zakładki, która pobiera treść na żądanie, Googlebot nie uruchomi tej interakcji — więc treść nie jest widziana. Załaduj główną treść przy przewijaniu lub umieść ją w początkowym HTML.

Zweryfikowana oś czasu

Indeksowanie mobile-first zajęło około siedmiu lat od początku do końca. Datowane kamienie milowe:

• Listopad 2016 — Google po raz pierwszy ogłosił indeksowanie mobile-first i rozpoczął testy.
• 2018 — rozpoczęto szerokie wdrożenie po okresie testów.
• 2019 — mobile-first stał się domyślny dla nowych stron: domeny odkryte po tym czasie były indeksowane mobile-first od początku.
• Marzec 2020 — Google ogłosił, że przełączy całą sieć do września 2020. Jak ujął to Mueller, Google będzie “switching to mobile-first indexing for all websites starting September 2020.” (tłumaczenie) „przełączać wszystkie witryny na indeksowanie mobile-first od września 2020 r.”.
• Lipiec 2020 — ten termin został przedłużony. Google: “we’ve decided to extend the timeframe to the end of March 2021.” (tłumaczenie) „zdecydowaliśmy się przedłużyć termin do końca marca 2021 r.”.
• Maj 2023 — ostatnia partia została przeniesiona: “the last batch of sites eligible for mobile-first indexing have been moved over.” (tłumaczenie) „ostatnia partia witryn kwalifikujących się do indeksowania mobile-first została przeniesiona”. Praktycznie to moment, w którym wdrożenie się zakończyło.
• Październik 2023 — Google ogłosił zakończenie: “the trek to Mobile First Indexing is now complete.” (tłumaczenie) „droga do indeksowania mobile-first została zakończona” (Mueller).

Dwa poprawne sposoby powiedzenia “kiedy to było ukończone” i warto je rozróżniać: wdrożenie faktycznie zakończyło się ostatnią partią w maju 2023, podczas gdy Google oficjalnie ogłosił ukończenie w październiku 2023. “Very small set of sites which do not work on mobile devices at all” (tłumaczenie) „Bardzo mały zestaw witryn, które w ogóle nie działają na urządzeniach mobilnych”, jest po prostu indeksowany przez desktopowego Googlebota — to wyjątek, którym Google zarządza, a nie ustawienie, które wybierasz. (Informacje o “którym crawlerze” w Search Console zostały usunięte wkrótce po ogłoszeniu z października 2023, ponieważ nie było już mieszanki do raportowania.) Dla stron, które naprawdę nie są dostępne na urządzeniach mobilnych, praktyczne ryzyko teraz polega na braku możliwości indeksowania.

Konfiguracja: responsywne vs. dynamiczne serwowanie vs. osobne URL-e

Istnieją trzy sposoby serwowania mobile i Google ma wyraźną preferencję:

• Responsive design (zalecane). Jeden URL, jeden HTML, układ dostosowuje się przez CSS. Google: “zaleca Responsive Web Design, ponieważ jest to najłatwiejszy wzorzec do wdrożenia i utrzymania.” Parytet jest praktycznie automatyczny, ponieważ istnieje tylko jedna wersja.
• Dynamiczne serwowanie. Ten sam URL, ale serwer zwraca różny HTML w zależności od user-agenta. Działa, ale jest podatne na błędy — łatwo dostarczyć wersję desktopową i mobilną niezgodnie, co łamie parytet dokładnie w sposób opisany powyżej.
• Osobne URL-e (m-dot). Różny HTML na różnych URL-ach (np. m.example.com). Najmniej zalecane z trzech i najbardziej wymagające w utrzymaniu. Jeśli z tego korzystasz, wytyczne Google: “Dla osobnych URL-i ustaw wersje desktopowe jako kanoniczne z linkiem alternatywnym do wersji mobilnej” i sprawdź swoje linki hreflang między osobnymi URL-ami. Mobilny URL musi serwować pełną, ważną treść — ponieważ to ona jest indeksowana.

Jak sprawdzić, czy Twoja witryna jest objęta indeksowaniem mobile-first

W tym momencie praktycznie każda normalna witryna jest. Aby potwierdzić konkretną stronę, użyj Search Console → URL Inspection / Page indexing i sprawdź wartość “Crawled as” — “Googlebot smartphone” oznacza, że strona jest indeksowana mobile-first. (Jak wspomniano, Google usunęło szersze raportowanie informacji o crawlerach po ogłoszeniu zakończenia wdrożenia, ponieważ nie ma już znaczącego podziału.)

Czy Bing stosuje indeksowanie mobile-first? Nie.

To jest aspekt międzywyszukiwarkowy, którego prawie nikt nie porusza, a ma znaczenie, jeśli zależy Ci na czymś więcej niż Google. Bing nie przeszedł na indeksowanie mobile-first w taki sposób jak Google. Utrzymuje pojedynczy, niezależny od urządzenia indeks zamiast indeksowania wersji mobilnej specyficznie. James Murray z Microsoft Bing wyjaśnił rozumowanie: “uważamy, że bardziej przydatne jest posiadanie zintegrowanego widoku i bycie bardziej niezależnym od urządzenia” oraz “chcemy dać Ci ten sam indeks, a następnie personalizować go dla Ciebie jako użytkownika.”

Wniosek: higiena parytetu treści nadal pomaga Ci w Bing, ale Bing nie ogłosił przejścia na indeksowanie wersji mobilnej — traktuje indeks jako niezależny od urządzenia.

Częste mity, sprostowane

• “Istnieje osobny indeks mobilny.” Nie — jest jeden indeks. Indeksowanie mobile-first po prostu zmienia, którą wersję Google bierze pod uwagę.
• “To wzmocnienie pozycji.” Nie — to która treść jest indeksowana/klasyfikowana, a nie bonus.
• “To to samo co mobile-friendly.” Nie — to różne koncepcje. To dotyczy indeksowania; mobile-friendliness to użyteczność/doświadczenie strony.
• “Możesz zrezygnować / pozostać przy indeksowaniu desktopowym.” Nie. (Witryny, które naprawdę nie działają na mobile, są wyjątkiem obsługiwanym przez Google, a nie ustawieniem.)
• “Ukryta/zakładkowa/akordeonowa treść nie będzie liczona.” Nieaktualne — Google nie dyskontuje już treści ukrytych dla UX.
• “Treść mobilna musi być identyczna z desktopową.” Nie — musi zawierać tę samą ważną treść, nie być identyczna bajt po bajcie.
• “To dotyczy tylko mobilnych wyników wyszukiwania.” Nie — wersja mobilna jest używana do indeksowania i rankingu zarówno w wynikach desktopowych, jak i mobilnych.
• “Bing też robi indeksowanie mobile-first.” Nie — Bing pozostaje niezależny od urządzenia.

Aby zobaczyć, gdzie to się mieści w szerszym obrazie — crawling, renderowanie i sam indeks — zobacz centrum indeksowania. Zasady parytetu tutaj są również powodem, dla którego problemy z puchnięciem indeksu i crawlingiem pojawiają się później: jeśli Google nie widzi Twojej treści na mobile, nie może jej dobrze zaindeksować w pierwszej kolejności.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Indeksowanie mobile-first = Google używa wersji mobilnej treści strony, przeszukiwanej przez Googlebota smartphone, do indeksowania i rankingu. Jeden indeks, bez możliwości rezygnacji, nie jest to wzmocnienie rankingu — zmienia tylko którą wersję czyta Google.
• Googlebot to teraz głównie crawler smartphone — większość żądań przeszukiwania używa mobilnego crawlera, mniejszość desktopowego.
• Parytet treści to zasada nr 1: “tylko treść pokazana na mobilnej stronie jest używana do indeksowania.” Utrzymuj tekst, dane strukturalne (w tym dane strukturalne wideo), obrazy + tekst alternatywny, nagłówki, tytuły/opisy meta, meta tagi robots oraz linki wewnętrzne równoważne na mobile. Mueller: “anything that you want to have indexed, it needs to be on the mobile site.” (tłumaczenie) „cokolwiek chcesz mieć zaindeksowane, musi być na mobilnej stronie.”
• Parytet ≠ identyczność. Ważna treść musi być na mobile, ale nie musi być identyczna co do bajtu. Ukryta/treść w zakładkach jest teraz w porządku — Google już jej nie dyskontuje.
• Pułapka leniwego ładowania: Google nie wywoła interakcji (przesunięcie/kliknięcie/wpisanie), aby załadować treść. Ładuj główną treść przy przewijaniu lub w początkowym HTML.
• To nie jest przyjazność mobilna — to osobna koncepcja użyteczności/doświadczenia strony.
• Konfiguracje: responsywny jest zalecany; dynamiczne serwowanie działa, ale jest kruche; osobne URL-e (m-dot) są najmniej zalecane (ustaw desktopowy canonical + alternatywny na mobile, sprawdź hreflang).
• Oś czasu: ogłoszone w listopadzie 2016 → domyślne dla nowych stron 2019 → “cała sieć do września 2020” (ogłoszone w marcu 2020) → przedłużone do marca 2021 → ostatnia partia maj 2023 → ogłoszone jako zakończone w październiku 2023. Mały zestaw stron tylko desktopowych pozostaje na desktopowym przeszukiwaniu.
• Sprawdź to przez Search Console “Crawled as: Googlebot smartphone.”
• Bing nie przeszedł — zachowuje pojedynczy indeks niezależny od urządzenia.

Oficjalna dokumentacja

Dokumentacja źródłowa od wyszukiwarek.

Google

• Najlepsze praktyki indeksowania mobile-first — kanoniczny dokument: lista kontrolna parytetu (treść, dane strukturalne, obrazy/alt, tytuły/opisy, meta robots), zasada leniwego ładowania oraz responsywne vs. dynamiczne serwowanie vs. osobne URL-e. Zacznij tutaj.
• Googlebot — crawler, który wykonuje pracę: Googlebot Smartphone vs. Desktop i dlaczego większość żądań przeszukiwania jest mobilna.
• Przeszukiwanie i indeksowanie — centrum szerszego tematu przeszukiwania/indeksowania, w którym to się znajduje.
• Ogłoszenie indeksowania mobile-first dla całej sieci (marzec 2020) — ogłoszenie „cała sieć do września 2020”.
• Przygotuj się do indeksowania mobile-first — z dodatkowym czasem (lipiec 2020) — przedłużenie terminu do marca 2021.
• Indeksowanie mobile-first zostało wdrożone (październik 2023) — oficjalne ogłoszenie „zakończone”.

Bing / Microsoft

• Bing: No Separate Mobile Index (James Murray interview) — dlaczego Bing pozostał niezależny od urządzenia zamiast przejść na indeksowanie mobile-first.

Cytaty ze źródła

Oficjalne wypowiedzi Google i Bing. Każdy link to link bezpośredni, który przenosi do cytowanego fragmentu na stronie źródłowej.

Google — co oznacza indeksowanie mobile-first

• “Only the content shown on the mobile site is used for indexing.” (tłumaczenie) „Do indeksowania wykorzystywana jest wyłącznie treść widoczna w wersji mobilnej witryny.” Przejdź do cytatu
• “For most sites Google Search primarily indexes the mobile version of the content. As such the majority of Googlebot crawl requests will be made using the mobile crawler, and a minority using the desktop crawler.” (tłumaczenie) „W przypadku większości witryn Google Search indeksuje przede wszystkim wersję mobilną treści. W związku z tym większość żądań indeksowania Googlebota będzie wysyłana przez robota mobilnego, a mniejszość przez robota desktopowego.” Przejdź do cytatu
• “a mobile crawler that simulates a user on a mobile device.” (Googlebot Smartphone) (tłumaczenie) „robot mobilny, który symuluje użytkownika na urządzeniu mobilnym.” Przejdź do cytatu

Google — parytet treści

• “Make sure that your mobile site contains the same content as your desktop site.” (tłumaczenie) „Upewnij się, że Twoja witryna mobilna zawiera tę samą treść co witryna desktopowa.” Przejdź do cytatu
• “Make sure that your mobile and desktop sites have the same structured data.” (tłumaczenie) „Upewnij się, że Twoje witryny mobilna i desktopowa mają te same dane strukturalne.” Przejdź do cytatu
• “Make sure that the mobile site has the same alt text for images as the desktop site.” (tłumaczenie) „Upewnij się, że witryna mobilna ma ten sam tekst alternatywny dla obrazów co witryna desktopowa.” Przejdź do cytatu
• “the title element and the meta description are equivalent across both versions of your site.” (tłumaczenie) „element tytułu i metaopis są równoważne w obu wersjach Twojej witryny”. Przejdź do cytatu
• “Use the same clear and meaningful headings on the mobile site as you do on the desktop site.” (tłumaczenie) „Używaj tych samych jasnych i znaczących nagłówków w witrynie mobilnej, co w witrynie desktopowej.” Przejdź do cytatu
• “Use the same video structured data on both your mobile site and desktop site.” (tłumaczenie) „Używaj tych samych danych strukturalnych wideo zarówno w witrynie mobilnej, jak i desktopowej.” Przejdź do cytatu
• “Use the same robots meta tags on the mobile site and the desktop site.” (tłumaczenie) „Używaj tych samych meta tagów robots w witrynie mobilnej i desktopowej.” Przejdź do cytatu

Google — pułapka leniwego ładowania i konfiguracja

• “Don’t lazy-load primary content upon user interaction. Google won’t load content that requires user interactions (for example, swiping, clicking, or typing) to load.” (tłumaczenie) „Nie stosuj leniwego ładowania głównej treści w odpowiedzi na interakcję użytkownika. Google nie załaduje treści, która wymaga interakcji użytkownika (na przykład przesuwania, klikania lub pisania), aby się załadować.” Przejdź do cytatu
• Google “recommends Responsive Web Design” (tłumaczenie) „zaleca responsywne projektowanie stron” jako najłatwiejszy wzorzec do wdrożenia i utrzymania. Przejdź do cytatu
• “Separate URLs: Serves different HTML to each device, and on separate URLs.” (tłumaczenie) „Osobne URL-e: Serwuje różny HTML dla każdego urządzenia, na osobnych URL-ach.” Przejdź do cytatu

John Mueller, Google — kluczowe ostrzeżenie (Pubcon Pro Virtual 2020, za relacją Search Engine Journal)

• “we will only index the mobile content in the future.” (tłumaczenie) „będziemy indeksować wyłącznie treści mobilne w przyszłości.” Przejdź do cytatu
• “anything that you want to have indexed, it needs to be on the mobile site.” (tłumaczenie) „cokolwiek chcesz, aby było zaindeksowane, musi znajdować się na stronie mobilnej.” Przejdź do cytatu

John Mueller, Google — harmonogram (za dosłowną relacją Search Engine Land)

• “the trek to Mobile First Indexing is now complete.” (tłumaczenie) „Droga do indeksowania mobile-first została zakończona” (październik 2023). Przejdź do cytatu
• “a very small set of sites which do not work on mobile devices at all” (tłumaczenie) „bardzo mały zestaw witryn, które w ogóle nie działają na urządzeniach mobilnych” — pozostaje indeksowany przez desktopowego Googlebota. Przejdź do cytatu
• “the last batch of sites eligible for mobile-first indexing have been moved over.” (tłumaczenie) „ostatnia partia witryn kwalifikujących się do indeksowania mobile-first została przeniesiona” (maj 2023). Przejdź do cytatu
• “we’ve decided to extend the timeframe to the end of March 2021.” (tłumaczenie) „zdecydowaliśmy się przedłużyć termin do końca marca 2021 roku” (lipiec 2020). Przejdź do cytatu
• “switching to mobile-first indexing for all websites starting September 2020.” (tłumaczenie) „przejście na indeksowanie mobile-first dla wszystkich witryn od września 2020 roku” (ogłoszone w marcu 2020). Przejdź do cytatu

James Murray, Microsoft Bing — dlaczego Bing nie przeszedł na mobile-first

• “we think it’s more useful to have an integrated view and to be more device agnostic.” (tłumaczenie) „uważamy, że bardziej przydatne jest posiadanie zintegrowanego widoku i bycie bardziej niezależnym od urządzenia.” Przejdź do cytatu
• “we want to give you the same index and then personalise to you as the user.” (tłumaczenie) „chcemy dać ci ten sam indeks, a następnie spersonalizować go dla ciebie jako użytkownika.” Przejdź do cytatu

Lista kontrolna audytu parytetu mobile-first

Przeprowadź ją na swoim mobilnym HTML (wyświetl źródło wersji mobilnej lub użyj wyrenderowanego HTML w URL Inspection), ponieważ to ta wersja jest indeksowana przez Google:

• Ta sama treść. Pełna, ważna treść jest obecna na mobile — nie przycięta “dla porządku”. Wszystko, co chcesz zaindeksować, jest w mobilnym HTML.
• Te same dane strukturalne. Ten sam markup jest dostarczany w obu wersjach, odwołując się do tych samych URL-i co sama strona.
• Te same obrazy + tekst alternatywny. Żadne obrazy nie są pomijane na mobile; tekst alternatywny jest zgodny z wersją desktopową (wpływa to na wyszukiwanie obrazów).
• Te same tytuły i meta opisy. Równoważne title i meta opis w obu wersjach.
• Te same nagłówki. Mobile zachowuje tę samą jasną, znaczącą strukturę nagłówków (H2/H3) co desktop — nie spłaszczoną do zwykłego tekstu.
• Te same dane strukturalne wideo. VideoObject (lub inny markup wideo) obecny na desktopie jest również dostarczany na mobile.
• Te same meta tagi robots. Żadnych przypadkowych noindex/nofollow w szablonie mobilnym (klasyczne przypadkowe wyindeksowanie).
• Te same linki wewnętrzne. Nawigacja i kluczowe linki są w mobilnym HTML — nie ukryte za interakcjami, które muszą się uruchomić, zanim linki się załadują.
• Brak treści zależnej od interakcji. Główna treść ładuje się przy przewijaniu lub w początkowym HTML, nie tylko po dotknięciu/przesunięciu/wpisaniu.
• Ukryta/treść w zakładkach jest OK — akordeony i zakładki są w porządku, o ile treść jest w HTML (Google nie dyskontuje już treści ukrytej przez UX).
• (Tylko osobne URL-e) Desktop ustawiony jako kanoniczny z linkiem alternate do mobile; hreflang poprawny między wersjami; mobilny URL serwuje pełną treść.
• Zweryfikowane w Search Console — “Crawled as: Googlebot smartphone.”

Modele mentalne

1. Mobile = źródło prawdy. Cokolwiek jest w Twoim mobilnym HTML, to Google indeksuje i rankuje. Treść tylko na desktopie jest, dla celów indeksowania, niewidoczna. Audytuj względem wersji mobilnej, nie tej, którą zwykle oglądasz na laptopie.

2. Parytet, nie identyczność. Nie potrzebujesz identyczności bajt po bajcie — potrzebujesz każdego ważnego elementu na mobile: treści, danych strukturalnych, obrazów + tekstu alternatywnego, tytułów/opisów, meta robots, linków wewnętrznych. Szczuplejszy układ jest w porządku; brak substancji nie jest.

3. Indeksowanie ≠ wzrost, i ≠ przyjazność mobilna. Indeksowanie mobile-first zmienia którą wersję Google czyta — nie podnosi rankingów i nie jest tym samym co użyteczność na telefonie. Trzymaj te trzy pojęcia osobno, a większość zamieszania zniknie.

4. Nie zmuszaj Google do interakcji. Googlebot nie przesunie, nie kliknie ani nie wpisze, aby ujawnić treść. Jeśli treść pojawia się tylko after akcji użytkownika, traktuj ją jako niezaindeksowaną. Ładuj ją przy przewijaniu lub w początkowym HTML.

5. Wybierz konfigurację, która czyni parytet automatycznym. Responsywny design oznacza jedną wersję, więc parytet jest za darmo. Dynamiczne serwowanie i osobne URL-e oznaczają dwie wersje, które musisz utrzymywać w synchronizacji — każdy element parytetu powyżej staje się rzeczą, która może po cichu dryfować. Wybierz responsywny, chyba że masz silny powód, żeby nie.

Indeksowanie mobile-first — ściąga

Jedyna zasada: Google indeksuje Twój mobilny HTML. “Only the content shown on the mobile site is used for indexing.” (tłumaczenie) „Tylko treść pokazana na mobilnej stronie jest używana do indeksowania.” Jeśli nie ma jej na mobile, zakładaj, że nie będzie zaindeksowana.

Indeksowanie mobile-first vs. przyjazność mobilna

Porównanie konfiguracji

Dla osobnych URL-i: ustaw desktop jako kanoniczny, dodaj link alternate do mobilnego URL-a, utrzymuj poprawny hreflang i upewnij się, że mobilny URL serwuje pełną treść.

Lista kontrolna parytetu (zachowaj równoważność na mobile)

• Treść · dane strukturalne (w tym wideo) · obrazy + tekst alternatywny · nagłówki · tytuły + meta opisy · meta tagi robots · linki wewnętrzne.

Pułapki

• noindex tylko na mobile → przypadkowa deindeksacja.
• Treść ukryta za dotknięciem/przesunięciem/wpisaniem → niezaładowana przez Googlebota.
• Przycinanie “długiej” treści na mobile → przycięta treść może nie być indeksowana.

Harmonogram: ogłoszono w listopadzie 2016 → domyślnie dla nowych witryn w 2019 → ostatnia partia w maju 2023 → ogłoszono zakończenie w październiku 2023.

Inne wyszukiwarki: Bing nie przeszedł — pojedynczy indeks niezależny od urządzenia.

Częste problemy

Rzeczywiste tryby awarii, które pojawiają się po przejściu witryny na indeksowanie mobile-first, z prawdopodobną przyczyną i rozwiązaniem.

Treść, która była indeksowana na desktopie, nagle nie jest indeksowana

Objaw: Strona (lub jej sekcja), która wcześniej pojawiała się w wynikach wyszukiwania, przestaje się pojawiać, mimo że URL nadal zwraca 200, a wersja desktopowa wygląda bez zmian.

Prawdopodobna przyczyna: Treść została przycięta, zwinięta lub usunięta z szablonu mobile — często w ramach przeprojektowania “utrzymaj mobile czystym”, które usunęło akapit, blok FAQ lub opis kategorii, który renderuje tylko układ desktopowy.

Rozwiązanie + sprawdzenie: Wyświetl źródło wersji mobile (lub użyj URL Inspection w Search Console → Tested Page → View Crawled Page) i potwierdź, że brakujący tekst faktycznie znajduje się w HTML mobile, a nie tylko w HTML desktop. Jeśli go nie ma, dodaj go z powrotem do szablonu mobile — Google indeksuje to, co jest w HTML mobile, kropka.

Strona została deindeksowana po przeprojektowaniu

Objaw: Wcześniej indeksowany URL znika z raportu pokrycia w Search Console (“Excluded by noindex tag”) wkrótce po zmianie szablonu, bez zamierzonej deindeksacji.

Prawdopodobna przyczyna: Meta tag robots noindex istnieje w szablonie mobile, ale nie w desktopowym (lub odwrotnie) — klasyczna przypadkowa deindeksacja, gdy dwa szablony rozjeżdżają się.

Rozwiązanie + sprawdzenie: Porównaj <meta name="robots"> na mobile vs. desktop dla danego URL (wyświetl źródło obu, lub użyj curl z user-agentem mobile vs. desktop). Przepuść URL przez Search Console → URL Inspection, aby potwierdzić “Indexing allowed? Yes” po usunięciu zbłąkanego tagu.

Rozszerzone wyniki znikają po aktualizacji witryny

Objaw: Rozszerzone wyniki (gwiazdki recenzji, fragmenty FAQ, breadcrumbs), które pojawiały się przed przeprojektowaniem, przestają się pojawiać, mimo że strona nadal się pozycjonuje.

Prawdopodobna przyczyna: Dane strukturalne są w szablonie desktop, ale nie zostały przeniesione do szablonu mobile — Google czyta tylko HTML mobile, więc znaczniki, które są tylko na desktopie, są niewidoczne.

Rozwiązanie + sprawdzenie: Przepuść wyrenderowany HTML mobile przez Schema Validator lub Rich Result Eligibility Checker i potwierdź, że ta sama JSON-LD (lub mikrodane) pojawia się tam, co na desktopie.

Obrazy przestają pojawiać się w Grafice Google

Objaw: Obrazy, które wcześniej pojawiały się w Grafice Google dla strony, cicho znikają, a nowe obrazy nigdy się tam nie pojawiają.

Prawdopodobna przyczyna: Szablon mobile całkowicie pomija obraz (np. zamienia na lżejszy układ bez niego) lub usuwa/skraca tekst alt w porównaniu z desktopem.

Rozwiązanie + sprawdzenie: Porównaj tagi <img> i atrybuty alt wyrenderowanego HTML mobile z wersją desktopową dla tej samej strony. Jeśli się nie zgadzają, przywróć tekst alt mobile do zgodności z desktopem.

Sekcja karuzeli/zakładki/“load more” nigdy nie jest indeksowana

Objaw: Treść, która znajduje się w karuzeli, przycisku “load more” lub zakładce, która pobiera treść po kliknięciu, nigdy nie pojawia się w wynikach wyszukiwania, bez względu na to, jak ważna jest ta treść.

Prawdopodobna przyczyna: Treść ładuje się dopiero po interakcji użytkownika (przesunięcie, kliknięcie, dotknięcie, wpisanie). Googlebot nie wykonuje tych interakcji, więc nigdy nie widzi treści, która jest za nimi ukryta — to różni się od zwykłego akordeonu/zakładki, gdzie treść jest już w HTML i tylko wizualnie ukryta.

Poprawka + sprawdzenie: Wyświetl początkowy wyrenderowany HTML strony („View Crawled Page” w Search Console lub view-source z włączonym JavaScriptem) bez dotykania interfejsu użytkownika i potwierdź, że treść jest obecna. Jeśli pojawia się dopiero po interakcji ze stroną, przenieś ją do ładowania przy przewijaniu lub wbuduj w początkowy HTML.

Skrypty i fragmenty kodu

Narzędzia do samodzielnego sprawdzania parytetu mobile/desktop, bez czekania, aż Search Console wykryje rozbieżność.

Pobierz HTML mobile vs. desktop za pomocą curl (mac/Linux)

Porównuje to, co widzi Googlebot smartphone, z crawlerm desktopowym, używając odpowiednich stringów user-agent, i porównuje je.

URL="https://example.com/your-page/"

curl -s -A "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "$URL" > mobile.html

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "$URL" > desktop.html

diff mobile.html desktop.html

Uruchom to przed/po przeprojektowaniu, aby wykryć treść, dane strukturalne lub tagi noindex, które istnieją tylko w jednej wersji. Uwaga: to pobiera surowy HTML — jeśli Twoja treść jest wstrzykiwana przez JavaScript po stronie klienta, połącz to z narzędziem do renderowania (lub Render Gap witryny) zamiast polegać wyłącznie na curl.

To samo sprawdzenie w PowerShell (Windows)

$url = "https://example.com/your-page/"
$mobileUA = "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
$desktopUA = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Invoke-WebRequest -Uri $url -UserAgent $mobileUA -OutFile mobile.html
Invoke-WebRequest -Uri $url -UserAgent $desktopUA -OutFile desktop.html

Compare-Object (Get-Content mobile.html) (Get-Content desktop.html)

Regex: wyciągnij tagi meta robots z zapisanego HTML

Sprawdza, czy dyrektywy robots dla mobile i desktop są zgodne, po zapisaniu obu wersji za pomocą powyższych fragmentów curl/PowerShell.

<meta\s+name=["']robots["']\s+content=["']([^"']+)["']

Grupa przechwytująca 1 to string dyrektywy (np. index, follow lub noindex). Uruchom to osobno dla mobile.html i desktop.html i porównaj przechwycone wartości — niezgodność to ryzyko przypadkowego deindeksowania.

Konsola DevTools: lista obrazów + tekst alternatywny na bieżącej stronie

Wklej do panelu Konsoli (F12 → Konsola) podczas przeglądania renderowania mobile (użyj paska narzędzi urządzeń DevTools, aby zasymulować telefon), aby wykryć obrazy bez tekstu alt.

[...document.querySelectorAll('img')].map(img => ({
  src: img.currentSrc || img.src,
  alt: img.alt || '(missing alt)'
}));

Bookmarklet: przejdź bezpośrednio do URL Inspection dla bieżącej strony

Przeciągnij to na pasek zakładek; kliknięcie na dowolnej własnej stronie otwiera URL Inspection w Search Console dla tego dokładnego adresu URL, gdzie możesz sprawdzić „Crawled as”.

javascript:(function(){window.open('https://search.google.com/search-console/inspect?resource_id=&id='+encodeURIComponent(location.href));})();

Po otwarciu będziesz musiał wybrać odpowiednią właściwość w Search Console (bookmarklet nie przenosi ID właściwości/zasobu).

Testy walidacyjne

Dowód, że poprawka parytetu mobile-first faktycznie zadziałała, a nie tylko że dokonałeś edycji.

Potwierdź, że Google indeksuje stronę jako mobile

Test do wykonania: Search Console → URL Inspection, wprowadź adres URL, sprawdź pole „Crawled as” w wersji na żywo/zaindeksowanej.

Oczekiwany wynik: „Crawled as: Googlebot smartphone.”

Interpretacja błędu: Jeśli pokazuje „Googlebot desktop” dla normalnej strony, adres URL jest jednym z rzadkich wyjątków, które Google indeksuje jako desktop (lub strona nie została jeszcze ponownie zaindeksowana po Twojej poprawce) — poproś o indeksowanie, aby wymusić ponowne sprawdzenie.

Okno monitorowania: Natychmiastowe, gdy URL Inspection zwróci wynik; odczekaj kilka dni, jeśli dopiero co poprosiłeś o indeksowanie.

Wyzwalacz wycofania: N/D — to diagnostyka tylko do odczytu, nie zmiana do wycofania.

Potwierdź, że dane strukturalne trafiły do HTML mobile

Test do wykonania: Przepuść adres URL renderowany jako mobile przez Schema Validator (lub raport Rich Results w Search Console dla właściwości).

Oczekiwany wynik: Te same typy i pola danych strukturalnych, które dodałeś do desktop, pojawiają się w wyniku renderowania mobile, bez błędów parsowania.

Interpretacja błędu: Brakujący lub błędny znacznik oznacza, że JSON-LD został dostarczony tylko w szablonie desktop, albo błąd szablonu usunął go na mobile.

Okno monitorowania: Natychmiastowe dla sprawdzenia walidatorem; 1–2 tygodnie, zanim odpowiedni wynik rozszerzony pojawi się ponownie w Search Console/wynikach na żywo.

Wyzwalacz wycofania: Jeśli zmiana szablonu mobile spowodowała szersze uszkodzenie renderowania (układ, inne znaczniki), wycofaj zmianę szablonu i porównaj ponownie.

Potwierdź brak przypadkowego noindex w szablonie mobile

Test do wykonania: Pobierz HTML renderowany jako mobile (curl z user-agentem Googlebot smartphone lub „View Crawled Page” w Search Console) i sprawdź tag <meta name="robots">; alternatywnie użyj HTTP Status Checker witryny, aby potwierdzić, że sama strona zwraca 200, a nie jest zablokowana.

Oczekiwany wynik: index, follow (lub brak tagu, co domyślnie oznacza indeksowalność) zarówno na mobile, jak i desktop.

Interpretacja błędu: noindex obecny tylko na wersji mobilnej oznacza, że Google usunie stronę z indeksu, nawet jeśli wersja desktopowa wygląda dobrze — to najczęstsza przyczyna przypadkowego usunięcia z indeksu na stronach z mobile-first.

Okno monitorowania: Natychmiast dla sprawdzenia tagu; 1–4 tygodnie na ponowne pojawienie się strony w raporcie pokrycia w Search Console, jeśli już wypadła.

Wyzwalacz wycofania: Jeśli usunięcie tagu było samo w sobie błędem (strona miała pozostać z noindex), dodaj go ponownie i zweryfikuj.

Potwierdź, że przycięta/wczytywana leniwie treść jest teraz indeksowalna

Test do wykonania: Z włączonym JavaScriptem i bez interakcji ze stroną (bez kliknięć, dotknięć i przesunięć), wyświetl początkowy wyrenderowany HTML — „View Crawled Page” w Search Console jest najbliższym przybliżeniem tego, co faktycznie widzi Googlebot.

Oczekiwany wynik: Główna treść, o którą chodzi, jest obecna w tym wyrenderowanym HTML bez żadnej interakcji.

Interpretacja błędu: Jeśli treść pojawia się dopiero po kliknięciu/dotknięciu/przesunięciu, Googlebot nadal jej nie zobaczy — poprawka (ładowanie przy przewijaniu lub w początkowym HTML) jeszcze nie zadziałała.

Okno monitorowania: Natychmiast dla sprawdzenia renderowania; 2–4 tygodnie na pojawienie się treści w pokryciu indeksu w Search Console lub w wynikach wyszukiwania site:.

Wyzwalacz wycofania: Jeśli zmiana zachowania ładowania zepsuła UX lub wydajność strony, przywróć poprzedni stan i znajdź podejście ładowania przy przewijaniu zamiast wymagającego interakcji.

Sprawdź się: Mobile-First Indexing

Pięć szybkich pytań o mobile-first indexing. Wybierz odpowiedź na każde, a potem sprawdź.

Dziennik zmian