Czy Google indeksuje treści generowane przez JavaScript?

Tak, Google potrafi wykonywać JavaScript i wykorzystywać wygenerowaną treść. Trzeba jednak sprawdzić, czy konkretna implementacja działa poprawnie i nie utrudnia dostępu do zawartości. Zasady opisuje dokumentacja Google dotycząca JavaScript SEO.

Czy brak treści w źródle strony oznacza problem z SEO?

Nie przesądza o problemie. Treść może zostać dodana podczas renderowania. W takiej sytuacji sprawdź jej obecność w wyrenderowanej wersji oraz wynik testu Google. Sposoby diagnozy przedstawia poradnik rozwiązywania problemów z JavaScriptem.

Czy każda strona powinna korzystać z SSR?

Wybór zależy od potrzeb witryny. SSR ułatwia dostarczenie treści w początkowym HTML, ale wiąże się też z kosztami generowania odpowiedzi. Warto porównać dostępne podejścia i ich ograniczenia, korzystając z przewodnika po renderowaniu na web.dev.

Czy wyłączenie JavaScriptu pokazuje stronę tak, jak widzi ją Google?

Nie. Taki test pomaga zauważyć zależność zawartości od skryptów, ale Google potrafi je wykonywać. Do oceny jego dostępu użyj również narzędzia do sprawdzania adresów URL.

Czy ukrycie tekstu w rozwijanej sekcji uniemożliwia jego odczytanie?

Samo zwinięcie sekcji nie odpowiada na to pytanie. Sprawdź, czy tekst już znajduje się w dokumencie, czy jest pobierany dopiero po kliknięciu. Google nie wykonuje takich interakcji jak użytkownik. Więcej wyjaśnia dokumentacja dotycząca doładowywania treści.

Czy warto wdrożyć dynamic rendering?

Google traktuje dynamic rendering jako obejście problemu i obecnie go nie zaleca. Rozwiązanie polega na rozpoznawaniu robotów i dostarczaniu im wyrenderowanej wersji, podczas gdy użytkownicy otrzymują wersję renderowaną w przeglądarce. Zwiększa to złożoność utrzymania. Zalecane alternatywy opisuje dokumentacja Google o renderowaniu dynamicznym.

Czy muszę znać programowanie, żeby zacząć naukę JavaScript SEO?

Na początek wystarczy umiejętność rozpoznania podstawowych elementów HTML, sprawdzenia odpowiedzi serwera i porównania treści przed renderowaniem oraz po nim. Bardziej złożone poprawki będą wymagać współpracy z programistą. Twoim zadaniem jest umieć wykryć problem, pokazać jego skutki i sprawdzić rezultat zmiany.

JavaScript w SEO - Adam Suchorski

JavaScript a SEO

JavaScript odpowiada za wiele funkcji, z których korzystasz podczas przeglądania stron: filtrowanie produktów, rozwijanie menu, doładowywanie kolejnych wyników czy obsługę interaktywnych kalkulatorów. Może też generować niemal całą zawartość witryny.

Z perspektywy SEO liczy się to, czy wyszukiwarka potrafi dotrzeć do tej zawartości, odczytać ją i znaleźć prowadzące dalej linki. Strona, która działa poprawnie na Twoim komputerze, wymaga jeszcze sprawdzenia w narzędziach Google.

W tym rozdziale poznasz podstawy renderowania, najczęstsze problemy związane z JavaScriptem i sposoby ich diagnozowania.

Czym jest JavaScript SEO?

JavaScript SEO to część optymalizacji technicznej zajmująca się wpływem JavaScriptu na odkrywanie, renderowanie i indeksowanie stron.

W praktyce sprawdzasz między innymi, czy po uruchomieniu skryptów dostępne są opisy produktów, nagłówki, linki i informacje potrzebne do interpretacji strony. Oceniasz także, czy aplikacja poprawnie obsługuje poszczególne adresy URL.

Wyobraź sobie sklep rowerowy, w którym opis roweru i odnośniki do podobnych modeli pojawiają się dopiero po pobraniu danych przez JavaScript. W takim przypadku audyt powinien objąć również etap doładowania tych informacji.

