SSR (server-side rendering) — HTML документа для этого URL собирается на сервере или на edge до того, как ответ уйдёт клиенту. В теле HTTP уже есть заголовок, оффер, абзац задачи и ссылки <a href>, а не пустой #root. Это не очередь Web Rendering Service и не тумблер «Рендеринг страниц JavaScript β». Контракт origin — соседний JavaScript SEO. Очередь Chromium у Google — соседний JavaScript SEO в Google. CSR и общий рендеринг для поисковиков в карте — отдельные H1, этот URL их не занимает.
Классический PHP и WordPress уже отдают документ с origin: для поиска это и есть SSR. «SSR» в стеке React/Vue обычно значит другое: те же компоненты, что рисует браузер, сначала выполняются на Node (или edge), сериализуются в HTML, затем гидратируются. Пререндер и статическая генерация дают тот же поисковый эффект — документ в первом ответе, — но HTML собирается на сборке, не на каждый запрос. Хаб — техническое SEO.
Что именно должно уехать в первом ответе
Google Search Central прямо пишет: обход URL и разбор HTML-ответа хорошо работают на классических сайтах и на server-side rendered страницах, где HTTP-ответ уже содержит контент. App shell — обратный случай: в первом HTML нет документа, и Google видит его только после исполнения JS. Яндекс в справке «Индексирование страниц с JavaScript β» советует запретить рендеринг, если SSR или пререндер уже реализованы: робот не гоняет второй проход и не сравнивает две версии.
| Режим | Когда появляется HTML документа | Что видит робот без JS | Для каких URL |
|---|---|---|---|
| SSR | На запросе, на origin или edge | Готовый документ этого пути | Денежные шаблоны, данные меняются часто, нужен настоящий 404/410 |
| Пререндер / статика | На сборке | Готовый документ этого пути | Стабильные публичные URL без персонализации в HTML |
| CSR | В браузере после бандла | Оболочка, лоадер, «включите JS» | Кабинет за логином, не публичный индекс |
| Dynamic rendering | Отдельный HTML боту по User-Agent | Зависит от детектора | Google назвал workaround, не архитектуру |
Dynamic rendering в справке Google — обходной путь, не долгосрочное решение: вместо него рекомендуют SSR, static rendering или hydration одной и той же страницы. Отдельный HTML «только боту» легко разъезжается с тем, что видит человек, и при разных фактах это уже клоакинг. Этот H1 про серверный документ, не про детектор бота.
Зачем поиск просит HTML с сервера, если Google умеет JS
Google обрабатывает JS-приложения тремя фазами: crawl → render → index. Ссылки из первого HTML попадают в очередь обхода сразу, из href. Страница с кодом 200 встаёт в очередь WRS; рендер может занять секунды, а может ждать ресурсов — публичной «нормы в сутках» нет. Пока документ в очереди, индекс и граф ссылок опираются на исходный ответ. Не все боты исполняют JavaScript: это буквально написано в том же гайде Search Central, не байка агентства. Лимит обхода хоста — соседний crawl budget: тяжёлый CSR жжёт очередь рендера, SSR снимает зависимость от второго прохода.
У Яндекса исполнение JS на стороне робота создаёт дополнительную нагрузку на ваш сервер — это в карточке β, не оценка «на глаз». Если origin уже отдаёт полный HTML, тумблер «Рекомендую рендерить» не нужен. Блог Вебмастера предупреждает: если выключить пререндер/SSR, роботу нужно время, чтобы начать исполнять JS; контент части URL может временно быть неполным. Переключение — письмо в поддержку, не «поменяли флаг и забыли».
SSR даёт то, чего у чистого CSR часто нет: осмысленный HTTP-статус на этом же пути. Несуществующий SKU может ответить 404/410, а не 200 с текстом «не найдено» после гидратации. Пустая оболочка с 200 — soft 404, разбор на 404. Каноникал, title и noindex тоже кладут в исходный HTML: у Google каноникализация идёт до рендера, поздняя подмена в скрипте опаздывает.
SSR выполнен, когда
curlбез браузера видит тот же H1, оффер и внутренние ссылки, что и человек после гидратации. Если в исходнике пустой контейнер — это CSR под другим именем.
Как проверить, что SSR не декорация в README
Фреймворк в package.json ничего не доказывает. Next.js на сплошных Client Components, Nuxt без server routes, «SSR-плагин» к SPA — часто всё ещё оболочка. Проверка на проде, не на localhost.
- Скачайте URL без JS:
curl -sSденежного пути. В теле должны быть видимый заголовок, цена/оффер, абзац задачи и хотя бы несколько<a href="/…">на канонические пути, не#/products. - Сравните «Просмотр кода страницы» и дерево Elements после загрузки. Расхождение заголовка или цены — гидратация перерисовала другой документ, либо сервер сериализовал пустое дерево.
- В Search Console инспектор URL: скачанный HTML уже содержит те же факты, что отрисованный. Если документ появляется только после Chromium — это не SSR, это очередь WRS, см. JavaScript SEO в Google.
- В Яндекс Вебмастере: Индексирование → Проверка страницы и режим «без JavaScript». Если версия без JS полная — рендеринг в кабинете запрещают. Робот — робот Яндекса, не «как в Chrome под вашим профилем».
- Несуществующий путь того же шаблона: сервер должен отдать 404/410, а не 200 с клиентским редиректом. Иначе SSR есть только на счастливом URL.
Гидратация после SSR — нормально: браузер вешает обработчики на уже существующую разметку. Ломается схема, когда сервер рендерит лоадер, а данные добирает только клиент; или когда кэш CDN отдаёт HTML вчерашнего SKU, а API уже другой. Отпечаток в имени бандла (app.a1b2c3.js) по-прежнему нужен: WRS кэширует агрессивно и может игнорировать Cache-Control — это гигиена соседнего JS-контракта, не «буст SSR».
Индексация как решение хранить документ — индексация Google и индексация Яндекса. Если на денежных шаблонах в первом ответе пусто, это дыра доступа, а не «ещё не прогрели WRS»: постановка — SEO-аудит сайта.
Ограничение. Нет замера «какой процент витрин в РФ отдаёт настоящий SSR» — не выдумываем. Не обещаем, что SSR сам поднимает позиции. Он снимает зависимость индекса от очереди рендера и от тумблера Яндекса. Скорость отрисовки для человека (LCP, TTFB) — следующие H1 в этом кластере, не этот URL.
Частые вопросы
SSR и пререндер — это одно и то же для поиска?
Для робота важно, что документ уже в HTTP-ответе. SSR собирает HTML на запросе, пререндер и статическая генерация — на сборке. Оба закрывают app shell. Различаются свежесть данных, персонализация и возможность отдать 404 на лету; поисковый контракт один.
Если на сайте SSR, нужно ли включать рендеринг JavaScript в Вебмастере?
Нет. Справка Яндекса просит запретить рендеринг, когда сервер или пререндер уже отдают полный HTML. Иначе робот второй раз исполняет скрипты и дополнительно грузит origin. Тумблер «на усмотрение» оставляйте только пока SSR нет.
Google умеет выполнять JavaScript. Зачем тогда SSR?
Умеет через очередь WRS, не вместо первого HTML. Ссылки, каноникал, статус и оффер надёжнее в ответе сервера. Не все боты исполняют JS, и сам Google называет server-side или pre-rendering хорошей идеей. CSR как режим — соседний H1.
Как отличить настоящий SSR от SPA, которую назвали SSR в документации?
Откройте исходник без исполнения скриптов. Если H1, оффер и внутренние ссылки уже в теле ответа — это SSR или пререндер. Если виден пустой контейнер и бандл — это CSR, какой бы флаг ни стоял в конфиге фреймворка.