Рендеринг и SSR: что это такое и как влияет на SEO сайта

Что такое рендеринг и SSR?

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

Инженер Google Мартин Сплитт объясняет рендеринг для веба одной фразой:

Рендеринг в этом контексте означает подстановку данных в шаблон.

Мартин Сплитт, Google

Стратегии различаются тем, где и когда эта подстановка происходит. При SSR сервер собирает готовый HTML в ответ на запрос. В документации Vue описано, как компоненты превращаются в строки HTML на сервере, уходят в браузер и затем «гидратируются» в интерактивное приложение. Противоположный вариант называется CSR (клиентский рендеринг): сервер отдаёт почти пустой документ и скрипт, а страницу собирает браузер посетителя.

Для владельца сайта вся теория сводится к одному вопросу: что лежит в первом HTML-ответе. Если там уже есть заголовки, текст и ссылки, поисковому роботу не нужно ничего выполнять. Если там пустой контейнер, содержимое появится только после работы скриптов, и это меняет скорость, индексацию и риски.

Для маркетолога рендеринг важен по трём причинам. Он определяет, какой текст попадёт в индекс, как быстро человек увидит первый экран после клика из рекламы и сколько бюджета уйдёт на доработки, если страницы придётся переделывать после запуска. Узнать ответ на первый вопрос проще всего ещё до запуска проекта, поэтому включайте проверку рендеринга в приёмку сайта.

Как работает рендеринг страницы?

Серверный сценарий состоит из нескольких шагов, и каждый можно проверить отдельно. Порядок почти одинаков у Next.js, Nuxt и других фреймворков, различаются только названия функций.

1. Браузер или робот запрашивает адрес, сервер определяет, какая страница нужна.
2. Сервер берёт данные из базы или API и подставляет их в шаблон.
3. В ответ уходит полный HTML с заголовками, текстом, ссылками и метатегами.
4. Браузер показывает страницу и в фоне загружает скрипты.
5. Скрипты «оживляют» готовую разметку: работают кнопки, фильтры, формы.

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

При клиентском рендеринге порядок обратный. Сервер отправляет документ с одним контейнером и набором файлов JavaScript, а текст появляется после их выполнения. Главный риск такой схемы Сплитт описывает прямо: если при передаче что-то пошло не так, посетитель не увидит контент, и это затрагивает SEO. В том же материале отмечен и плюс CSR: переходы внутри приложения ощущаются как работа в программе.

Показательный пример разработчики описали на vc.ru. Они делали магазин более чем на двадцать тысяч товаров и поставили Nuxt перед Битриксом, чтобы получить серверный рендеринг. Первая загрузка неожиданно выросла до 0,45 секунды, потому что страница собиралась из трёх-пяти отдельных запросов к бэкенду, и каждый заново запускал ядро Битрикса. Команда объединила их в один слой REST API, и первая загрузка вернулась к скорости самого Битрикса. Вывод: SSR переносит работу на сервер, поэтому медленный бэкенд сразу виден в скорости ответа.

Виды рендеринга: CSR, SSR, SSG, ISR

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

Различие проще всего увидеть на примере одного магазина. Карточка товара при CSR приходит в виде оболочки, и название с ценой появляются после запроса к API. При SSR то же название и цена уже лежат в первом ответе сервера. При SSG страница собрана заранее, и цена в ней устареет, пока её не пересоберут, поэтому для часто меняющихся цен выбирают SSR или ISR.

SSG снимает нагрузку с сервера. В том же разделе документации Vue сказано, что при таком подходе страницы рендерятся один раз при сборке и отдаются как статические файлы, поэтому он дешевле в развёртывании, а SSR требует среды с сервером Node.js. Сплитт указывает и ограничение: статические страницы не отвечают на действия посетителей, поэтому сложной интерактивности нужен другой подход.

ISR решает главную слабость SSG, пересборку всего сайта после каждой правки. По описанию Work Solutions, страницы остаются статическими, но автоматически обновляются по расписанию. Next.js и Nuxt поддерживают все три режима, поэтому на одном сайте каталог можно отдавать по ISR, а личный кабинет собирать в браузере.

