JavaScript a SEO – jak Google renderuje treści i co z tego wynika

Google potrafi wykonywać JavaScript i indeksować generowane przez niego treści. Renderowanie to jednak dodatkowy etap przetwarzania strony, z własną kolejką i ograniczeniami. Jeśli treść, linki lub metadane powstają dopiero po wykonaniu skryptów, mogą do Google nie dotrzeć. Poniżej wyjaśniamy, jak działa ten proces i jak sprawdzić, co widzi wyszukiwarka.

Czym jest JavaScript SEO?

JavaScript SEO to optymalizacja stron korzystających z JavaScriptu tak, aby wyszukiwarki miały dostęp do ich treści, linków i metadanych. Sam JavaScript nie jest problemem. Kłopoty pojawiają się wtedy, gdy ważne elementy strony powstają dopiero po wykonaniu skryptów, które robot przetworzy z opóźnieniem albo wcale. Dlatego techniczne SEO serwisów opartych na JavaScripcie obejmuje zarówno kod HTML wysyłany przez serwer, jak i wersję strony po wyrenderowaniu.

Jak Googlebot przetwarza strony z JavaScriptem?

Według dokumentacji Google dotyczącej JavaScript SEO strony z JavaScriptem przechodzą trzy fazy: crawlowanie, renderowanie i indeksowanie.

Pobranie HTML → kolejka renderowania → wykonanie JavaScriptu → analiza wyrenderowanego HTML → indeksowanie

1. Crawlowanie – pobieranie strony

Googlebot pobiera adres URL, sprawdza, czy robots.txt nie blokuje do niego dostępu, i analizuje odpowiedź serwera, w tym kod HTML i zawarte w nim linki. Na tradycyjnej stronie większość treści jest już w tym dokumencie. W aplikacji renderowanej po stronie przeglądarki początkowy HTML często zawiera tylko szkielet, który dopiero JavaScript wypełnia treścią.

2. Renderowanie – wykonywanie JavaScriptu

Do kolejki renderowania trafiają strony ze statusem HTTP 200. Strony z innym kodem, np. 404, mogą zostać pominięte. Strona może czekać w kolejce kilka sekund, ale może to trwać dłużej. Google renderuje strony aktualną (evergreen) wersją Chromium: wykonuje JavaScript i analizuje powstały dokument HTML.

3. Indeksowanie – przetwarzanie zawartości

Wyrenderowany HTML Google wykorzystuje do indeksowania treści i odkrywania kolejnych linków. Część informacji robot może więc poznać już przy pobraniu strony, a część dopiero po renderowaniu. Jeśli renderowanie się nie powiedzie, indeksowanie strony w Google nie obejmie treści, które powstają w przeglądarce.

CSR, SSR, SSG i dynamic rendering – które podejście wybrać?

Model renderowania określa, gdzie i kiedy powstaje HTML z treścią strony:

Google pisze, że renderowanie po stronie serwera lub pre-rendering nadal jest dobrym pomysłem, bo przyspiesza stronę dla użytkowników i robotów. W dokumentacji o dynamic renderingu zaleca zamiast niego renderowanie po stronie serwera, renderowanie statyczne lub hydratację. Hydratacja to uzupełnienie gotowego HTML o interaktywne funkcje JavaScriptu: treść jest dostępna od razu, a skrypty obsługują interfejs.

Nie ma jednego modelu dobrego dla każdego serwisu. Wybór zależy od rodzaju witryny i od tego, które treści mają znaczenie dla widoczności organicznej.

SPA i frameworki JavaScript – czy React szkodzi SEO?

Problemem nie jest sam React, Vue czy Angular, tylko sposób, w jaki aplikacja udostępnia treść i obsługuje adresy URL. W SPA (Single Page Application) przejścia między widokami odbywają się bez przeładowania dokumentu. Jeśli widoki nie mają własnych adresów albo nawigacja nie opiera się na zwykłych linkach, część podstron może zostać przez Google pominięta.

Google zaleca obsługę nawigacji przez History API zamiast routingu na fragmentach adresów, np. #/produkty. Przy wyborze CMS lub frameworka warto od początku sprawdzić, czy pozwala on wysyłać podstawową treść w HTML z serwera.

Najczęstsze problemy SEO na stronach z JavaScriptem

Strona, która poprawnie wyświetla się w przeglądarce, nie musi wyglądać tak samo dla Googlebota. Te problemy warto sprawdzić w pierwszej kolejności.

Linki bez prawidłowego <a href>

Google podąża tylko za linkami w elementach <a> z atrybutem href. Elementy div czy span z obsługą kliknięcia w JavaScripcie nie są dla niego linkami. Linki można wstawiać do strony skryptem, o ile mają właściwą strukturę, czyli <a href=”/adres/”>.

