JavaScript SEO: jak Googlebot pobiera i renderuje zasoby

Googlebot najpierw pobiera HTML nadrzędnego adresu URL. Potem Web Rendering Service pobiera pliki JavaScript i CSS, na które wskazuje ten kod, i buduje stronę tak, jak zrobiłaby to przeglądarka. A tekst, który pojawia się dopiero po tym kroku? Trafia do indeksu tylko wtedy, gdy każdy wymagany zasób jest dostępny. To JavaScript SEO w pigułce i zarazem wyjaśnienie objawu, który większość z nas już widziała: w przeglądarce strona wygląda na kompletną, a Google pokazuje ledwie skrawek jej tekstu. Temat jest też świeży, bo 3 grudnia 2024 Google otworzył serię Crawling December wpisem o pobieraniu zasobów i budżecie indeksowania.

Jak Googlebot pobiera stronę opartą na JavaScript?

Zaczyna od początkowego HTML z nadrzędnego adresu URL. Zasoby, do których ten HTML się odwołuje, są pobierane później, na potrzeby renderowania. Wpis Google o pobieraniu zasobów strony mówi to wprost: te początkowe dane mogą wskazywać na JavaScript, CSS, obrazy i filmy, dokładnie tak jak w przypadku przeglądarki. Kolejność wygląda tak:

1. Sprawdzenie robots.txt - zablokowany adres URL jest pomijany, żadne żądanie nie zostaje wysłane.
2. Żądanie HTTP - robot pobiera HTML strony.
3. Kolejka renderowania - strona czeka, aż zasoby Google pozwolą ją przetworzyć.
4. Pobieranie zasobów - pobierane są skrypty, arkusze stylów i dane, które one wywołują.
5. Wyrenderowany HTML - to on służy do indeksowania i odkrywania linków.

Co Web Rendering Service robi z Twoimi zasobami

Web Rendering Service (w skrócie WRS) bierze wszystko, co pobrał, i składa stronę tak, jak zrobiłaby to przeglądarka użytkownika. Pod spodem działa headless Chromium, który wykonuje JavaScript. Które strony trafiają do kolejki? Podstawy JavaScript SEO od Google podają, że strony z kodem stanu 200 są ustawiane w kolejce do renderowania, chyba że metatag robots albo nagłówek każe Google ich nie indeksować. Oczekiwanie może trwać kilka sekund. Ale może też potrwać dłużej.

Google indeksuje wyrenderowany HTML, a potem analizuje go jeszcze raz w poszukiwaniu linków. Dlatego menu, paginacja i bloki z powiązanymi treściami budowane przez skrypty muszą w tym wyniku przyjąć postać linków wewnętrznych dostępnych dla robotów. Jeśli tak się nie stanie, strony, do których prowadzą, pozostają nieodkryte.

Zablokowane pliki JavaScript i inne powody znikania tekstu

Wyszukiwarka Google nie wyrenderuje JavaScriptu z zablokowanych plików ani na zablokowanych stronach. Wystarczy reguła disallow w robots.txt nałożona na skrypt, arkusz stylów albo ścieżkę API, a wyrenderowany HTML powstaje bez treści, które one generują. Do tego renderowanie po stronie Googlebota zawodzi tu po cichu: szkielet HTML trafia do indeksu, a tekst nigdy nie dociera. Żadnego alarmu, nic. Najpierw sprawdź te przyczyny na własnym serwerze źródłowym:

• zablokowane ścieżki /assets lub /api w robots.txt,
• hosty zasobów, które odrzucają żądania botów,
• limity żądań, które blokują roboty w trakcie pobierania skryptów,
• wywołania API zwracające błędy zamiast danych.

