JavaScript-сайт в поиске: что увидит робот до того, как выполнится интерфейс

Начните с маршрутов, а не с технологии

Ошибочный порядок выглядит так: сначала выбрать SSR, SSG или пререндеринг как общую идеологию, а потом искать, что с ней делать. Рабочий порядок обратный. Сначала разделите маршруты по бизнес-роли: какие приводят органический спрос, какие объясняют услугу, какие помогают навигации, а какие существуют только внутри личного кабинета или интерфейса.

У страницы, которая должна участвовать в поиске, есть минимальный набор: понятный URL, ответ сервера, заголовок, основной текст, ссылки на следующие документы, canonical и индексируемое состояние. Интерфейс вокруг этого набора может быть динамичным. Но если смысл услуги появляется только после клика по вкладке, бесконечной прокрутки или ответа стороннего API, его нельзя считать доступным только потому, что пользователь увидит его в своем браузере.

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

Что робот видит до и после выполнения JavaScript

Первый ответ сервера и итог после выполнения скриптов - разные контрольные точки. В первом может быть уже готовая страница, а может быть только каркас. Во втором браузероподобный рендерер может собрать больше содержания, но и здесь важны ресурсы, время, ошибки запросов и сценарий загрузки.

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

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

Выберите модель рендеринга для задачи страницы

SSR, SSG, пререндеринг и CSR - не четыре уровня качества. Это способы распределить работу между сервером, сборкой и браузером. У каждой модели есть сильная зона, а решение зависит от частоты изменений, количества маршрутов, требований к скорости ответа и того, насколько страница важна для поискового входа.

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

Яндекс дает отдельное управление рендерингом JavaScript в Вебмастере. Оно может быть полезно, если на сайте нет SSR или пререндеринга; при SSR или пререндеринге сама справка Яндекса советует отключить выполнение JavaScript для робота. Там же описан сценарий для контента с задержкой загрузки через window.YandexRotorSetting. Эти настройки следует применять после диагностики конкретного шаблона, а не как универсальную замену архитектуре. Детали доступны в справке Яндекс Вебмастера.

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

Не прячьте важный контент за действием пользователя

Отложенная загрузка полезна для скорости и удобства, особенно для изображений и тяжелых блоков. Но контент, который появляется только после прокрутки, клика по кнопке «показать еще» или выбора в интерфейсе, требует отдельной проверки. Google указывает, что поисковый робот не взаимодействует со страницей как пользователь: для поискового содержимого не стоит рассчитывать на клик или ручной скролл. Руководство по lazy loading советует загружать релевантное содержимое, когда оно находится в области просмотра, а не только после действия человека.

Здесь важно не превратить задачу в запрет на интерактивность. Динамическая форма, калькулятор или вкладка могут оставаться частью опыта. Вопрос в другом: сможет ли человек и робот понять тему страницы, ее предложение и следующий маршрут без этого сценария. Если ответ отрицательный, сначала верните основной смысл в страницу, а потом улучшайте взаимодействие.

Согласуйте SEO, разработку и контент до релиза

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

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

Хорошая приемка не просит у команды один скриншот и не заканчивается словом «задеплоено». Я бы зафиксировал контрольную выборку маршрутов, ожидаемые блоки и дату проверки в поисковых инструментах. Так изменение можно признать завершенным по факту доступного содержания, а не по количеству закрытых задач.

Проверяйте результат по контрольной выборке

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

Страница может быть корректной в исходном HTML и все равно не появляться в поиске по другой причине: например, из-за robots, canonical, ответа сервера или дубля. Тогда не стоит продолжать спорить о JavaScript. Перейдите к диагностике индексирования и ведите один URL по его фактическому статусу.

Готовность JavaScript-шаблона подтверждается не тем, что он «отрисовался», а тем, что важное содержание стабильно проходит путь от URL до поисковой проверки.

Один следующий шаг для команды

Не начинайте с миграции всего сайта. Выберите один приоритетный тип страницы, где органический спрос уже есть или планируется: например, услуги или экспертные материалы. Сделайте карту из пяти-десяти URL, отметьте обязательный контент, посмотрите первый ответ и рендеринг, а затем сформулируйте одну задачу с владельцем и критерием приемки.

Перед каждым релизом поискового шаблона сверяйте HTML, рендеринговый результат и контрольный URL в поисковых панелях. Эта короткая привычка полезнее разовой «SEO-проверки JavaScript»: она ловит расхождения до того, как одинаковая ошибка появится на десятках страниц.