Найти в Дзене

Почему я настаиваю на SSR/SSG/Prerender для JS-сайтов

Яндекс и Google умеют исполнять JS, но это второй этап обхода, а значит – очередь и лишние ресурсы. Есть термин «краулинговый бюджет» (объём URL и ресурсов, которые робот готов обойти за период), и чем проще вы отдаёте страницу, тем больше URL попадут в индекс без задержек. Я не спорю с прогрессом, я просто не трачу бюджет на то, что можно отдать готовым HTML – и дальше покажу, как это сделать без боли. SSR (Server-Side Rendering) – сервер формирует HTML на каждый запрос. Хорошо для динамики и фильтров, если есть кэш на уровне CDN/edge.
SSG (Static Site Generation) – HTML собирается заранее на билде. Идеально для статей, лонгридов, лендингов: отдача быстрая, робот счастлив.
Prerender – промежуточное решение для SPA: вы уже пишете на React/Vue, но на выходе добавляете слой, который генерит готовый HTML для робота и пользователей.
CSR – когда первый ответ сервера «пустой», а всё дорисовывается JS. Для SEO-критичных страниц это медленный путь к индексу.
ISR (Incremental Static Regener
Оглавление

Зачем вообще трогать рендеринг

Яндекс и Google умеют исполнять JS, но это второй этап обхода, а значит – очередь и лишние ресурсы. Есть термин «краулинговый бюджет» (объём URL и ресурсов, которые робот готов обойти за период), и чем проще вы отдаёте страницу, тем больше URL попадут в индекс без задержек. Я не спорю с прогрессом, я просто не трачу бюджет на то, что можно отдать готовым HTML – и дальше покажу, как это сделать без боли.

И так на каждом проекте с 2023 года
И так на каждом проекте с 2023 года

Быстрые инсайты за 60 секунд

  • Критический контент (H1, основной текст, важные ссылки, разметка schema) должен приходить в первом ответе сервера в виде HTML.
  • Если сайт – SPA, не переписывайте всё: пререндерьте (Prerender – предварительная отрисовка SPA в HTML на этапе билда) ключевые разделы и ядро семантики.
  • CSR (Client-Side Rendering – отрисовка на клиенте) оставляем для личных кабинетов и закрытых зон, но витрину и контент переводим на SSR/SSG – дальше разберём границы.

Термины «на пальцах», без академизма

SSR (Server-Side Rendering) – сервер формирует HTML на каждый запрос. Хорошо для динамики и фильтров, если есть кэш на уровне CDN/edge.

SSG (Static Site Generation) – HTML собирается заранее на билде. Идеально для статей, лонгридов, лендингов: отдача быстрая, робот счастлив.

Prerender – промежуточное решение для SPA: вы уже пишете на React/Vue, но на выходе добавляете слой, который генерит готовый HTML для робота и пользователей.

CSR – когда первый ответ сервера «пустой», а всё дорисовывается JS. Для SEO-критичных страниц это медленный путь к индексу.

ISR (Incremental Static Regeneration) – гибрид: страница собрана статикой, но может пересобираться по расписанию или сигналу, не останавливая сайт.

Как выбрать режим под задачу

  • Если у вас контентные разделы, новости, блог – берите SSG или SSG+ISR. Вы получите стабильный HTML и быстрый TTFB, а Яндексу это нравится.
  • Если магазин с фильтрами, сортировками и большим каталогом – SSR с кэшем и аккуратными серверными пагинациями.
  • Если личный кабинет или сложный JS-инструмент – пусть будет CSR, но закрытый от индекса robots/meta.
  • Если переписывать фронт дорого – пререндерьте сотни ключевых страниц, чтобы не ждать милости очереди рендеринга.

Где CSR ломает индексацию в Яндексе

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

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

В следующем блоке дам рабочие настройки, которые спасают даже при частичном CSR.

Набор инструментов, без которых я не запускаю рендер-стратегию

Я использую Яндекс.Вебмастер для проверки «как видит робот» и покрытия. Логи сервера – чтобы смотреть частоту обхода и TTFB. Lighthouse как прокси-метрику LCP/CLS. Снимки HTML до и после гидрации – чтобы убедиться, что «на сервере одно, на клиенте другое» не разрушает контент.

Это не академическая дисциплина, а просто дисциплина – и ниже я покажу порядок действий, который повторяю из проекта в проект.

Порядок действий: как я перевожу витрину с CSR на «нормальный» рендер

Сначала выделяю SEO-критичную часть: список категорий, карточки, статьи, FAQ. Затем выбираю режим: если фронт готов к SSR – включаю SSR и ставлю кэш на CDN с политикой stale-while-revalidate, чтобы Яндекс видел быстрый ответ, а пользователи – живые данные. Если SSR нет – ставлю Prerender на 300–1000 ключевых URL и на шаблоны списков/карточек.

Далее чищу параметры: сортировки и вид отображения – под каноникал, технические хвосты – в clean-param на стороне Яндекса и на уровне сервера. Закрываю пагинацию «бесконечной лентой», переводя её в серверные страницы /page/2 и т.д., иначе робот упрётся в первый экран. В итоге робот получает готовый HTML и предсказуемую навигацию – секрет в предсказуемости, а не в модных аббревиатурах.

Тонкие места, о которых обычно забывают

Разметка schema.org должна быть в HTML первого ответа, а не как «скрипт, который добавим позже». Хлебные крошки и основное меню – серверные, иначе вы скрываете от робота карту сайта.

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

Частые ошибки (короткий список)

  • Включили SSR, но не включили кэш – TTFB вырос, краулинг просел, винят «Яндекс».
  • Пререндерят только карточки, забывают списки – робот не находит путь к карточкам.
  • Оставляют параметры сортировки и вида без каноникала – индекс размазывается по «одной и той же» странице.

Мини-кейсы из моей практики

Контентная SPA без переноса на SSR – пререндер 600 ключевых статей и шаблонов списков дал заметно более короткую очередь индексации.

Маркетплейс на SSR с агрессивным кэшем и серверной пагинацией – карточки начали попадать в поиск стабильно, а не «как повезёт».

Блог с SSG+ISR – материал отдаётся молниеносно, а обновления вытягиваются по сигналу без перекатывания всего проекта. У этих историй общий знаменатель: робот видит HTML сразу, а я не трачу бюджет на то, чтобы «дождаться рендера».

Мини-чеклист перед релизом

  1. Критический контент, навигация и schema – в HTML первого ответа; сравните снапшот до/после гидрации.
  2. Выбран режим под раздел: SSG/ISR для статей, SSR+кэш для каталога, CSR закрыт для кабинетов.
  3. Пагинации серверные, фильтры – чистые URL с каноникалом; техпараметры удаляются на сервере и в clean-param.

FAQ

Яндекс ведь исполняет JS – зачем городить SSR/SSG

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

Можно оставить CSR, ничего не меняя

Для закрытых зон – можно и нужно. Для витрины и контента – нет: вам нужен предсказуемый HTML, иначе индексация будет «как повезёт», а позиционирование – размазанным. Чуть выше я дал порядок миграции без переписывания всего фронта.

Что выбрать для каталога с фильтрами

SSR с кэшем на edge и чистыми серверными пагинациями. Сортировки и вид – под каноникал на базовый URL. Фильтры, которые открываем – в отдельные ЧПУ-страницы с контролем индексации. Это не теория, это накопившаяся практика.

Можно ли жить на Prerender вечно

Можно, если он закрывает 90% органики и поддерживается в CI. Но чаще это переходный этап: проект растёт, и удобнее иметь нативный SSR/SSG. Я начинаю с пререндера, когда бюджет и сроки жмут, а затем планирую эволюцию.

Как проверить, что всё работает

Снимок HTML на первом ответе, сравнение с «видимым DOM», отчёты Яндекс.Вебмастера «как видит робот», логи и TTFB. Если всё совпадает, а TTFB адекватный – вы на рельсах.

В моей практике это тот «секретный метод», который почему-то зовут сложным словом «архитектура рендеринга», хотя на деле это про принятие зконов Яндекса и Google – отдайте им то, что они просят, и они зайдут чаще и глубже.

В конце статьи – если остались нюансы вашего стека или хотите разбор конфигурации, напишите в комменты, приложите пару URL и я подскажу, с чего начать. И да, подписывайтесь – пишу в Дзене регулярно, а за кулисами делюсь быстрыми кейсами и чек-листами в телеграме t.me/seo_and_sem