SSR vs CSR SEO: co wybrać dla publicznej strony

Przy wyborze SSR czy CSR łatwo skupić się wyłącznie na tym, czy Google potrafi odczytać aplikację korzystającą z JavaScriptu. Potrafi. To jednak nie kończy tematu, bo publiczną stronę odwiedzają również inne crawlery, a ich możliwości nie są identyczne.

W przypadku treści ważnej dla wyszukiwarki i systemów AI kluczowe pytanie brzmi więc inaczej: czy najważniejsza zawartość strony znajduje się już w HTML otrzymanym przez crawlera, czy pojawia się dopiero po wykonaniu JavaScriptu?

Jeżeli treść jest dostępna w HTML z serwera, crawler może ją odczytać bez dodatkowego renderowania po swojej stronie. Taki sposób dostarczenia treści dają SSR i SSG. Jeżeli natomiast strona opiera się na CSR i istotna zawartość pojawia się dopiero po wykonaniu JavaScriptu w przeglądarce, rezultat zależy od tego, czy konkretny crawler ten JavaScript rzeczywiście uruchamia.

To rozróżnienie jest ważniejsze niż proste stwierdzenie, że jedna metoda renderowania jest zawsze dobra, a druga zawsze zła. CSR nadal ma zastosowania, szczególnie tam, gdzie widoczność w wyszukiwarkach nie jest celem. Problem zaczyna się wtedy, gdy od wykonania JavaScriptu uzależniasz dostęp do treści, która ma być indeksowana albo odczytywana przez zewnętrzne systemy.

W praktyce oznacza to, że przy stronie firmowej, artykule, stronie usługi lub innej publicznej treści nie można zakładać, że każdy crawler zachowa się tak samo jak współczesny Googlebot. To założenie staje się szczególnie istotne wraz z rosnącym ruchem crawlerów wykorzystywanych przez narzędzia AI.

Google opisuje przetwarzanie stron korzystających z JavaScriptu jako proces obejmujący pobranie strony, a następnie renderowanie jej przez Web Rendering Service korzystający z Chromium. Strona wymagająca wykonania JavaScriptu może więc zostać przez Google wyrenderowana, a jej treść może trafić do indeksu.

Nie oznacza to jednak, że zawartość generowana wyłącznie przez JavaScript jest dla Google równoważna z treścią dostępną od razu w HTML. Renderowanie trafia do kolejki. Jeżeli najważniejsza treść strony pojawia się dopiero po wykonaniu JavaScriptu, jej przetworzenie może nastąpić później. Dokumentacja Google wskazuje też dwie sytuacje, w których wynik może być niepełny: zablokowane zasoby oraz JavaScript, który się nie wykona.

Nie ma za to podstaw, by przypisywać CSR konkretny stały czas indeksacji ani twierdzić, że SSR zawsze trafi do indeksu w określonej liczbie godzin. Udokumentowany mechanizm jest prostszy: Google potrafi renderować JavaScript, ale zawartość zależna od jego wykonania przechodzi przez dodatkowy etap przetwarzania.

Dla właściciela strony konsekwencja jest praktyczna. Jeśli tekst opisujący usługę, produkt albo artykuł ma znaczenie dla widoczności organicznej, nie uzależniałbym dostępu do tej treści od poprawnego wykonania JavaScriptu przez crawlera. Dostarczenie jej w HTML z serwera usuwa ten warunek.

Szczegóły dotyczące konfiguracji frameworka i elementów technicznych opisuję osobno we wpisie Next.js a SEO. Tutaj istotniejszy jest sam sposób, w jaki różne roboty dochodzą do treści.

Różnica staje się wyraźniejsza, gdy poza Googlebotem spojrzysz na crawlery związane z systemami AI. Badanie Vercel i MERJ z grudnia 2024 roku pokazało, że żaden z analizowanych głównych crawlerów AI, poza infrastrukturą wykorzystywaną przez Gemini, nie renderował JavaScriptu.

W badaniu uwzględniono między innymi crawlery OpenAI (OAI-SearchBot, ChatGPT-User i GPTBot), ClaudeBot, crawlery Meta i ByteDance oraz PerplexityBot. ChatGPT i Claude pobierały część plików JavaScript, ale samo pobranie pliku nie oznaczało jego wykonania. Dla ChatGPT pliki JS stanowiły 11,50% zapytań, a dla Claude 23,84%. Wyjątkiem jest Gemini, który korzysta z infrastruktury Googlebota i renderuje JavaScript.

Skala aktywności tych robotów pokazuje, dlaczego nie jest to już poboczny problem techniczny. W badanym miesiącu GPTBot wykonał 569 mln zapytań, a Claude 370 mln. Łącznie odpowiadało to za około 20% z 4,5 mld zapytań wykonanych przez Googlebota w sieci Vercel.

