Google po cichu, ale wymownie dopisało 23 czerwca 2026 roku do swojej dokumentacji dla deweloperów wyjaśnienie, ile bajtów treści tekstowej, na przykład kodu HTML, faktycznie pobiera Googlebot. Liczba, która od miesięcy krążyła po branżowych dyskusjach, dostała wreszcie oficjalne miejsce w materiałach Search Central: indeksujący wariant Googlebota czyta około 2 MB kodu HTML pojedynczego adresu URL, a wszystko powyżej tego progu jest po prostu ucinane. To nie jest nowa zasada ani zmiana w działaniu wyszukiwarki, lecz dopowiedzenie czegoś, co i tak obowiązywało, tyle że teraz na piśmie i bez miejsca na domysły.
Dla zespołów SEO i dla wszystkich, którzy walczą o widoczność w wynikach Google i w odpowiedziach generatywnych, ten z pozoru techniczny zapis ma realne konsekwencje. Jeśli najważniejsze elementy strony, tytuł, dane strukturalne czy kluczowa treść, znajdą się za granicą 2 MB, Google ich nie zobaczy. W praktyce limit bajtów Googlebota staje się cichym arbitrem tego, co w ogóle ma szansę trafić do indeksu.
Kontekst: limit bajtów wraca jak bumerang
Temat progów bajtowych Googlebota nie pojawił się znikąd. Już w lutym 2026 roku Google trzykrotnie w ciągu dziewięciu dni poprawiało dokumentację crawlera, doprecyzowując, że proces dzieli się na dwie fazy: pobieranie (fetching) z limitem rzędu 15 MB oraz przetwarzanie na potrzeby indeksu, gdzie dla treści HTML obowiązuje próg około 2 MB. W marcu 2026 roku Gary Illyes opublikował na blogu Search Central obszerny wpis pod tytułem „Inside Googlebot”, w którym rozłożył na czynniki pierwsze architekturę pobierania i przetwarzania, odsyłając dodatkowo do odcinka 105 podcastu Search Off the Record.
Czerwcowa aktualizacja domyka tę narrację. Google przeniosło część wiedzy z bloga i podcastu wprost do twardej dokumentacji referencyjnej, tej, do której sięgają deweloperzy i specjaliści, gdy chcą mieć pewność, a nie wrażenie. Komunikat jest spójny od miesięcy: to wyjaśnienie, a nie rewolucja. Mimo to fakt, że konkretna liczba (2 MB) zyskała rangę oficjalnego zapisu, zmienia sposób, w jaki branża musi o niej myśleć. Z anegdoty stała się parametrem technicznym, który da się zaplanować i zmierzyć.
Warto pamiętać, skąd w ogóle bierze się rozróżnienie na 15 MB i 2 MB. Pierwsza liczba opisuje to, ile danych Googlebot pobiera z serwera w trakcie samego transferu pliku. Druga dotyczy tego, ile surowego kodu HTML trafia następnie do systemów indeksujących i do Web Rendering Service, czyli komponentu, który uruchamia JavaScript i renderuje stronę tak, jak zrobiłaby to przeglądarka. Te dwie wartości łatwo pomylić, a różnica między nimi decyduje o tym, gdzie dokładnie kończy się widoczność strony.
Kluczowe fakty z dokumentacji
Najnowszy zapis i powiązane materiały Google układają się w kilka twardych punktów, które warto mieć przed oczami przy każdej rozmowie o wadze strony i o crawl budżecie.
| Element | Limit lub zachowanie |
|---|---|
| Kod HTML pojedynczego adresu URL | około 2 MB, wliczając nagłówki HTTP odpowiedzi |
| Pliki PDF | do 64 MB |
| Domyślny limit dla nieokreślonych crawlerów | 15 MB |
| Zasoby zewnętrzne (CSS, JS) | osobne liczniki bajtów, nie wliczają się do 2 MB strony |
| Przekroczenie progu | treść powyżej limitu zostaje ucięta, nie odrzucona |
| Pliki multimedialne, fonty, egzotyczne formaty | nie są pobierane przez WRS |
Dwie rzeczy zasługują na szczególną uwagę. Po pierwsze, do limitu 2 MB wliczają się nagłówki odpowiedzi HTTP, więc realny budżet na sam kod jest minimalnie mniejszy niż okrągłe dwa megabajty. Po drugie, zasoby zewnętrzne, takie jak osobne pliki CSS i JavaScript, dostają własne liczniki i nie konsumują budżetu strony nadrzędnej. To kluczowa wskazówka projektowa, do której wrócę przy rekomendacjach.
Jak działa obcinanie treści
Najważniejsze nieporozumienie wokół limitu dotyczy tego, co się dzieje, gdy strona jest większa niż 2 MB. Google jasno tłumaczy: Googlebot nie odrzuca takiej strony i nie traktuje jej jak błędu. Zamiast tego zatrzymuje pobieranie dokładnie w punkcie odcięcia i przekazuje uciętą treść dalej, do systemów indeksujących oraz do Web Rendering Service. Wszystko, co znajdowało się za granicą 2 MB, nigdy nie zostaje pobrane, wyrenderowane ani zaindeksowane.
Konsekwencja jest brutalnie prosta. Jeśli w kodzie HTML upchniesz przed właściwą treścią ogromne menu, rozbudowane bloki inline CSS, osadzone w base64 obrazy oraz skrypty, możesz nieświadomie wypchnąć poza próg te elementy, na których naprawdę Ci zależy. Dane strukturalne schema.org, znaczniki canonical, meta tagi czy główny tekst artykułu mogą zostać po niewłaściwej stronie cięcia. Google nie wyśle ostrzeżenia, nie pokaże czerwonej flagi w Search Console. Strona po prostu zostanie zaindeksowana w okrojonej wersji, a Ty będziesz się zastanawiać, dlaczego rich results nie działają.
Drugi istotny szczegół dotyczy kolejności. Ponieważ Googlebot czyta kod od góry, pozycja elementu w dokumencie HTML ma znaczenie. Im wcześniej w kodzie znajdą się tytuł, opis, canonical i dane strukturalne, tym mniejsze ryzyko, że zostaną ucięte na stronach o ekstremalnej wadze. Web Rendering Service dostaje dokładnie tę uciętą wersję, więc nawet zaawansowane renderowanie nie odtworzy treści, której Googlebot nigdy nie pobrał. Jeśli chcesz zrozumieć, jak renderowanie wpływa na widoczność, warto sięgnąć po nasz materiał o renderowaniu JavaScript pod SEO, bo to właśnie tam ten próg potrafi zaboleć najmocniej.
Co to znaczy dla SEO
Dla większości serwisów limit 2 MB nie jest problemem. Typowa strona artykułowa, nawet bogato sformatowana, rzadko zbliża się do tej granicy w samym kodzie HTML. Kłopoty zaczynają się w trzech scenariuszach: na rozbudowanych stronach kategorii i filtrów w sklepach, na stronach z setkami pozycji w jednym widoku oraz w serwisach, które renderują dużą część treści po stronie klienta i wypychają do HTML olbrzymie ładunki danych w formacie JSON.
Google i komentatorzy branżowi zgodnie wskazują kilka praktycznych ruchów, które chronią przed niezamierzonym ucięciem treści:
- Przenieś ciężki CSS i JavaScript do zewnętrznych plików, zamiast wklejać je inline w dokumencie HTML. Te zasoby mają osobne liczniki bajtów.
- Umieszczaj meta tagi, tytuł, canonical i dane strukturalne możliwie wysoko w kodzie, najlepiej w sekcji head i tuż za nią.
- Unikaj obrazów osadzonych w base64 wprost w HTML, bo potrafią błyskawicznie zjeść budżet 2 MB.
- Tnij rozdęte menu nawigacyjne i powtarzalne bloki, które renderują się na każdej stronie.
- Mierz realną wagę dokumentu HTML, a nie wagę całej strony po renderowaniu, bo to dwie różne liczby.
To dobry moment, by potraktować wagę kodu jako element technicznego audytu, a nie ciekawostkę. Jeśli budujesz listę kontrolną dla zespołu, limit bajtów Googlebota pasuje wprost do sekcji o indeksowalności w naszej checkliście technicznego SEO 2026. Warto też pamiętać, że waga dokumentu i wydajność idą w parze: strony, które przekraczają próg, niemal zawsze mają też problemy z metrykami, o których piszemy w opracowaniu o Core Web Vitals w 2026 roku.
Jak zmierzyć wagę surowego kodu HTML
Najczęstszy błąd przy analizie limitu polega na patrzeniu na niewłaściwą liczbę. Narzędzia typu PageSpeed Insights czy zakładka Network w przeglądarce pokazują wagę całej strony po renderowaniu, łącznie z grafikami, fontami i wykonanymi skryptami. Googlebota interesuje natomiast surowy dokument HTML, ten, który serwer zwraca przed uruchomieniem JavaScriptu. To dwie zupełnie różne wartości i tylko ta druga decyduje o progu 2 MB.
Aby sprawdzić realną wagę kodu, najprościej pobrać dokument tak, jak robi to crawler, bez renderowania. Wystarczy zwykłe zapytanie po stronie serwera, na przykład poleceniem curl z zapisem odpowiedzi do pliku, i sprawdzenie rozmiaru tego pliku. Alternatywnie w narzędziu do crawlowania serwisu warto włączyć kolumnę z rozmiarem odpowiedzi HTML i posortować adresy malejąco. Strony, które zbliżają się do 1,5 MB samego kodu, powinny zapalić żółtą lampkę, a te powyżej 2 MB wymagają natychmiastowej interwencji.
Dobrą praktyką jest dodanie tego pomiaru do cyklicznego audytu technicznego, najlepiej automatycznie. Jeśli serwis publikuje setki nowych adresów miesięcznie, ręczne sprawdzanie nie ma sensu. Reguła w narzędziu monitorującym, która alarmuje, gdy rozmiar surowego HTML przekroczy ustalony próg, kosztuje kilka minut konfiguracji, a oszczędza godzin diagnozowania zagadkowych problemów z indeksacją kluczowych podstron.
Co to znaczy dla AIO i widoczności w modelach
Warstwa wyszukiwania generatywnego dodaje do tej historii nowy wymiar. AI Overviews oraz AI Mode w Google korzystają z tego samego indeksu, który zasila klasyczne wyniki, a więc z tej samej, potencjalnie uciętej wersji strony. Jeśli kluczowy fragment treści, ten, który najlepiej odpowiada na pytanie użytkownika, znajdzie się poza progiem 2 MB, model językowy nie będzie miał z czego go zacytować. W świecie, w którym widoczność coraz częściej oznacza bycie przywołanym w odpowiedzi asystenta, ucięta treść to nie tylko utracona pozycja, lecz utracona szansa na cytowanie.
Dla strategii optymalizacji pod modele (AIO, czyli optymalizacja pod silniki odpowiedzi) wniosek jest jasny: gęsta, dobrze ustrukturyzowana i wysoko umieszczona w kodzie treść ma podwójną wartość. Po pierwsze, mieści się bezpiecznie w budżecie bajtów. Po drugie, jest łatwiejsza do wyodrębnienia i zacytowania przez systemy generatywne, które premiują jasne fragmenty i czytelne dane strukturalne. Limit 2 MB i logika AIO pchają więc w tę samą stronę: mniej balastu w kodzie, więcej sensu na górze dokumentu.
Architektura w tle: jeden crawler, wiele produktów
Czerwcowy zapis to także okazja, by przypomnieć, jak Google opisuje swoją infrastrukturę pobierania. Według wyjaśnień Gary’ego Illyesa Googlebot funkcjonuje jako jeden z użytkowników czegoś, co przypomina scentralizowaną platformę crawlingową. Z tej samej infrastruktury, choć z innymi nazwami crawlerów i odmiennymi konfiguracjami, korzystają inne produkty Google, w tym Google Shopping czy AdSense. To dlatego limity bajtowe i zasady pobierania są spójne w obrębie ekosystemu, a nie ustalane od nowa dla każdego bota.
Ta perspektywa ma praktyczne znaczenie. Skoro różne produkty dzielą wspólny mechanizm, optymalizacja kodu pod limit Googlebota działa szerzej niż tylko na potrzeby organicznych wyników wyszukiwania. Lżejszy, lepiej uporządkowany dokument HTML to korzyść, która rozlewa się na wiele kanałów jednocześnie.
Reakcje branży
W komentarzach ekspertów dominuje ton spokojnej satysfakcji, że Google wreszcie zapisało to, co i tak było wiadome. Serwisy branżowe, w tym Search Engine Journal i Search Engine Roundtable, podkreślają, że to klasyczne doprecyzowanie dokumentacji, a nie sygnał do paniki. Wielu praktyków technicznego SEO zwraca jednak uwagę, że oficjalny zapis ułatwia rozmowy z zespołami deweloperskimi: trudniej zbagatelizować wagę kodu, gdy można pokazać konkretną liczbę w dokumentacji Google, a nie kolejny wpis na blogu.
Pojawiają się też głosy, że dla serwisów enterprise, zwłaszcza dużych sklepów i platform z rozbudowanymi widokami, próg 2 MB powinien stać się stałym punktem monitoringu, obok statusów indeksowania i raportów pokrycia. Komentatorzy przypominają przy okazji, że Google używa sformułowania „na przykład 2 MB”, co część branży interpretuje jako sygnał, że wartość jest ilustracją rzędu wielkości, a nie sztywną gwarancją na wieczność. Innymi słowy, lepiej projektować z marginesem niż balansować na granicy.
Co dalej
Najbliższe miesiące pokażą, czy Google pójdzie dalej w stronę transparentności i czy podobne progi doczekają się równie jasnych zapisów dla innych typów zasobów. Na razie kierunek jest czytelny: firma porządkuje wiedzę o crawlingu, przenosi ją z formatu narracyjnego do referencyjnego i daje branży twarde liczby, na których można budować procesy. Dla zespołów SEO to zaproszenie, by raz na jakiś czas zważyć własny kod HTML i sprawdzić, ile naprawdę waży to, co serwują Googlebotowi.
Praktyczny plan na najbliższy sprint jest prosty. Zinwentaryzuj najcięższe szablony w serwisie, zmierz wagę surowego HTML, przenieś inline’owe skrypty i style do plików zewnętrznych, a najważniejsze znaczniki przesuń jak najwyżej. To niewielki nakład pracy, który chroni przed cichą utratą widoczności, zarówno w klasycznych wynikach, jak i w generatywnych odpowiedziach. W świecie, w którym o pozycję walczy się na bajty, kilkaset kilobajtów oszczędności potrafi zadecydować o tym, czy Google zobaczy całą Twoją stronę, czy tylko jej początek.
Ile dokładnie kodu HTML czyta Googlebot?
Według dokumentacji Google z 23 czerwca 2026 roku indeksujący Googlebot pobiera około 2 MB kodu HTML pojedynczego adresu URL, wliczając w to nagłówki odpowiedzi HTTP. Treść powyżej tego progu jest ucinana i nie trafia do indeksu ani do Web Rendering Service.
Czy to oznacza zmianę w działaniu wyszukiwarki?
Nie. Google podkreśla, że to doprecyzowanie dokumentacji, a nie zmiana zachowania. Limit obowiązywał wcześniej, ale dopiero teraz konkretna liczba została zapisana w oficjalnych materiałach dla deweloperów, obok wcześniejszych wyjaśnień z bloga i podcastu Search Off the Record.
Co się dzieje, gdy strona przekracza 2 MB?
Googlebot nie odrzuca takiej strony. Zatrzymuje pobieranie w punkcie odcięcia i przekazuje uciętą treść do systemów indeksujących oraz do WRS. Wszystko, co znajdowało się powyżej progu, nigdy nie zostaje pobrane, wyrenderowane ani zaindeksowane.
Czy pliki CSS i JavaScript liczą się do limitu 2 MB?
Nie, jeśli są to zasoby zewnętrzne. Osobne pliki CSS i JS mają własne liczniki bajtów i nie konsumują budżetu strony nadrzędnej. Dlatego przeniesienie ciężkich stylów i skryptów do zewnętrznych plików to jeden z najprostszych sposobów na zmieszczenie kluczowej treści w progu 2 MB.
Jaki jest limit dla plików PDF?
Dla plików PDF Google podaje limit 64 MB, znacznie wyższy niż 2 MB dla HTML. Domyślny limit dla nieokreślonych crawlerów wynosi z kolei 15 MB i opisuje fazę pobierania pliku, a nie przetwarzania treści tekstowej do indeksu.