Серверный рендеринг и SEO: почему сайт на JavaScript может плохо индексироваться

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

Разберём, как это работает и какой подход выбрать для сайта, который должен приносить трафик из поиска.

Два способа сформировать страницу

Серверный рендеринг (SSR)

Сервер формирует готовый HTML с текстом, заголовками, ссылками и метатегами и отправляет его браузеру. Браузер сразу показывает содержимое, а JavaScript добавляет интерактивность — меню, формы, анимации.

Так работают классические сайты на PHP-фреймворках, в том числе на Laravel, и большинство CMS.

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

Сервер отдаёт минимальный HTML-каркас и JavaScript-приложение. Содержимое строится в браузере после загрузки и выполнения скриптов и запросов к API.

Так работают одностраничные приложения на популярных JavaScript-библиотеках, если их не дополнять серверным рендерингом.

Как поисковые системы обрабатывают JavaScript

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

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

Типичные проблемы JavaScript-сайтов

• пустой исходный HTML: текст и заголовки появляются только после выполнения скриптов;
• одинаковые метатеги: title и description меняются скриптом, и поисковик может видеть один и тот же заголовок на всех страницах;
• ссылки без адресов: переходы реализованы через обработчики кликов, а не обычные ссылки, и робот не может их обнаружить;
• адреса с решёткой: разделы вида /#/services — для поисковика это одна страница;
• медленная первая загрузка: пользователь видит пустой экран, пока скачивается и выполняется приложение, что ухудшает LCP;
• ошибки 404, которые отдают код 200: приложение показывает «страница не найдена», но сервер отвечает, что всё в порядке.

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

• Откройте исходный код страницы (не инструменты разработчика, а именно «Просмотр кода страницы»). Есть ли там текст статьи или описания услуги? Если в исходнике только пустой контейнер и скрипты — контент формируется на клиенте.
• Отключите JavaScript в браузере и обновите страницу. Что осталось?
• Проверка URL в Search Console покажет, как Google видит отрисованную страницу.
• Проверка ответа сервера в Яндекс.Вебмастере покажет исходный HTML.

Что выбрать для сайта компании

Для сайтов, которые должны приводить клиентов из поиска, — корпоративных сайтов, страниц услуг, блогов, каталогов — надёжнее серверный рендеринг:

• контент сразу доступен поисковикам;
• страница быстро отображается, особенно на слабых телефонах;
• проще управлять метатегами, canonical, микроразметкой;
• статус ответа сервера корректный: 200, 301, 404.

Интерактивность при этом никуда не девается: JavaScript используется для того, что действительно требует динамики, — квизов, фильтров, калькуляторов, форм.

Когда клиентский рендеринг уместен

• закрытые части сайта, которые не нужно индексировать: личные кабинеты, админ-панели, внутренние сервисы;
• сложные интерактивные инструменты, где важна скорость реакции интерфейса.

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

Влияние на скорость и Core Web Vitals

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

Как это устроено у меня

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

Итог

Серверный рендеринг — надёжная основа для SEO: поисковики сразу видят контент, страницы быстрее открываются, а технические настройки проще контролировать. Если ваш сайт построен как JavaScript-приложение и плохо индексируется, проверьте исходный HTML страниц — проблема может быть именно в этом. Подробнее о технологиях — в статье почему Laravel. Я разрабатываю быстрые сайты с серверным рендерингом — подробнее на страницах корпоративных сайтов и веб-систем. Оставьте заявку — проверю, как поисковики видят ваш сайт.