SEO одностраничных приложений: как добиться индексации SPA в Google и чтения его AI

SEO одностраничных приложений это набор приемов, которые делают приложение на JavaScript, написанное на React, Vue, Angular или Svelte, таким же простым для сканирования, как классический сайт. Проблема хорошо задокументирована: в своих основах JavaScript SEO Google объясняет, что обрабатывает страницы на JavaScript в три этапа (сканирование, рендеринг, индексация), и каждая слабость SPA находится где-то в этом конвейере. Это руководство посвящено SPA, а о JavaScript-сайтах в целом читайте наше руководство по JavaScript SEO.

Что такое одностраничное приложение и почему его трудно оптимизировать для SEO?

Традиционный сайт возвращает полный HTML-документ для каждого URL. SPA возвращает почти один и тот же документ для каждого URL: пустой <div id="root">, несколько мета-тегов и большой пакет JavaScript. Браузер загружает пакет, обращается к API, а затем рисует страницу. Когда посетитель нажимает ссылку, JavaScript подменяет контент без перезагрузки.

Для человека с быстрым телефоном результат ощущается мгновенным. Для краулера первый ответ это пустая оболочка: ни заголовка, ни текста, ни ссылок. Все зависит от того, выполняет ли бот JavaScript и когда. Этот единственный факт объясняет большинство проблем SEO у SPA:

