SEO strony w JavaScript wymaga porównania odpowiedzi HTML serwera z kodem po wykonaniu skryptów. Google może renderować JavaScript, lecz widoczność treści zależy od dostępnych zasobów, poprawnych linków i sygnałów indeksowania. Sprawdź oba stany w narzędziach przeglądarki oraz w Inspekcji URL Search Console, zanim uznasz pusty HTML za błąd.
Jak Google przechodzi od odpowiedzi serwera do renderu?
Googlebot najpierw pobiera adres URL. Sprawdza zasady dostępu, status odpowiedzi i kod HTML, który serwer zwrócił bez udziału przeglądarki. Z tego dokumentu może już wyodrębnić standardowe linki. Stronę z odpowiedzią 200, jeśli nie blokuje jej reguła indeksowania, przekazuje do kolejki renderowania. Następnie mechanizm oparty na Chromium wykonuje dostępny JavaScript i analizuje powstały dokument. Dokumentacja Google o JavaScript SEO opisuje właśnie tę kolejność.
Nie ma jednej gwarantowanej liczby sekund między pobraniem a renderowaniem. Dlatego treść widoczna wyłącznie po uruchomieniu skryptu tworzy dodatkową zależność: skrypt, jego żądania sieciowe i komponent muszą zadziałać. Sam fakt użycia Reacta, Vue czy innej biblioteki nie rozstrzyga o problemie. Decyduje wynik dla konkretnego adresu URL i konkretnego zasobu. Dla strony usługowej szczególnie ważne są opis usługi, lokalizacja, cennik lub warunki oferty, nagłówek i link do kontaktu.
Pusty kod źródłowy nie oznacza automatycznie braku indeksacji. Google może zobaczyć treść po renderze. Z drugiej strony pełny widok w Twojej zalogowanej przeglądarce nie dowodzi, że robot otrzymał to samo: sesja, zgoda na cookies lub odpowiedź API mogą zmieniać wynik. W diagnozie trzeba oddzielić możliwości Google od tego, co rzeczywiście stało się z badanym URL-em.
HTML źródłowy i wyrenderowany DOM: porównanie na przykładzie
Poniższy przykład jest demonstracyjny. Nie pochodzi z audytu seo-krakow.pl ani z żadnego rzeczywistego klienta. Załóżmy stronę usługi w Krakowie, której serwer odsyła ogólny szkielet aplikacji. Po wykonaniu skryptu przeglądarka dodaje właściwy nagłówek, opis i link do formularza. Różnica jest sygnałem do badania, a nie gotowym werdyktem.
``html <!-- Odpowiedź serwera: przykład --> <title>Usługi | Firma</title> <div id="app"></div> <script src="/assets/app.js"></script> ``
``html <!-- DOM po poprawnym renderowaniu: przykład --> <title>Projektowanie ogrodów Kraków | Firma</title> <main><h1>Projektowanie ogrodów w Krakowie</h1> <p>Projektujemy ogrody przy domach i firmach w Krakowie.</p> <a href="/kontakt/">Zapytaj o projekt</a></main> ``
| Element | HTML odpowiedzi | DOM po renderze | Pytanie kontrolne |
|---|---|---|---|
| Tytuł i H1 | Ogólny tytuł, brak H1 | Tytuł usługi i H1 | Czy Google widzi wersję specyficzną dla URL-a? |
| Treść główna | Brak | Opis usługi | Czy wynik renderowania zawiera opis bez interakcji? |
| Link wewnętrzny | Brak | Standardowe href | Czy adres jest odkrywany także przez inne strony? |
| Canonical i robots | Do sprawdzenia w obu stanach | Do sprawdzenia po zmianach JS | Czy skrypt nie zmienia intencji indeksowania? |
| Dane strukturalne | Mogą być w źródle lub DOM | Powinny odpowiadać widocznej treści | Czy test Google widzi zgodny obiekt? |
Jeżeli po renderze brak opisu, trzeba znaleźć przyczynę: nieudane żądanie API, błąd skryptu, zasób zablokowany dla robota, wymóg logowania albo treść ładowaną dopiero po kliknięciu. Jeśli render zawiera opis, kolejnym pytaniem jest indeksowanie i wybór kanonicznego adresu. Tego nie rozstrzyga zrzut ekranu aplikacji. Użyj Inspekcji URL i sprawdź dane Google dla dokładnie tej strony.
Co porównać dla jednego adresu URL?
Zacznij od statusu HTTP i adresu końcowego po przekierowaniach. Strona usługowa powinna odsyłać sensowną odpowiedź dla robota bez wymogu zalogowania. Potem zapisz HTML odpowiedzi, otwórz ten sam URL w przeglądarce z włączonym JavaScriptem i porównaj dokument po renderze. W Search Console użyj testu bieżącego adresu, obejrzyj wyrenderowany HTML i zasoby strony. Pamiętaj, że test bieżący i stan w indeksie opisują inne momenty.
W obu stanach poszukaj title, opisu meta, H1, głównej treści, atrybutu canonical, dyrektywy robots, linków z href oraz danych strukturalnych. Zapisz różnice w tabeli, zamiast stwierdzać ogólnie, że „Google nie widzi strony”. Zwróć uwagę, czy skrypt nie podmienia canonicala na stronę główną albo nie dodaje noindex po błędzie. Nie zakładaj jednak, że każdy element musi być identyczny przed renderem i po nim. Istotna jest zgodność ostatecznego dokumentu z zamierzoną podstroną oraz możliwość jego uzyskania przez Google.
Narzędzia deweloperskie przeglądarki pomagają znaleźć błędy konsoli i nieudane żądania sieciowe. Crawler uruchomiony raz bez JavaScriptu i raz z renderowaniem pokaże skalę różnic w wielu adresach. To przydatne zwłaszcza dla powtarzalnego szablonu kategorii lub usługi. Sprawdź próbkę ręcznie, zanim zautomatyzowany wynik uznasz za dowód. Crawler i Google mogą mieć różny czas, dostęp do zasobów i kontekst, więc kontrola w Search Console pozostaje potrzebna.
Jak przeprowadzić test renderowania krok po kroku?
- Wybierz trzy reprezentatywne adresy: usługę, wpis blogowy i stronę kontaktu. Dodaj wariant o największej różnicy między widokiem a kodem źródłowym.
- Zapisz status HTTP, docelowy adres, HTML odpowiedzi i reguły dostępu dla strony oraz jej skryptów. Zaznacz, kiedy pobrano próbkę.
- Otwórz stronę bez logowania i uruchom JavaScript. Zapisz DOM po załadowaniu oraz błędy konsoli i sieci.
- Porównaj tytuł, H1, treść, linki, canonical, robots i dane strukturalne. Przypisz każdej różnicy wpływ na odkrywanie lub interpretację URL-a.
- W Inspekcji URL uruchom test na żywo, obejrzyj wyrenderowaną stronę i jej zasoby. Porównaj wynik z tym, co zapisano lokalnie.
- Jeśli elementu brakuje, napraw konkretną zależność i powtórz test. Następnie obserwuj stan indeksowania, bo pojedynczy test nie oznacza natychmiastowej aktualizacji indeksu.
Przykładowy protokół może mieć kolumny: URL, element, odpowiedź serwera, lokalny DOM, test Google, hipoteza, poprawka, data ponownego sprawdzenia. Wpis „brak” jest użyteczny tylko wtedy, gdy wiadomo, w której kolumnie wystąpił. Dzięki temu deweloper może odtworzyć błąd, a osoba odpowiedzialna za SEO może ocenić, czy poprawka dotyczy szablonu, pojedynczego adresu czy konfiguracji serwera. To także ułatwia rozdzielenie problemu renderu od opisanych osobno stanów indeksowania.
Kiedy wybrać SSR, generowanie statyczne lub render w przeglądarce?
Renderowanie po stronie serwera (SSR) oznacza, że odpowiedź zawiera już treść potrzebną na stronie. Generowanie statyczne przygotowuje taki HTML wcześniej, podczas budowy witryny. Renderowanie po stronie klienta (CSR) dostarcza szkielet i tworzy treść później w przeglądarce. Każdy model może współistnieć z interaktywnymi komponentami. Wybór zależy od tego, jak często zmieniają się dane, jak szybko trzeba odsyłać treść i czy aplikacja może stabilnie pobrać wszystkie zależności.
Dla strony usługi, kategorii lub artykułu warto zapewnić najważniejszy tekst, H1 i nawigację w HTML wysyłanym przez serwer, jeśli architektura projektu na to pozwala. To upraszcza odkrywanie treści przez różne roboty i zmniejsza liczbę warunków koniecznych do jej pokazania. Nie oznacza to automatycznej przewagi rankingowej samego skrótu SSR. Nadal liczą się jakość informacji, dostępność URL-i, linkowanie i techniczne sygnały indeksowania. Przebudowa architektury bez zdiagnozowanego problemu może kosztować więcej niż naprawa jednego endpointu API.
Jeśli pozostajesz przy CSR, utrzymuj zasoby publicznie dostępne, twórz standardowe linki z href, zapewnij stabilny stan po renderze i testuj konkretne szablony. Krytyczna treść nie powinna wymagać kliknięcia przycisku, podania zgody lub przewinięcia na określoną odległość. Lazy loading może obsługiwać obrazy i elementy dodatkowe, ale nie powinien ukrywać jedynego opisu produktu przed renderem. Część problemów jest też powiązana z wydajnością, dlatego po rozwiązaniu dostępu do treści warto sprawdzić Core Web Vitals.
Co zrobić po znalezieniu różnicy?
Najpierw nazwij brakujący element i ustal, czy problem jest powtarzalny. Jeśli wszystkie podstrony usług mają ten sam ogólny tytuł, przeanalizuj szablon. Jeśli tylko jeden wpis nie ma opisu, sprawdź dane wejściowe i odpowiedź API. Gdy dokument po renderze jest pełny, ale URL nie jest w indeksie, sprawdź canonical, noindex, jakość strony i linkowanie. Mieszanie tych przyczyn prowadzi do przypadkowych zmian, po których trudno ocenić wynik.
Poprawkę weryfikuj w trzech warstwach: odpowiedź serwera, renderowany dokument i odczyt Google. Zapisz datę wdrożenia, sprawdź URL ponownie po przetworzeniu i oceń, czy błąd zniknął także na innych stronach korzystających z komponentu. Przegląd całej witryny możesz rozpocząć od audytu technicznego SEO albo szerszego audytu SEO. Ten artykuł skupia się na renderowaniu, a ogólna lista obszarów kontroli jest w przewodniku po SEO technicznym.
Co sprawdzić dalej?
Temat łączy się z kolejnymi decyzjami w serwisie. Zobacz także mapa witryny xml, wykryto obecnie nie zindeksowano oraz kanoniczny url.