Nie wynika z tego, że sama obecność treści w HTML zagwarantuje cytowanie w odpowiedzi AI. Wynika natomiast coś bardziej podstawowego: crawler, który nie wykonuje JavaScriptu, nie zobaczy treści dostępnej wyłącznie po jego wykonaniu. Jeśli zależy Ci na tym, aby publiczna treść mogła zostać odczytana również przez takie systemy, HTML dostarczony przez serwer usuwa tę przeszkodę.

Dziś publiczną treść pobierają systemy działające według różnych zasad, dlatego jej dostępność warto projektować pod więcej niż jeden rodzaj crawlera, a nie wyłącznie pod indeksację w Google.

SSR i SSG łączy jedna najważniejsza właściwość: treść potrzebna do SEO i odczytu przez crawlery może znaleźć się w HTML otrzymanym z serwera. CSR przenosi renderowanie do przeglądarki i dlatego w przypadku zawartości pojawiającej się dopiero po wykonaniu JavaScriptu wymaga od crawlera dodatkowej możliwości.

Dlatego przy publicznych stronach internetowych nie sprowadzałbym decyzji do stwierdzenia, że Google „radzi sobie z JavaScriptem”. Radzi sobie, ale część innych crawlerów nie wykonuje go wcale. Jeśli ta sama strona ma być dostępna zarówno dla wyszukiwarki, jak i dla systemów AI pobierających publiczny internet, wspólnym mianownikiem pozostaje gotowa treść w HTML.

Nie oznacza to, że cała aplikacja musi być budowana według jednej metody. Z punktu widzenia widoczności liczy się przede wszystkim to, gdzie znajduje się treść, którą chcesz udostępnić robotom. Jeśli buduję publiczną stronę w Next.js, traktuję renderowanie serwerowe albo statyczne jako naturalny punkt wyjścia dla zawartości, która ma pracować w wyszukiwarce. Więcej o samej usłudze piszę na stronie tworzenie stron Next.js.

CSR nie jest błędem samym w sobie. Renderowanie po stronie przeglądarki jest rozsądnym wyborem w obszarach za logowaniem, w panelach oraz w aplikacjach, dla których SEO nie ma znaczenia. Brak treści w początkowym HTML nie tworzy tam tego samego problemu, bo nie oczekujesz, że publiczny crawler wyszukiwarki albo systemu AI będzie odczytywał i indeksował zawartość.

Granica jest więc dość czytelna. Jeśli użytkownik ma wejść na stronę przez wyszukiwarkę albo treść ma być dostępna dla crawlerów, dostarcz istotną zawartość w HTML z serwera. Jeżeli natomiast tworzysz zamknięty panel dostępny po zalogowaniu, przewaga SSR lub SSG wynikająca z dostępności treści dla robotów przestaje być argumentem.

To rozróżnienie pomaga uniknąć dwóch skrajności. Pierwszą jest przekonanie, że CSR automatycznie uniemożliwia indeksację w Google. Nie uniemożliwia, bo Google korzysta z Web Rendering Service. Drugą jest założenie, że skoro Google potrafi wykonać JavaScript, każda publiczna treść może bez konsekwencji zależeć wyłącznie od CSR. Badanie crawlerów AI pokazuje, że nie wszystkie roboty dysponują takim samym mechanizmem.

Sposób renderowania nie jest zastępczym wynikiem wydajności strony. Nie ma rzetelnych podstaw, żeby przypisywać SSR i CSR stałe przedziały LCP. Zamiast zakładać wynik na podstawie architektury, lepiej odnieść się do progów Core Web Vitals podawanych przez Google. Ocena jest oparta na 75. percentylu, czyli wyniku, którego nie przekracza 75% zebranych pomiarów. Wartości uznawane za dobre to:

• LCP poniżej 2,5 s: moment wyświetlenia największego elementu treści w widoku.

• INP poniżej 200 ms: reakcja strony na interakcję użytkownika.

• CLS poniżej 0,1: nieoczekiwane przesunięcia układu.

Te wartości są użyteczne przy porównywaniu rzeczywiście działających stron, ale sam wybór SSR nie zapewni automatycznie określonego wyniku, a CSR nie musi przekroczyć któregoś z progów. Renderowanie określa przede wszystkim, czy treść jest dostępna w HTML bez wykonania JavaScriptu. Core Web Vitals mówią o doświadczeniu użytkownika mierzonym konkretnymi wskaźnikami. Jednego nie zastępuj drugim.

Jeżeli więc wybierasz technologię dla publicznej strony, najpierw zadbaj o to, aby treść przeznaczona do wyszukiwarki i odczytu przez crawlery była dostępna bez wykonywania JavaScriptu po ich stronie. Wydajność oceniaj osobno, na podstawie LCP, INP i CLS.