Renderowanie – co to jest i jak wpływa na stronę?

Czym jest renderowanie

Dla widoczności w wyszukiwarce liczy się to, co powstaje po tym kroku, a nie to, co przyszło z serwera. Różnica bywa niewielka albo ogromna, a dla własnego serwisu lepiej ją znać, niż zgadywać.

Wszystko idzie do kolejki, nie tylko strony ze skryptami

Google opisuje przetwarzanie jako trzy kroki: skanowanie, renderowanie, indeksowanie. Do drugiego trafiają wszystkie adresy odpowiadające kodem 200: „Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page”.1

Najczęstsze nieporozumienie dotyczy właśnie tego zdania. Strona bez ani jednej linii JavaScriptu też ląduje w kolejce. Dokumentacja mówi wprost: „All pages with a 200 HTTP status code are sent to the rendering queue, no matter whether JavaScript is present on the page”.1 Rezygnacja ze skryptów nie jest więc przepustką omijającą kolejkę, tylko sposobem na to, żeby wynik renderowania nie różnił się od tego, co wysłał serwer.

Czekanie bywa krótkie, ale gwarancji nie ma: „The page may stay on this queue for a few seconds, but it can take longer than that”, a treść buduje wtedy „a headless Chromium”.1 Istotny jest jeszcze jeden szczegół: odnośniki są zbierane ponownie z wyrenderowanego dokumentu: „Googlebot parses the rendered HTML for links again and queues the URLs it finds for crawling”.1

Zmierzyliśmy różnicę na własnym serwisie

Zamiast zgadywać, pobraliśmy czternaście własnych podstron dwa razy: raz zwykłym zapytaniem, bez wykonywania skryptów, a raz przeglądarką bez interfejsu, która wykonała wszystko.2 Porównanie dotyczyło liczby słów, liczby odnośników i obecności nagłówka pierwszego poziomu.

Wyniki: renderowanie dokłada w medianie 21% słów (od 8% do 84%), liczba odnośników rośnie o jeden na każdej badanej stronie, a nagłówek h1 jest obecny w surowej odpowiedzi serwera na wszystkich czternastu. Innymi słowy: szkielet treści i cała nawigacja istnieją, zanim ruszy jakikolwiek skrypt.

Rekordzistą jest strona kontaktu z przyrostem 84%, bo tam skrypt buduje formularz. To dobra ilustracja zasady: im bardziej strona jest aplikacją, a nie dokumentem, tym więcej zależy od renderowania.

Tekst obecny w kodzie to nie zawsze tekst widoczny

Przy okazji wyszła rzecz, która potrafi zmylić przy takim pomiarze. Mediana 38% tekstu obecnego w wyrenderowanym dokumencie jest niewidoczna bez interakcji: siedzi w zwiniętych sekcjach, menu mobilnym i podpowiedziach.

Nasz pierwszy pomiar wykazał, że po renderowaniu treści ubywa o jedną czwartą, co jest oczywistym absurdem. Powód: liczyliśmy tekst widoczny dla oka, a porównywaliśmy go z całym tekstem z kodu. Drugie podejście liczyło z kolei zawartość znaczników script i style, przez co przyrost wyszedł trzycyfrowy. Dopiero trzecia wersja pomiaru dała liczbę, którą można podać.

Praktyczny wniosek wykracza poza to jedno hasło: zanim porównasz „co widzi robot” z „co widzi człowiek”, ustal, co dokładnie liczysz. Inaczej dostaniesz liczbę prawdziwą arytmetycznie i bezużyteczną w praktyce.

Jak sprawdzić to u siebie

Najprostsza droga bez żadnych narzędzi: wyłącz JavaScript w ustawieniach przeglądarki i otwórz stronę. Jeśli zostaje pusty ekran albo sam szkielet bez tekstu, treść zależy od renderowania w całości. Drugi krok to narzędzie sprawdzania adresu URL w Search Console, które pokazuje wyrenderowany kod widziany przez robota.

Sprawdź trzy rzeczy naraz: czy jest nagłówek h1, czy są odnośniki nawigacyjne i czy główna treść pojawia się bez klikania. Treść odsłaniana dopiero po interakcji użytkownika do indeksu tą drogą nie trafi.

Czym sprawdzić, co widzi robot

Renderowanie wpływa na pracę Googlebota i na wynik indeksowania, a jego efekt ogląda się narzędziem sprawdzania adresu URL w Google Search Console. Stronę budowaną tak, żeby treść nie zależała od skryptów, przygotowujemy przy tworzeniu serwisu.

Najczęstsze pytania

Czy Google widzi strony oparte na JavaScript?
Tak, renderuje je bezgłowa przeglądarka Chromium. Trzeba się jednak liczyć z czekaniem w kolejce, które bywa dłuższe niż kilka sekund.

Czy strona bez JavaScriptu omija kolejkę renderowania?
Nie. Dokumentacja mówi wprost, że trafiają tam wszystkie adresy z kodem 200 niezależnie od obecności skryptów. Korzyść jest inna: wynik renderowania nie różni się wtedy od tego, co wysłał serwer.

Ile treści na mojej stronie zależy od skryptów?
Da się to zmierzyć, porównując odpowiedź serwera z wersją po renderowaniu. U nas różnica wyniosła w medianie 21% słów, a nagłówek h1 i nawigacja były obecne od razu.

Jak sprawdzić to najprościej?
Wyłączyć JavaScript w przeglądarce i otworzyć stronę. To, co zostaje, jest bliskie temu, co robot dostaje przed wykonaniem skryptów.

Źródła

1. Google Search Central, „Understand JavaScript SEO basics”: „Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page”; „The page may stay on this queue for a few seconds, but it can take longer than that”; „Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript”; „Googlebot parses the rendered HTML for links again and queues the URLs it finds for crawling”; „All pages with a 200 HTTP status code are sent to the rendering queue, no matter whether JavaScript is present on the page” (odczyt 2026-08-21). Zobacz dokumentację Google →

2. Pomiar własny essaseo.pl z 2026-08-21 (`pomiar_renderu.py`): czternaście podstron pobranych dwa razy: zapytaniem bez wykonywania skryptów oraz przeglądarką bez interfejsu. Przyrost słów po renderowaniu: mediana +21,0%, zakres od +7,9% do +83,6%. Liczba odnośników rosła o jeden na każdej stronie, nagłówek h1 obecny w surowej odpowiedzi na 14 z 14. Udział tekstu obecnego w dokumencie, lecz niewidocznego bez interakcji: mediana 38,1%.