Routing oparty na znaku

Adresy z fragmentem, np. example.com/#/oferta, utrudniają Google odkrycie poszczególnych widoków aplikacji. Google zaleca History API, które pozwala obsługiwać nawigację w SPA na zwykłych adresach URL. Dawny schemat indeksowania AJAX z adresami #! jest wycofany.

Zablokowane pliki JavaScript w robots.txt

Google nie wyrenderuje JavaScriptu z plików ani na stronach zablokowanych w robots.txt. Jeśli plik blokuje skrypty potrzebne do wygenerowania treści, użytkownik zobaczy kompletną stronę, a robot dokument bez istotnych informacji. Przy diagnostyce sprawdzaj więc nie tylko sam adres, ale też zasoby JS, których wymaga.

Noindex i canonical ustawiane skryptem

JavaScript może ustawiać i zmieniać title oraz meta description. Inaczej jest z dyrektywą noindex: gdy Google trafi na nią w początkowym HTML, może pominąć renderowanie, więc usunięcie jej skryptem może nie zadziałać.

Tag canonical najlepiej umieścić w HTML i nie zmieniać go skryptem. Jeśli dodaje go JavaScript, musi to być jedyny rel=”canonical” na stronie.

Soft 404 w aplikacjach SPA

Przy routingu po stronie klienta serwer często zwraca kod 200 także dla nieistniejących podstron. Użytkownik widzi komunikat o błędzie, a Google dostaje sygnał, że strona istnieje, co prowadzi do błędów soft 404. Google wskazuje dwa rozwiązania: przekierowanie na adres, który zwraca 404 z serwera, albo dodanie noindex na stronie błędu.

Treść zależna od cookies, storage lub uprawnień

Według poradnika Google o rozwiązywaniu problemów z JavaScriptem renderer czyści Local Storage, Session Storage i ciasteczka HTTP między wczytaniami stron. Nie obsługuje też m.in. WebSockets, WebRTC i WebGL, a Googlebot nie udziela zgód na uprawnienia, np. dostęp do kamery. Treść nie może od nich zależeć. Rozwiązaniem jest wykrywanie dostępności funkcji i zastępcze implementacje (polyfille).

Przekierowania wykonywane przez JavaScript

Przekierowanie JavaScriptem wymaga wyrenderowania strony, dlatego Google traktuje je jako ostateczność: tylko wtedy, gdy nie da się wdrożyć przekierowania serwerowego ani meta refresh. Przy trwałej zmianie adresu stosuj przekierowania 301 po stronie serwera.

Nieaktualne pliki JavaScript w pamięci podręcznej

Googlebot intensywnie korzysta z pamięci podręcznej, więc przy renderowaniu może użyć starszej wersji pliku JS lub CSS. Google zaleca nazwy plików zawierające odcisk zawartości, np. main.2bb85551.js. Po zmianie pliku zmienia się jego nazwa, a robot pobiera nową wersję.

JavaScript a boty AI – czy ChatGPT zobaczy treść z JavaScriptu?

Według badania Vercel i MERJ z grudnia 2024 roku roboty GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot i PerplexityBot pobierały pliki JavaScript, ale ich nie wykonywały. AppleBot renderował JavaScript, a Gemini korzystał z infrastruktury Googlebota, która JavaScript renderuje.

To wynik pomiaru z końca 2024 roku, a nie deklaracja dostawców, więc zachowanie tych robotów mogło się zmienić. Wniosek techniczny pozostaje jednak aktualny: treść obecna w początkowym HTML jest dostępna także dla robotów, które nie wykonują skryptów. Dotyczy to zwłaszcza treści artykułów, opisów produktów i usług oraz nawigacji. Jak zarządzać dostępem tych robotów, opisujemy w artykule o llms.txt i botach AI.

Jak sprawdzić, co Google widzi na stronie z JavaScriptem?

Najważniejsze jest porównanie początkowego HTML z dokumentem wyrenderowanym przez Google. Służy do tego narzędzie do sprawdzania adresów URL w Google Search Console, które w 2019 roku zastąpiło dawną funkcję „Pobierz jako Google”.