Wprowadzenie do zagadnienia znajdziesz w przewodniku JavaScript SEO od Ahrefs.

Jak Google przetwarza strony z JavaScriptem?

Google potrafi wykonywać JavaScript. Przetwarzanie strony obejmuje trzy główne etapy:

Skanowanie — Googlebot pobiera stronę i analizuje odpowiedź serwera.
Renderowanie — system renderujący uruchamia JavaScript i przetwarza zawartość strony.
Indeksowanie — Google analizuje uzyskaną treść i decyduje o jej uwzględnieniu w indeksie.

Renderowanie może nastąpić po pewnym czasie od pobrania strony. Nie ma jednego gwarantowanego terminu dla wszystkich adresów. Istotne zasoby, takie jak skrypty potrzebne do wyświetlenia treści, muszą być dostępne dla Google.

Możliwość wykonania JavaScriptu nie oznacza, że każda aplikacja zostanie przetworzona bez błędów.

Przeczytaj: Google — JavaScript a SEO: podstawy.

HTML źródłowy a strona po uruchomieniu JavaScriptu

Podczas analizy rozróżniaj dwie rzeczy:

HTML otrzymany z serwera — początkowy dokument przesłany do przeglądarki.
DOM — aktualną strukturę dokumentu w przeglądarce, którą JavaScript może zmieniać.

Opis produktu może być nieobecny w początkowym HTML, a następnie pojawić się w DOM po wykonaniu skryptów. Możliwa jest też sytuacja odwrotna: treść znajduje się w odpowiedzi serwera, ale skrypt ją usuwa lub zastępuje.

Dlatego samo polecenie „Wyświetl źródło strony” nie wystarcza do pełnej oceny. Strukturę dokumentu po wykonaniu JavaScriptu sprawdzisz w panelu Elements narzędzi deweloperskich Chrome.

Przeczytaj: Chrome DevTools — przeglądanie i zmienianie DOM.

CSR, SSR i SSG — gdzie powstaje treść strony?

W rozmowach o JavaScript SEO często pojawiają się skróty opisujące sposób generowania zawartości.

Sposób renderowania	Jak działa?	Na co zwrócić uwagę?
CSR — Client-Side Rendering	Przeglądarka buduje zawartość przy użyciu JavaScriptu.	Dostępność treści zależy od wykonania skryptów i pobrania potrzebnych danych.
SSR — Server-Side Rendering	Serwer generuje HTML w odpowiedzi na żądanie.	Ważna treść może być dostępna już w odpowiedzi serwera. Trzeba też zadbać o czas jej przygotowania.
SSG — Static Site Generation	HTML powstaje wcześniej, podczas budowania witryny.	Należy zaplanować aktualizowanie wygenerowanych stron po zmianach treści.

Te rozwiązania można łączyć w jednej witrynie. Poradniki mogą być generowane statycznie, a bardziej interaktywne części korzystać z innych sposobów renderowania.

Możesz spotkać się również z pojęciem hydratacji. To etap, w którym JavaScript dodaje interaktywność do HTML przygotowanego wcześniej po stronie serwera.

Wybór architektury wpływa na dostępność treści, wydajność i utrzymanie witryny. Sam skrót „SSR” w dokumentacji projektu nie zastępuje testów.

Przeczytaj: web.dev — Rendering on the Web.

Co sprawdzać podczas optymalizacji?

1. Dostępność głównej treści

Zacznij od elementów, które decydują o wartości konkretnej podstrony: opisu usługi, treści artykułu, specyfikacji produktu czy listy ofert.

Otwórz adres bez wcześniejszego odwiedzania witryny. Sprawdź, czy właściwa zawartość pojawia się również bez zapisanych ustawień i wcześniejszej sesji. System renderujący Google nie zachowuje między wczytaniami stron danych tak jak powracający użytkownik.

Jeśli treści brakuje, sprawdź błędy JavaScriptu i żądania pobierające dane. Problem może wynikać z niedostępnej usługi, błędu aplikacji albo założenia, że użytkownik wcześniej wykonał określoną czynność.

Przeczytaj: Google — rozwiązywanie problemów z JavaScriptem.

2. Linki, za którymi może podążać wyszukiwarka

