Limit 2 MB Googlebota: co tracą duże strony HTML przy crawlowaniu

Googlebot pobiera tylko pierwsze 2 MB pliku obsługiwanego typu i pierwsze 64 MB pliku PDF. To, co leży za tym progiem, nigdy nie trafia do rozpatrzenia pod kątem indeksowania, jak podaje dokumentacja Googlebota od Google. Kogo to powinno obchodzić? Głównie serwisy na WordPressie i page builderach, których szablony wypluwają bardzo ciężki HTML. To właśnie tam limit 2 MB Googlebota daje się we znaki. Większość stron jest znacznie mniejsza, więc bez paniki: najpierw zmierz własne dokumenty i popraw tylko te, które zbliżają się do progu.

Co dokładnie mówi limit 2 MB Googlebota?

Googlebot przestaje pobierać plik, gdy dojdzie do progu, i przekazuje dalej tylko tę część, którą już ma. 3 lutego 2026 roku Google przeniosło domyślne limity rozmiaru plików swoich robotów do dokumentacji crawlerów i doprecyzowało wartości dla samego Googlebota. Próg dotyczy danych nieskompresowanych, więc rozmiar transferu, który widzisz przy gzip albo Brotli, nie jest liczbą, która się liczy. I nie, nic w dokumentacji nie opisuje tego limitu jako sygnału rankingowego. Określa on tylko, jaka część pliku trafia do indeksowania.

2 MB a limit crawlowania 15 MB: która wartość dotyczy Twoich stron?

W przypadku wyszukiwarki Google obowiązuje mniejszy limit rozmiaru pliku Googlebota, a nie ogólna wartość domyślna. Limit crawlowania 15 MB to poziom bazowy dla wszystkich robotów i fetcherów Google, a treść powyżej niego jest ignorowana, jak wynika z przeglądu robotów Google. Ta sama strona wyjaśnia, że poszczególne projekty mogą ustawiać inne progi dla danego robota i typu pliku, a jako przykład podaje Googlebota.

Co duże strony HTML tracą za progiem?

Wszystko, co jest za progiem. W długim dokumencie może to oznaczać końcowe partie tekstu, nawigację w stopce, linki wewnętrzne i dane strukturalne umieszczone na końcu źródła. A ponieważ Googlebot znajduje nowe adresy URL głównie przez linki na crawlowanych stronach, ucięta stopka może sprawić, że zaczniesz szukać osieroconych stron, które w przeglądarce wyglądały na dobrze podlinkowane.

Pliki CSS i JavaScript wskazane w HTML są pobierane osobno, a każde z tych pobrań podlega temu samemu limitowi. Zbyt duży bundle też może zostać ucięty, co wpływa na to, jak strona renderuje się dla Google. Moim zdaniem SEO dużych stron HTML sprowadza się do kompletności: czy cały dokument i każdy plik, od którego on zależy, faktycznie trafia do procesu indeksowania?

Jak zmierzyć rozmiar nieskompresowanego HTML za pomocą curl

Pobierz surowy dokument bez kompresji i odczytaj liczbę bajtów. Oto jak sprawdzić rozmiar strony HTML w sposób zgodny z tym, co liczy limit:

1. Pobierz stronę przez curl i nie proś o kompresję (pomiń flagę -compressed).
2. Zapisz wynik i wypisz rozmiar: curl -s -o page.html -w '%{size_download}' https://example.com/page/
3. Powtórz test dla największych plików CSS i JavaScript, bo każdy z nich ma własny limit.

Patrz na sam dokument HTML, a nie na łączną wagę strony podawaną przez narzędzia w przeglądarce. Zacznij od najcięższych szablonów: długich landing page’y złożonych w page builderze, archiwów kategorii, stron z osadzonymi danymi.

Skąd bierze się nadmiar: inline CSS, JavaScript i obrazy base64

Rzadko z tekstu. Większość przerośniętych dokumentów puchnie od kodu i danych osadzonych bezpośrednio w znacznikach. Typowi winowajcy nadmiaru inline CSS i JavaScript w WordPressie i page builderach to bloki stylów dla każdego widżetu, skrypty wstawione inline, zserializowany stan w JSON, inline SVG i obrazy zakodowane w base64. Poprawki wprowadza się w CMS, motywie albo na serwerze źródłowym:

• Przenieś inline CSS i JS do plików zewnętrznych.
• Zastąp obrazy base64 zwykłymi plikami graficznymi.
• Usuń nieużywane moduły buildera i zduplikowane sekcje.
• Podziel bardzo długie strony na kilka krótszych.

Umieść ważną treść i linki na początku HTML

Kolejność w źródle wygrywa z kolejnością wizualną. Główna treść i linki wewnętrzne, na których Ci zależy, powinny pojawiać się przed ciężkimi skryptami i blokami dekoracyjnymi. Utrzymuj sekcję head w ryzach, żeby body zaczynało się wcześnie, a duże skrypty inline i bloki danych przesuń na koniec dokumentu albo do plików. Jeśli strona i tak zostanie ucięta, ocaleje wtedy ta część, która ma znaczenie.

Sprawdź też, czy roboty mogą pobrać CSS, JavaScript i obrazy, na których opiera się strona, na przykład pisząc na serwerze źródłowym reguły hotlinkowania przepuszczające roboty. Reverse proxy NGINX takie jak Jalvo, z adresami IP z UE i USA przed istniejącym hostingiem, niczego tu nie zmienia: o rozmiarze HTML nadal decydują serwer źródłowy i CMS. W przypadku ciężkich stron, które w ogóle nie mają powodu pojawiać się w wyszukiwarce, najpierw ustal, kiedy noindex wygrywa z disallow.

Zmierz nieskompresowany HTML najcięższych szablonów, przenieś kod inline i obrazy base64 do plików, a potem umieść główną treść i linki na początku źródła. Przy takim podejściu limit 2 MB Googlebota staje się rutynową kontrolą szablonów. A nie ukrytym powodem, dla którego część strony nigdy nie trafia do indeksu.

FAQ