Renderowanie

TL;DR — Renderowanie to etap, na którym wyszukiwarka uruchamia kod Twojej strony — w tym JavaScript — w przeglądarce, aby zbudować gotową stronę, dzięki czemu może zobaczyć Twoje treści i linki. Google robi to dla praktycznie każdej strony w swoim Web Rendering Service i zwykle to działa. Jak Twoja strona generuje swój HTML (serwer, przeglądarka lub w czasie budowania) decyduje o tym, jak bezpieczny jesteś.

Czym jest renderowanie

Kiedy otwierasz stronę, Twoja przeglądarka pobiera HTML, a następnie uruchamia CSS i JavaScript, aby zbudować stronę, którą faktycznie widzisz. Wyszukiwarki robią to samo. Renderowanie to etap, na którym wyszukiwarka uruchamia kod Twojej strony, aby zbudować finalną wersję strony, dzięki czemu może przeczytać treści i podążać za linkami tak, jak Ty.

To znajduje się w środku sposobu, w jaki Google obsługuje stronę:

1. Crawl — Google pobiera surowy HTML Twojego adresu URL.
2. Render — Google uruchamia JavaScript strony w przeglądarce, aby zbudować gotową stronę.
3. Index — Google czyta gotową stronę i archiwizuje ją.

Jeśli Twoje treści pojawiają się dopiero po uruchomieniu JavaScriptu, Google musi pomyślnie wyrenderować stronę, zanim będzie mógł ją zobaczyć. Renderowanie jest więc mostem między pobieraniem strony a rozumieniem jej.

Google renderuje w prawdziwej (ale nietypowej) przeglądarce

Renderer Google nazywa się Web Rendering Service (WRS). To headless Chrome, który jest “evergreen”, co oznacza, że nadąża za aktualną wersją Chrome i obsługuje nowoczesne funkcje internetowe. Więc stary strach — “Google nie potrafi uruchomić JavaScriptu” — nie jest prawdą. Potrafi. Dowód potwierdzający to twierdzenie Google Search runs JavaScript with an evergreen version of Chromium. Zakres: Google's Web Rendering Service; browser support does not guarantee that every application-specific interaction or resource will work. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google Search Central: Fix Search-related JavaScript problems

To po prostu nietypowa przeglądarka. Nie przewija ani nie klika, zapomina wszystko między stronami (nie pozostaje zalogowana) i agresywnie buforuje pliki. Te dziwactwa są źródłem większości niespodzianek, a zakładka Advanced je omawia.

Wielki wybór: gdzie budowany jest Twój HTML

Najważniejszą decyzją dla SEO jest gdzie produkowany jest HTML Twojej strony:

• W przeglądarce (renderowanie po stronie klienta) — serwer wysyła prawie pustą stronę, a JavaScript buduje wszystko. Najbardziej ryzykowne dla wyszukiwarki.
• Na serwerze (renderowanie po stronie serwera) — serwer wysyła kompletną stronę. Bezpieczne.
• W czasie budowania (statyczne / prerenderowanie) — strony są budowane raz, z wyprzedzeniem. Najbezpieczniejsze i najszybsze.

Większość nowoczesnych frameworków miesza te podejścia. Zasada kciuka: jeśli Twoje ważne treści są w HTML przed uruchomieniem jakiegokolwiek JavaScriptu (lub pojawiają się niemal natychmiast), jesteś w dobrej formie.

Chcesz głębszą wersję — jak faktycznie zachowuje się Web Rendering Service, czy “dwie fale indeksowania” to wciąż aktualna koncepcja, oraz pełne porównanie wszystkich opcji renderowania? Przełącz się na zakładkę Advanced. Aby poznać praktyczne problemy z JavaScriptem i rozwiązania, zobacz JavaScript SEO.

TL;DR — Google renderuje Twój JS w evergreen, headless Chromium — Web Rendering Service — aby zbudować DOM, który indeksuje. Dzieje się to dla praktycznie wszystkich stron, zwykle w ciągu sekund do minut, więc “dwie fale indeksowania” są w dużej mierze przestarzałe i nie ma budżetu renderowania na stronę. WRS jest bezstanowy, odrzuca prośby o uprawnienia, nie wchodzi w interakcje ze stroną i agresywnie buforuje. Twoja opcja renderowania decyduje o ryzyku SEO: SSR / statyczne / prerenderowanie / hydratacja są niskiego ryzyka; pełne CSR jest ryzykowne; dynamiczne renderowanie to obejście, którego Google odradza. Aby poznać praktyczne problemy z JS, które to tworzy, zobacz JavaScript SEO. Oficjalne ujęcie czasu brzmi: “may stay on this queue for a few seconds, but it can take longer than that” (tłumaczenie) „strona może pozostać w kolejce przez kilka sekund, ale czasem trwa to dłużej”.

Gdzie znajduje się renderowanie

