Что такое SEO рендеринг и как SSR и CSR влияют на сайт

Когда дело доходит до отображения контента на странице, у разработчиков есть два пути: обработать скрипт на стороне сервера (хостинга) или доверить эту задачу браузеру. От этого выбора зависит, что именно получит поисковый робот, а значит, и видимость сайта в поиске.

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

В статье объясняем, что такое серверный (SSR) и клиентский (CSR) рендеринг, как Google и «Яндекс» обрабатывают JavaScript, как выбрать подход по типу сайта и проверить, что видит робот. Отдельно разбираем кейс онлайн-школы.

10 часов вебмастеринга на 3 месяца в подарок

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

Получить подарок

Читайте также:

Отличия SEO под Яндекс и Google

Что такое SEO рендеринг

Рендеринг — это сборка страницы из HTML, CSS и JavaScript в тот вид, который получают пользователь и поисковый робот. Процесс рендеринга различается тем, где собирается страница: на сервере (SSR, server-side rendering) или в браузере (CSR, client-side rendering).

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

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

Серверный рендеринг SSR и его особенности

Серверный рендеринг (SSR) — это формирование полного HTML страницы на сервере в ответ на запрос, до того как браузер получит ответ.

Пользователю отправляется уже готовый HTML, вся страница отрисована и контент доступен. SSR не стоит путать со статической генерацией (SSG): при SSR HTML создается по запросу к каждому URL, а при SSG он собирается заранее, при сборке сайта. У подхода два плюса и один минус:

• Робот и пользователь получают контент уже в первом HTML-ответе, поэтому роботу не нужен отдельный шаг рендеринга.
• Контент доступен независимо от того, включен ли JavaScript у посетителя. Google отмечает, что серверный рендеринг или пререндеринг (заранее подготовленный HTML) остается хорошей идеей: он ускоряет сайт для пользователей и роботов, а выполнять JavaScript умеют не все боты.
• Нагрузка на сервер выше, чем при отдаче статических файлов, а от времени его ответа зависит скорость загрузки страницы.

Клиентский рендеринг CSR и его риски

Клиентский рендеринг (CSR) — это построение страницы прямо в браузере с помощью JavaScript: логика, получение данных, шаблоны и маршрутизация выполняются на клиенте, а не на сервере.

При CSR сервер отдает каркас страницы, а у пользователей контент собирают скрипты, которые загружены в их браузере. Если в исходном HTML нет контента, Google должен выполнить JavaScript, чтобы увидеть контент страницы. Для этого робот ставит страницы с кодом ответа 200 в очередь на рендеринг, и ожидание в очереди может занять больше нескольких секунд. Подробнее о работе со скриптами рассказывает материал про оптимизацию JavaScript по рекомендациям Google.

• Плюс: разработка быстрее, по документации фреймворка Nuxt коду не нужно учитывать совместимость с сервером.
• Плюс: хостинг дешевле, потому что сервер отдает статические файлы и не тратит ресурсы на сборку страниц.
• Риск: пользователь или бот без JavaScript получит пустую страницу-каркас вместо контента.

5 классных SEO-кейсов

Круче, чем Гудини: как мы вырастили трафик в 2,2 раза

Все вы прекрасно знаете Гарри Гудини: этот фокусник мог выбраться из закрытой бочки, брошенной в воду. Примерно в таких же рамках оказались и мы, начиная работу с сайтом Eurorepar. Узкий функционал, жесткие требования. Но мы справились без магии, увеличив трафик х2!

Читать кейс

Читать кейс

Как выжать максимум из двадцатилетнего сайта

Можно ли выжать максимум из 20-летнего сайта и докрутить его до современных стандартов? А если есть отягчающие обстоятельства — накрутка поведенческих факторов, антиботы, да еще и админка капризничает и сама удаляет категории?

Читать кейс

Читать кейс

Долгая дорога в SEO и мощный прорыв

Наш клиент — интернет-магазин B2B промышленной тематики. Он достался нам после предыдущих подрядчиков, и первые год-два мы исправляли их ошибки. А потом началась долгая кропотливая работа, которая в итоге принесла желанный результат.

Читать кейс

Читать кейс

Qugo: вырастили трафик из блога платформы b2b в 9,7 раз!

Молодой сайт, сложная тематика b2b, крупные конкуренты — с такими вводными трафик и позиции оставляли желать лучшего. Но бы добились цели: повысили трафик и позиции, улучшили узнаваемость бренда

Читать кейс

Читать кейс

Эффективное ссылочное продвижение для федеральной аптечной сети

Федеральная аптечная сеть пришла в Kokoc Performance (входит в Kokoc Group) за ссылочным продвижением. Интересно, что в компании есть своя in-house команда по SEO, которая подготовила ссылочную стратегию, а за ее реализацией обратилась к нам.

