Renderowanie po stronie serwera czy klienta: co jest lepsze dla SEO?

Każda strona internetowa musi gdzieś w swojej architekturze rozstrzygnąć, gdzie właściwie powstaje kod HTML. Przy renderowaniu po stronie serwera (SSR) serwer składa kompletną stronę HTML i wysyła ją do przeglądarki już wypełnioną treścią. Przy renderowaniu po stronie klienta (CSR) serwer wysyła niemal pusty szkielet HTML wraz z paczką JavaScriptu, a właściwą stronę buduje przeglądarka – dopiero po pobraniu i uruchomieniu skryptów. U użytkownika z szybkim łączem i nowoczesną przeglądarką oba podejścia mogą dać dokładnie ten sam efekt wizualny. Różnią się tym, co dzieje się wcześniej – i to właśnie tam zwykle kryją się problemy z SEO.

Co Google naprawdę robi ze stroną opartą na JavaScripcie

Google potrafi renderować JavaScript – to wiadomo od lat. Haczyk polega na tym, że renderowanie odbywa się w drugim przebiegu, oddzielnie od pierwszego crawlowania, i wymaga po stronie Google więcej mocy obliczeniowej. Nie dzieje się więc natychmiast i nie odbywa się z nieograniczoną cierpliwością. Strona, która do wyświetlenia treści w całości potrzebuje JavaScriptu po stronie klienta, zmusza Google do dodatkowej pracy tylko po to, by zobaczyć to, co strona renderowana na serwerze podaje od razu. Na małej stronie rzadko kończy się to katastrofą. Na dużym serwisie z dziesiątkami tysięcy podstron powolny lub zawodny etap renderowania może oznaczać, że strony zostaną zaindeksowane z opóźnieniem, z niepełną treścią albo wcale.

Inne crawlery i platformy – podglądy linków w mediach społecznościowych, część crawlerów AI, różne narzędzia SEO – często radzą sobie z renderowaniem JavaScriptu znacznie gorzej niż Google. Strona oparta wyłącznie na CSR może wyglądać dla nich na zupełnie pustą, co odbija się na podglądach linków, odczycie danych strukturalnych i wszystkim innym, co polega na czytaniu samego kodu, a nie na uruchamianiu pełnej przeglądarki.

Kiedy CSR w zupełności wystarczy

Nie każda strona musi być zaindeksowana i nie każda część aplikacji musi być dostępna dla crawlerów. To, co znajduje się za ekranem logowania, w panelu czy w procesie zamówienia, nie jest treścią dla wyszukiwarek – i tam CSR sprawdza się dobrze, bo odbiorcą jest prawdziwa przeglądarka z włączonym JavaScriptem, a nie crawler. Jeśli wasz produkt to głównie aplikacja dla zalogowanych użytkowników z kilkoma publicznymi stronami marketingowymi, pragmatycznym rozwiązaniem jest często podejście hybrydowe: strony, które mają pozycjonować się w wyszukiwarce, renderujecie na serwerze, a aplikacja dla zalogowanych może być renderowaną po stronie klienta aplikacją typu SPA – nikt przecież nie szuka w Google waszego panelu po zalogowaniu.

Kiedy SSR jest wart swojej złożoności

Każda strona, której jedynym zadaniem jest bycie znalezioną w wyszukiwarce – strony produktów, wpisy blogowe, strony kategorii i list, strony lokalizacji, dokumentacja – zyskuje na SSR lub na generowaniu statycznym (które w praktyce jest po prostu SSR wykonanym podczas budowania, a nie przy każdym żądaniu). Treść jest obecna już w pierwszej odpowiedzi HTML, więc nic nie zależy od tego, czy drugi etap renderowania pójdzie dobrze. Taka strona zwykle ładuje się też szybciej dla prawdziwego użytkownika, bo przeglądarka nie musi czekać na pobranie, sparsowanie i wykonanie paczki JavaScriptu, zanim cokolwiek pojawi się na ekranie – a to ma znaczenie dla Core Web Vitals i ostatecznie dla konwersji.

Kompromis jest realny: SSR dokłada złożoności po stronie serwera i – w zależności od frameworka – zmienia sposób obsługi cache'owania, hydratacji oraz stanu, który musi być zsynchronizowany między serwerem a klientem. Nowoczesne frameworki sprawiły jednak, że jest to dużo mniej bolesne niż kiedyś. Oferują choćby generowanie statyczne dla treści, które rzadko się zmieniają, i przyrostową regenerację dla tych, które zmieniają się częściej, więc nie trzeba wybierać dla całej strony między „w pełni statyczną” a „w pełni dynamiczną”.

Praktyczna checklista

Jeśli strona ma pozycjonować się w wyszukiwarce albo dobrze wyglądać jako podgląd udostępnionego linku, renderujcie ją na serwerze lub podczas budowania.
Jeśli strona jest dostępna tylko po zalogowaniu i nigdy nie będzie crawlowana ani publicznie udostępniana, renderowanie po stronie klienta to rozsądna i prostsza opcja domyślna.
Testujcie narzędziem, które pokazuje surową, niewyrenderowaną odpowiedź HTML – a nie tylko to, co widać w inspektorze narzędzi deweloperskich po wykonaniu JavaScriptu – bo to bliższe temu, co crawler widzi w pierwszym przebiegu.
Nie zakładajcie, że „Google potrafi renderować JavaScript” oznacza „to bez znaczenia”. Ma to tym większe znaczenie, im większa skala, im wolniejszy serwer i im bardziej treść zależy od czasu, jak w przypadku wiadomości czy stanów magazynowych.

Właściwe rozwiązanie tej kwestii od początku – czyli decyzja, które części strony muszą być renderowane na serwerze, a które mogą zostać po stronie klienta – to jedna z pierwszych decyzji architektonicznych, jakie podejmujemy w każdym projekcie webowym w Burncode. Przerabianie tego już po zbudowaniu strony, gdy traci ona widoczność w wyszukiwarce, to znacznie większe przedsięwzięcie niż zaplanowanie tego z góry.