• Отложенный или отсутствующий контент: текст появляется только после рендеринга, который Google выполняет позже, а другие боты пропускают.
• Один URL на множество представлений: старые SPA используют маршрутизацию через фрагменты (/#/pricing), а часть после # никогда не отправляется на сервер, поэтому все представления сливаются в один URL.
• Одинаковые title и описания: оболочка несет один <title>, и если маршрутизатор его не обновляет, он общий для всех страниц.
• Ссылки без href: кнопки и обработчики onClick переходят для пользователей, но не дают краулерам ничего, по чему можно идти.
• Мягкие ошибки 404: сервер отвечает 200 на любой путь, включая несуществующие страницы, поэтому представления ошибок индексируются как тонкие страницы.
• Тяжелый JavaScript: большие пакеты замедляют первое отображение и взаимодействия, что вредит Core Web Vitals.

Как Google сканирует и рендерит SPA?

Googlebot сначала загружает необработанный HTML и читает найденные там ссылки и директивы. Страницы со статусом 200 затем попадают в очередь Web Rendering Service, то есть headless Chromium. Google заявляет, что страница «может оставаться в этой очереди несколько секунд, но может и дольше». После рендеринга полученный HTML снова разбирается на предмет контента и ссылок, а затем индексируется.

Четыре детали из документации Google важны для SPA:

1. Надежными ссылками считаются только элементы <a> с href. Ссылки, добавленные через JavaScript, подходят, если они соответствуют этому формату.
2. Фрагменты не являются отдельными страницами. Google просит использовать History API (pushState) вместо маршрутов с #. Старую схему сканирования AJAX (URL с #!) он признал устаревшей в октябре 2015 года.
3. Тег noindex в исходном HTML имеет приоритет. Google может пропустить рендеринг, увидев noindex, поэтому последующее удаление тега через JavaScript не работает.
4. Рендеринг использует кэшированные файлы. Googlebot агрессивно кэширует JavaScript и CSS, поэтому используйте имена файлов с отпечатком (хэш содержимого в имени файла), чтобы избежать устаревших пакетов.

Практический вывод: Google может проиндексировать SPA с клиентским рендерингом, но вы добавляете для каждой страницы второй шаг, задержку и точку отказа. Тайм-аут, заблокированный вызов API или ошибка JavaScript во время рендеринга оставляют проиндексированную версию пустой. Проверьте, что видит Google, с помощью инструмента проверки URL в Search Console и прочитайте наше руководство о том, как работает индексация Google, если страницы остаются вне индекса.

Читают ли ChatGPT, Claude и Perplexity JavaScript?

В основном нет. В исследовании, опубликованном в декабре 2024 года по трафику своей сети, Vercel и MERJ обнаружили, что «ни один из крупных AI-краулеров сейчас не рендерит JavaScript»: GPTBot, OAI-SearchBot и ChatGPT-User (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Meta-ExternalAgent и Bytespider читают только необработанный HTML. Они действительно загружают файлы JavaScript (около 11.5% запросов ChatGPT и 23.8% запросов Claude), но не выполняют их. Исключения это Gemini, который опирается на инфраструктуру рендеринга Google, и AppleBot, использующий краулер на основе браузера.

Для SPA с клиентским рендерингом это означает, что AI-краулеры, питающие ChatGPT, Claude и Perplexity, видят пустую страницу. Ваш продукт может ранжироваться в Google и все равно оставаться невидимым в ответах AI, потому что ассистент не прочитал о нем ни слова. То же относится к большинству ботов предпросмотра ссылок в социальных сетях и мессенджерах, которые читают теги Open Graph в необработанном HTML. Когда контент окажется в HTML, проверьте также, что ваш robots.txt разрешает нужные AI-краулеры.

Какую стратегию рендеринга должно использовать SPA?

Решение: отправлять настоящий HTML в первом ответе. В своей документации по динамическому рендерингу Google называет динамический рендеринг (выдачу предварительно отрендеренной версии только ботам) «обходным путем, а не рекомендуемым решением» и указывает вместо него на серверный рендеринг, статический рендеринг или гидратацию. Определения ниже следуют справочнику Rendering on the Web на web.dev.

Большинство современных фреймворков позволяют смешивать стратегии по маршрутам: статика для маркетинговых страниц, серверный рендеринг для каталога, клиентский рендеринг для приложения после авторизации. Такая гибридная схема дает краулерам полный HTML там, где приходит поисковый трафик, и сохраняет опыт SPA там, где он приносит пользу.

Варианты фреймворков

Сайты, созданные AI-конструкторами сайтов, заслуживают особого упоминания: многие из них экспортируют приложение на React с клиентским рендерингом. Если вы построили сайт с помощью такого конструктора, прочитайте наши заметки о SEO и GEO для Lovable, прежде чем считать, что Google и ChatGPT смогут его прочитать.

Чек-лист SEO для SPA: что исправлять по маршрутам

1. Дайте каждому представлению чистый URL, доступный для сканирования

Используйте History API (/pricing, никогда не /#/pricing), один URL на единицу контента и один и тот же URL, независимо от того, приходит ли посетитель напрямую или через навигацию внутри приложения. Каждый URL должен загружать правильный контент при открытии в новой вкладке: именно такой тест проводит краулер.

2. Используйте настоящие ссылки

Каждый элемент навигации, ведущий на индексируемую страницу, должен быть <a href="/path">. Компоненты ссылок фреймворков (Link, NuxtLink, routerLink) выдают такую разметку, а собственные обработчики кликов на элементах div или button нет. Хорошие ссылки также несут архитектуру вашего сайта: если на страницу нет ссылок, краулеры редко ее находят.

3. Обновляйте title, описание и canonical для каждого маршрута

Каждому маршруту нужны собственные title, мета-описание, canonical и теги Open Graph, по возможности генерируемые на сервере. Наша страница о мета-тегах перечисляет, что нужно задать. Оставляйте один канонический тег: Google рекомендует задавать его в HTML, а если JavaScript его меняет, результат не должен противоречить исходному.

4. Возвращайте честные коды статуса

Отсутствующие товары и удаленные статьи не должны отвечать 200 с сообщением об ошибке. При SSR возвращайте настоящий 404 или 410 с сервера. В чистом SPA Google допускает два запасных варианта: перенаправить с помощью JavaScript на URL, возвращающий 404, или добавить в представление ошибки мета-тег robots с noindex.

5. Размещайте основной контент и структурированные данные в HTML

Заголовки, основной текст, цены, FAQ и структурированные данные JSON-LD должны быть в ответе сервера, а не загружаться после клика или прокрутки. Контент во вкладках, которые рендерятся по требованию, или за кнопками «показать еще» часто пропускается.

6. Держите JavaScript легким

Разделяйте пакет по маршрутам, откладывайте то, что не нужно для первого представления, и избегайте повторного рендеринга всей страницы во время гидратации. Учтите, что полевые данные Chrome (CrUX) относят метрики переходов внутри приложения к URL, который посетитель загрузил первым, поэтому тестируйте свои ключевые шаблоны по отдельности.

7. Проверяйте, что получают боты

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

Как понять, что у вашего SPA есть проблема с SEO?

SEO для SPA и GEO: быть найденным в Google и процитированным AI

Годами клиентский рендеринг был управляемым риском, потому что Google в конце концов рендерил JavaScript. Теперь, когда часть поиска происходит в ChatGPT, Claude, Gemini и Perplexity, цена изменилась: страница, существующая только после выполнения JavaScript, отсутствует в источниках, которые способно прочитать большинство ассистентов. Доступность для сканирования в необработанном HTML стала первым условием оптимизации для генеративных движков.

Когда HTML становится полным, остальное подчиняется обычным правилам: ассистенты цитируют страницы, которые четко отвечают на один вопрос, с проверяемыми фактами и структурированными данными. Функции GEO-оптимизации Sorank помогают писать и публиковать такой контент, а отслеживание упоминаний в ИИ показывает, цитируют ли ChatGPT, Claude и Gemini ваш бренд после исправления рендеринга.

Главное правило SEO одностраничных приложений умещается в одно предложение: все, что вы хотите видеть в ранжировании Google и в цитатах AI, должно быть в HTML, который отправляет сервер. Оставьте SPA для опыта после авторизации, рендерите публичные страницы на сервере или на этапе сборки, а затем проверяйте, что получают боты, до и после каждого релиза.