Element wyglądający jak link nie zawsze jest odnośnikiem możliwym do prawidłowego odczytania przez Google.

Do nawigacji między podstronami używaj elementów <a> z atrybutem href, który zawiera docelowy adres:

<a href="/rowery-miejskie/">Rowery miejskie</a>

Sam przycisk uruchamiający funkcję JavaScript nie jest równoważnym rozwiązaniem. Dotyczy to między innymi menu, kart produktów i odnośników do powiązanych artykułów.

Linki mogą być dodawane przez JavaScript. Ważne, aby po ich wygenerowaniu miały właściwą postać i wskazywały rzeczywiste adresy.

Przeczytaj: Google — sprawdzone metody dotyczące linków.

3. Osobne adresy dla osobnych podstron

Aplikacja może zmieniać widok bez pełnego przeładowania strony. Każda podstrona przeznaczona do wyszukiwania powinna jednak działać również po bezpośrednim otwarciu jej adresu.

Przykładowo adres /rowery/rower-miejski/ powinien prowadzić do właściwego produktu także po wklejeniu go do nowej karty.

Unikaj rozwiązań, w których różne podstrony są dostępne wyłącznie przez fragmenty adresu, takie jak /#/rowery. Google zaleca obsługę takich widoków z wykorzystaniem History API. Zwykłe odnośniki do sekcji tego samego dokumentu, na przykład #specyfikacja, mają inne zastosowanie.

Przeczytaj: Google — obsługa adresów w aplikacjach JavaScript.

4. Tytuły, canonical i ustawienia indeksowania

Sprawdź, czy każda podstrona ma właściwy tytuł i metaopis. JavaScript może je ustawiać lub zmieniać, dlatego kontroluj również ich końcową postać.

Szczególnej uwagi wymaga noindex. Jeśli znajduje się już w początkowym HTML, Google może pominąć renderowanie. Usunięcie tego oznaczenia dopiero przez JavaScript nie jest bezpiecznym sposobem udostępniania strony do indeksowania.

Przeczytaj: Google — metadane i indeksowanie stron z JavaScriptem.

Zadbaj także o spójny adres kanoniczny, czyli wskazanie preferowanej wersji strony. Najlepiej umieścić go w początkowym HTML. Sprawdź, czy skrypty nie dodają sprzecznych oznaczeń i nie zmieniają wskazania na inny adres.

Przeczytaj: Google — określanie kanonicznego adresu URL.

5. Prawidłowe kody odpowiedzi serwera

Komunikat „Nie znaleziono strony” widoczny w przeglądarce nie oznacza jeszcze, że serwer zwrócił kod błędu.

Nieistniejący adres powinien otrzymać odpowiednią odpowiedź, zwykle 404 lub 410. Jeśli serwer zwraca 200, a strona pokazuje błąd albo pustą zawartość, Google może rozpoznać ją jako soft 404.

Podczas testów sprawdzaj więc zarówno wygląd strony, jak i odpowiedź serwera. Dotyczy to szczególnie aplikacji, które dla wielu różnych adresów zwracają ten sam początkowy dokument.

Przeczytaj: Google — wpływ kodów stanu HTTP na przetwarzanie stron.

6. Lazy loading i doładowywanie wyników

Lazy loading polega na odraczaniu wczytywania wybranych elementów, na przykład zdjęć znajdujących się dalej na stronie.

Wdrożenie powinno umożliwiać załadowanie potrzebnej zawartości, gdy znajdzie się ona w widocznym obszarze. Nie zakładaj, że Google kliknie przycisk albo wykona gest przewijania wymagany przez Twój skrypt.

Przykład: opis produktu pobierany dopiero po kliknięciu „Pokaż opis” wymaga innej oceny niż opis już obecny w dokumencie, którego widoczność zmienia rozwijana sekcja.

Przeczytaj: Google — dostępność treści ładowanych leniwie.

Jeśli sklep używa nieskończonego przewijania lub przycisku „Załaduj więcej”, zapewnij kolejnym częściom listy osobne adresy i dostępne linki. Dzięki temu odkrywanie produktów nie zależy wyłącznie od interakcji z interfejsem.

