Co się dzieje, kiedy Googlebot trafia na stronę ze skryptami

Warto rozdzielić trzy etapy, bo błąd na każdym z nich wygląda inaczej i inaczej się go naprawia.

• Pobranie — Googlebot ściąga surowy dokument HTML. Nie ma w nim jeszcze niczego, co dorysowały skrypty.

• Renderowanie — dokument trafia do usługi renderującej, która uruchamia go w Chromium. Nie dzieje się to natychmiast po pobraniu: renderowanie stoi w osobnej kolejce i bywa odłożone.

• Indeksowanie — do indeksu idzie wynik renderowania, czyli HTML po wykonaniu skryptów.

Dobra wiadomość: od 2019 roku Google renderuje w aktualnej wersji Chromium, a nie w zamrożonym silniku sprzed lat. Nowoczesna składnia zadziała i nie trzeba transpilować kodu specjalnie dla robota.

Zła wiadomość: renderowanie to jedno podejście, bez ponowień na życzenie. Jeśli skrypt czeka na odpowiedź zewnętrznego API, które akurat zwróci błąd, albo treść pojawia się dopiero po interakcji użytkownika — do indeksu pójdzie strona bez tej treści. Nikt Ci o tym nie powie wprost.

Jest jeszcze kolejność, o której łatwo zapomnieć: jeśli w surowym HTML-u siedzi znacznik noindex, Google odrzuca stronę zanim ją wyrenderuje. Zdejmowanie go skryptem jest bezużyteczne.

Sprawdzanie adresu URL, czyli podgląd oczami robota

Punktem wyjścia jest zawsze narzędzie sprawdzania adresu URL w Search Console. Wklejam adres, wybieram test na żywo, a potem klikam Wyświetl przetestowaną stronę — i to jest właściwy moment całej diagnostyki.

W zakładce z kodem HTML dostaję dokument po renderowaniu. Szukam w nim konkretnych rzeczy: nagłówka H1, głównego tekstu, listy produktów, linków w menu, znaczników danych strukturalnych. Jeśli w tym HTML-u nie ma zdania, na którym Ci zależy, to nie ma go w Google.

Zrzut ekranu obok traktuję jako drugi dowód. Zdarza się, że w kodzie treść jest, ale zrzut pokazuje białą stronę albo wieczny spinner — wtedy problem dotyczy raczej stylów niż samych danych.

Od stycznia tego roku te dane są dostępne także programowo, przez API narzędzia sprawdzania adresu URL. Przydaje się przy większych serwisach, bo pozwala odpytać wiele adresów zamiast klikać je pojedynczo. Warto jednak wiedzieć, czego z niego nie wyciągniesz: zwraca stan indeksowania i wynik testu, ale nie wyrenderowanego kodu ani zrzutu ekranu.

Wiadomości konsoli i zasoby, których nie udało się załadować

W tym samym oknie, w sekcji z dodatkowymi informacjami, są dwie listy, które w praktyce rozwiązują większość spraw.

Pierwsza to wiadomości konsoli JavaScript. Traktuję je jak log z awarii: jeden nieprzechwycony wyjątek w kodzie budującym listę produktów wystarczy, żeby cała lista nie powstała. Nie każdy komunikat jest winowajcą — ostrzeżenia o wycofanych metodach czy hałas z narzędzi analitycznych są zwykle nieszkodliwe.

Druga to zasoby strony, których nie udało się załadować, wraz z powodem. Tutaj wychodzą rzeczy najbardziej banalne: plik zablokowany w robots.txt, adres kierujący w pustkę po wdrożeniu nowej wersji, skrypt z zewnętrznej domeny odrzucający ruch robota. Jeżeli na tej liście jest plik, od którego zależy wyświetlenie treści, dalej nie muszę szukać.

Uzupełniająco używam testu optymalizacji mobilnej i testu wyników z elementami rozszerzonymi — oba pokazują wyrenderowany HTML i te same komunikaty, a działają bez dostępu do Search Console.

Skrypty zablokowane w robots.txt

To wciąż numer jeden na liście przyczyn i najprostsza rzecz do sprawdzenia. Blokady w robots.txt są dziedziczone po latach i kopiowane z gotowców, w których ktoś kiedyś uznał, że robot nie musi zaglądać do katalogów technicznych. Efekt: Googlebot ma prawo pobrać HTML, ale nie pliki, które ten HTML dopiero wypełniają treścią. Nie zgłasza wtedy błędu — po prostu renderuje puste rusztowanie.

Sprawdzam trzy grupy reguł: katalogi ze skryptami i stylami, ścieżki z zasobami motywu i wtyczek, oraz adresy punktów końcowych API, z których strona pobiera dane. Ta trzecia bywa przeoczona, bo nie kojarzy się z zasobami na stronie, a bez niej lista produktów czy opinii nie powstanie.