Динамический рендеринг устроен иначе. Сервер определяет робота по user-agent и отдаёт ему отрисованную версию, а людям отдаёт обычное приложение. Google называет это временным решением и прямо не рекомендует как долгосрочное, поскольку оно добавляет сложность и расходы. Подмена не считается маскировкой, пока содержимое всех версий одинаково. Для нового проекта разумнее сразу выбрать SSR или SSG.

Выбирать удобно не для сайта целиком, а для типов страниц. Статьи блога и справочник хорошо живут на SSG, карточки товаров с остатками и ценами просят SSR или ISR, а личный кабинет и конструктор остаются на CSR. Такая смесь называется гибридной, и современные фреймворки поддерживают её из коробки. Договаривайтесь с разработчиками именно о таблице страниц и подходов: она понятна и маркетологу, и инженеру.

Влияние рендеринга на SEO и скорость

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

Яндекс работает похожим образом, и у него есть собственная настройка. В Вебмастере есть раздел «Рендеринг страниц JavaScript», в котором по умолчанию выбрано решение на усмотрение робота. Справка Яндекса советует запретить рендеринг, если на вашем проекте уже реализован SSR или пререндеринг, и предупреждает, что выполнение скриптов создаёт дополнительную нагрузку на сервер.

Если контент подгружается с задержкой, можно сообщить об этом роботу. Для этого страница создаёт объект window.YandexRotorSetting до события DomContentLoaded, как описано в той же справке. Вторая сторона вопроса: документация Vue напоминает, что поисковики хорошо индексируют синхронные приложения, а вот загрузка содержимого после спиннера через запрос может остаться незамеченной.

Представьте карточку товара на Vue: страница открывается со спиннером, а название, цену и описание подтягивает запрос к API. В документации Vue сказано, что при такой асинхронной загрузке ждать никто не будет, и тогда SSR может оказаться необходим. Практический вывод для заказчика: название, цену и описание нужно отдавать в первом HTML, а отзывы и блок рекомендаций можно догружать позже.

Рендеринг на сервере к тому же ускоряет получение первого экрана. В документации Vue сказано, что такой подход, как правило, улучшает показатели Core Web Vitals, особенно при медленном интернете или слабом устройстве. Для коммерческих страниц это важно: посетитель видит цену и кнопку раньше, чем догрузятся скрипты, и реже уходит с пустого экрана.

Скорость связана с деньгами напрямую. Агентство Work Solutions в том же материале приводит данные: по статистике Amazon, каждые 100 миллисекунд задержки снижают конверсию на 1%, а по данным Google вероятность отказа растёт на 32%, когда загрузка страницы затягивается с одной до трёх секунд. Цифры взяты из чужих исследований, поэтому используйте их как ориентир для гипотез и проверяйте на своём магазине.

Как проверить, как рендерится ваша страница?

Проверка занимает несколько минут и не требует разработчика. Начните с того, что видит робот до выполнения скриптов.

1. Откройте страницу, нажмите «Просмотр кода страницы» и найдите в теле заголовок и абзац текста.
2. Либо выполните запрос curl к адресу и посмотрите ответ: он показывает только исходный HTML.
3. Сравните с тем, что видно в браузере после загрузки: если текста в исходнике нет, страница рендерится на клиенте.
4. Проверьте, как робот видит страницу в Яндекс Вебмастере, раздел индексирования, и сверьте, что нужное содержимое участвует в поиске.

Тот же приём описан в материале Work Solutions: если в теле ответа уже есть текст статьи, ссылки и заголовки, значит страница рендерится на сервере, а если лежит один корневой контейнер и несколько файлов JavaScript, это клиентский рендеринг. Яндекс в своей справке рекомендует проверять именно индексирование страниц с JavaScript и полноту содержимого в поиске.

После проверки запишите результат по группам страниц: главная, категории, карточки, статьи. Так видно, где рендеринг уже серверный, а где остался клиентским, и по каким группам нужна работа. Если в исходнике пусто только у части шаблонов, начните именно с них: исправление одного шаблона затрагивает сотни адресов.

