Treść niewidoczna bez JavaScriptu: strony w React, Angular i Vue (SPA)

Aktualizacja: 18.10.2026

Jeśli audyt pokazał, że „w kodzie strony prawie nie ma treści”, to serwer wysyła przeglądarce pustą skorupę, a teksty, menu i linki dokleja dopiero JavaScript. Człowiek tego nie zauważa, bo przeglądarka wszystko wykonuje. Google zwykle sobie poradzi, ale później i nie zawsze w całości, a boty AI (ChatGPT, Claude, Perplexity) w większości widzą pustą stronę i nie mają czego zacytować.

Na czym polega problem: renderowanie u klienta i na serwerze

Strona może powstać w dwóch miejscach:

Renderowanie po stronie serwera (SSR) – serwer wysyła gotowy HTML z treścią. Każdy, kto pobierze adres – przeglądarka, Googlebot, bot AI, narzędzie SEO – od razu widzi nagłówki, tekst i linki. Tak działa większość stron na WordPressie, sklepy na Shopify, PrestaShop czy Shoperze.
Renderowanie po stronie klienta (CSR) – serwer wysyła prawie pusty plik z jednym kontenerem (np. <div id="root"></div> albo <app-root>) i paczkę skryptów. Treść powstaje dopiero w przeglądarce. Tak domyślnie działają aplikacje jednostronicowe (SPA) zbudowane w czystym React (np. Create React App, Vite), Angularze bez SSR czy Vue bez Nuxta.

Nasz audyt pobiera surowy HTML, tak jak robi to większość botów. Jeśli znajdzie w nim kontener aplikacji i bardzo mało tekstu oraz linków, zgłasza „Treść ładowana przez JavaScript”. Wtedy część testów treści oznaczamy jako „nie do oceny”, a „Ilość treści” może pokazywać kilka słów, choć w przeglądarce widzisz pełną stronę. Ten drugi test liczy słowa razem z menu i stopką i ostrzega poniżej 200 słów. Sama liczba słów nie jest czynnikiem rankingowym, ale strona z kilkoma zdaniami ma po prostu mało materiału, z którego Google i AI mogą zrozumieć ofertę.

Jak to wygląda u Google

Według dokumentacji Google („Podstawy SEO w JavaScripcie”) Googlebot przetwarza takie strony w trzech fazach: pobranie (crawling), renderowanie i indeksowanie. Najpierw pobiera HTML i wyciąga z niego linki. Strony z kodem 200 trafiają do kolejki renderowania, gdzie Chromium bez interfejsu wykonuje JavaScript, a Google indeksuje dopiero wyrenderowany HTML.

Google pisze wprost, że strona może czekać w kolejce kilka sekund, „ale może to potrwać dłużej” – zależy to od zasobów Google. W praktyce oznacza to:

nowe i zmienione treści mogą trafiać do indeksu wolniej niż na stronie z gotowym HTML-em,
jeśli skrypt rzuci błędem, wczytuje dane z API, które odpowiada za wolno, albo wymaga interakcji (kliknięcia, przewinięcia), część treści może się w ogóle nie zaindeksować,
linki generowane tylko przez JavaScript Google odkrywa dopiero po renderowaniu,
pliki JS zablokowane w robots.txt uniemożliwiają poprawne renderowanie,
tag noindex w pierwotnym HTML-u może sprawić, że Google w ogóle pominie renderowanie – usunięcie go skryptem nie zadziała (więcej w artykule o noindex).

Sam Google zaznacza, że renderowanie po stronie serwera lub prerendering to nadal dobry pomysł, bo przyspiesza stronę i nie wszystkie boty potrafią uruchomić JavaScript.

Boty AI w większości nie wykonują JavaScriptu

Najczęściej cytowane dane pochodzą z analizy Vercel i MERJ z grudnia 2024 r. (ruch na sieci Vercel i nextjs.org). Wynik: żaden z głównych crawlerów AI nie renderował JavaScriptu – dotyczyło to botów OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User), Anthropic (ClaudeBot), Perplexity (PerplexityBot), Meta i ByteDance. Pobierały pliki JS, ale ich nie wykonywały. Wyjątkami były Gemini, który korzysta z infrastruktury Googlebota, i Applebot.