Osobno pilnuję, żeby nie blokować adresów, które chcę usunąć z indeksu — blokada nie usuwa strony z wyników, tylko uniemożliwia odczytanie jej treści i znacznika noindex.

Wzorce w kodzie, które regularnie wycinają treść z indeksu

Poza awariami jest zestaw rozwiązań, które działają dla użytkownika i nie działają dla robota. Widzę je na większości serwisów opartych na frameworkach, które przejmuję do opieki.

• Treść odsłaniana kliknięciem — zakładki i przyciski „pokaż więcej”, które dociągają tekst po kliknięciu. Googlebot nie klika i nie przewija; treść musi być w wyrenderowanym HTML-u, nawet jeśli wizualnie jest zwinięta.

• Linki, które nie są linkami — element obsługiwany zdarzeniem, przekierowujący routerem, bez atrybutu href z prawdziwym adresem. Robot nie ma po czym przejść dalej, więc podstrony zostają odcięte od nawigacji.

• Adresy z fragmentem po znaku # — widoki różniące się tylko fragmentem to dla Google jedna strona. Każdy widok, który ma być w indeksie, potrzebuje pełnego adresu URL.

• Doczytywanie przy przewijaniu — bez zwykłych linków do kolejnych stron dalsze wyniki listy dla robota nie istnieją.

• Stan trzymany w pamięci przeglądarki — jeśli strona wymaga danych zapisanych wcześniej lokalnie albo w ciasteczku, robot ich nie ma. Każde wejście traktuje jak pierwsze w życiu.

• Błędy zwracane z kodem 200 — nieistniejący produkt pokazujący komunikat wygenerowany skryptem, przy poprawnej odpowiedzi serwera. Google oznaczy takie adresy jako miękkie 404.

W przeglądarce weryfikuję to szybciej: przełączam agenta użytkownika na Googlebota dla smartfonów, bo indeksowanie opiera się dziś na wersji mobilnej, i patrzę na panel sieci oraz konsolę.

Raport Pokrycie i statystyki indeksowania

Pojedynczy adres diagnozuję narzędziem sprawdzania URL. Skalę problemu widzę dopiero w raportach zbiorczych.

W raporcie Pokrycie patrzę na wykluczenia. Duża grupa adresów w stanie „Wykryto — obecnie nie zindeksowano” bywa objawem tego, że renderowanie tych stron nic sensownego nie zwraca. Podobnie masowe miękkie 404 przy adresach, które w przeglądarce wyglądają normalnie. To nie dowód, tylko wskazanie, gdzie kopać dalej.

W statystykach indeksowania szukam odpowiedzi serwera z podziałem na typy plików. Błędy przy plikach JavaScript i CSS to sygnał, że robot regularnie nie dostaje zasobów, których potrzebuje. Istotne są też wysokie czasy odpowiedzi — im dłużej trwa pobranie zasobu, tym większa szansa, że nie zmieści się w oknie renderowania.

Pamiętaj przy tym, że Google agresywnie buforuje pliki JavaScript i CSS i nie kieruje się Twoimi nagłówkami tak, jak przeglądarka. Po wdrożeniu poprawki robot może jeszcze korzystać ze starej wersji pliku — dlatego warto mieć skrót treści w nazwie.

Co robię z ustaleniami

Kolejność napraw wynika u mnie z kosztu i pewności efektu. Najpierw odblokowuję zasoby w robots.txt i naprawiam brakujące pliki, bo to zmiany małe i pewne. Potem usuwam błędy z konsoli, które wywalają budowanie treści. Dopiero na końcu wchodzę w architekturę.

Jeśli treść krytyczna dla wyszukiwarki powstaje wyłącznie w przeglądarce, wracam do rozmowy z programistami o renderowaniu po stronie serwera albo o generowaniu statycznych wersji podstron. Przy kilkunastu stałych podstronach byłoby to przerostem formy, przy katalogu z tysiącami produktów jest zwykle jedynym rozwiązaniem, które przestaje generować nowe problemy.

Dynamicznego renderowania dla robotów nie polecam jako celu. Google wciąż opisuje je jako obejście i tak też je traktuję: rozwiązanie awaryjne, kiedy przebudowa aplikacji jest niemożliwa w rozsądnym czasie.

I rzecz najważniejsza: naprawę trzeba potwierdzić tym samym narzędziem, którym wykryto problem. Wdrożenie poprawki nie kończy sprawy. Kończy ją wyrenderowany HTML, w którym widzę treść, oraz — po pewnym czasie — spadek liczby wykluczeń w raporcie. Bez tej pętli zostajesz z przekonaniem, że problem został rozwiązany, i bez żadnego dowodu.