Отдельно проверьте ссылки. Google находит ссылки только в элементах a с атрибутом href, поэтому переходы, которые собираются скриптом без настоящих адресов, остаются невидимыми для обхода. В той же документации Google для приложений с клиентской маршрутизацией рекомендовано применять History API вместо фрагментов адреса.

Когда SSR нужен, а когда можно обойтись?

SSR оправдан там, где страницы должны находить в поиске: интернет-магазины, медиа, справочники и каталоги услуг. В материале о базовом SEO подробно разобрано, какие страницы вообще стоит продвигать, а в руководстве по SEO описан технический минимум. Рендеринг входит в этот минимум.

Есть случаи, когда SSR избыточен. Work Solutions перечисляют закрытые системы вроде CRM и админ-панелей: им не нужна индексация, и клиентский рендеринг упрощает разработку. Сплитт в том же материале говорит, что универсального решения нет: выбор зависит от того, что делает сайт и как часто меняется контент.

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

Цена у SSR есть. Документация Vue предупреждает, что отрисовка полноценного приложения на Node.js требует больше процессорного времени, чем выдача статических файлов, поэтому при большом трафике нужно грамотно использовать кэширование. Мартин Сплитт тоже советует снижать нагрузку кэшем или прокси, чтобы не собирать одну и ту же страницу повторно. Для редкого содержимого дешевле выбрать SSG.

Интересный урок даёт эксперимент SearchPilot. Туристический клиент компании хранил блок «Популярные рейсы» в JS-компоненте: часть ссылок лежала в исходном HTML, остальные прятались за вкладкой, которая рисовалась только скриптом. Аналитики вынесли скрытые ссылки в HTML и провели контролируемый тест. Заметного эффекта на органический трафик не нашли, и в выводах признали: заранее предсказать реакцию поисковиков нельзя, универсального рецепта для JS-фреймворков нет. Значит, ждать скачка от одного только переноса ссылок не стоит.

Типичные ошибки при работе с рендерингом

Первая ошибка: считать, что подключённый фреймворк означает SSR. Команда Work Solutions рассказывает в том же материале, что в половине проектов, которые она берёт на поддержку, клиенты уверены в серверном рендеринге. Проверка показывает другое: Next.js или Nuxt числятся в package.json, а весь рендеринг идёт на клиенте, то есть перед нами обычное SPA со всеми проблемами индексации. Агентство описывает собственный опыт, поэтому доверяйте выводу, но проверяйте его на своём проекте.

Вторая ошибка: добавлять SSR к готовому SPA в надежде на быструю победу. По оценке тех же авторов, если приложение изначально писали как SPA на чистом React или Vue, добавить SSR крайне сложно. Придётся переписывать получение данных, роутинг и места, где код обращается к браузерным объектам. Поэтому архитектуру выбирают на старте, а для старых проектов начинают с ключевых страниц.

Третья ошибка: закрыть скрипты от робота. Google не выполняет JavaScript в файлах, которые заблокированы настройками, поэтому правила в robots.txt нельзя писать наугад. Четвёртая: отдавать успешный ответ на несуществующие адреса. В одностраничных приложениях маршрутизация идёт на клиенте, и роботу нужен ответ «не найдено» или хотя бы тег noindex на страницах-ошибках.

Хороший способ не попасть в эти ловушки - превратить их в приёмку. Перед запуском попросите разработчиков показать исходный HTML карточки товара, статьи и категории, ответ на несуществующий адрес и список файлов, закрытых в robots.txt. Четыре проверки занимают час, а исправлять найденное до выхода в поиск дешевле, чем после того, как страницы уже выпали из индекса.

• Проверьте исходный HTML ключевых страниц: текст, заголовки, метатеги и ссылки должны быть на месте до выполнения скриптов.
• Не закрывайте в robots.txt файлы скриптов и стилей, нужные для отрисовки, иначе робот увидит страницу не так, как посетитель.
• Для несуществующих адресов отдавайте ответ «не найдено» или ставьте тег noindex на страницах-ошибках.
• Если SSR уже есть, настройте рендеринг в Вебмастере по справке Яндекса.

Частые вопросы