Renderowanie dynamiczne (dynamic rendering)
Na czym polega ten mechanizm
Serwer rozpoznaje nadawcę żądania i w zależności od wyniku tej weryfikacji przygotowuje dwie odmienne wersje tego samego adresu. Przeglądarka użytkownika otrzymuje standardową aplikację opartą na JavaScripcie, natomiast robot wyszukiwarki dostaje gotowy, wyrenderowany wcześniej kod HTML. Rozróżnienie następuje najczęściej na podstawie nagłówka User-Agent, rzadziej po adresie IP.
Skąd wzięła się potrzeba takiego rozwiązania
Aplikacje jednostronicowe zbudowane w Reakcie, Angularze czy Vue budują treść dopiero po pobraniu i wykonaniu skryptów. Crawler musi wtedy przejść przez dodatkowy etap kolejkowania i renderowania, który bywa opóźniony o godziny, a przy dużych serwisach nawet o kilka dni. Prerendering skraca ten dystans — bot dostaje pełną zawartość już przy pierwszej odpowiedzi serwera.
Czym się to realizuje
Warstwę pośrednią buduje się zwykle na headless Chrome sterowanym przez Puppeteer, na Rendertronie albo na usłudze zewnętrznej pokroju Prerender.io. Wygenerowane snapshoty trafiają do cache’a na poziomie CDN, co eliminuje narzut czasowy przy kolejnych wizytach robota.
Ograniczenia i stanowisko wyszukiwarki
Google od 2022 roku opisuje to podejście jako obejście problemu, a nie docelową architekturę. Utrzymanie dwóch ścieżek renderowania kosztuje, a rozbieżność między nimi grozi zakwalifikowaniem serwisu jako cloakingu. Rekomendowanym kierunkiem pozostaje renderowanie po stronie serwera lub generowanie statyczne — rozwiązania, w których bot i człowiek widzą ten sam dokument.
