SEO для сайтов на JavaScript: как не потерять индексацию

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

Разберём, как поисковики обрабатывают JS-сайты и какие ошибки чаще всего стоят трафика.

Как поисковики индексируют сайты на JavaScript?

Поисковики индексируют JS-сайты в два этапа: сначала получают HTML от сервера и индексируют то, что в нём есть, а затем, если хватает ресурсов, выполняют JavaScript и дополняют картину. Между этапами может пройти время, а часть роботов второй этап пропускает совсем.

Что это значит на практике:

• если основной текст есть только после выполнения JS, индексация откладывается или неполная;
• ссылки, которые появляются после клика или прокрутки, робот может не найти;
• метатеги, выставленные скриптом, не всегда учитываются;
• боты, собирающие данные для AI-ассистентов, часто не выполняют JavaScript вовсе.

Поэтому правило простое: всё, что должно попасть в поиск, должно быть в HTML-ответе сервера.

Какой способ рендеринга выбрать?

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

Способ	Как работает	Подходит для
CSR (рендеринг в браузере)	Сервер отдаёт пустой шаблон, страницу собирает JS	Личные кабинеты, админки — то, что не индексируется
SSR (серверный рендеринг)	HTML собирается на сервере при запросе	Каталоги, карточки товаров, часто меняющийся контент
SSG (статическая генерация)	HTML собирается при сборке	Лендинги, документация, редко меняющиеся страницы
ISR / SWR	Статика, которая обновляется по расписанию или в фоне	Блоги, каталоги с умеренной частотой изменений

Подробнее о том, как SSR устроен в Nuxt, — в статье SSR в Nuxt и SEO, а о выборе фреймворка — в статье Nuxt или Next.js.

Фото: Unsplash

Какие ошибки в JS-приложении мешают индексации?

Индексации мешают не только отсутствие серверного рендеринга, но и ошибки в самом приложении: адреса с решёткой, ссылки-кнопки, «мягкие» 404 и контент, который загружается только при прокрутке. Их можно допустить даже в приложении с SSR.

Адреса и ссылки

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

<!-- Плохо: робот не увидит перехода -->
<span @click="router.push('/catalog/shoes')">Обувь</span>

<!-- Хорошо: обычная ссылка, роутер перехватит клик сам -->
<a href="/catalog/shoes">Обувь</a>

В Vue и React для этого есть компоненты RouterLink, NuxtLink и Link — они рендерят настоящий <a href>.

Коды ответов и «мягкие» 404

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

Контент при прокрутке

Бесконечная лента без обычной пагинации прячет от робота всё, что ниже первой порции. Решение — пагинация с отдельными адресами страниц (?page=2) и ссылками на них, а бесконечная прокрутка — поверх неё, для удобства пользователя.

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

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

Быстрая проверка из терминала:

# Есть ли заголовок и текст статьи в ответе сервера?
curl -s https://example.com/blog/some-article | grep -o '<h1[^>]*>.*</h1>'

Что ещё проверить:

1. title, description, canonical и hreflang — в ответе сервера, а не только после выполнения JS.
2. Несуществующий адрес возвращает код 404.
3. Карта сайта содержит все публичные страницы.
4. В инструменте проверки URL в Google Search Console отрендеренная страница совпадает с тем, что видит пользователь.

Когда JS-сайту всё-таки не нужен SSR?

SSR не нужен разделам, которые не должны попадать в поиск: личным кабинетам, админкам, внутренним инструментам и шагам оформления заказа. Для них обычное одностраничное приложение проще, дешевле в хостинге и не создаёт нагрузки на сервер.

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

Коротко

• Всё, что должно попасть в поиск, должно быть в HTML-ответе сервера, а не появляться после JavaScript.
• Для публичных страниц выбирайте SSR или статическую генерацию, для закрытых разделов достаточно CSR.
• Используйте адреса без решётки, настоящие ссылки <a href> и пагинацию с отдельными адресами.
• Отдавайте настоящие коды 404 и 301 вместо «мягких» ошибок.
• Проверяйте сырой HTML через curl и инструмент проверки URL в панели вебмастера.