Читать кейс

Читать кейс

1/5

Читайте также:

Чек-лист по SEO: 44 способов увеличить поисковый трафик

Как Google и «Яндекс» обрабатывают JavaScript

По опыту Kokoc.com, раньше ресурсы, целиком построенные на скриптах, даже не брали в работу, поскольку поисковые роботы видели пустые страницы. Сегодня Google выполняет JavaScript в актуальной версии Chromium, но отдельным шагом: страницы с кодом 200 попадают в очередь на рендеринг, затем отрендеренный HTML разбирается заново и используется для индекса. В марте 2026 года Google указал в журнале обновлений документации, что его поиск рендерит JavaScript уже несколько лет.

У «Яндекса» выполнением скриптов можно управлять в разделе Вебмастера «Рендеринг страниц JavaScript», который по состоянию на октябрь 2026 года помечен β (бета-версия). В справке «Яндекса» сказано, что по умолчанию включена опция «На усмотрение робота Яндекса»: робот сам решает, выполнять ли JavaScript, и может оценить качество и полноту контента с JavaScript и без него. При выполнении скриптов робот способен создавать дополнительную нагрузку на сервер. Если контент загружается с задержкой, об этом можно сообщить «Яндексу» специальным кодом JavaScript.

SSR vs CSR для SEO и скорости сайта

Для SEO главное различие в том, получает ли робот контент в первом HTML-ответе.

На скорость загрузки влияет реализация. По документации web.dev (техническая площадка Google), SSR обычно дает быстрый первый показ контента и позволяет отправить клиенту меньше JavaScript, но генерация страницы занимает время и может увеличить время ответа сервера. Преимущество SSR по скорости не автоматическое: если после ответа сервера на клиенте остается много работы, показатели вроде INP (задержка реакции на действия пользователя) все равно могут вырасти. При CSR метрики тоже можно улучшать: при жестком бюджете JavaScript клиентский рендеринг почти догоняет серверный, хотя на мобильных устройствах сделать его быстрым трудно.

Результат стоит оценивать по метрикам Core Web Vitals, набору показателей пользовательского опыта от Google. По данным web.dev, хорошим считается LCP (Largest Contentful Paint) до 2,5 секунды от начала загрузки страницы, INP (Interaction to Next Paint) не более 200 миллисекунд и CLS (Cumulative Layout Shift) не более 0,1. Значения оценивают по 75-му процентилю загрузок, отдельно для мобильных и десктопных устройств. Как сократить время загрузки, подробно разобрано в гайде по скорости загрузки страниц сайта.

Статическая генерация и гибридный рендеринг

Между чистыми SSR и CSR есть другие способы отдать роботу готовый HTML. В популярных инструментах разработки это решается на уровне фреймворка: Next.js работает с React, Nuxt с Vue, а Angular поддерживает серверный и гибридный рендеринг. Разработчику достаточно поставить задачу: контент важных для поиска страниц должен приходить в первом HTML.

• SSG, статическая генерация: HTML каждого URL создается заранее, при сборке сайта. Подходит для страниц, которые меняются редко, а у больших сайтов сборка может занимать много времени.
• ISR, инкрементальная статическая регенерация: подход из Next.js, который позволяет обновлять статический контент без пересборки всего сайта.
• SSR с гидратацией: сервер отдает готовый HTML, затем скрипты подключаются к нему в браузере, и этот шаг называют гидратацией. В документации Nuxt это универсальный рендеринг. По документации web.dev, это рабочее решение, но у него могут быть заметные недостатки по производительности.
• Гибридный рендеринг: разные режимы (SSR, SSG, CSR) для разных частей сайта, так его понимают Angular и Nuxt.
• Динамический рендеринг: боты получают серверную версию страницы, пользователи клиентскую. Google называет его устаревшим обходным решением и не рекомендует из-за сложности и требований к ресурсам.

Как выбрать рендеринг для вашего сайта

При выборе подхода ориентируются на то, нужен ли странице органический трафик и как часто меняется ее контент. Делать одинаковый рендеринг для всего сайта не обязательно: по документации web.dev, SSR можно использовать на одних страницах и не использовать на других.

• Интернет-магазин и каталог: товары и листинги должны попадать в индекс. Nuxt относит интернет-магазины и маркетплейсы к проектам, для которых подходит серверный рендеринг; по web.dev, страницам с персонализацией статическая генерация не подходит.
• Блог, новостной сайт, база знаний: Nuxt называет блоги контентными сайтами, для которых подходит серверный рендеринг. Если страницы меняются редко, их можно собирать заранее.
• Лендинг и корпоративный сайт: страниц немного, поэтому, как правило, достаточно готового статического HTML.
• Личный кабинет и закрытый сервис: страницы не нужны поиску, и Nuxt считает клиентский рендеринг хорошим выбором для приложений без индексации.

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

