Рендеринг для поисковиков — как робот получает документ URL: из тела HTTP или после исполнения JavaScript. Это карта двух контуров, не режим SSR и не режим CSR. HTML с сервера — соседний SSR. Сборка в браузере — соседний CSR. Что origin обязан отдать в первом ответе — JavaScript SEO. Очередь Chromium у Google — JavaScript SEO в Google. Хаб — техническое SEO.
Пока документ не собран, нет ни сниппета, ни графа ссылок, ни осмысленного статуса. Сканирование ставит URL в очередь, индексация решает хранить готовый документ. Рендер — слой между ними. Скорость для человека (LCP, TTFB) — следующие H1, этот URL про видимость документа роботу, не про полевой CrUX.
Два контура, не один «JS SEO»
Google всегда ставит страницу с кодом 200 в очередь Web Rendering Service, даже если скриптов нет. Сначала разбирается исходный HTML: ссылки из href уходят в очередь обхода сразу. Потом headless Chromium исполняет JS, и в индекс идёт отрисованный HTML, ссылки собираются вторым проходом. Задержка очереди не нормируется публично. Не все боты вообще исполняют JavaScript — это прямо в справке Search Central.
Яндекс рендер не обещает по умолчанию. Кабинет «Индексирование → Рендеринг страниц JavaScript β»: «на усмотрение», «рекомендую рендерить», «не рендерить». Справка советует запретить исполнение, если уже есть SSR или пререндер. Если документа в первом HTML нет — либо включаете исполнение, либо меняете архитектуру. Исполнение JS роботом дополнительно грузит ваш сервер. Робот — робот Яндекса.
| Вопрос | Яндекс | |
|---|---|---|
| Кто решает исполнять JS | WRS для каждого 200 без noindex в исходнике |
Тумблер в Вебмастере, по умолчанию «на усмотрение» |
| Что индексируется | Отрисованный HTML после Chromium | Либо первый HTML, либо HTML после рендера — как настроили |
| Если документ уже в ответе сервера | Рендер всё равно в очереди, но контент уже есть до него | Рендеринг запрещают, второй проход не нужен |
| Если в ответе оболочка | Зависимость от очереди WRS и открытых бандлов | Зависимость от тумблера β; иначе в базе оболочка |
| Где смотреть факт | Инспектор URL: скачанный vs отрисованный HTML | Проверка страницы и сравнение с JS / без JS |
Лимит обхода хоста общий: соседний crawl budget. Рендер жрёт квоту ресурсов (JS/CSS). WRS кэширует бандлы до ~30 дней и может игнорировать Cache-Control — смена файла без смены имени оставляет роботу старый клиент. Это гигиена контура, не «настройка рендеринга в плагине».
Какой режим выбрать, а не какой фреймворк купить
Решение одно: должен ли публичный URL быть читаемым без исполнения JS. Если да — SSR, пререндер или статическая генерация, гидратация сверху. Если нет — URL не для индекса (noindex в исходном HTML). CSR как единственный режим на денежной карточке — долг: вы отдаёте индекс очереди Google и тумблеру Яндекса.
Dynamic rendering (HTML боту по User-Agent, человеку — CSR) Google назвал workaround, не архитектуру. Он не клоакинг, пока факты те же; разные факты — уже клоакинг. Для поиска это третий документ, который надо сопровождать. На карте режимов он тупик, не «рендеринг для поисковиков».
Рендеринг для поиска выполнен, когда оба кабинета показывают тот же H1, оффер и внутренние ссылки, что
curlбез браузера — либо честно видно, что документа нет и URL не индексируют.
Практическая развилка на одном шаблоне. Скачайте денежный URL без JS. Есть заголовок, цена, абзац, <a href> — origin уже отрендерил, в Яндексе рендер запрещают, в Google проверяют, что отрисованный HTML не противоречит исходнику (другой каноникал после JS — гонка). Пустой root — либо SSR на этот шаблон, либо тумблер Яндекса плюс открытые бандлы плюс инспектор WRS; «оставим как есть» означает оболочку в индексе. Несуществующий путь того же шаблона должен быть 404/410, не 200 после клиентского роутера, см. 404.
Индексация как решение хранить документ — индексация Google и индексация Яндекса. Если на проде в первом ответе пусто, это дыра доступа: постановка SEO-аудита сайта, не задача «прогреть рендер».
Ограничение. Нет замера, какая доля сайтов в РФ рендерится ботом, а какая — на origin. Не путайте этот H1 с Core Web Vitals: полевой LCP не доказывает, что робот видит документ. Не копируйте гайд 2018 года про «два прохода через неделю» — актуальная схема Google: crawl, затем очередь WRS, без обещанного интервала.
Частые вопросы
Рендеринг для поисковиков и JavaScript SEO — это один URL?
Нет. JavaScript SEO в technical-seo — контракт origin (первый HTML, статус, RotorSettings). JavaScript SEO в Google — очередь WRS. Этот H1 — карта, как два робота собирают документ и какой режим выбрать. SSR и CSR разобраны отдельно.
Нужно ли исполнять JavaScript, если страница уже приходит готовой с сервера?
Яндексу — нет, справка просит запретить рендеринг при SSR или пререндере. Google всё равно поставит 200 в очередь WRS, но документ у него уже есть до Chromium. Второй проход нужен, когда в первом HTML нет контента.
Чем проверка в Chrome отличается от рендера робота?
У вас есть cookie, storage, WebSocket и быстрый API. WRS чистит storage между URL и ходит HTTP. Яндекс может не исполнять JS, пока тумблер «на усмотрение». Факт — инспектор и «Проверка страницы», не вкладка под вашим профилем.
Dynamic rendering закрывает задачу рендеринга для поиска?
Нет. Google держит его как временный обход. Пока факты бота и человека совпадают, это не клоакинг, но два контура HTML надо сопровождать. Устойчивая схема — один документ с origin (SSR/статика) плюс гидратация, не отдельный HTML «для робота».