1. Sprawdź adres w Search Console. Wpisz adres podstrony w narzędziu do sprawdzania adresów URL i przejrzyj informacje o indeksowaniu.
2. Przetestuj opublikowaną wersję. Test na żywo pokazuje, jak Google przetwarza stronę teraz, a nie przy ostatnim pobraniu.
3. Przeanalizuj wyrenderowany HTML. Sprawdź, czy są w nim główna treść, nagłówki, linki i metadane. Przejrzyj też zrzut ekranu, listę wczytanych zasobów i komunikaty konsoli JavaScript.
4. Porównaj z kodem źródłowym. Ustal, które elementy są w HTML od razu, a które powstają dopiero po wykonaniu skryptów. Różnica sama w sobie nie jest błędem. Błędem jest brak w wyrenderowanej wersji treści potrzebnych do zrozumienia strony.
5. Sprawdź błędy i zasoby. Jeśli treść jest niekompletna, szukaj zablokowanych lub niewczytanych zasobów i błędów skryptów. Błędy JavaScriptu u użytkowników i robotów można rejestrować przez window.addEventListener(’error’, …).

Wyrenderowany HTML pokazuje też Test wyników z elementami rozszerzonymi. W rozbudowanych serwisach sprawdź kilka typów podstron, bo mogą być generowane w różny sposób. Jeśli strona jest niewidoczna w Google, diagnoza renderowania to jeden z pierwszych kroków.

Checklista JavaScript SEO – co sprawdzić podczas audytu?

1. Treść: czy główna zawartość jest w HTML wyrenderowanym przez Google?
2. Status HTTP: czy istniejące strony zwracają 200, a nieistniejące 404?
3. Renderowanie: czy po wykonaniu JavaScriptu Google dostaje kompletną stronę?
4. Linki: czy odnośniki to elementy <a> z atrybutem href?
5. Routing: czy widoki SPA mają zwykłe adresy URL obsługiwane przez History API?
6. robots.txt: czy nie blokuje plików JS potrzebnych do renderowania?
7. noindex: czy początkowy HTML nie zawiera niezamierzonej dyrektywy?
8. Canonical: czy na stronie jest tylko jedna deklaracja rel=”canonical”?
9. Soft 404: czy nieistniejące podstrony nie zwracają kodu 200?
10. Zależności przeglądarki: czy treść nie wymaga cookies, storage ani uprawnień?
11. Przekierowania: czy są serwerowe, a nie wykonywane JavaScriptem?
12. Pamięć podręczna: czy nazwy plików JS i CSS zmieniają się po aktualizacji?

Po zmianach w architekturze aplikacji kontrolę warto powtórzyć. Wydajność strony to osobny obszar, mierzony wskaźnikami Core Web Vitals.

Jak sprawdzić, czy JavaScript nie ogranicza widoczności strony?

Strona może działać poprawnie dla użytkownika, a jednocześnie nie przekazywać Google części treści, linków czy metadanych. Przy serwisach opartych na React, Vue, Angularze i innych technologiach JavaScript trzeba więc analizować zarówno początkowy HTML, jak i jego wyrenderowaną wersję.

Audyt SEO pozwala wskazać techniczne bariery w renderowaniu i indeksowaniu oraz ustalić z zespołem developerskim, co trzeba zmienić.

FAQ

Czym jest JavaScript SEO?

To optymalizacja stron korzystających z JavaScriptu tak, aby roboty wyszukiwarek miały dostęp do ich treści, linków i metadanych. Obejmuje m.in. sposób renderowania, obsługę adresów URL i kontrolę indeksowania.

Czy Google indeksuje treści generowane przez JavaScript?

Tak. Google renderuje strony aktualną wersją Chromium i indeksuje treść powstałą po wykonaniu skryptów. Renderowanie to jednak dodatkowy etap: strona czeka w kolejce, a treść, która się nie wyrenderuje, nie trafi do indeksu.

Czy React szkodzi SEO?

Nie. Problemy wynikają ze sposobu renderowania, obsługi adresów URL i budowy linków, a nie z samego frameworka. Aplikacja w React z poprawnymi linkami, routingiem na History API i treścią dostępną w HTML może być dobrze indeksowana.

Czy dynamic rendering to cloaking?

Nie, jeśli treść pokazywana robotowi jest zasadniczo taka sama jak treść dla użytkownika. Google traktuje jednak dynamic rendering jako obejście i zaleca renderowanie po stronie serwera, renderowanie statyczne lub hydratację.

Jak sprawdzić, jak Google renderuje stronę?

Użyj narzędzia do sprawdzania adresów URL w Google Search Console i przetestuj opublikowaną wersję strony. Przeanalizuj wyrenderowany HTML, zrzut ekranu, wczytane zasoby i konsolę JavaScript. Wyrenderowany kod pokazuje też Test wyników z elementami rozszerzonymi.

Czy można blokować pliki JavaScript w robots.txt?

Można, ale nie te, których Google potrzebuje do wyrenderowania treści. Google nie wyrenderuje JavaScriptu z zablokowanych plików, więc treść, którą generują, nie trafi do indeksu.