Przeczytaj: Google — paginacja i przyrostowe wczytywanie stron.

7. Wydajność i reakcja na działania użytkownika

JavaScript może obciążać przeglądarkę także wtedy, gdy treść jest już widoczna. Długie zadania mogą opóźniać reakcję na kliknięcie menu, zmianę filtra czy dodanie produktu do koszyka.

Jednym ze wskaźników pomagających ocenić ten problem jest INP — Interaction to Next Paint, opisujący responsywność strony.

Przy analizie wydajności sprawdź między innymi niepotrzebne skrypty, kod zewnętrznych usług i koszt obsługi interakcji. Poprawki powinny wynikać z pomiarów oraz konkretnych problemów użytkowników.

Przeczytaj: web.dev — optymalizacja INP.

Jak sprawdzić stronę krok po kroku?

Wybierz kilka reprezentatywnych adresów: stronę główną, kategorię, produkt i artykuł. Dodaj również adres, który nie istnieje, aby sprawdzić obsługę błędów.

Porównaj zawartość przed wykonaniem skryptów i po nim

Zapisz krótki fragment głównej treści oraz przykładowy link wewnętrzny. Poszukaj ich w odpowiedzi HTML i w DOM.

Przy większej witrynie użyj crawlera obsługującego JavaScript. Pozwoli on porównać między innymi treści, linki i metadane. Pamiętaj, że wynik działania crawlera jest symulacją, a nie zapisem tego, co Google faktycznie zindeksował.

Instrukcję znajdziesz w poradniku skanowania stron JavaScript w Screaming Frog.

Sprawdź adres w Google Search Console

W narzędziu do sprawdzania adresów URL przeanalizuj informacje o wersji znanej Google, a następnie uruchom test wersji opublikowanej.

W szczegółach testu sprawdź wyrenderowany HTML, zrzut ekranu oraz informacje o zasobach. Wyszukaj wcześniej zapisany fragment tekstu i link. Sam wygląd zrzutu ekranu nie wystarcza do oceny wszystkich elementów.

Poprawny wynik testu wersji opublikowanej nie jest potwierdzeniem indeksacji. Informuje o bieżącej możliwości przetworzenia strony w zakresie objętym testem.

Przeczytaj: Search Console — narzędzie do sprawdzania adresów URL.

Opisz problem tak, aby można było go odtworzyć

Zamiast zgłaszać „Google nie widzi JavaScriptu”, zapisz konkretne ustalenie:

„Na stronie produktu opis jest widoczny po kliknięciu zakładki, ale nie występuje w HTML z testu wersji opublikowanej w Search Console”.

Dołącz adres, brakujący fragment i warunki testu. Po poprawce powtórz sprawdzenie tej samej podstrony oraz kilku innych korzystających z tego samego szablonu.

Materiały do dalszej nauki

Po dokumentacji Google sięgnij po przewodniki branżowe uwzględnione w segmencie JavaScript SEO w LearningSEO:

Ahrefs — JavaScript SEO — przegląd zagadnień i problemów spotykanych podczas optymalizacji.
Conductor — JavaScript SEO Best Practices Guide for Beginners — materiał wprowadzający w techniczne podstawy.
Onely — przewodnik po JavaScript SEO — rozwinięcie zagadnień związanych z renderowaniem i indeksowaniem.
Sitebulb — wpływ renderowania JavaScriptu na indeksowanie — materiał pomocny przy analizowaniu różnic między HTML a wyrenderowaną stroną.
Semrush — JavaScript SEO — omówienie optymalizacji witryn korzystających z JavaScriptu.

Ćwiczenie praktyczne

Wybierz jedną podstronę produktu lub usługi. Zapisz jej adres, tytuł, główny nagłówek, fragment opisu i jeden link wewnętrzny.

Następnie porównaj te elementy w trzech miejscach:

HTML otrzymanym z serwera.
DOM po wykonaniu JavaScriptu.
HTML z testu wersji opublikowanej w Search Console.

Zanotuj różnice. Oceń, czy dotyczą tylko sposobu prezentacji, czy także dostępności ważnej treści. Przygotuj jedno konkretne zalecenie albo zapisz, że w badanym zakresie nie wykryto problemu.