Google jednoznacznie opisuje trzyetapową obsługę aplikacji JavaScript: najpierw pobieranie, następnie renderowanie, a na końcu indeksowanie. Dowód potwierdzający to twierdzenie Google documents crawling, rendering, and indexing as the three main phases for processing JavaScript web apps. Zakres: Google Search processing of JavaScript web applications; the phases can overlap operationally. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics Renderowanie jest mostem. Crawling pobiera surowy HTML; renderowanie uruchamia JavaScript, aby zbudować gotowy DOM; indeksowanie czyta ten wyrenderowany DOM, a wszelkie nowe linki, które renderer znajdzie, są ponownie kierowane do crawlowania. Według słów Google: “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome, similar to how your browser renders pages you visit.” (tłumaczenie) „Podczas pobierania Google renderuje stronę i uruchamia znaleziony JavaScript w aktualnej wersji Chrome, podobnie jak przeglądarka renderuje odwiedzane strony.”

Usługa renderowania w sieci

Google renderuje w Web Rendering Service (WRS) — bezgłowym Chrome, który jest zawsze aktualny: “While Google Search runs JavaScript with an evergreen version of Chromium…” (tłumaczenie) „Wyszukiwarka Google uruchamia JavaScript w stale aktualizowanej wersji Chromium…” — dzięki temu WRS śledzi bieżący Chrome, więc nowoczesne funkcje JavaScript i CSS działają.

Problem polega na tym, że WRS to osobliwa przeglądarka, a jej dziwactwa powodują większość prawdziwych problemów:

• Jest bezstanowy. Jak ująłem to w moim przewodniku po JavaScript SEO, “Google loads each page stateless like it’s a fresh load.” (tłumaczenie) „Google ładuje każdą stronę bezstanowo, jak przy nowej wizycie.” Dokumentacja Google wyjaśnia szczegóły: “Local Storage and Session Storage data are cleared across page loads” (tłumaczenie) „Dane pamięci lokalnej i sesyjnej są czyszczone między ładowaniami stron” oraz “HTTP Cookies are cleared across page loads.” (tłumaczenie) „Pliki cookie HTTP są czyszczone między ładowaniami stron”. Nie polegaj na niczym zapisanym po stronie klienta, aby serwować treści.
• Odmawia uprawnień. “Expect Googlebot to decline user permission requests.” Treści ukryte za geolokalizacją, powiadomieniami lub prośbą o dostęp do kamery nie zostaną wyrenderowane.
• Nie wchodzi w interakcje. Brak przewijania, klikania lub najeżdżania — więc treści, które ładują się tylko po jednym z tych zdarzeń, są domyślnie niewidoczne. (To źródło większości błędów leniwego ładowania i nieskończonego przewijania; poprawki znajdują się na stronie JavaScript SEO.)
• Agresywnie buforuje. “Googlebot caches aggressively in order to reduce network requests and resource usage. WRS may ignore caching headers.” (tłumaczenie) „Googlebot intensywnie buforuje, aby ograniczyć liczbę żądań sieciowych i zużycie zasobów. WRS może ignorować nagłówki buforowania.” To oznacza, że Google może uruchomić nieaktualną wersję Twojego JS lub CSS. Rozwiąż to za pomocą fingerprintingu plików — wersjonuj nazwy plików (app.4f2a9c.js), aby zmiana treści wymusiła świeże pobranie.

Eksperyment z 2026 roku: pięć sekund to nie twarda ściana wykonania

Eksperyment WRS przeprowadzony przez stronę trzecią, opisany w lipcu 2026 roku, testował opóźniony JavaScript i aktywność sieciową, zamiast zakładać pięciosekundowy limit czasu. Zaobserwowany renderer używał wirtualnego zegara i ukończył opóźnione żądania, które zajmowały około 6–12 sekund czasu rzeczywistego. Użyteczny wynik jest wąski: przeczy on powszechnej zasadzie audytowej, że wszystko, co dzieje się po dokładnie pięciu sekundach, jest automatycznie niewidoczne dla Google. Nie dowodzi on, że każde opóźnione zależności zostaną ukończone, że Google czeka w nieskończoność ani że wolne dostarczanie po stronie klienta jest bezpieczne.

Przeczytaj eksperyment i jego metodologię jako dowód od strony trzeciej, obok oficjalnego oświadczenia Google, że czas w kolejce renderowania nie ma opublikowanego stałego opóźnienia. W praktyce przetestuj końcowy DOM i żądane zasoby. Brak odpowiedzi API, wymóg interakcji, zablokowany skrypt lub zależność stanu pozostają prawdziwą awarią renderowania, nawet jeśli reguła „pięciu sekund” oparta na stoperze nie jest.

Czy „dwie fale indeksowania” nadal istnieją?

Przez lata modelem mentalnym były „dwie fale indeksowania”: Google najpierw indeksował surowy HTML, a następnie wracał po dniach lub tygodniach, aby wyrenderować i zaindeksować treści JavaScript. Ten model jest obecnie w dużej mierze przestarzały. Martin Splitt powiedział, że idea dwóch fal odgrywa coraz mniejszą rolę, że wiele stron przechodzi przez fazę renderowania nawet wtedy, gdy nie polega na JavaScript, oraz że crawling, renderowanie i indeksowanie z czasem się zbiegają.