Dwa zastrzeżenia, żeby nie przesadzić. Po pierwsze, to stan z konkretnego badania, a firmy AI mogą zmieniać swoje boty. Po drugie, asystenci AI czasem opierają się też na indeksach wyszukiwarek (wyszukiwanie w ChatGPT i Copilocie korzysta z indeksu Binga), więc strona nie jest dla nich zawsze całkowicie niewidoczna. Mimo to, jeśli bot AI pobiera Twoją stronę bezpośrednio, a treść powstaje tylko w JavaScripcie, dostaje pusty kontener. Dlatego w części GEO naszego audytu traktujemy to jako bloker.

Jak sprawdzić samemu

„Wyświetl źródło” kontra „Zbadaj”. W Chrome kliknij prawym przyciskiem na stronie i wybierz Wyświetl źródło strony (Ctrl+U, na Macu Cmd+Opt+U). To jest surowy HTML, który dostaje bot. Wyszukaj (Ctrl+F) zdanie, które widzisz na stronie, np. z pierwszego akapitu. Potem kliknij prawym przyciskiem i wybierz Zbadaj – tam widać kod już po wykonaniu JavaScriptu. Jeśli tekst jest w „Zbadaj”, a nie ma go w „Wyświetl źródło”, treść ładuje JavaScript.
Wyłącz JavaScript. W Chrome otwórz DevTools (F12), naciśnij Ctrl+Shift+P (Cmd+Shift+P na Macu), wpisz „Disable JavaScript” i przeładuj stronę. Biała strona albo samo logo oznacza, że bez JS nie ma treści. Po teście tak samo włącz JavaScript z powrotem (lub zamknij DevTools).
Google Search Console → Sprawdzenie adresu URL. Wklej adres, kliknij Testuj URL na żywo, potem Wyświetl sprawdzoną stronę. W zakładce HTML widzisz kod po renderowaniu przez Google, w zakładce Zrzut ekranu – jak strona wyglądała dla Googlebota (zrzut jest dostępny tylko w teście na żywo). W Więcej informacji sprawdź zasoby, których nie udało się wczytać, i komunikaty konsoli JavaScript. Bez dostępu do GSC podobny podgląd da Test wyników z elementami rozszerzonymi.
Nasz audyt. Po poprawkach uruchom go ponownie – test „Treść ładowana przez JavaScript” powinien zniknąć, a „Ilość treści” pokazać realną liczbę słów.

Jak naprawić

Cel jest jeden: serwer ma od razu wysyłać HTML z treścią, linkami, tytułem i opisem. JavaScript może potem dodać interaktywność (to tzw. hydracja). Google rekomenduje tu renderowanie po stronie serwera, generowanie statyczne albo hydrację.

React

Czysty React (Create React App, Vite) renderuje wszystko w przeglądarce. Najczęstsza droga to przeniesienie aplikacji do frameworka z SSR, zwykle Next.js. W Next.js z App Routerem komponenty domyślnie renderują się na serwerze, a strony bez danych zmiennych w czasie można generować statycznie przy budowaniu (SSG). Jeśli migracja jest za duża, alternatywą jest prerendering: przy budowaniu lub przez zewnętrzną usługę generuje się gotowe pliki HTML dla każdego adresu.

Vue

Odpowiednikiem Next.js jest Nuxt, który domyślnie używa renderowania uniwersalnego (najpierw serwer, potem przeglądarka). Sprawdź w nuxt.config.ts, czy ktoś nie ustawił ssr: false – to wyłącza renderowanie na serwerze. Do hostingu statycznego Nuxt generuje gotowe pliki HTML poleceniem nuxt generate. Wyłączenie SSR tylko dla wybranych ścieżek (np. panelu klienta) jest w porządku, o ile strony publiczne mają SSR.

Angular

Dawniej służył do tego Angular Universal. Od wersji 17 jego funkcje przeniesiono do pakietu @angular/ssr. Do istniejącego projektu dodajesz SSR poleceniem:

ng add @angular/ssr

a nowy projekt zakładasz z ng new --ssr. Angular pozwala też ustawić tryb renderowania per ścieżka, np. prerendering (statyczny HTML przy budowaniu) dla stron ofertowych i bloga.

Usługi prerenderingu

