SSR

Как работает

При серверном рендеринге сервер выполняет код приложения и формирует полноценный HTML с контентом ещё до отправки ответа. Браузер и поисковый бот получают готовую страницу с текстом, заголовками и ссылками, а JavaScript затем «оживляет» её на клиенте — этот шаг называют гидрацией.

Противоположный подход — client-side rendering (CSR): сервер отдаёт почти пустой HTML, а контент строит браузер. Есть и промежуточные варианты: пререндеринг заранее генерирует статические HTML-файлы для каждого URL, а динамический рендеринг отдаёт боту серверную версию, а пользователю — клиентскую. Динамический рендеринг Google считает обходным решением, а не рекомендацией.

Выбор подхода зависит от задачи. Для контентных сайтов и интернет-магазинов, где важна индексация каждой страницы, серверный рендеринг или пререндеринг предпочтительнее чистого CSR. Для закрытых личных кабинетов и приложений, которые не нужно индексировать, клиентский рендеринг вполне уместен.

Схематично разница в ответе сервера:

<!-- CSR: контент собирает браузер -->
<div id="root"></div>

<!-- SSR: сервер вернул готовый HTML -->
<div id="root">
  <h1>Каталог товаров</h1>
  <ul><li>Чайник электрический</li></ul>
</div>

Почему важно для SEO

Готовый HTML снимает главный риск JavaScript-сайтов: поисковику не нужно ждать рендеринга и исполнять скрипты, чтобы увидеть контент. Это ускоряет и упрощает индексацию, особенно важно для Яндекса, чьи возможности рендеринга скромнее, и для крупных сайтов, где отложенный рендеринг съедает краулинговый бюджет. Сама проблема JS-индексации разобрана в карточке javascript-seo.

SSR влияет и на скорость. Пользователь быстрее видит контент, но нагрузка смещается на сервер, поэтому важно следить за временем ответа — метрикой TTFB из карточки ttfb. Плохо оптимизированный сервер может отдавать HTML медленно, а тяжёлые скрипты гидрации — блокировать отрисовку, о чём речь в карточке render-blocking.

Существует и гибридный вариант — часть страниц рендерится на сервере, часть на клиенте, в зависимости от их роли в поиске. Такой подход позволяет не переплачивать серверными ресурсами там, где индексация не нужна. SSR не панацея: он усложняет разработку и инфраструктуру, поэтому применять его стоит там, где индексация JS-контента действительно критична.

Частые ошибки

• Внедрять SSR, но оставлять критичный контент подгружаемым скриптами после гидрации.
• Оставлять метатеги и canonical на откуп клиентским скриптам вместо исходного HTML.
• Не следить за TTFB: серверный рендеринг под нагрузкой замедляет ответ.
• Отдавать боту и пользователю разный по смыслу контент — это трактуется как клоакинг.
• Кэшировать серверный HTML неправильно, показывая устаревшие данные.
• Считать SSR обязательным для любого сайта, включая простые статические страницы.

Как проверить

Откройте исходный код страницы через View Source или запросите её утилитой curl — при SSR основной контент, заголовки и ссылки уже присутствуют в ответе сервера. В Google Search Console инструмент «Проверка URL» покажет, что бот получил при обходе. Время ответа сервера удобно смотреть в DevTools → Network по полю TTFB.

Проверять наличие контента в исходном HTML на всех типах страниц вручную трудоёмко. SEO Crawler обходит сайт по ответам сервера и показывает, где заголовки, текст и ссылки присутствуют сразу, а где страница приходит фактически пустой, — так видно, работает ли рендеринг единообразно по всему сайту.

Вывод

SSR отдаёт поисковику готовый HTML и снимает риски индексации JavaScript-контента. Применяйте его там, где это оправдано, следите за TTFB и убеждайтесь, что серверная и клиентская версии совпадают по содержимому.