W praktyce renderowanie odbywa się dla praktycznie każdej strony i zwykle jest szybkie. Obecna dokumentacja Google mówi, że przeszukana strona “może pozostać w tej kolejce przez kilka sekund, ale może to potrwać dłużej” — nie ma opublikowanego stałego opóźnienia ani limitu czasu. Dowód potwierdzający to twierdzenie Google says a crawled page may stay on the rendering queue for a few seconds, but it can take longer than that. Zakres: Google's rendering queue for a page that returns a 200 status and is eligible for rendering. The source gives a variable duration, not a fixed timeout or service-level guarantee. Poziom ufności: wysoki · Zweryfikowano: 2026-07-25 Google Search Central: rendering-queue duration Potwierdza: A page may remain on the rendering queue for a few seconds or longer. Jako historyczny punkt odniesienia, pracownicy Google (Martin Splitt i Tom Greenaway) raz podali medianę około pięciu sekund, z 90. percentylem w minutach — a nie “tygodnie”, które sugerował stary strach. Cytuję tę liczbę w moim przewodniku po JavaScript SEO, ale traktuję ją jako przestarzały punkt danych z konferencji, a nie aktualną opublikowaną metrykę — Google nie opublikował jej ponownie jako bieżącej liczby, a powyższy cytat o czasie oczekiwania w kolejce jest obecnym oficjalnym ujęciem.

I nie ma budżetu renderowania w takim sensie, w jakim ludzie to sobie wyobrażają. Google nie śledzi per-stronowego wyniku “jak kosztowne było renderowanie”, który trzeba oszczędzać. Renderowanie jest tanie w skali Google — optymalizuj pod kątem użytkowników i wydajności, a nie widmowego budżetu renderowania.

Opcje renderowania

“Gdzie budowany jest HTML?” — to pytanie decyduje o ryzyku SEO. Pełna lista:

• Renderowanie po stronie klienta (CSR). Serwer wysyła prawie pustą powłokę; przeglądarka (lub WRS) uruchamia JavaScript, aby zbudować wszystko. To jest “The most problematic one is going to be full client-side rendering where all of the rendering happens in the browser.” (tłumaczenie) „Najbardziej problematyczne będzie pełne renderowanie po stronie klienta, w którym całość odbywa się w przeglądarce.” Może działać, ale stawiasz wszystko na to, że renderowanie się powiedzie, i jest to najwolniejsza opcja do zaindeksowania.
• Renderowanie po stronie serwera (SSR). Serwer buduje pełny HTML dla każdego żądania. Treść jest w surowym HTML, więc ryzyko dla wyszukiwarek jest niskie.
• Generowanie statycznych stron (SSG) / prerenderowanie. HTML jest budowany raz podczas wdrożenia. Najniższe ryzyko — treść jest w surowym HTML i jest szybka.
• Hydratacja (izomorficzna / uniwersalna). Robisz SSR lub SSG dla pierwszego renderowania, a następnie JavaScript “hydratuje” je w przeglądarce, aby dodać interaktywność. To robi większość nowoczesnych frameworków i jest niskim ryzykiem dla treści — tylko uważaj na niezgodności hydratacji, które mogą wyczyścić lub zastąpić treść.
• Incremental Static Regeneration (ISR). Statyczne strony regenerowane według harmonogramu lub na żądanie. Jak SSG, z świeższą treścią — dobre dla dużych katalogów.
• Renderowanie na brzegu sieci (Edge rendering). SSR uruchamiany na węzłach brzegowych CDN — takie samo niskie ryzyko jak SSR, z szybszym czasem do pierwszego bajtu dla globalnej publiczności.
• Strumieniowe SSR. HTML strumieniowany do przeglądarki w częściach, gdy jest gotowy. Niskie ryzyko, ale upewnij się, że treść do indeksowania nie jest uwięziona tylko w późnej lub opóźnionej części.

Moje podsumowanie z mojego przewodnika po JavaScript SEO: “Każdy rodzaj SSR, renderowania statycznego i prerenderowania będzie odpowiedni dla wyszukiwarek. Gatsby, Next, Nuxt itd. są świetne.” Framework ma mniejsze znaczenie niż tryb renderowania, który dostarczasz — ta sama aplikacja Next.js jest bezpieczna lub ryzykowna w zależności od tego, czy serwujesz SSR/SSG, czy pełne CSR.

Dynamiczne renderowanie — obejście, nie strategia

Dynamiczne renderowanie oznacza wykrywanie botów i serwowanie im wstępnie wyrenderowanej, pozbawionej JavaScript wersji, podczas gdy użytkownicy otrzymują wersję po stronie klienta. Google jest teraz w tej sprawie bezpośredni: “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” (tłumaczenie) „Renderowanie dynamiczne było obejściem, a nie długoterminowym rozwiązaniem problemów z treścią generowaną przez JavaScript w wyszukiwarkach” oraz “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” (tłumaczenie) „Renderowanie dynamiczne jest obejściem, a nie zalecanym rozwiązaniem, ponieważ tworzy dodatkowe komplikacje i wymagania dotyczące zasobów.” Dowód potwierdzający to twierdzenie Google describes dynamic rendering as a workaround and does not recommend it as a long-term solution. Zakres: Google Search guidance for JavaScript-generated content; server-side rendering, static rendering, or hydration are the recommended alternatives. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google Search Central: Dynamic rendering as a workaround Zgadzam się z tym i zawsze się zgadzałem — szczerze mówiąc, nigdy tego nie polecałem i cieszę się, że Google teraz też to odradza. To serwowanie różnych treści botom i użytkownikom, co jest bardzo blisko cloakingu. Sięgnij po SSR, statyczne lub hydratację.