Usługi typu Prerender.io pobierają stronę w przeglądarce bez interfejsu, zapisują gotowy HTML i serwują go botom, a ludziom dalej aplikację JS. To szybkie wyjście, gdy nie da się przebudować aplikacji. Uwaga: Google nazywa takie podawanie innej wersji botom (dynamic rendering) „obejściem, a nie zalecanym rozwiązaniem”, bo dokłada złożoności i zasobów. Traktuj to jako rozwiązanie przejściowe, a docelowo planuj SSR lub generowanie statyczne. Pilnuj też, żeby wersja dla botów miała tę samą treść co dla ludzi.

WordPress i WooCommerce

WordPress, także z builderem (Elementor, Divi, WPBakery), renderuje treść po stronie serwera, więc zwykle tego problemu nie ma. Jeśli audyt go zgłasza, przyczyną bywa:

sekcje, zakładki lub listy produktów ładowane AJAX-em lub przez REST API po wczytaniu strony (np. wtyczki „load more”, filtry produktów, niektóre widżety opinii i cenników),
wtyczki lub motywy, które ukrywają treść do czasu wykonania skryptu (np. ekran ładowania zakrywający całą stronę),
headless WordPress lub headless WooCommerce, gdzie WordPress jest tylko zapleczem, a front to osobna aplikacja React lub Vue – wtedy obowiązują zasady z sekcji React/Vue, czyli Next.js albo Nuxt z SSR.

Sprawdź w „Wyświetl źródło”, których fragmentów brakuje, i w ustawieniach danej wtyczki poszukaj opcji renderowania treści od razu zamiast ładowania asynchronicznego. Jeśli takiej nie ma, rozważ inną wtyczkę dla kluczowych treści (opis oferty, produkty, linki do kategorii).

Shopify, PrestaShop, Shoper

Te platformy generują strony po stronie serwera: Shopify z szablonów Liquid, PrestaShop z szablonów Smarty, Shoper ze swoich szablonów. Sama platforma nie jest więc problemem. Problem robią:

aplikacje i moduły ładujące treść skryptem: recenzje, FAQ, zakładki opisu, „podobne produkty”, filtry kategorii,
motywy, które dociągają opisy lub listy produktów asynchronicznie,
sklepy headless (np. Shopify Hydrogen lub własny front w React) – tu trzeba zadbać o SSR w samej aplikacji frontowej.

Zrób test „Wyświetl źródło” na karcie produktu i kategorii. Jeśli brakuje opisu lub nazw produktów, wyłączaj po kolei podejrzane aplikacje na kopii motywu (w Shopify: duplikat motywu w Sklep online → Motywy)albo zapytaj autora aplikacji, czy ma tryb renderowania po stronie serwera.

Jak sprawdzić, że naprawione

W „Wyświetl źródło” widać tekst, nagłówki i linki, które widzisz na stronie.
Po wyłączeniu JavaScriptu strona pokazuje treść (może być mniej interaktywna, to normalne).
W Search Console test na żywo pokazuje pełny zrzut ekranu i kompletny HTML. Potem kliknij Poproś o zindeksowanie dla najważniejszych adresów i upewnij się, że mapa witryny jest aktualna.
Nasz audyt nie zgłasza już „Treść ładowana przez JavaScript” ani blokera dla botów AI.

Ile to potrwa: Google musi ponownie pobrać i przetworzyć strony. Pojedyncze adresy zgłoszone ręcznie bywają odświeżone w ciągu kilku dni, cała witryna – zwykle w ciągu kilku tygodni, w zależności od jej wielkości i tego, jak często Googlebot ją odwiedza. Dla botów AI nie ma żadnego terminu: zobaczą treść przy kolejnej wizycie, ale nie wiadomo, kiedy ona nastąpi ani czy zacytują stronę. Przejście na SSR usuwa przeszkodę techniczną, ale samo w sobie nie gwarantuje pozycji ani cytowań.

Kiedy warto poprosić o pomoc

Gdy strona jest aplikacją w React, Angularze lub Vue, przejście na SSR to zwykle praca programistyczna: zmiana sposobu budowania, serwera i wdrożenia, a przy okazji ryzyko zmiany adresów, tytułów i przekierowań. Jeśli nie masz pod ręką zespołu, który zna ten framework, albo planujesz migrację, warto zaplanować ją razem z kimś, kto pilnuje też SEO. IF.PL zajmuje się zarówno SEO, jak i budową stron, więc możemy ocenić, czy wystarczy prerendering, czy lepiej przebudować front.