Boty AI i JavaScript: dlaczego ChatGPT może widzieć pustą stronę
Krótka odpowiedź: W temacie boty AI i JavaScript obowiązuje prosta reguła: bot, który nie wykonuje skryptów, widzi tylko HTML wysłany przez twój serwer. Jeśli tekst twojej strony powstaje dopiero w przeglądarce, ten HTML może być pustą powłoką. W pomiarze Vercel i MERJ z grudnia 2024 roku żaden z dużych crawlerów AI nie wykonywał JavaScriptu, natomiast crawler Google i AppleBot tak. To migawka z 2024 roku, więc sprawdź własne strony i umieść główną treść w samym HTML: renderuj ją na serwerze albo generuj z wyprzedzeniem.
Jak crawler dostaje twoją stronę?
Każde pobranie zaczyna się tak samo: żądanie do twojego serwera, na które przychodzi odpowiedź w postaci HTML. To, co dzieje się potem, decyduje o tym, ile z twojej strony dotrze do bota.
Przeglądarka wczytuje skrypty, na które wskazuje HTML, wykonuje je i pokazuje wynik. Crawler może zatrzymać się na pierwszym HTML. Albo renderuje: wykonuje skrypty, czeka i dopiero potem czyta.
Jeśli serwer wysyła tekst od razu, obie drogi prowadzą do tej samej treści. Jeśli strona jest składana w przeglądarce, pierwszy HTML zawiera jej niewiele. Dokumentacja Google nazywa to modelem „app shell”. Bot bez JavaScriptu dostaje mniej więcej coś takiego:
<body>
<div id="root"></div>
<script src="/app.js"></script>
</body>
Nagłówek, tekst, lista produktów i linki pojawiają się dopiero po wykonaniu /app.js. Nie każdy crawler to wykonuje i na tym polega cały problem.
Co Google robi z JavaScriptem
Google to łatwy przypadek. Jego dokumentacja o podstawach JavaScript SEO mówi:
- Google Search wykonuje JavaScript w „evergreen” wersji Chromium.
- Strona przechodzi trzy fazy: crawlowanie, renderowanie i indeksowanie.
- Strona ze statusem 200 trafia do kolejki do renderowania, co może potrwać kilka sekund albo dłużej. W przypadku strony ze statusem innym niż 200, na przykład 404, renderowanie może zostać pominięte.
- Tytuł, meta opis i canonical mogą być ustawiane przez JavaScript.
Ta sama strona podaje też powód, dla którego powstał ten artykuł. Google pisze, że renderowanie po stronie serwera albo wstępne renderowanie nadal jest dobrym pomysłem, bo przyspiesza stronę dla użytkowników i crawlerów, a także dlatego, że nie wszystkie boty potrafią wykonywać JavaScript. „Google indeksuje moją stronę” nie znaczy więc, że każdy bot ją przeczyta.
Boty AI i JavaScript: co jest potwierdzone
Najbardziej znany pomiar pochodzi od Vercel i MERJ i ukazał się w grudniu 2024 roku pod tytułem The rise of the AI crawler. Wynik: żaden z dużych crawlerów AI nie wykonywał JavaScriptu. Badanie wymienia wśród nich GPTBot, OAI-SearchBot, ChatGPT-User i ClaudeBot. Googlebot (w badaniu wymieniony przy Gemini) oraz AppleBot renderowały JavaScript.
Obok tego wyniku trzeba postawić dwa zastrzeżenia. Po pierwsze, to migawka z 2024 roku, a nowszego pomiaru, który moglibyśmy przytoczyć, nie mamy. Crawlery się zmieniają, więc potraktuj ten wynik jako ostrzeżenie, a nie prawo. Po drugie, mówi on o tym, co bot czyta, a nie o tym, czy strona zostanie zacytowana w odpowiedzi. Cytowania nikt nie może obiecać, z JavaScriptem ani bez niego.
Same boty mają różne zadania. Tak opisują je operatorzy:
| Operator | Bot | Cel według operatora |
|---|---|---|
| OpenAI | GPTBot | Trenowanie generatywnych modeli podstawowych |
| OpenAI | OAI-SearchBot | Wyszukiwanie w ChatGPT |
| OpenAI | ChatGPT-User | Pobrania na prośbę użytkownika, na przykład przy pytaniu w ChatGPT |
| Anthropic | ClaudeBot | Zbiera treści z sieci, które mogą przyczynić się do trenowania |
| Anthropic | Claude-SearchBot | Poprawia jakość wyników wyszukiwania |
| Anthropic | Claude-User | Pobrania, gdy użytkownik o coś pyta Claude |
| Perplexity | PerplexityBot | Pokazuje strony w wynikach wyszukiwania Perplexity i do nich linkuje |
Źródła to OpenAI, Anthropic i Perplexity. Perplexity ma ponadto osobnego bota do pobrań na prośbę użytkownika. Jeśli boty stojące za odpowiedziami wyszukiwania AI czytają tylko HTML, strona z pustą powłoką nie daje im niczego do zacytowania. To, które z nich renderują skrypty, zmierzyło właśnie badanie z 2024 roku i właśnie to warto sprawdzić na własnych stronach.
Kogo to dotyczy
Dotyczy cię to, jeśli tekst albo linki twoich stron nie istnieją w HTML, który wysyła serwer:
- Strony składane w całości w przeglądarce. Serwer odpowiada powłoką i paczką skryptów, a skrypt dopiero pisze nagłówek, tekst i nawigację.
- Treści doładowywane przez skrypty. Listy produktów, ceny, opinie, zakładki albo sekcje „Wczytaj więcej”, które pochodzą z wywołania API po załadowaniu strony.
- Linki, które powstają dopiero po wykonaniu skryptów. Crawler bez JavaScriptu może podążać tylko za linkami, które są w HTML. Na to samo natrafia przeszukiwanie witryny w SEOgrinder: zaznacza, że linków powstających dopiero w przeglądarce nie da się prześledzić.
- Tytuł, opis, canonical i znaczniki Open Graph ustawiane przez skrypt. Google to akceptuje. Bot, który pomija skrypty, nigdy ich nie zobaczy.
Nie dotyczy cię to, jeśli serwer wysyła tekst od razu. Interaktywne dodatki, takie jak menu, wykres czy kalkulator, mogą nadal powstawać w przeglądarce. SEOgrinder zgłasza strony istniejące tylko w przeglądarce jako „Strona powstaje dopiero w przeglądarce”, bo wiele crawlerów AI nie wykonuje tam JavaScriptu i widzi niemal pustą stronę.
Trzy testy w jedną minutę
Do odpowiedzi nie potrzebujesz żadnego narzędzia. Wszystkie trzy testy odpowiadają na to samo pytanie: czy mój tekst jest w HTML, który wysyła serwer?
- Pokaż źródło strony. Otwórz stronę i wybierz „Pokaż źródło strony” (w Chrome: „Wyświetl źródło strony”; skrót Ctrl+U, na Macu Cmd+Option+U). Nie używaj „Zbadaj”: inspektor pokazuje stronę po wykonaniu skryptów. Wyszukaj w źródle zdanie, które możesz przeczytać na stronie.
- Pobierz stronę przez curl. W terminalu uruchom
curl -sL https://example.com/twoja-strona | grep -io "krótka fraza z twojej strony", podstawiając krótką frazę z własnej strony. Jeśli fraza się wyświetli, jest w HTML, chyba że występuje wyłącznie wewnątrz elementuscript, bo to się nie liczy. Jeśli nic się nie wyświetli, sprawdź najpierw pisownię i znaki specjalne; w przeciwnym razie jej w HTML nie ma. - Wyłącz JavaScript. Otwórz narzędzia deweloperskie, wywołaj menu poleceń (Ctrl+Shift+P, na Macu Cmd+Shift+P), wpisz „JavaScript”, wybierz opcję wyłączenia JavaScript (w angielskim interfejsie „Disable JavaScript”) i przeładuj stronę. Jeśli główna treść zniknęła, bot bez JavaScriptu widzi to samo.
Jak odczytać wynik:
| Co widzisz | Co to oznacza |
|---|---|
| Fraza jest w źródle i w wyniku curl | Tekst jest w dostarczonym HTML. Ta część jest w porządku. |
| Frazy brakuje w źródle, ale widać ją w przeglądarce | Strona jest budowana w przeglądarce. Boty, które pomijają skrypty, nie widzą tekstu. |
Dwa ograniczenia: curl pokazuje to, co twój serwer wysyła do curl, a nie to, co wysyła do konkretnego bota, na przykład gdy zapora sieciowa traktuje boty inaczej. A żeby zobaczyć, co Google wyrenderował, użyj narzędzia do sprawdzania adresu URL (URL Inspection) w Google Search Console.
Jak to naprawić: umieść treść w HTML
Celem jest, żeby nagłówki, tekst główny i linki wewnętrzne były widoczne w źródle. Są dwie popularne drogi:
- Renderowanie po stronie serwera (SSR). Serwer buduje gotowy HTML przy każdym żądaniu.
- Wstępne renderowanie, zwane też generowaniem statycznym (SSG). Strony są generowane z wyprzedzeniem, na przykład podczas budowania serwisu, a serwer tylko wydaje pliki.
Oba sposoby umieszczają treść już w pierwszej odpowiedzi. Poza tym:
- Zacznij od ważnych stron. Pełna przebudowa rzadko jest potrzebna. Zacznij od stron, które mają się pozycjonować albo być cytowane.
- Wstaw najważniejsze do pierwszego HTML. Chodzi o tytuł, meta opis, canonical, znaczniki Open Graph, tekst główny i linki nawigacyjne zapisane jako prawdziwe elementy
<a href>. - Pokaż crawlerom i odwiedzającym tę samą treść. Google wymienia „dynamic rendering”, w którym boty dostają gotową wersję, tylko jako obejście. Pokazywanie crawlerom czegoś innego niż odwiedzającym to cloaking.
- Sprawdź wynik w źródle. Po zmianie powtórz trzy testy.
Nic z tego nie jest gwarancją pozycji w wynikach. Usuwasz techniczną przeszkodę i nic więcej.
Jak SEOgrinder wykrywa strony budowane w przeglądarce
SEOgrinder patrzy na HTML, który dostarcza twój serwer, a nie na to, co przeglądarka z niego zrobi. Wpisz adres, uruchom analizę, a zadania pojawią się w karcie Zadania, posortowane według wpływu. Z tym tematem wiążą się trzy wyniki:
- „Strona powstaje dopiero w przeglądarce”. Wynik podaje, ile słów, nagłówków i linków wewnętrznych zawiera dostarczony HTML, i zaznacza, że Google renderuje takie strony z opóźnieniem, a wiele crawlerów AI widzi niemal pustą stronę.
- Zbiorczy wynik z przeszukiwania witryny, na przykład „5 stron powstaje dopiero w przeglądarce”. Przeszukiwanie zgłasza, ile z przeszukanych stron dostarcza niemal pustą powłokę HTML. Strony z noindex oraz strony logowania i rejestracji nie są liczone.
- Strony logowania lub rejestracji, które powstają dopiero w przeglądarce. Zwykle to w porządku, bo takie strony działają dla odwiedzających bez renderowania po stronie serwera. Jeśli jedna z nich ma się pozycjonować, renderuj ją na serwerze.
Po poprawce kliknij Sprawdź ponownie: raporty są przechowywane w pamięci podręcznej do 24 godzin, a ten przycisk wymusza świeże sprawdzenie (kilka razy na godzinę). Przycisk Przekaż AI zamienia raport w zlecenie pracy w Markdownie dla agenta programistycznego, takiego jak Claude Code, Cursor albo GitHub Copilot, z jednym sprawdzalnym warunkiem docelowym dla każdego wyniku.
Czego SEOgrinder nie robi: nie mierzy, czy ChatGPT, Gemini albo Perplexity faktycznie wymieniają twoją markę. Sprawdza techniczną podstawę, czyli to, czy treść w ogóle da się przeczytać.
Najczęstsze błędy
- Test przez „Zbadaj” zamiast przez źródło strony. Inspektor pokazuje wynik po wykonaniu skryptów, a tego właśnie bot bez JavaScriptu nie dostaje.
- Wniosek „Google to indeksuje, więc każdy bot to przeczyta”. Google wykonuje JavaScript, a jego własna dokumentacja mówi, że nie wszystkie boty to robią.
- Ustawianie tytułu i znaczników meta wyłącznie skryptem. Google na to pozwala, ale bot, który nie wykonuje skryptów, nigdy ich nie zobaczy. Umieść je w pierwszym HTML.
- Linki będące tylko obsługą kliknięcia. Używaj prawdziwych linków
<a href>, żeby crawler mógł za nimi podążać bez skryptów. - Traktowanie dynamic renderingu jako stałego rozwiązania. Google nazywa go obejściem.
- Odpowiadanie na każdy nieznany adres powłoką i statusem 200. Aplikacje renderowane po stronie klienta często tak robią, a takie strony mogą zostać uznane za soft 404. Rozwiązaniem jest prawdziwy status 404 dla nieistniejących adresów.
- Zezwalanie botom w robots.txt i odrzucanie ich na zaporze sieciowej. Tekst jest, ale bot dostaje błąd. SEOgrinder ma na ten przypadek osobny wynik: „Roboty AI dozwolone, ale odrzucane przez serwer — sprawdź”. Przeczytaj też nasz artykuł o robots.txt dla botów AI.
Najczęstsze pytania
Czy Google widzi moją stronę zbudowaną w JavaScripcie?
Zwykle tak, ale później. Google wykonuje JavaScript w evergreen Chromium, a strony ze statusem 200 czekają w kolejce na renderowanie. Indeksowanie nigdy nie jest gwarantowane. Narzędzie do sprawdzania adresu URL w Google Search Console pokazuje, co widzi Googlebot.
Czy wystarczy mapa witryny?
Nie. Mapa witryny mówi crawlerom, jakie adresy istnieją. Nie wstawia tekstu do HTML tych stron.
Czy ChatGPT i Claude wykonują JavaScript?
W pomiarze Vercel i MERJ z 2024 roku wymienione tam crawlery OpenAI i Anthropic tego nie robiły. Nowszego pomiaru nie mamy, więc przetestuj własne strony zamiast polegać na jednej czy drugiej odpowiedzi.
Czy muszę przebudować całą stronę?
Niekoniecznie. Zwykle pierwszym krokiem jest renderowanie po stronie serwera albo wstępne renderowanie stron, które mają się pozycjonować albo być cytowane. Części interaktywne mogą zostać w przeglądarce.
Twój następny krok
Wybierz jedną ważną stronę i zrób trzy testy. Jeśli tekstu brakuje w źródle, uruchom bezpłatne skanowanie w SEOgrinder i otwórz kartę Zadania. Napraw najważniejsze strony, renderując je na serwerze albo generując z wyprzedzeniem, a potem kliknij Sprawdź ponownie.