Серверный или клиентский рендеринг: что лучше для SEO?

Каждому сайту на уровне архитектуры приходится решать, где именно собирается HTML. При серверном рендеринге (SSR) сервер формирует полную HTML-страницу и отправляет её в браузер уже заполненной контентом. При клиентском рендеринге (CSR) сервер отправляет почти пустой HTML-каркас и JavaScript-бандл, а браузер собирает саму страницу после того, как JavaScript загрузится и выполнится. Для пользователя с быстрым интернетом и современным браузером оба подхода могут дать один и тот же визуальный результат. Различаются они тем, что происходит до этого момента, — и именно в этом промежутке обычно и кроются проблемы с SEO.

Что Google на самом деле делает со страницей, перегруженной JavaScript

Google умеет рендерить JavaScript — это так уже много лет. Нюанс, на котором спотыкаются многие, в том, что рендеринг у Google происходит на втором этапе, отдельно от первичного сканирования, и требует от Google больше вычислительных ресурсов. Поэтому он происходит не мгновенно и не с бесконечным терпением. Страница, которая целиком зависит от клиентского JavaScript при отображении контента, заставляет Google выполнять дополнительную работу только ради того, чтобы увидеть то, что страница с серверным рендерингом отдаёт сразу. На небольшом сайте это редко бывает критично. На крупном сайте с десятками тысяч страниц медленный или ненадёжный рендеринг может привести к тому, что страницы попадут в индекс с опозданием, с неполным контентом или не попадут туда вовсе.

Другие краулеры и платформы — превью ссылок в соцсетях, некоторые ИИ-краулеры, различные SEO-инструменты — зачастую справляются с рендерингом JavaScript гораздо хуже, чем Google. Страница только с CSR может выглядеть для них совершенно пустой, а это сказывается на превью ссылок, извлечении структурированных данных и всём остальном, что зависит от чтения самой разметки, а не от запуска полноценного браузера.

Где CSR вполне подходит

Не каждую страницу нужно индексировать, и не каждая часть приложения должна быть доступна краулерам. За формой входа, внутри дашборда, в процессе оформления заказа — всё это не контент для поисковых систем, и CSR там отлично работает, потому что аудитория — реальный браузер с включённым JavaScript, а не краулер. Если ваш продукт — это в основном приложение для авторизованных пользователей и несколько публичных маркетинговых страниц, прагматичным решением часто становится гибридный подход: рендерить на сервере страницы, которые должны ранжироваться, а приложение для авторизованных пользователей оставить одностраничным с клиентским рендерингом — ведь никто не ищет в Google ваш личный кабинет.

Где SSR оправдывает свою сложность

Любая страница, вся задача которой — находиться в поиске (страницы товаров, статьи блога, страницы категорий и каталогов, страницы филиалов, документация), выигрывает от SSR или статической генерации (которая, по сути, тот же SSR, только выполняемый при сборке, а не при каждом запросе). Контент присутствует уже в первом HTML-ответе, поэтому нет зависимости от того, насколько удачно пройдёт второй этап рендеринга. Кроме того, такие страницы обычно быстрее загружаются для реального посетителя: браузеру не нужно ждать, пока JavaScript-бандл скачается, разберётся и выполнится, чтобы показать хоть что-то. А это важно для Core Web Vitals и в конечном счёте для конверсии.

Компромисс вполне реален: SSR добавляет сложности на стороне сервера и, в зависимости от фреймворка, меняет подход к кэшированию, гидратации и состоянию, которое нужно синхронизировать между сервером и клиентом. Современные фреймворки сделали это гораздо менее болезненным, чем раньше, благодаря таким подходам, как статическая генерация для редко меняющегося контента и инкрементальная регенерация для того, что меняется часто, так что не приходится выбирать между «полностью статическим» и «полностью динамическим» вариантом для всего сайта.

Практический чек-лист

Если страница должна ранжироваться в поиске или корректно выглядеть в превью ссылки, рендерите её на сервере или при сборке.
Если страница доступна только после авторизации и никогда не будет сканироваться или публично распространяться, клиентский рендеринг — разумный и более простой вариант по умолчанию.
Проверяйте страницы инструментом, который показывает исходный, неотрендеренный HTML-ответ, а не только то, что вы видите в инструментах разработчика браузера после выполнения JavaScript, — это ближе к тому, что краулер видит при первом проходе.
Не считайте, что «Google умеет рендерить JavaScript» означает «это неважно». Это становится тем важнее, чем больше масштаб, чем медленнее сервер и чем чувствительнее контент ко времени — как новости или складские остатки.

Правильно решить этот вопрос с самого начала — определить, какие части сайта нужно рендерить на сервере, а какие можно оставить на клиенте, — одно из первых архитектурных решений, которые мы принимаем в каждом проекте по веб-разработке в Burncode. Переделывать это на готовом сайте, который уже теряет видимость в поиске, гораздо дороже, чем заложить заранее.