Jedna uwaga: Bing nadal sugeruje renderowanie dynamiczne. Microsoft twierdzi, że “bingbot is generally able to render JavaScript” (tłumaczenie) „Bingbot zazwyczaj potrafi renderować JavaScript”, ale że robienie tego na dużą skalę jest trudne, więc “we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript.” (tłumaczenie) „zalecamy renderowanie dynamiczne jako dobrą alternatywę dla witryn w dużym stopniu opartych na JavaScript”. Praktyczny wniosek: SSR/SSG zadowala obie wyszukiwarki i omija całą debatę.

Co to oznacza dla Twoich treści

Renderowanie decyduje o tym, czy Google kiedykolwiek zobaczy Twoje treści JavaScript — ale zobaczenie ich to tylko połowa zadania. Gdy strona jest wyrenderowana, praktyczne kwestie to prawdziwe linki <a href>, parzystość pól między surowym a wyrenderowanym HTML, kolejność etapów dyrektyw robots, leniwe treści, nieskończone przewijanie i miękkie błędy braku strony. Wszystko to znajduje się na stronie JavaScript SEO, wraz z przepływem testowania (wyrenderowany HTML w URL Inspection, zrzut ekranu i konsola).

To jest etap renderowania w wyszukiwarkowym potoku. Dla etapów wokół niego zobacz crawling (jak strony są pobierane) i indexing (co dzieje się z wyrenderowaną stroną następnie), lub centrum How Search Works dla całej podróży.

Jedna zasada audytu jest tutaj warta zapamiętania: wyrenderowany to stan, a nie uniwersalny zwycięzca. Dla treści ciała i linków do przeszukania, wyrenderowany DOM pokazuje, co udany JavaScript dodał lub usunął. Dla tytułów i opisów pokazuje dodatkowe dane wejściowe, podczas gdy Google może nadal generować link do tytułu lub snippet z innych źródeł. Dla dyrektyw robots, surowy noindex może zapobiec renderowaniu, więc usuwanie JavaScript jest asymetryczne. Dla kanonicznych, Google zaleca użycie jednego źródła lub jednej wartości ustawionej przez JavaScript, zamiast zmieniania istniejącej wartości. A JavaScript nie może zmienić już otrzymanego statusu odpowiedzi HTTP. Trzymaj te kolumny osobno w dowodach i korzystaj z aktualnych wytycznych JavaScript SEO Google dla zachowania specyficznego dla pól.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Renderowanie = most od crawl do indeksowania. Google uruchamia Twój JS w wiecznie aktualnym, bezgłowym Chromium — Web Rendering Service — aby zbudować DOM, który indeksuje. Trzy fazy: crawl → render → index.
• “Dwie fale indeksowania” są w dużej mierze przestarzałe (Splitt). Renderowanie odbywa się dla zasadniczo wszystkich stron, zwykle szybko. Aktualne dokumenty Google mówią, że strona “may stay on this queue for a few seconds, but it can take longer than that” (tłumaczenie) „może pozostać w tej kolejce przez kilka sekund, ale może to potrwać dłużej” — nie opublikowano żadnego stałego opóźnienia. (Istnieje wartość ~5 s mediana/90. percentyl minut, ale to przestarzały punkt danych z konferencji, a nie aktualny wskaźnik.) Nie ma budżetu renderowania na stronę.
• WRS to dziwna przeglądarka: bezstanowa (localStorage/ciasteczka wyczyszczone między ładowaniami), odrzuca prośby o uprawnienia, nie przewija/klika/najeżdża, i cache’uje JS/CSS agresywnie (może ignorować nagłówki cache) → używaj odcisków palców w nazwach plików.
• Opcje renderowania według ryzyka SEO: SSG/prerender (najniższe) ≈ SSR ≈ hydratacja ≈ ISR ≈ edge/streaming (niskie) ≪ pełne CSR (najwyższe). Patrick: “SSR, renderowanie statyczne i prerenderowanie … są świetne”; pełne CSR jest “najbardziej problematyczne.”
• Renderowanie dynamiczne to obejście, Google odradza je (blisko cloakingu). Bing nadal je zaleca — ale SSR/SSG zadowala oba.
• To framework nie decyduje o ryzyku — to tryb renderowania. Ta sama aplikacja jest bezpieczna lub ryzykowna w zależności od tego, czy używasz SSR/SSG czy pełnego CSR.
• Renderowanie to połowa zadania — praktyczne problemy JS (linki, parzystość, leniwe treści, nieskończone przewijanie, miękkie błędy braku strony, testowanie) są omówione na stronie JavaScript SEO.

