Sprzeczności w dokumentacji Google: co mówi jedna strona, a co druga

Krótka odpowiedź

Dokumentacja Google dla właścicieli stron nie jest jednym tekstem. To wiele osobnych stron, aktualizowanych w różnych latach i tłumaczonych na wiele języków. Zdarza się więc, że dwie strony Google mówią o tym samym co innego, że pracownik Google w podcaście mówi co innego niż dokumentacja albo że polskie tłumaczenie zmienia sens angielskiego oryginału.

Zebraliśmy dziesięć takich przypadków i pułapek, które da się dziś sprawdzić: z cytatem, adresem i datą aktualizacji strony, a gdzie to możliwe także z nazwiskiem osoby z Google. Przy każdym piszemy, jaką decyzję podjąć. Stan na 29 października 2026 roku.

Skąd biorą się sprzeczności

Widzimy trzy powody. Pierwszy to zakres: przewodnik o spamie, opis robots.txt i pomoc Merchant Center to osobne dokumenty i każdy opisuje temat ze swojej perspektywy. Drugi to czas. Strona zaktualizowana w październiku 2026 roku stoi obok strony z grudnia 2025 roku, a wpis na blogu z 2019 roku nadal jest w sieci. Trzeci to tłumaczenia. Polska wersja bywa aktualizowana później i mniej precyzyjna, zwłaszcza tam, gdzie angielski rozróżnia dwa pojęcia, a tłumaczenie oddaje oba tym samym słowem.

Google sam to przyznaje w dzienniku zmian dokumentacji. W styczniu 2024 roku napisał, że poprzednie sformułowanie strony o opisach w wynikach „incorrectly implied”, czyli błędnie sugerowało, skąd biorą się opisy. W lutym 2026 roku przeniósł limity rozmiaru plików, bo pierwotne miejsce „was not the most logical place”.

Indeksowanie i robots.txt

1. robots.txt jako sposób na wykluczenie strony z indeksu

Strona A. Przewodnik „Prevent user-generated spam” (aktualizacja 26.10.2026) radzi platformom, by strony do udostępniania, wyniki narzędzi i aplikacje oznaczały noindex „or block crawling in robots.txt by default”. Dziennik zmian podaje cel: trzymać takie strony poza indeksem.

Strona B. Wprowadzenie do robots.txt (aktualizacja 10.12.2025) mówi, że ten plik „is not a mechanism for keeping a web page out of Google”, a zablokowany adres Google może zindeksować, jeśli prowadzą do niego linki. Strona o noindex dodaje, że przy blokadzie w robots.txt robot nigdy nie zobaczy reguły noindex.

Polska wersja. Tłumaczenie przewodnika z 28.10.2026 mówi „domyślnie zablokuj indeksowanie w pliku robots.txt”. Polska strona o robots.txt pisze przy tym: „Nie jest to mechanizm służący do ukrywania strony internetowej przed Google”.

Dlaczego to ważne. Link do udostępnienia, wynik kalkulatora albo koszyk wklejony na forum może trafić do Google jako adres bez treści. Sama blokada w robots.txt tego nie zatrzyma.

Co robić. Strony, które mają zniknąć z wyników, oznacz noindex i zostaw je dostępne dla robota. Robots.txt używaj do oszczędzania pobrań, gdy nie zależy Ci na tym, czy adres pojawi się w indeksie. Szerzej piszemy o tym przy zmianie z 26 października 2026 roku dotyczącej wyników narzędzi.

2. „Crawl” w polskiej dokumentacji to często „indeksowanie”

Strona A. Angielska strona o Googlebocie (aktualizacja 3.02.2026): „Googlebot crawls the first 2MB of a supported file type”, czyli pobiera pierwsze 2 MB pliku.

Strona B. Polska wersja: „Googlebot indeksuje pierwsze 2 MB obsługiwanego typu pliku”. Na tej samej stronie „crawl rate” to „szybkość indeksowania”, a cały dział o pobieraniu stron nazywa się „Infrastruktura indeksowania Google”, z podstroną „Zarządzanie budżetem indeksowania”. Pomoc Search Console mówi tymczasem o skanowaniu: „Ostatnie skanowanie”, „Strona zeskanowana, ale jeszcze niezindeksowana”.