Googlebot opiera się na kodach stanu HTTP, żeby ustalić, czy coś poszło nie tak. Aplikacja działająca po stronie klienta, która dla brakującej albo pustej strony odpowiada kodem sukcesu, tworzy bałagan opisany w tekście o pozornych błędach 404. Znaczenie ma też routing: adresy URL powinny być dostępne przez History API, a nie przez fragmenty. I każda poprawka z tej listy dotyczy wszystkich odwiedzających jednakowo. Chodzi o jedną działającą stronę, a nie o osobną wersję dla robotów.

Pobieranie zasobów strony a Twój budżet indeksowania

Każdy zasób pobrany na potrzeby renderowania uszczupla budżet indeksowania nazwy hosta, która go udostępnia. Żeby złagodzić ten koszt, WRS próbuje zapisać w pamięci podręcznej każdy plik JavaScript i CSS, do którego odwołują się renderowane strony, na okres do 30 dni i bez względu na dyrektywy buforowania HTTP, jak podaje wpis Crawling December o zasobach. Multimedia też się liczą: pobrania wykonywane przez Googlebot-Image i Googlebot-Video zużywają budżet witryny.

Co więc zrobić z budżetem indeksowania dla plików JS i CSS? To w gruncie rzeczy proste. Im mniej zasobów potrzebuje Twoja główna treść, tym mniej budżetu idzie na renderowanie i tym więcej zostaje na inne zadania robota. Google zaktualizował też wpis 6 grudnia 2024, dodając uwagę o wpływie serwowania zasobów z innego originu na wydajność. Moim zdaniem warto to rozważyć, zanim przeniesiesz zasoby na inną nazwę hosta.

Dlaczego Google może uruchomić nieaktualną wersję Twojego skryptu

WRS buforuje agresywnie i może ignorować nagłówki buforowania. Skutek uboczny: może wyrenderować stronę ze starym JavaScriptem albo CSS. Rozwiązaniem jest content fingerprinting. Skrót zawartości pliku staje się częścią jego nazwy, na przykład main.2bb85551.js, więc każda aktualizacja daje nowy adres URL, a po nieaktualną kopię nikt już nie sięga.

Unikaj natomiast parametrów zapytania omijających pamięć podręczną, które zmieniają się przy każdym żądaniu, choć treść pliku się nie zmienia. Nowe adresy URL oznaczają nowe pobrania, a te spalają budżet na pliki, które Google już ma. Skonfiguruj fingerprinting w swoim narzędziu do budowania, a potem upewnij się, że Twój serwer źródłowy albo NGINX faktycznie poprawnie serwuje pliki z haszem w nazwie.

Jak sprawdzić, co faktycznie wyrenderował Googlebot

Otwórz wyrenderowany HTML w narzędziu do sprawdzania adresów URL albo w teście wyników z elementami rozszerzonymi i wyszukaj w nim tekst, którego brakuje w Google. Liczy się tylko treść widoczna w tym wyniku (w przypadku komponentów webowych shadow DOM i light DOM są w nim spłaszczane). Dowody przeglądałbym w tej kolejności:

1. sam wyrenderowany HTML,
2. lista zasobów, których nie udało się wczytać,
3. reguły robots.txt obejmujące te pliki,
4. kody stanu skryptów i punktów końcowych API.

W praktyce SEO przy renderowaniu po stronie klienta sprowadza się do jednego nawyku: umieszczaj kluczowy tekst i linki w początkowym HTML tam, gdzie pozwala na to Twój framework, jednakowo dla każdego odwiedzającego. Masz przed witryną proxy? Obraz się nie zmienia - Jalvo przekazuje żądania do Twojego serwera źródłowego, więc reguły renderowania i zasobów pozostają w konfiguracji serwera źródłowego albo CMS-a.

Zasada stojąca za JavaScript SEO jest krótka. Google może zindeksować tylko to, co jego renderer jest w stanie pobrać i zbudować. Odblokuj skrypty, arkusze stylów i ścieżki API, od których zależy Twoja treść, dodaj skrót zawartości do nazw plików, żeby aktualizacje dostawały nowe adresy URL, i sprawdzaj wyrenderowany HTML po każdym istotnym wdrożeniu.

FAQ