Oficjalna dokumentacja

Dokumentacja źródłowa od wyszukiwarek.

Google

• Zrozum podstawy SEO dla JavaScriptu — trzy fazy (crawl → render → index) i wiecznie zielony renderer Chromium.
• Napraw problemy z JavaScriptem związane z wyszukiwaniem — ograniczenia WRS: bezstanowe przechowywanie/ciasteczka, odrzucone uprawnienia, agresywne buforowanie.
• Dynamiczne renderowanie jako obejście — dlaczego dynamiczne renderowanie jest obejściem, a nie zalecanym długoterminowym rozwiązaniem.
• Szczegółowy przewodnik po tym, jak działa wyszukiwarka Google — gdzie renderowanie znajduje się w procesie crawl → index → serve.

Bing / Microsoft

• Seria bingbot: JavaScript, dynamiczne renderowanie i cloaking. Ojej! — stanowisko Binga, że może renderować JS, ale zaleca dynamiczne renderowanie na dużą skalę.
• Nowy wiecznie zielony Bingbot — renderowanie Bingbota na Chromium opartym na Microsoft Edge.

Cytaty ze źródła

Oficjalne wypowiedzi Google i Binga (plus kilka z moich własnych tekstów). Każdy link do wyszukiwarki to link bezpośredni, który przeskakuje do cytowanego fragmentu na stronie źródłowej.

Google — potok renderowania

• “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (tłumaczenie) „Google przetwarza aplikacje internetowe JavaScript w trzech głównych fazach: 1. Pobieranie 2. Renderowanie 3. Indeksowanie.” Przejdź do cytatu
• “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome, similar to how your browser renders pages you visit.” (tłumaczenie) „Podczas pobierania Google renderuje stronę i uruchamia cały znaleziony JavaScript, używając najnowszej wersji Chrome, podobnie jak Twoja przeglądarka renderuje odwiedzane strony.” Przejdź do cytatu
• “While Google Search runs JavaScript with an evergreen version of Chromium…” (tłumaczenie) „Podczas gdy Google Search uruchamia JavaScript z wiecznie zieloną wersją Chromium…” Przejdź do cytatu
• “The page may stay on this queue for a few seconds, but it can take longer than that.” (tłumaczenie) „Strona może pozostać w tej kolejce przez kilka sekund, ale czasem trwa to dłużej” — obecne oficjalne sformułowanie dotyczące czasu oczekiwania w kolejce renderowania; nie opublikowano żadnego stałego opóźnienia. Przejdź do cytatu

Google — usługa renderowania sieci Web

• “Local Storage and Session Storage data are cleared across page loads.” (tłumaczenie) „Dane Local Storage i Session Storage są czyszczone przy każdym załadowaniu strony.” Przejdź do cytatu
• “HTTP Cookies are cleared across page loads.” (tłumaczenie) „Ciasteczka HTTP są czyszczone przy każdym załadowaniu strony.” Przejdź do cytatu
• “Expect Googlebot to decline user permission requests.” (tłumaczenie) „Należy oczekiwać, że Googlebot odrzuci prośby o uprawnienia użytkownika.” Przejdź do cytatu
• “Googlebot caches aggressively in order to reduce network requests and resource usage. WRS may ignore caching headers.” (tłumaczenie) „Googlebot agresywnie buforuje, aby zmniejszyć liczbę żądań sieciowych i zużycie zasobów. WRS może ignorować nagłówki buforowania.” Przejdź do cytatu

Google — dynamiczne renderowanie

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” (tłumaczenie) „Dynamic rendering był obejściem, a nie długoterminowym rozwiązaniem problemów z treścią generowaną przez JavaScript w wyszukiwarkach.” Przejdź do cytatu
• “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” (tłumaczenie) „Dynamic rendering jest obejściem, a nie zalecanym rozwiązaniem, ponieważ tworzy dodatkowe złożoności i wymagania dotyczące zasobów.” Przejdź do cytatu

Microsoft Bing

• “bingbot is generally able to render JavaScript…” (tłumaczenie) „bingbot jest ogólnie w stanie renderować JavaScript…” Przejdź do cytatu
• “we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript.” (tłumaczenie) „zalecamy dynamic rendering jako świetną alternatywę dla stron internetowych w dużym stopniu polegających na JavaScript.” Przejdź do cytatu

Martin Splitt, Google (przekazane za pośrednictwem transkrypcji Onely z hangoutu Webmaster Central z 2019 r.)

• O modelu dwóch fal: Splitt powiedział, że odgrywa on coraz mniejszą rolę, że wiele stron przechodzi przez fazę renderowania nawet bez JavaScript, oraz że crawling, renderowanie i indeksowanie zbiegają się. Przeczytaj relację

Patrick Stox (moja własna praca — JavaScript SEO: A Definitive Guide)