Dlaczego to ważne. Pobranie strony i dodanie jej do indeksu to dwa osobne etapy. Od tego, który z nich blokujesz, zależy, czy strona zniknie z wyników. Błąd w polskim tłumaczeniu z punktu 1 wynika właśnie z tego pomieszania.

Co robić. Gdy polski tekst mówi o „indeksowaniu” w kontekście robots.txt, robota, limitów albo częstotliwości wizyt, sprawdź angielski oryginał. Zwykle chodzi tam o pobieranie stron.

Linki: noindex, nofollow i canonical

3. noindex z follow: linki działają czy nie

Dokumentacja. Strona o tagu robots meta (aktualizacja 24.03.2026) opisuje nofollow i dodaje, że bez tej reguły Google „może używać linków na stronie, aby znaleźć linkowane strony”. Nie mówi, co dzieje się z linkami, gdy noindex zostaje na stronie przez długi czas.

Wypowiedź. John Mueller z Google w hangoucie z grudnia 2017 roku (relacja Search Engine Roundtable z 28 grudnia 2017 roku): jeśli noindex zostaje na stronie dłużej, Google usuwa ją całkiem i przestaje śledzić linki, więc „noindex and follow is essentially kind of the same as a noindex, nofollow”. We wrześniu 2024 roku na Reddicie (za Search Engine Journal): linki ze strony z noindex mogą zostać wykorzystane, „but it's not guaranteed”.

Dlaczego to ważne. Jeśli sklep oznacza noindex strony paginacji, filtry albo tagi i liczy, że linki z nich nadal prowadzą robota do produktów, może się przeliczyć.

Co robić. Nie opieraj odkrywania ważnych stron na linkach ze stron z noindex. Produkty i kategorie powinny mieć linki z indeksowanych stron i być w mapie witryny.

4. nofollow: zakaz czy wskazówka

Strona A. Tag robots meta: nofollow znaczy „Do not follow the links on this page”, czyli nie korzystaj z linków na tej stronie.

Strona B. Strona o noindex nazywa tę samą regułę „nofollow hint”, po polsku „podpowiedź nofollow”. Strona o atrybutach linków pisze o atrybucie rel="nofollow", że takie linki „will generally not be followed”, czyli zazwyczaj. Google ogłosił 10 września 2019 roku, że atrybuty nofollow, sponsored i ugc są wskazówkami przy rankingu, a nofollow od 1 marca 2020 roku także przy pobieraniu i indeksowaniu.

Dlaczego to ważne. Kto traktuje nofollow jak blokadę, może zostawić bez ochrony strony, które nie powinny trafić do Google, na przykład panel klienta podlinkowany z menu.

Co robić. Nofollow traktuj jako prośbę. Żeby strona nie trafiła do wyników, oznacz ją noindex. Gdy chodzi o dane prywatne, zabezpiecz ją hasłem.

5. noindex i canonical na jednej stronie

Dokumentacja. Strona o adresach kanonicznych (aktualizacja 10.07.2026) odradza noindex jako sposób wyboru strony kanonicznej, bo noindex „will completely block the page from Search”. Zalecanym rozwiązaniem jest rel="canonical".

Wypowiedzi. John Mueller w 2014 roku (relacja Search Engine Roundtable z 19 marca 2014 roku): „I'd pick one, but not both”. W 2017 roku w hangoucie: w praktyce Google uznaje, że canonical „is a mistake”, i kieruje się noindex. W kwietniu 2023 roku na Twitterze: łączenie ma sens, „if you care more about indexing than canonicalizing”.

Dlaczego to ważne. Odpowiedź zmieniała się z latami: od „nie łącz” w 2014 roku, przez „łącz, jeśli wykluczenie strony jest ważniejsze” w 2023 roku, do „I'd just pick one” we wrześniu 2024 roku (za Search Engine Journal). Sprawdzaj więc, z którego roku jest wypowiedź, na której opiera się poradnik.