Сергей Шабуров

Руководитель отдела SEO Kokoc Performance

Как проверить, что видит поисковый робот

Проверка строится на сравнении двух версий: исходного HTML, который сервер отдает по URL, и страницы после выполнения скриптов. Часть проверок можно сделать в самом браузере, остальные дают инструменты «Яндекса» и Google. В кейсе ниже первым сигналом тоже стало расхождение: код в панели разработчика и в просмотре кода страницы был разным.

1. Откройте исходный код страницы и найдите в нем фрагмент основного контента, ссылки, title и canonical.
2. Сравните с версией в панели разработчика браузера: она показывает, что появилось только после выполнения скриптов.
3. Проверьте URL в Google Search Console инструментом «Проверка URL»: живая проверка показывает снимок отрендеренной страницы, ее код и список ресурсов.
4. Проверьте страницу в «Яндекс Вебмастере» инструментом «Проверка страницы»: он показывает код ответа и то, как выглядит контент страницы для робота.
5. Отключите JavaScript в браузере и посмотрите, остается ли контент и работают ли ссылки.

Типичные ошибки при рендеринге в браузере

Типичные ошибки на сайтах с рендерингом в браузере связаны со ссылками, метатегами и кодами ответа. Google находит ссылки только в элементах <a> с атрибутом href, а о роли самих ссылок рассказывает материал про внутренние ссылки для SEO. В декабре 2025 года Google уточнил, что canonical лучше задавать так же, как в исходном HTML, потому что канонизация происходит до и после рендеринга; о самом теге рассказывает статья про rel=canonical.

Чтобы в одностраничных приложениях не возникали мягкие 404, нужен редирект на URL с ответом 404 или noindex на страницах ошибок. Поведение рендеринга для страницы с noindex в исходном коде не определено однозначно и может измениться, поэтому там, где страница может понадобиться в индексе, этот тег в исходном коде не ставят.

Эффективное SEO

• Гарантия результатов
• Комплексное развитие
• При любом тарифе отслеживаем динамику заявок и звонков с сайтов
• Регулярный пересмотр семантического ядра

Узнать больше

Читайте также:

Новый поиск «Яндекса» Y1: что изменится для пользователей, владельцев сайтов и SEO-специалистов

Почему рендеринг в браузере тормозил трафик онлайн-школы

В сентябре 2024 года мы провели разовый SEO-аудит сайта онлайн-школы (EdTech), подробности есть в кейсе по этому сайту. При проведении технического аудита нас смутило, что через панель разработчика и через просмотр кода страницы код был разный. Вебмастер сообщал о дублирующихся метатегах, несмотря на их уникальность в исходном коде страниц. Внутренние ссылки не сканировались, хотя страницы попадали в индекс, а canonical нормально не отрабатывал, несмотря на правильное указание в коде.

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

Команда разработчиков клиента вносила правки в две итерации, с ноября 2024 по апрель 2025 года, и трафик начал расти еще в ходе работ: за год (июль 2024 к июлю 2025) он вырос в 2,28 раза.

Видимость сайта в поисковых системах тоже выросла: запросов в топ-3 Яндекса стало больше в 2,5 раза (август 2024 к августу 2025), а в топ-3 Google в 8,9 раза. Рост совпал с исправлением рендеринга, но контрольной группы сайтов для сравнения нет, поэтому связь роста с рендерингом — наблюдение агентства, а не измеренный эффект.

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

Павел Талакин

Руководитель группы экспериментальных клиентов

Почему серверный рендеринг не панацея

Рендеринг на сервере устраняет техническое препятствие, но не заменяет работу над сайтом. Если у вас неоптимизированный сайт, не проработаны коммерческие факторы, мало контента или он некачественный — одним рендерингом проблему не решить. У клиента были проработаны структура, коммерческая и контентная части, а нерешенной оставалась техническая ошибка, и после ее исправления трафик и видимость выросли. Поэтому решение о рендеринге стоит принимать вместе с остальными пунктами технического аудита: структурой, контентом и коммерческими факторами.

Статья впервые опубликована на SEOnews

FAQ по SEO рендерингу

Коротко о главном

• Рендеринг превращает код страницы в то, что видят пользователь и робот, поэтому для поиска важно, где и когда собирается контент.
• SSR отдает готовый HTML, CSR собирает страницу скриптами в браузере и зависит от рендеринга на стороне поисковой системы.
• Google выполняет JavaScript отдельным шагом, а робот «Яндекса» по умолчанию сам решает, выполнять ли скрипты; режим можно поменять в бета-настройке «Вебмастера».
• Выбор зависит от типа сайта, а проверка сводится к сравнению исходного и отрендеренного HTML.
• Рендеринг остается одной из технических причин, остальные факторы сайта сохраняют значение.