Почему SPA плохо индексируется и что даёт серверный рендеринг

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

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

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

• Обход идёт в два прохода: сначала HTML, потом отложенный рендеринг скриптов.
• Рендеринг дорог, поэтому доходит не до всех страниц и не сразу.
• Ошибка в скрипте или таймаут запроса — робот видит пустую страницу.
• Многие ИИ-краулеры скрипты не исполняют: без серверного HTML вас просто нет.
• Глубокие разделы страдают сильнее всего: до них очередь доходит в последнюю очередь.

Самая быстрая проверка — просмотр исходного кода страницы в браузере (не панель разработчика с готовым DOM, а именно исходный код). Найдите в нём предложение из вашего основного текста. Если оно есть — контент приходит с сервера. Если вместо текста видно пустой контейнер и список скриптов, робот получает то же самое.

Вторая проверка — отключить JavaScript в браузере и открыть страницу. Останется ли на ней содержимое и работающие ссылки? Третья — посмотреть в вебмастере, как выглядит страница для робота, и сравнить с тем, что видите вы. Четвёртая — проверить, что навигация сделана обычными ссылками с адресами, а не обработчиками кликов: по кнопке без ссылки робот никуда не перейдёт.

Отдельно проверьте метаданные. В одностраничных приложениях title и description часто подставляются скриптом после загрузки, и в исходном HTML у всех страниц оказывается один и тот же заголовок. В выдаче это выглядит как сайт из сотни одинаковых страниц, а в мессенджерах ссылки теряют превью.

• Просмотр исходного кода: есть ли в нём предложение из основного текста.
• Открыть страницу с отключённым JavaScript — останется ли содержимое.
• Сравнить вид страницы для робота в вебмастере с тем, что видите вы.
• Навигация — настоящие ссылки с адресами, а не обработчики кликов.
• Уникальные title и description должны приходить с сервера, а не подставляться скриптом.

Клиентский рендеринг (CSR) — всё рисуется в браузере. Годится для интерфейсов за авторизацией: личный кабинет, админка, дашборд. Их всё равно не индексируют, зато интерактивность важна.

Статическая генерация (SSG) — страницы собираются заранее, при сборке проекта, и отдаются как готовые файлы. Идеальный вариант для контента, который меняется редко: посадочные страницы, статьи блога, кейсы, документация. Быстро, дёшево, надёжно: сервер отдаёт готовый HTML, ошибиться негде.

Серверный рендеринг (SSR) — страница собирается на сервере в момент запроса. Нужен там, где содержимое зависит от данных, меняющихся постоянно: каталог с ценами и остатками, результаты поиска и фильтрации, персонализированные разделы. Инкрементальная регенерация (ISR) — компромисс: страница статическая, но пересобирается по расписанию или по событию. Это рабочий режим для большого каталога, где полная пересборка при каждом изменении слишком дорога.

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

Спор «SPA против классического сайта» устарел вместе с фреймворками, в которых надо было выбирать один режим на весь проект. Современный подход — гибрид: публичные страницы отдаются с сервера готовыми, а интерактивные части остаются клиентскими компонентами внутри них. Каталог собирается на сервере, а фильтры и корзина работают в браузере; статья статическая, а виджет обратной связи — клиентский.

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

Отдельно про «SEO-плагины» и предварительный рендеринг для роботов. Схема, где боту отдают одну версию страницы, а человеку другую, живёт до первого расхождения содержимого — а расходятся они всегда. Если есть возможность перейти на нормальный серверный рендеринг, костыли с раздачей разных версий лучше не заводить.

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

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

Дальше по порядку: сначала главная и посадочные, потом каталог и карточки, потом блог. Каждый шаг проверяется на реальных страницах — исходный код, метаданные, скорость, статус в вебмастере. Параллельно чинятся сопутствующие вещи, которые в одностраничных приложениях ломаются почти всегда: уникальные title и description, канонические адреса, sitemap.xml с настоящими датами, корректные коды ответов вместо 200 на всё подряд, включая несуществующие адреса.

Заранее договоритесь о критерии успеха: не «стало красивее», а рост числа проиндексированных страниц и появление текста в исходном коде на выбранных шаблонах. Это проверяемо, и по этому же критерию видно, что работа закончена.

• Инвентаризация: какие шаблоны реально нужны в поиске.
• Очередь работ: главная и посадочные → каталог и карточки → блог.
• Личный кабинет и внутренние интерфейсы можно оставить клиентскими.
• Попутно: уникальные метаданные, canonical, sitemap, корректные коды ответов.
• Критерий успеха — рост числа проиндексированных страниц, а не ощущения.

Серверный рендеринг заметно улучшает то, что видит пользователь на медленном интернете и слабом телефоне: содержимое появляется сразу, а не после загрузки и исполнения скриптов. Это напрямую отражается на Core Web Vitals — времени до отрисовки основного содержимого и стабильности вёрстки, — а значит, и на поведенческих показателях.

Второй эффект — корректные превью ссылок. Мессенджеры и соцсети не исполняют скрипты: они читают Open Graph-теги из исходного HTML. У приложения с клиентской подстановкой метаданных все ссылки выглядят одинаково безлико, и это тихо съедает переходы из личных сообщений и чатов, куда ваши же клиенты пересылают страницы друг другу.

Третий — участие в ИИ-ответах. Раз многие краулеры ассистентов не исполняют скрипты, серверный HTML становится условием попадания в цитирование. Это тот случай, когда одно техническое решение закрывает сразу три задачи: обычный поиск, скорость и ИИ-видимость.

• Быстрее появляется содержимое — лучше Core Web Vitals и поведение пользователей.
• Корректные Open Graph-превью в мессенджерах и соцсетях.
• Участие в ИИ-ответах: краулерам ассистентов нужен текст в исходном HTML.
• Меньше зависимость от ошибок скриптов и таймаутов API.