Co robić. Duplikat, który ma przekazać sygnały innej stronie: sam canonical. Strona, która nie może pojawić się w wynikach: noindex, a canonical opcjonalnie. Pełną chronologię i inne pary sygnałów opisujemy w tekście o sprzecznych sygnałach dla Google.

Mapa witryny, limity plików i paginacja

6. priority i changefreq w mapie witryny

Strona A. Przewodnik Google o mapach witryn (aktualizacja 8.07.2026): „Google ignores <priority> and <changefreq> values”. Datę lastmod Google bierze pod uwagę tylko, jeśli jest „consistently and verifiably (…) accurate”, czyli stale i sprawdzalnie zgodna z prawdziwą datą zmiany.

Strona B. Ten sam przewodnik po bardziej złożone przykłady odsyła na sitemaps.org. Tam przykładowa mapa zawiera <changefreq>monthly</changefreq> i <priority>0.8</priority>. Protokół zaznacza jednak, że te pola są opcjonalne, a ich obsługa zależy od wyszukiwarki. To raczej pułapka niż sprzeczność: kto kopiuje przykład z sitemaps.org, dodaje pola, które Google pomija.

Dlaczego to ważne. Wtyczki do WordPressa i platformy sklepów nadal generują te pola. Nie szkodzą, ale ustawianie priorytetów na stronach to dla Google stracony czas.

Co robić. Zadbaj o lastmod: niech zmienia się tylko przy istotnej zmianie treści. Data aktualizowana codziennie na wszystkich adresach, choć treść się nie zmienia, przestaje być wiarygodna. Więcej w tekście o mapie strony XML.

7. Limit rozmiaru pliku: dokumentacja zna go lepiej niż podcast

Dokumentacja. Strona o Googlebocie (aktualizacja 3.02.2026): Googlebot pobiera pierwsze 2 MB obsługiwanego pliku i pierwsze 64 MB pliku PDF. Ogólna strona o robotach Google (aktualizacja 12.06.2026) podaje domyślny limit 15 MB i wyjaśnia, że Googlebot może mieć mniejszy.

Wypowiedź. W podcaście Search Off the Record z 13 października 2026 roku Martin Splitt z Google mówi o PDF-ach: „I don't know the specific limit for PDF files”. John Mueller proponuje, żeby po prostu to przetestować.

Dlaczego to ważne. Przez lata w branży krążyła liczba 15 MB, bo tyle podawała strona o Googlebocie do lutego 2026 roku. Dla stron HTML dziś liczy się 2 MB.

Co robić. Treść, która ma trafić do Google, umieść w pierwszych 2 MB kodu HTML strony. Duże katalogi i cenniki w PDF podziel, jeśli przekraczają 64 MB. O tym, jak Google czyta PDF, piszemy w tekście o plikach PDF w Google.

8. rel=prev/next: zalecenie przeżyło funkcję

Dokumentacja wtedy. Google przez lata zalecał oznaczanie kolejnych stron listy tagami rel="next" i rel="prev".

Wypowiedź. 21 marca 2019 roku John Mueller napisał na Twitterze, że Google zauważył, że nie używa tych tagów przy indeksowaniu „for a number of years now”, więc usuwa ich opis. Dzisiejsza strona o paginacji (aktualizacja 10.12.2025) mówi, że Google ich już nie używa, choć mogą z nich korzystać inne wyszukiwarki.

Dlaczego to ważne. Google sam przyznał, że zalecenie było nieaktualne przez lata, zanim zniknęło z dokumentacji. Strony wdrażały tagi, których Google od lat nie używał.

Co robić. Tagów nie trzeba usuwać, bo używać ich mogą inne wyszukiwarki. Każda strona listy powinna mieć własny adres kanoniczny i zwykłe linki do kolejnych stron, które robot może pobrać.

Opisy w wynikach i Merchant Center

