Sklep internetowy stracił 47% widoczności w wyszukiwaniu AI po wdrożeniu, które zmieniło sposób renderowania stron. Te same strony produktów nadal były w rankingu Google. Ale ChatGPT, Claude i Perplexity nie zwracały żadnych wyników. Różnicę zrobiło renderowanie JavaScript.
Dotyczy to każdej strony opartej na renderowaniu po stronie klienta. Landing page SaaS zbudowany we frameworku JavaScript nigdy nie pojawia się w odpowiedziach ChatGPT. Serwis informacyjny działający na frameworku JavaScript nie ma żadnej obecności w Perplexity. Baza wiedzy, która renderuje treści w bibliotece JavaScript, pozostaje niewidoczna dla robotów AI. To nie są przypadki skrajne. To domyślne zachowanie większości nowoczesnych frameworków webowych.
Różnica między stroną opartą na JavaScript a stroną widoczną dla AI nie zależy od złożoności ani budżetu. Chodzi o zrozumienie, co dzieje się w pierwszych milisekundach po przybyciu robota.
Co widzą roboty AI, gdy pobierają Twoją stronę
Robot Google wykonuje JavaScript. Czeka, aż strona się wyrenderuje, zapisuje końcowy stan wizualny i go indeksuje. Większość robotów AI tego nie robi.
Gdy robot ChatGPT (GPTBot) trafia na Twoją stronę, wygląda to tak: 1. Pobiera plik HTML 2. Wyciąga tekst widoczny w surowym kodzie HTML 3. Przechodzi do następnej strony
JavaScript, który renderuje Twój nagłówek, opis produktu i treść artykułu, nigdy się nie uruchamia. Robot widzi odwołania do plików JavaScript, ale je ignoruje. Twoja strona wygląda jak pusta powłoka bez treści.
Dzieje się tak, bo roboty AI są projektowane z myślą o szybkości i wydajności. Wykonywanie JavaScript jest wolne. Wymaga uruchomienia przeglądarki, czekania na załadowanie zasobów, obsługi błędów i pilnowania limitów czasu. Gdy przeszukujesz miliardy stron dziennie, wykonywanie JavaScript staje się zbyt kosztowne.
Google inwestuje w taką infrastrukturę, bo wyniki wyszukiwania zależą od rozumienia wyglądu strony. Wyszukiwarki AI stawiają na wyciąganie surowego tekstu. Są zoptymalizowane tak, by pobierać fakty i cytaty bezpośrednio z kodu HTML, a nie z tego, co pojawia się po przekształceniu go przez JavaScript.
Które sposoby renderowania sprawiają problemy robotom AI
Nie każdy framework JavaScript powoduje taką samą utratę widoczności. Problem dotyczy konkretnie renderowania po stronie klienta (CSR), gdzie JavaScript działa *w przeglądarce* i buduje stronę po załadowaniu kodu HTML.
Renderowanie po stronie klienta (CSR): popularne frameworki JavaScript ustawione na CSR. Kod HTML przychodzi pusty albo z zastępczymi szkieletami. JavaScript uzupełnia treść po pobraniu. Roboty AI nie czekają.
Renderowanie po stronie serwera (SSR): frameworki zaprojektowane do renderowania na serwerze. Serwer buduje stronę z treścią już wstawioną w kod HTML. Przeglądarka dostaje kompletny HTML. Roboty AI widzą wszystko od razu.
Generowanie statyczne (SSG): generatory stron statycznych. Strony są budowane z wyprzedzeniem i wdrażane jako statyczne pliki HTML. W chwili żądania nic się nie renderuje. Roboty AI od razu dostają pełną treść.
Aplikacje jednostronicowe (SPA): kategoria o najwyższym ryzyku. SPA ładuje jeden plik HTML i używa JavaScript do podmiany treści zależnie od nawigacji. Każda podstrona wygląda dla robota tak samo, chyba że serwer obsługuje każdą ścieżkę osobno.
W chwili, gdy wybierzesz CSR jako strategię renderowania, tworzysz niewidoczną barierę między swoimi treściami a każdym robotem AI w internecie.
Dlaczego to ma większe znaczenie, niż myślisz
Wyszukiwanie AI jest jeszcze na wczesnym etapie, ale jego użycie przyspiesza. Badania pokazują, że zapytania do wyszukiwarek AI rosną szybciej niż tradycyjne wyszukiwania w sieci. ChatGPT, Perplexity i Claude stają się głównymi narzędziami researchu dla profesjonalistów, studentów i osób podejmujących decyzje.
Gdy ktoś pyta ChatGPT o "najlepsze kreatory stron dla małej firmy", AI wybiera, które marki zacytować. Ta decyzja zależy od tego, które treści potrafi przeczytać. Jeśli Twoja strona opiera się na JavaScript, jest niewidoczna.
To nie jest problem przyszłości. Analiza ponad 500 mln żądań GPTBot z 2025 roku wykazała, że strony zależne od JavaScript otrzymywały znacznie mniej cytowań niż strony konkurencji renderowane po stronie serwera w tej samej branży. Różnica rosła przy treściach technicznych, stronach produktów i poradnikach, czyli dokładnie tych typach treści, które wyszukiwarki AI przedkładają nad inne.
Dla firm B2B i e-commerce cytowania w AI stają się dźwignią widoczności wobec konkurencji. Cytat w odpowiedzi ChatGPT albo we fragmencie Perplexity może dać taką samą wartość ruchu jak pozycja na pierwszej stronie Google. Z tą różnicą, że Twoja marka nie zostanie zacytowana, jeśli robot nie potrafi przeczytać Twoich treści.
Jak zdecydować, co z tym zrobić
Nie każda strona musi odchodzić od renderowania po stronie klienta. Decyzja zależy od trzech czynników: rodzaju treści, odbiorców i wartości biznesowej widoczności w wyszukiwaniu AI w Twojej sytuacji.
Najpierw zadaj sobie te pytania:
Czy Twoje treści zasługują na cytowanie przez AI? Wiadomości, poradniki, porównania produktów, artykuły badawcze, porady ekspertów. Takie treści AI cytuje. Dokumentacja techniczna, narzędzia interaktywne i panele przeznaczone głównie dla zalogowanych osób nie są cytowane. Jeśli Twoja strona to głównie to drugie, renderowanie JavaScript ma mniejsze znaczenie.
Czy Twoi odbiorcy szukają w wyszukiwarkach AI? Profesjonaliści B2B, osoby porównujące produkty, studenci, programiści. Intensywnie korzystają z wyszukiwania AI. Jeśli Twoi odbiorcy to bardzo wąska nisza, która szuka wyłącznie w Google, widoczność w AI da mniejszy zwrot w najbliższym czasie.
Ile kosztuje bycie niewidocznym? Dla serwisu informacyjnego lub bazy wiedzy zero cytowań w AI to konkurencyjne obciążenie. Dla intranetu firmy albo SaaS tylko dla członków to bez znaczenia. W przypadku sklepu internetowego zależy od tego, czy klienci odkrywają produkty przez rekomendacje zakupowe AI.
Jeśli odpowiedzi to "treści warte cytowania przez AI", "tak, moi odbiorcy używają wyszukiwania AI" i "utrata widoczności to realny koszt", działaj dalej. Jeśli odpowiedzi są mieszane, możesz ustawić priorytety inaczej.
Renderowanie po stronie serwera: najpełniejsze rozwiązanie
SSR rozwiązuje problem JavaScript kompleksowo. Serwer buduje kompletną stronę z całą treścią, zanim wyśle ją do przeglądarki. Gdy pojawia się dowolny robot, treść już tam jest.
Jak to działa: gdy ktoś (albo bot) żąda strony, Twój serwer uruchamia kod i tworzy końcowy HTML. Ten HTML zawiera nagłówek, tekst artykułu i szczegóły produktu. Przeglądarka dostaje kompletną stronę i od razu ją wyświetla. JavaScript nadal może wzbogacać interaktywność, ale treść jest już dostępna.
Platformy, które upraszczają SSR: frameworki zaprojektowane specjalnie po to, by renderowanie po stronie serwera było proste. Komponenty piszesz raz, framework obsługuje renderowanie na serwerze, a strona przychodzi już zbudowana.
Kompromis: SSR wymaga zasobów serwera. Serwer przetwarza każde żądanie, buduje HTML i go wysyła. To zużywa więcej procesora i pamięci niż serwowanie gotowych plików statycznych. Wolne lub złożone strony mogą wydłużyć czas odpowiedzi, co wpływa na wskaźniki wydajności, takie jak First Contentful Paint (FCP) i Core Web Vitals.
Dla większości stron spadek wydajności jest niewielki. Dla stron o dużym ruchu i złożonych podstronach staje się zauważalny. Da się to rozwiązać cache'owaniem, przetwarzaniem na krawędzi sieci lub optymalizacją kodu, ale wymaga to decyzji architektonicznych.
Pre-renderowanie: lżejsze podejście do treści statycznych
Pre-renderowanie buduje strony z wyprzedzeniem i wdraża je jako statyczne pliki HTML. Gdy pojawia się robot, od razu dostaje kompletną stronę. Gdy ktoś wchodzi na stronę, dostaje statyczny plik, który ładuje się bardzo szybko.
Usługi pre-renderowania automatyzują ten proces. Wskazujesz im swoją stronę, odwiedzają każdy adres z mapy witryny, renderują każdą stronę (wykonując JavaScript), zapisują końcowy HTML i serwują te statyczne wersje robotom, podczas gdy przeglądarki nadal dostają wersję interaktywną.
To działa, jeśli: treść zmienia się rzadko. Wpisy blogowe, strony produktów, dokumentacja. Treści aktualizowane najwyżej raz dziennie.
To nie działa, jeśli: treść jest dynamiczna. Stany magazynowe, dane zależne od użytkownika, informacje w czasie rzeczywistym, treści spersonalizowane. Jeśli strona wygląda inaczej dla każdej osoby odwiedzającej, pre-renderowanie nie uchwyci wszystkich wersji.
Koszt i złożoność: takie usługi kosztują 99-499 USD miesięcznie, zależnie od liczby stron. Utrzymujesz dwa zestawy treści: jeden dla przeglądarki (JavaScript), drugi wyrenderowany z wyprzedzeniem dla robotów. To podwaja nakład na utrzymanie. Gdy publikujesz nowy artykuł, musisz przebudować i ponownie wdrożyć wersję statyczną.
Dla stron o stabilnej treści pre-renderowanie to pragmatyczny kompromis między nicnierobieniem a migracją do SSR.
Renderowanie dynamiczne: taktyczna opcja dla niektórych stron
Renderowanie dynamiczne wykrywa, jaki agent użytkownika wysyła żądanie. Jeśli to robot, serwuje HTML wyrenderowany na serwerze. Jeśli przeglądarka, serwuje wersję JavaScript. Dzięki temu zachowujesz obecny stos technologiczny, a roboty dostają kompletną treść.
W teorii pomysł jest elegancki. W praktyce jest kruchy. Musisz:
Prowadzić listę agentów użytkownika (User-Agent) robotów AI i stale ją aktualizować, gdy pojawiają się nowe roboty. Pominiesz jednego, a ten robot zobaczy pustą stronę.
Zbudować renderowanie po stronie serwera specjalnie dla robotów, zachowując renderowanie po stronie klienta dla przeglądarek. To w praktyce budowanie dwóch wersji strony.
Sprawdzać, czy obie wersje pozostają zsynchronizowane. Błąd w wersji dla robotów po cichu psuje widoczność w wyszukiwaniu AI.
Renderowanie dynamiczne sprawdza się na prostych stronach z treścią. W złożonych aplikacjach to więcej kłopotu niż pożytku. Jeśli i tak renderujesz na serwerze dla robotów, możesz renderować dla wszystkich (to właśnie SSR).
Jak sprawdzić, czy Twoja strona ma ten problem teraz
Nie musisz zgadywać. Możesz to sprawdzić bezpośrednio.
Zobacz źródło strony: kliknij stronę prawym przyciskiem myszy, wybierz "Pokaż źródło strony" i wyszukaj swój nagłówek. Jeśli nagłówka nie ma w surowym HTML, jest renderowany przez JavaScript. Roboty AI go nie zobaczą.
Pobierz przez curl: w terminalu uruchom curl https://yoursite.com/your-page. Jeśli treści tam nie ma, wyrenderował ją JavaScript.
Sprawdź plik robots.txt: jeśli blokujesz robotom wykonywanie JavaScript, zobaczą tylko surowy HTML. Sprawdź plik robots.txt albo ustawienia przeszukiwania strony.
Użyj narzędzia typu crawler: crawler SEO może pobrać Twoje strony tak, jak zrobiłby to robot. Jeśli treść widać w przeglądarce, ale nie w crawlerze, winny jest JavaScript.
Szukaj bezpośrednio w wyszukiwarkach AI: wpisz w ChatGPT, Perplexity lub Claude konkretne frazy ze swoich stron. Jeśli Twoje treści nigdy się nie pojawiają, masz problem z widocznością przez JavaScript.
Optymalizacja pod konkretne roboty AI
Nie wszystkie roboty AI zachowują się tak samo. Mają różne możliwości renderowania, różną częstotliwość przeszukiwania i różne preferencje treści.
ChatGPT (GPTBot): nie wykonuje JavaScript. Pobiera surowy HTML. Korzysta z indeksu zewnętrznej wyszukiwarki do treści w czasie rzeczywistym. Częstotliwość: mniej więcej raz w tygodniu dla ugruntowanych treści.
Claude (zewnętrzna wyszukiwarka): nie wykonuje JavaScript. Pobiera surowy HTML. Preferuje świeże, autorytatywne treści. Częstotliwość: różna, zależnie od sygnałów świeżości treści.
Perplexity: nie wykonuje JavaScript. Pobiera surowy HTML. Mocno waży świeżość. Treści starsze niż 48 godzin mogą dostać niższy priorytet. Częstotliwość: wysoka dla tematów na topie, niska dla treści statycznych.
AI Overviews Google: *wykonuje* JavaScript, bo korzysta z tej samej infrastruktury renderowania co Wyszukiwarka Google. Mimo to optymalizuj tak, jakby tego nie robiły, a Twoja strona będzie bardziej widoczna w innych wyszukiwarkach AI.
Praktyczny wniosek: nie optymalizuj pod jednego robota. Renderuj kluczowe treści na serwerze, a będą widoczne dla wszystkich.
W czym pomaga WEMASY
Kreator stron WEMASY domyślnie tworzy HTML renderowany na serwerze. Każda strona, którą stworzysz, jest zbudowana z treścią w kodzie HTML, zanim trafi do przeglądarki. Bez renderowania JavaScript. Twoje strony są od razu widoczne dla robotów AI.
Jeśli porównujesz kreatory stron, a widoczność w wyszukiwaniu AI ma znaczenie dla Twojej firmy, renderowanie po stronie serwera powinno być wymogiem, a nie dodatkiem. Zobacz, co zawiera każdy pakiet WEMASY.
Najczęściej zadawane pytania
Czy mogę używać JavaScript do funkcji interaktywnych bez blokowania robotów AI?
Tak. Renderuj główną treść na serwerze (nagłówek, tekst artykułu, szczegóły produktu), a JavaScript wykorzystuj do ulepszeń (animacje, walidacja formularzy, interaktywne widżety). Nazywa się to "progressive enhancement". Treść jest już w kodzie HTML, a JavaScript dodaje dopracowanie. Roboty AI widzą główną treść. Przeglądarki dostają pełne, interaktywne doświadczenie. W kreatorze stron WEMASY możesz to ustawić bezpośrednio na swojej stronie.
Czy migracja na renderowanie po stronie serwera spowolni moją stronę?
Może, jeśli serwer jest za słaby albo strony są złożone. Nowoczesne renderowanie po stronie serwera z warstwami cache (jak cache na krawędzi sieci w nowoczesnych platformach hostingowych) może być wręcz szybsze niż renderowanie po stronie klienta. Dla większości stron różnica jest niewielka. Jeśli wydajność budzi obawy, przetestuj to w środowisku testowym, zanim się zobowiążesz.
Czy muszę zmieniać cały stos technologiczny?
Jeśli używasz frameworka JavaScript w trybie CSR, przejście na framework SSR oznacza przepisanie komponentów tak, by działały z renderowaniem na serwerze. To nie jest szybka podmiana. Jeśli strona jest zupełnie nowa, od początku wybierz framework nastawiony na SSR. Jeśli masz ugruntowaną stronę, w krótkim terminie bardziej praktyczne może być pre-renderowanie lub renderowanie dynamiczne.
Co jeśli roboty AI w końcu zaczną obsługiwać JavaScript?
Możliwe, ale nieprędko. Wykonywanie JavaScript jest w dużej skali obliczeniowo kosztowne. Dopóki wartość biznesowa cytowań w AI nie uzasadni kosztu infrastruktury, roboty będą dalej pobierać surowy HTML. Na razie renderuj treści na serwerze i ogranicz ryzyko.
Czy problem z renderowaniem JavaScript szkodzi pozycjom mojej strony w Google?
Nie. Robot Google wykonuje JavaScript, więc Twoje pozycje w Google nie są zagrożone. Problem dotyczy wyszukiwarek AI, takich jak ChatGPT, Claude i Perplexity. Nie wykonują one JavaScript. Renderuj treści na serwerze, jeśli zależy Ci na widoczności w wynikach wyszukiwania AI, a nie dlatego, że wymaga tego Google. To osobny problem względem SEO.
Czy serwisy informacyjne mają ten sam problem z JavaScript?
Tak, i często jest pomijany. Serwis informacyjny zbudowany na frameworku JavaScript, który renderuje treść po stronie klienta, nie dostaje żadnych cytowań w AI, nawet jeśli treść jest opublikowana i zaindeksowana. Wydawcy newsów odkryli to przypadkiem, gdy artykuły widoczne w Google News nie miały żadnych wzmianek w ChatGPT ani Perplexity. Sprawdź źródło strony. Jeśli nie ma w nim nagłówka, napraw to.