Годами в интернете живёт миф: «SPA-приложение нельзя продвигать в поиске, потому что поисковики не видят JavaScript». Разберу, что из этого правда сегодня, а что — устаревшее знание, и как понять, какой вариант архитектуры подходит именно вашему проекту.
Вадим ЛукьянцевFrontend-разработчик, Краснодар · 6 минут на чтение
Что такое SPA и чем он в корне отличается от обычного сайта
SPA (Single Page Application) — это приложение на Vue.js или React, где браузер один раз загружает одну HTML-страницу, а дальше весь контент подгружается и меняется через JavaScript без перезагрузки. Обычный многостраничный сайт устроен иначе: каждый URL — это отдельный html-документ, который сервер отдаёт целиком и сразу.
Для пользователя разница ощущается как отзывчивость интерфейса — переходы происходят мгновенно, без белого экрана перезагрузки. Для поисковика разница куда практичнее: важно, что именно приходит по сети в первом ответе сервера — готовый текст страницы или пустой html-каркас, который ещё предстоит «дорисовать» через JavaScript.
Откуда взялся миф «SPA не индексируется»
Миф не на пустом месте: несколько лет назад поисковые роботы действительно не умели выполнять JavaScript и видели SPA-страницу как пустой контейнер без текста. Сегодня Google обрабатывает JS-страницы в два прохода: сначала забирает исходный html, а затем — с задержкой от нескольких дней до пары недель — рендерит страницу headless-браузером, чтобы увидеть итоговый контент.
Технически SPA индексируется, но не мгновенно и не гарантированно с первого захода робота.
Как это работает на практике сегодня
У Google второй проход рендеринга работает стабильно, хотя и с задержкой. У Яндекса ситуация менее предсказуема: рендеринг JS-контента исторически слабее и медленнее, чем у Google, и для проектов, где основной трафик — из Яндекса, полагаться только на клиентский рендеринг рискованно.
Важно: если SPA отдаёт контент только через клиентский JavaScript (CSR) без серверного рендеринга или пре-рендеринга, а сайт при этом рассчитывает на органический трафик из Яндекса — это реальный риск неполной или запоздалой индексации, а не гипотетическая проблема.
SSR и пре-рендеринг — как решается проблема индексации
Решение — серверный рендеринг (SSR): сервер сразу генерирует готовый html с содержимым внутри, а JavaScript затем «оживляет» интерактивность поверх уже видимого контента (это называется гидратацией). Для Vue.js это делает Nuxt.js, для React — Next.js, оба фреймворка включают SSR из коробки.
На проекте сайта Большого театра России мы выбрали именно Nuxt.js, а не «чистый» Vue-SPA — сознательно, из-за требований по индексации. Это федеральный сайт с большим объёмом исторического и каталожного контента (труппа, репертуар, архив), и весь этот контент должен был гарантированно попадать в поиск, а не зависеть от того, дождётся ли робот второго прохода рендеринга.
Выбор фреймворка здесь — не вкусовщина, а прямое следствие требований по индексации конкретного проекта.
Когда SPA реально вредит SEO
Риск реален в двух ситуациях. Первая — чистый CSR без SSR или пре-рендеринга у проекта с множеством контентных страниц (блог, каталог, статьи), который рассчитывает на органический поиск как основной канал трафика. Вторая — тяжёлый JS-бандл, из-за которого страдает скорость первой отрисовки: это напрямую бьёт по Core Web Vitals, а они — фактор ранжирования и у Google, и у Яндекса.
Когда SPA — оправданный выбор, даже с этим компромиссом
Не любому проекту вообще нужна органика. Личный кабинет, CRM, админ-панель, внутренний корпоративный инструмент — весь этот контент закрыт авторизацией и никогда не должен попадать в поиск, так что вопрос индексации там просто не стоит. То же самое для продуктов, где основной трафик идёт из рекламы, соцсетей или прямых заходов по бренду, а не из органической выдачи — там чистый SPA без SSR полностью оправдан.
Как проверить, что ваш SPA сейчас нормально индексируется
Быстрая самопроверка без специальных инструментов: отключите JavaScript в браузере (расширение или настройки) и откройте страницу — если основной текст не виден вообще, робот в худшем случае видит то же самое. Дальше стоит сравнить количество страниц сайта с количеством проиндексированных через оператор site: в Яндексе и Google, и проверить конкретные url через «Проверку страниц» в Яндекс.Вебмастере или Google Search Console — они показывают, что именно робот увидел при рендеринге.
Если нужна не самопроверка, а технический разбор конкретного сайта на скрытые проблемы индексации — смотрите условия SEO-аудита.
Планируете SPA-приложение и хотите, чтобы оно нормально индексировалось?
Оценю архитектуру проекта и скажу, нужен ли SSR/пре-рендеринг именно в вашем случае, или можно обойтись без него.
Правда ли, что Google вообще не видит SPA? Нет, это устаревшее представление. Google обрабатывает JS-страницы в два прохода и в итоге видит отрендеренный контент, но с задержкой от нескольких дней до пары недель против мгновенной индексации обычного html.
А как обстоят дела с Яндексом? Хуже и менее предсказуемо, чем у Google: рендеринг JS-контента у Яндекса исторически слабее. Для проектов, где Яндекс — основной источник органического трафика, SSR или пре-рендеринг стоит закладывать сразу, а не «на будущее».
Обязательно ли делать SSR для любого SPA-проекта? Нет. Если у проекта нет контентных страниц, зависящих от органического поиска (личный кабинет, внутренний инструмент, продукт с трафиком из рекламы или бренда), SSR — не обязательная трата бюджета.
Можно ли добавить SSR к уже готовому SPA задним числом? Технически можно, но на практике это обычно не косметическая правка, а частичный переезд на Nuxt.js/Next.js с пересмотром роутинга и логики загрузки данных — по объёму работ ближе к переработке архитектуры, чем к доработке.
Вадим ЛукьянцевОб авторе — нажмите, чтобы раскрыть
Веб-разработчик, Краснодар. Делаю сайты под ключ на Vue/Nuxt и React/Next, вёрстку по макетам из Figma и PSD, сайты на WordPress и SEO-продвижение — сам, без субподрядчиков.
Работаю с 2GIS, Яндекс.Бизнесом, самозанятость оформлена официально с 2024 года. С клиентами по всему Краснодарскому краю и удалённо по России.