9. Skąd Google bierze opis strony w wynikach

Strona wtedy. Kopia strony o opisach z archiwum internetu (30.11.2023): Google korzysta z różnych źródeł, „including descriptive information in the meta description tag for each page”. Kilka akapitów niżej ta sama strona mówiła, że opisy powstają automatycznie z treści strony.

Strona dziś. Od stycznia 2024 roku: Google „primarily uses the content on the page”, a opis meta wykorzystuje, gdy lepiej opisuje stronę. W dzienniku zmian Google przyznał, że poprzednie brzmienie błędnie sugerowało, że głównym źródłem są opis meta i dane strukturalne.

Dlaczego to ważne. Opis meta nadal bywa pokazywany, ale nie ma gwarancji. Jeśli Google pokazuje inny fragment, zwykle dlatego, że lepiej pasuje do zapytania.

Co robić. Pisz opis meta dla najważniejszych stron, a początek treści strony formułuj tak, żeby sam nadawał się na opis w wynikach.

10. Automatyczne aktualizacje produktów przy częstych zmianach cen

Strona A. Pomoc Merchant Center o automatycznych aktualizacjach produktów: automatyzacja „może nie działać w przypadku produktów, w których przypadku często zmienia się cena lub wartość dostępności (np. więcej niż raz dziennie)”, a produkt może zostać odrzucony zamiast zaktualizowany. Kopia tej strony z archiwum internetu z 14 lipca 2026 roku tego akapitu nie ma.

Strona B. Pomoc o niezgodnej dostępności produktu nadal pisze: „jeśli często aktualizujesz ceny i dostępność, zalecamy korzystanie z automatycznych aktualizacji produktów”.

Dlaczego to ważne. Sklep, który zmienia ceny kilka razy dziennie i korzysta z automatyzacji, zgodnie z drugą stroną robi to, co Google zaleca przy częstych zmianach, a zgodnie z pierwszą ryzykuje odrzucenie produktów.

Co robić. Przy częstych zmianach cen wysyłaj dane do Merchant Center częściej, przez harmonogram pliku albo Merchant API. Automatyzację traktuj jako zabezpieczenie na pojedyncze rozbieżności. Szczegóły w tekście o częstych zmianach cen w Merchant Center.

Jak czytać dokumentację Google

1. Sprawdź angielski oryginał. Dopisz do adresu strony ?hl=en i porównaj zdanie, na którym opierasz decyzję. Zwracaj uwagę na słowa „crawl” i „index”.
2. Sprawdź datę. Na dole każdej strony dokumentacji Search Central jest data ostatniej aktualizacji. Polska wersja ma własną datę, która nie mówi, czy treść jest już przetłumaczona w całości.
3. Czytaj dziennik zmian po angielsku. Na stronie developers.google.com/search/updates Google opisuje, co zmienił, a często też dlaczego. Polska wersja tej strony 29 października 2026 roku kończyła się na wpisie z 18 września i nie miała żadnej zmiany z października.
4. Porównaj ze stroną o tym samym temacie. Jeśli przewodnik o spamie mówi coś o robots.txt, sprawdź, co mówi strona o robots.txt. Przy sprzeczności zwykle bardziej precyzyjna jest strona poświęcona danemu mechanizmowi.
5. Wypowiedzi pracowników Google traktuj jako uzupełnienie. John Mueller, Gary Illyes i Martin Splitt często opisują zachowanie, którego dokumentacja nie obejmuje. Sprawdzaj datę wypowiedzi: odpowiedź z 2014 roku mogła się zmienić.
6. Gdy źródła się różnią, wybierz rozwiązanie bezpieczne w obu wersjach. Przykład z punktu 1: noindex działa niezależnie od tego, którą stronę Google uznamy za aktualną.

Jeśli nie masz czasu porównywać dokumentacji z tym, co dzieje się w Twoim serwisie, zrobimy to w ramach audytu SEO: sprawdzimy noindex, robots.txt, mapę witryny i linki kanoniczne na żywych danych z Search Console.