• “Google loads each page stateless like it’s a fresh load.” (tłumaczenie) „Google ładuje każdą stronę bezstanowo, jakby to było świeże ładowanie.”
• “pages went to the renderer at a median time of five seconds” (90. percentyl w minutach) — przestarzały punkt danych z epoki konferencyjnej, nie aktualna opublikowana metryka; patrz aktualny oficjalny cytat o czasie oczekiwania w kolejce powyżej. (tłumaczenie) „strony trafiały do renderera w medianie pięciu sekund”
• “The most problematic one is going to be full client-side rendering where all of the rendering happens in the browser.” (tłumaczenie) „Najbardziej problematyczny będzie pełny rendering po stronie klienta, gdzie całe renderowanie odbywa się w przeglądarce.”
• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.” (tłumaczenie) „Każdy rodzaj SSR, statycznego renderowania i prerenderowania będzie odpowiedni dla wyszukiwarek. Gatsby, Next, Nuxt itd. są świetne.”

Modele mentalne

1. Crawl → render → indeksuj. Renderowanie jest mostem. Crawling pobiera surowy HTML; renderowanie uruchamia JS, aby zbudować DOM; indeksowanie czyta ten DOM. Gdy treść JS znika, zapytaj, który krok się nie powiódł — czy została pobrana? czy została wyrenderowana? czy wyrenderowany DOM zawierał treść?

2. Renderer to prawdziwa przeglądarka z amnezją. Evergreen Chrome, ale bezstanowy (zapomina o cookies/magazynie między stronami), bez interakcji (nie przewinie ani nie kliknie) i chętny do cache’owania (może uruchomić nieaktualny JS/CSS). Projektuj tak, jakby każda wizyta była świeżym, nietkniętym, pierwszym ładowaniem.

3. Tryb renderowania decyduje o ryzyku, nie framework. SSR, statyczne, prerender i hydratacja umieszczają treść w DOM (lub szybko ją tam wprowadzają) — niske ryzyko. Pełny CSR stawia wszystko na renderowanie — najwyższe ryzyko. Ta sama aplikacja Next.js jest bezpieczna lub ryzykowna w zależności od tego, który tryb wdrażasz.

4. „Dwie fale” to stara mapa. Nie planuj wokół opóźnionej drugiej fali renderowania dni później. Renderowanie odbywa się dla zasadniczo wszystkich stron, zwykle w ciągu sekund do minut — i nie ma budżetu renderowania do racjonowania.

5. Dynamic rendering to sygnał ostrzegawczy, nie strategia. Serwowanie botom innego HTML niż użytkownikom to obejście, którego Google odradza (i jest blisko cloakingu). Jeśli sięgasz po to, prawdziwym rozwiązaniem jest zwykle SSR/SSG.

6. Umieść treść w DOM, a następnie zweryfikuj. Wybierz tryb, który szybko umieszcza treść w renderowanym DOM, a następnie potwierdź to za pomocą renderowanego HTML w URL Inspection. Twoja przeglądarka to nie Googlebot.

Opcje renderowania — kompromisy SEO

Web Rendering Service — szybkie fakty

Lista kontrolna audytu gotowości renderowania

Przejście, aby potwierdzić, że Twoja ważna treść faktycznie przetrwa renderowanie:

• Główna treść i główne linki nawigacyjne są obecne w surowym HTML (wyświetl źródło, nie inspektor DOM w DevTools) — nie tylko wstrzykiwane po uruchomieniu JavaScriptu.
• Każdy wewnętrzny link, który czytelnik musi kliknąć, to prawdziwy <a href="..."> — nie <div onclick>, trasa tylko z hashem (#/page) ani przycisk, który przesuwa stan po stronie klienta bez odpowiadającego linku.
• Żadne krytyczne pliki JS lub CSS nie są zablokowane w robots.txt (zablokowany pakiet może uniemożliwić WRS zbudowanie strony, którą musi wyrenderować).
• Treść ładowana po przewinięciu, najechaniu lub kliknięciu ma również ścieżkę, która renderuje się bez żadnej interakcji — WRS nie przewija, nie klika ani nie najeżdża.
• Nic ważnego nie zależy od localStorage, sessionStorage ani ciasteczek utrzymywanych między żądaniami — WRS jest bezstanowy i czyści wszystko między ładowaniami stron.
• Nic ważnego nie znajduje się za monitem o uprawnienia geolokalizacji, powiadomień lub kamery — WRS odrzuca je domyślnie.
• Nazwy plików JS/CSS są odciśnięte (app.4f2a9c.js), aby zmiana treści wymuszała świeże pobranie zamiast serwowania z agresywnego cache WRS.
• Renderowany HTML/zrzut ekranu w URL Inspection w Google Search Console pokazuje tę samą treść i linki, które widzisz we własnej przeglądarce.
• Witryna nie używa dynamicznego renderowania jako odpowiedzi na problem CSR — rozwiązaniem jest SSR, renderowanie statyczne lub hydratacja, a nie serwowanie botom innej wersji strony.

Błędy renderowania, które naprawdę bolą

Blokowanie JS lub CSS potrzebnych stronie do renderowania w robots.txt. Jeśli WRS nie może pobrać skryptu lub arkusza stylów, od których zależy strona, nie może zbudować dokładnego renderowanego DOM — otrzymujesz zepsuty lub pusty render zamiast strony, którą zamierzałeś. Zamiast tego: zezwól na indeksowanie swoich zasobów JS/CSS; robots.txt powinien trzymać boty z dala od miejsc o niskiej wartości, a nie od zasobów, którą potrzebują Twoje własne strony.

Dostarczanie stron krytycznych dla treści jako pełne renderowanie po stronie klienta (CSR) bez mechanizmu awaryjnego. CSR jest “the most problematic one … full client-side rendering where all of the rendering happens in the browser” (tłumaczenie) „najbardziej problematyczną opcją… pełnym renderowaniem po stronie klienta, gdzie całość odbywa się w przeglądarce” — stawia całą Twoją stronę na powodzeniu renderowania i jest najwolniejszą opcją do zaindeksowania. Zamiast tego: sięgnij po SSR, generowanie statyczne/prerenderowanie lub hydratację, aby treść była w (lub bardzo szybko trafiała do) surowego HTML.

Poleganie na trasach opartych na hashu (#/product/123) jako jedynej nawigacji. WRS podąża za prawdziwymi linkami <a href>; fragment hasha, który zmienia tylko stan po stronie klienta, bez odpowiednika URL renderowanego po stronie serwera, nie daje rendererowi niczego do dalszego indeksowania. Zamiast tego: używaj prawdziwych ścieżek, na które serwer może odpowiedzieć bezpośrednio (/product/123), nawet w aplikacji mocno opartej na kliencie.

Leniwe ładowanie treści bez ścieżki nieinteraktywnej do niej. Ponieważ WRS “doesn’t scroll, click, or hover,” treść, która pojawia się dopiero po jednym z tych zdarzeń, jest dla niego domyślnie niewidoczna. Zamiast tego: ładuj treść powyżej linii zagięcia i w rozsądnej odległości od viewportu bez wymagania interakcji, a prawdziwe leniwe ładowanie zarezerwuj dla treści rzeczywiście poniżej linii zagięcia z odpowiednim fallbackiem bez JS.

Traktowanie dynamicznego renderowania jako długoterminowego rozwiązania zamiast obejścia. Google wyraźnie stwierdza, że “dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements” (tłumaczenie) „renderowanie dynamiczne jest obejściem, a nie zalecanym rozwiązaniem, ponieważ tworzy dodatkowe komplikacje i wymagania dotyczące zasobów” — a serwowanie botom innych treści niż użytkownikom ociera się niebezpiecznie o cloaking. Zamiast tego: napraw sam tryb renderowania (SSR/statyczny/hydratacja), zamiast budować warstwę wykrywania botów wokół problemu CSR.

Testy walidacyjne

Kontrole typu pass/fail, aby potwierdzić, że poprawka renderowania faktycznie zadziałała — uruchom je po wdrożeniu zmiany, a nie jako ciągły wskaźnik zdrowia.

Test: treść pojawia się teraz w renderowanym DOM

• Test do uruchomienia — Prześlij URL do narzędzia URL Inspection w Google Search Console i użyj “Test Live URL,” a następnie otwórz zakładkę rendered HTML (lub przepuść stronę przez narzędzie Render Gap, aby porównać bezpośrednio surowy i renderowany HTML).
• Oczekiwany wynik — Treść, którą dodałeś lub poprawiłeś, pojawia się w renderowanym widoku HTML/DOM, nie tylko w narzędziach deweloperskich Twojej przeglądarki.
• Interpretacja błędu — Jeśli nadal brakuje jej w renderowanym HTML, ale jest obecna przy normalnym podglądzie strony, WRS nadal nie może jej zbudować — sprawdź zablokowany zasób JS/CSS, ładowanie tylko po interakcji lub zależność od pamięci klienta, zanim założysz, że poprawka zadziałała.
• Okno monitorowania — Natychmiastowe; test na żywo URL Inspection odzwierciedla bieżący stan URL od razu.
• Wyzwalacz wycofania — Renderowany HTML nadal nie zawiera treści po poprawce, albo test na żywo zgłasza nowy błąd indeksowania/renderowania, którego wcześniej nie zgłaszał.

Test: ważne linki przetrwają renderowanie

• Test do uruchomienia — Sprawdź renderowany HTML (URL Inspection lub Render Gap) pod kątem prawdziwych tagów <a href> wokół każdego linku, który czytelnik musi kliknąć, nie tylko widocznych elementów klikalnych.
• Oczekiwany wynik — Każdy link w renderowanym DOM ma rozwiązywalny href wskazujący na prawdziwy, indeksowalny URL.
• Interpretacja błędu — Brakujący lub pusty href na czymś, co wygląda na działający link, zwykle oznacza, że to <div>/<button> z handlerem kliknięcia po stronie klienta i bez ścieżki renderowanej po stronie serwera — WRS nie może za nim podążać.
• Okno monitorowania — Natychmiastowe.
• Wyzwalacz wycofania — Linki, które miały znaczenie przed zmianą, nie mają atrybutów href lub wskazują na fragment tylko z hashem w renderowanym wyniku.

Test: poprawka nie cofa się po cichu przy następnym wdrożeniu

• Test do uruchomienia — Uruchom ponownie kontrolę wyrenderowanego HTML (test na żywo URL Inspection lub Render Gap) po następnym wdrożeniu, które dotyczy szablonów tej strony lub potoku budowania.
• Oczekiwany wynik — Ta sama treść i linki nadal są obecne w wyrenderowanym DOM, tak jak przy pierwszym potwierdzeniu poprawki.
• Interpretacja błędu — Jeśli treść, która była obecna, zniknie ponownie, późniejsza zmiana prawdopodobnie ponownie wprowadziła zależność tylko po stronie klienta lub zepsuła ścieżkę renderowania po stronie serwera.
• Okno monitorowania — Sprawdzaj ponownie po każdym wdrożeniu, które dotyczy dotkniętych szablonów; to nie jest jednorazowa kontrola.
• Wyzwalacz wycofania — Treść lub linki, które zostały potwierdzone jako obecne, ponownie wypadają z wyrenderowanego DOM.

Zasoby warte Twojego czasu

Moje powiązane artykuły

• JavaScript SEO: A Definitive Guide — mój pełny przewodnik po renderowaniu, trybach renderowania, parytecie DOM, nieskończonym przewijaniu i problemie dwóch stron jako jednej.
• The Beginner’s Guide to Technical SEO — gdzie renderowanie mieści się między crawlingiem a indeksowaniem.

Moje wystąpienia

• How Search Works (SlideShare) — moje omówienie crawlingu, renderowania (WRS, bezstanowe ładowania, brak interakcji), indeksowania i rankingu. (Obowiązuje moje stałe zastrzeżenie: “This is my understanding of systems… not going to be 100% complete or accurate.” (tłumaczenie) „To jest moje rozumienie systemów… nie będzie w 100% kompletne ani dokładne.”)

Od innych

• web.dev — Rendering on the Web — kanoniczne wyjaśnienie kompromisów CSR / SSR / SSG / hydratacji od zespołu Chrome.
• Onely — Google’s Two Waves of Indexing — relacja na podstawie transkrypcji z sesji godzin pracy Martina Splitta wyjaśniająca, dlaczego model dwóch fal zanika; cytowane w treści artykułu.
• Search Engine Roundtable — Google: No Per-Page Search Cost — przedstawiciel Google wyjaśnia, że nie ma kosztu crawlingu/renderowania/indeksowania na stronę, który trzeba racjonować.
• Search Engine Journal — JavaScript SEO — branżowe omówienie najlepszych praktyk JS SEO, procesów testowania i zagadnień związanych z frameworkami.
• Vercel — Rendering Strategies — dokumentacja Next.js/edge rendering; przydatna przy wyborze między CSR, SSR, SSG, ISR a streamingowym SSR dla prawdziwego projektu.
• r/TechSEO — społeczność do debugowania problemów z renderowaniem/indeksowaniem.

Filmy

• Google Search Central (YouTube) — seria Martina Splitta JavaScript SEO i wyjaśnienia dotyczące renderowania to najlepsze oficjalne wideo z omówieniem, jak Web Rendering Service obsługuje Twój JS. Kanał

Statystyki, które warto cytować

• Aktualne oficjalne stanowisko: brak stałego opóźnienia. Dokumentacja Google mówi, że przeszukana strona “may stay on this queue for a few seconds, but it can take longer than that” (tłumaczenie) „może pozostać w tej kolejce przez kilka sekund, ale czasem trwa to dłużej” — nie ma opublikowanego stałego opóźnienia ani limitu czasu dla kolejki renderowania.
• Historyczny punkt danych (nieaktualny) — ~5 sekund mediany opóźnienia renderowania. We wcześniejszych uwagach konferencyjnych pracownicy Google (Martin Splitt i Tom Greenaway) podali, że strony docierają do renderera z medianą ~5 sekund, a 90. percentyl to minuty — a nie “tygodnie”, co sugerował stary strach przed dwiema falami. Cytuję to w moim przewodniku po JavaScript SEO, ale traktuję to jako historyczny punkt danych, a nie aktualną opublikowaną metrykę — Google nie opublikował tego ponownie jako bieżącej liczby.
• Dwie fale indeksowania zanikają. Według Martina Splitta model dwóch fal odgrywa coraz mniejszą rolę, gdy crawling, renderowanie i indeksowanie się zbiegają — renderowanie odbywa się teraz dla praktycznie wszystkich stron. Pokrycie
• Brak budżetu renderowania na stronę. Google wskazało, że nie śledzi, jak kosztowna jest indywidualna strona do przeszukania, wyrenderowania, zaindeksowania lub obsłużenia — więc nie ma “budżetu renderowania”, który trzeba oszczędzać tak, jak omawia się budżet crawl. Pokrycie

Sprawdź się: Renderowanie

Pięć szybkich pytań o to, jak Google renderuje strony. Wybierz odpowiedź na każde, a następnie sprawdź.

Dziennik zmian