Strona może działać w przeglądarce zupełnie normalnie, a jej najważniejsza treść może siedzieć bardzo daleko w kodzie. Użytkownik widzi nagłówek, tekst i ofertę. Googlebot może jednak najpierw przedzierać się przez ciężkie menu, wielkie kawałki kodu i obrazki zapisane w środku HTML-u. Trochę jak wejście do sklepu, w którym kasa jest, ale najpierw trzeba przejść przez magazyn pełen kartonów.
Tu pojawia się temat limitu 2 MB Googlebota. Spokojnie: to nie jest magiczna granica SEO ani zakaz posiadania większej strony. Chodzi o ilość nieskompresowanych danych pobieranych podczas crawlowania pojedynczego zasobu. Poniżej rozkładam temat na części i pokazuję, co można sprawdzić samodzielnie, bez grzebania w serwerze i bez zakładania peleryny administratora.
Limit 2 MB Googlebota — o co w ogóle chodzi?
Googlebot podczas crawlowania dla Google Search pobiera pierwsze 2 MB obsługiwanego pliku. W przypadku dokumentu HTML oznacza to początek kodu strony, liczony jako nieskompresowane dane. Jeśli plik jest większy, Googlebot nie wyrzuca całej strony do kosza. Nie działa to na zasadzie: „2 MB i koniec przygody, witryna skreślona”.
Problem polega na czymś innym. Po przekroczeniu limitu dalsza część pliku nie jest pobierana do dalszego przetwarzania w ramach tego pobrania. Jeżeli więc ważny tekst, metadane albo dane strukturalne znajdą się dopiero za punktem odcięcia, nie można zakładać, że Google je zobaczy z tego pobrania.
Warto też od razu odczarować kilka rzeczy:
- 2 MB nie jest magicznym limitem SEO. Samo przekroczenie tej wartości nie oznacza automatycznej utraty widoczności.
- Strona mniejsza niż 2 MB nie dostaje z automatu pieczątki „wszystko dobrze”. Rozmiar HTML-u to tylko jeden z elementów układanki.
- Nie da się ocenić indeksowania wyłącznie na podstawie liczby megabajtów. Trzeba sprawdzić konkretny adres i jego wersję wyrenderowaną.
Najbezpieczniejszy wniosek jest prosty: ważne elementy powinny być dostępne wcześnie, a duży HTML warto traktować jako sygnał do sprawdzenia, nie jako wyrok.
Co może napompować HTML i wypchnąć ważną treść?
HTML potrafi urosnąć po cichu. Nikt nie siada rano i nie mówi: „Dziś powiększę kod o setki kilobajtów”. Kod rozbudowuje się przy okazji: dochodzi menu, slider, fragment stylów, skrypt, obrazek wklejony bezpośrednio do dokumentu. Każdy element może mieć sens, ale razem tworzą korek przed właściwą treścią.
W materiałach Google jako przykłady elementów, które mogą zwiększać rozmiar dokumentu, wskazywane są między innymi:
- obrazy zakodowane bezpośrednio w HTML-u jako Base64,
- duże bloki inline CSS,
- duże bloki inline JavaScript,
- bardzo rozbudowane menu umieszczone przed główną treścią.
Do sprawdzenia są też inne techniczne elementy znajdujące się wysoko w dokumencie, na przykład slidery albo rozbudowane fragmenty generowane przez motyw i wtyczki. To nie znaczy, że każdy slider jest problemem, każdą wtyczkę trzeba wyrzucić, a menu ma zniknąć jak skarpetka po praniu. Chodzi o znalezienie tego, co niepotrzebnie zajmuje miejsce przed ważnym tekstem.
Nie usuwaj jednak kodu na ślepo. Skrypt może obsługiwać istotną funkcję, dane strukturalne mogą mieć swoje zadanie, a menu jest przecież potrzebne użytkownikowi. Najpierw trzeba ustalić, co faktycznie rozdmuchuje HTML i co znajduje się przed główną treścią. Dopiero potem można myśleć o uporządkowaniu kodu.
Dlaczego kolejność elementów w kodzie ma znaczenie?
Wyobraź sobie dokument HTML jak długi pociąg. Googlebot dociera do pierwszej części składu, ale przy określonym limicie nie pobiera kolejnych wagonów. Jeśli najważniejszy tekst jedzie na samym końcu, problemem nie jest tylko długość pociągu. Problemem jest też to, co ustawiono przed nim.
Dlatego kolejność elementów w kodzie ma znaczenie. Google zaleca umieszczanie wysoko w dokumencie najważniejszych elementów, takich jak:
- element
title, - link
canonical, - kluczowa treść strony,
- istotne dane strukturalne.
Jeżeli duży blok inline CSS, JavaScript, Base64 albo rozbudowane menu zajmuje początek dokumentu, główna treść może zostać przesunięta za punkt odcięcia. Wtedy nie powinno się zakładać, że będzie dostępna dla dalszego przetwarzania z tego pobrania.
To nadal nie jest trik w rodzaju „przenieś nagłówek wyżej i jutro wygrywasz Google”. Zmiana kolejności nie gwarantuje lepszej pozycji, większego ruchu ani sprzedaży. Chodzi o techniczną dostępność ważnych elementów dla crawlowania i indeksowania. Najpierw porządek, potem dopiero wnioski.
HTML to nie wszystko: JavaScript i wyrenderowana wersja strony
Tu łatwo o pomyłkę. Google Search przetwarza strony w etapach crawlowania, renderowania i indeksowania. Początkowy HTML to nie zawsze dokładnie to samo, co widzisz po załadowaniu strony w przeglądarce. Część treści może pojawić się dopiero po renderowaniu JavaScriptu.
Dlatego oglądanie strony jako użytkownik nie wystarcza. Możesz widzieć pełny opis, sekcję usług i dane dodatkowe, ale trzeba jeszcze sprawdzić, jak wygląda wersja dostępna po renderowaniu. Nie oznacza to, że każde użycie JavaScriptu jest błędem. Oznacza tylko, że widok w przeglądarce nie daje pełnego obrazu procesu.
Sam rozmiar początkowego HTML-u też nie odpowiada na wszystkie pytania. Nie mówi automatycznie, czy konkretna strona jest poprawnie indeksowana, czy ważna treść pojawia się we właściwym momencie i czy dane strukturalne są dostępne. Do tego potrzebna jest kontrola konkretnego adresu.
Szybka checklista bez grzebania w serwerze
Właściciel strony może zrobić podstawowe sprawdzenie bez logowania do serwera i bez polowania na tajemniczy plik o nazwie „final_final2”. Najważniejsza jest kontrola konkretnego URL-a, a nie zgadywanie na podstawie samej wielkości strony.
- Otwórz URL Inspection w Google Search Console i sprawdź wybrany adres.
- Przejrzyj wyrenderowany HTML, a nie tylko to, co widzisz w zwykłym widoku przeglądarki.
- Porównaj główną treść widoczną dla użytkownika z treścią dostępną w wersji wyrenderowanej.
- Sprawdź, czy dostępne są
title,canonical, główny tekst i istotne dane strukturalne. - Dane strukturalne przetestuj dodatkowo w Rich Results Test.
- Zwróć uwagę na treści pojawiające się dopiero po kliknięciu albo innej interakcji.
Jeśli nie wiesz, gdzie znaleźć wyrenderowany HTML albo jak odczytać wynik, nie zgaduj na podstawie samego rozmiaru pliku. Zapisz konkretny adres i przekaż go osobie technicznej. Narzędzia pomagają w kontroli, ale nie zastępują pełnego audytu.
Ważna rzecz przy danych strukturalnych: poprawny kod nie gwarantuje wyświetlenia wyniku rozszerzonego w Google. Może zwiększać możliwość kwalifikacji, ale Google nie obiecuje konkretnego wyglądu wyniku ani jego pokazania.
Kiedy warto poprosić o pomoc techniczną?
Warto poprosić o pomoc, gdy nie wiadomo, co właściwie rozdmuchuje HTML albo które elementy znajdują się przed główną treścią. Szczególnie wtedy, gdy kod jest generowany przez motyw, wtyczki lub kilka połączonych ze sobą mechanizmów. Samodzielne kasowanie skryptów metodą „zobaczymy, co wybuchnie” nie jest najlepszym planem.
Konsultacja ma sens także wtedy, gdy ważna treść pojawia się dopiero po JavaScripcie albo Search Console pokazuje różnicę między tym, co widzi użytkownik, a tym, co dostępne jest w wersji wyrenderowanej. W takiej sytuacji trzeba sprawdzić kolejność elementów, rolę kodu i konkretny adres, zamiast urządzać polowanie na samą liczbę 2 MB.
Przed zmianami dobrze ustalić trzy rzeczy:
- co w HTML-u jest naprawdę zbędne,
- które elementy powinny znaleźć się wcześniej,
- czy po zmianach ważna treść, metadane i dane strukturalne nadal są dostępne.
Celem nie jest odchudzenie strony za wszelką cenę. Celem jest sensowny, uporządkowany dokument, w którym najważniejsze informacje nie giną pod techniczną stertą. Jeśli potrzebujesz przejrzeć stronę, kod, grafikę, film albo teksty, mogę pomóc przełożyć techniczny problem na konkretne kroki.
Podsumowując: limit 2 MB Googlebota dotyczy pierwszych 2 MB nieskompresowanego, pobieranego zasobu. Większy HTML nie oznacza automatycznego odrzucenia strony, ale treść za punktem odcięcia nie powinna być traktowana jako pewnie dostępna z tego pobrania. Dlatego ważne elementy warto umieszczać wysoko w kodzie, a sytuację sprawdzać dla konkretnego URL-a i wersji wyrenderowanej. Pamiętaj też, że poprawne dane strukturalne nie gwarantują rich result. Napisz do Szwagra i opowiedz, czego potrzebujesz — strony, grafiki, filmu albo tekstów.
