Маршрутизация spa seo

Почему классический сайт и одностраничное приложение видны поисковым системам по-разному

На обычном сайте каждая страница — это отдельный HTML файл на сервере. Когда пользователь переходит по ссылке, сервер отправляет готовый документ с контентом, структурой и мета-тегами. Google и Яндекс получают полную информацию о странице при первом запросе. Это просто: робот скачивает HTML, видит содержание, индексирует, всё работает.

В одностраничном приложении всё по-другому. Вся разработка SPA построена на том, что браузер скачивает один index.html, а затем JavaScript динамически обновляет интерфейса и содержание без полной перезагрузки. Когда пользователь нажимает кнопку «Перейти в блог», JavaScript просто меняет состояния приложения в браузере. На сервер запроса не идёт.

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

History API, hash-mode и почему это критично для SEO

Маршрутизация зависит от режима, который вы выбрали. Есть два основных подхода.

Hash-mode (маршруты с решёткой):

example.com/#/blog example.com/#/products/item-123

Google долгое время игнорировал всё после #. Для поисковых систем это всё один URL — главная страница. Если вы не настроите специальные условия через Search Console, отдельные URL вашего приложения не попадут в индекс. При этом пользователь в браузере видит разные страницы, навигация работает, JavaScript переводит состояния приложения. Но Search Console покажет, что у вас всего одна страница. Трафик потерян.

History mode (настоящие URL без решётки):

example.com/blog example.com/products/item-123

Это выглядит как обычный сайт. React Router, Vue Router и другие фреймворки с History API могут работать в этом режиме. History API позволяет JavaScript менять адреса в браузере, не перезагружая страницу.

Проблема в том, что когда Google отправляет запроса на example.com/blog, сервер должен отдать index.html для всех маршрутов. Без правильной настройки сервер вернёт 404. Роботу кажется, что этой страницы не существует. История API помогает, но нужна серверная обработка — все запросы должны возвращать основной index.html, а затем JavaScript определит, какой маршрут загружать.

Почему поисковые роботы пропускают важные страницы SPA

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

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

Для сравнения: обычный блог на WordPress отдаёт готовый HTML со всеми ссылками на статьи. Google видит их сразу, индексирует и ранжирует. В SPA эту работу должны делать вы — настраивать серверный рендеринг или добавлять данные в на page load.

Дублирование контента и проблемы структуры URL

Ещё одна подводная камня — неправильная структура адресов. Компании часто делают ошибки типа:

• example.com/products и example.com/#/products работают параллельно — два URL с одинаковым контентом
• Один и тот же товар доступен через разные маршруты: /item/123 и /products/123
• Параметры в адресе меняются, но контент один — например, фильтры в e-commerce

Google видит несколько версий одной страницы, не знает, какую индексировать. Это дублирование контента. Пусть даже небольшое, оно снижает ваши позиции. Каждый URL требует ресурсов на индексацию. Если половина ресурсов потрачена на дубли, трафик упадёт.

Как Google на самом деле обрабатывает маршруты SPA

Сам Google эволюционировал. С 2014 года поисковик старается выполнять JavaScript и видеть динамически загруженный контент. Но это не означает, что он всегда справляется идеально.

Когда робот Google получает страницу SPA, он: 1. Скачивает пустой HTML 2. Ждёт загрузки JavaScript 3. Выполняет код в браузере (как настоящий пользователь) 4. Смотрит финальный DOM и индексирует то, что видит

Звучит хорошо, но есть нюансы. Google не дождётся асинхронные запросы от API бесконечно. Если ваше приложение загружает данные медленнее, чем ожидает Google, часть контента не попадёт в индекс. Яндекс обрабатывает JavaScript ещё с более строгими условиями.

Вот почему разработчики часто говорят: «Мы настроили маршрутизацию, всё работает в браузере». А маркетинг видит: трафик упал вдвое. Проблема именно в том, что для человека SPA работает отлично, а для поисковых систем всё сломано.

Частые ошибки при настройке маршрутизации SPA

Вот что часто упускают даже опытные разработчики:

Ошибка 1. Забыли настроить сервер для History mode. Сервер возвращает 404 для всех маршрутов кроме главной. React Router, Vue Router и Angular routing показывают, что всё работает в браузере пользователя, но робот получает ошибку. Проверить это можно вручную: откройте адресную строку, вставьте example.com/products/123 и обновите страницу. Если вместо товара видите 404 — вот и первая ошибка.

Ошибка 2. Никакой обработки данных на сервере. Когда Google выполняет JavaScript вашего приложения, он может не получить данные для наполнения страницы. Если товары загружаются через API запроса (асинхронно), Google может не дождаться ответа. На странице останется только пустой HTML вместо контента. Решение: используйте SSR (server-side rendering) или статический рендеринг, где на сервере генерируется готовый HTML с контентом.

Ошибка 3. Проблемы с мета-тегами. Каждая страница должна иметь свой title, description, og:image. В обычном сайте это просто — каждый файл имеет нужные теги. В SPA нужно динамически обновлять мета-теги в зависимости от маршрута. Если забыли это сделать, у всех страниц один и тот же title. Google ранжирует их как одну страницу. Трафик идёт на главную, остальные почти не видны.

Ошибка 4. Внутренние ссылки на JavaScript-ом, а не через href. Вместо <a href="/products"> написали <button onClick={() => navigate('/products')}>. Робот не видит обычную ссылку и может не переходить на эту страницу. Даже если переходит, без rel-атрибутов и правильной структуры навигации индексация затруднена.

Ошибка 5. Загрузка контента бесконечным скроллом. На первый взгляд удобно для пользователя. Но Google не скроллит и не кликает. Он видит только первые элементы. Если важные страницы появляются дальше — они не попадут в индекс. Для SEO лучше использовать пагинацию со ссылками на каждый отдельные URL — example.com/products?page=2.

Как настроить маршрутизацию SPA правильно

Есть несколько проверенных подходов:

Вариант 1: Server-Side Rendering (SSR). На сервере генерируется готовый HTML с контентом для каждого маршрута. Когда Google запрашивает /blog, сервер отдаёт полную страницу с контентом и мета-тегами. Пользователь сразу видит быстро загруженную страницу. JavaScript затем подгружается и конвертирует приложение в интерактивное. Это работает идеально для SEO. Но требует мощный сервер и сложнее в разработке.

Фреймворки, которые помогают: Next.js (для React), Nuxt (для Vue), Angular Universal. Все они позволяют настроить SSR без лишних сложностей.

Вариант 2: Static Site Generation (SSG). Вы заранее генерируете все HTML страницы вашего приложения и загружаете на сервер as static files. Когда Google запрашивает страницу, ему отдаётся готовый файл. Это очень быстро. Но подходит только если контент не меняется часто — например, для блога или портфолио. Для e-commerce с тысячами товаров придётся регенерировать множество файлов.

Вариант 3: Динамический рендеринг. Сервис вроде Google Web Light или Prerender.io заранее отрендеривает страницы приложения и отдаёт готовый HTML роботам, а пользователям отправляет обычное SPA. Это компромисс: не нужно менять серверную архитектуру, но нужно доплачивать за сервис и синхронизировать данные.

Вариант 4: Правильная настройка Hash mode. Если по каким-то причинам вы не можете уйти с hash-режима, нужна специальная подготовка для Google. Через Search Console добавьте параметр, что вы используете Ajax crawling. Google будет обрабатывать # как separator и пытаться индексировать отдельные URL. Но это работает хуже, чем История API с SSR.

FAQ: Вопросы, которые задают разработчики и маркетеры

Почему Google не индексирует все URL в моем SPA?

Скорее всего, приложение использует hash-mode без специальной подготовки, или JavaScript загружает контент медленнее, чем Google готов ждать. Проверьте в Google Search Console, какие страницы индексированы. Часто там видна только главная. Решение: переходите на History mode с SSR, или используйте статический рендеринг, или настраивайте динамический рендеринг.

Что такое История API и как она влияет на SEO?

History API — это JavaScript interface, который позволяет менять адрес в браузере без перезагрузки страницы. Когда вы нажимаете кнопку в SPA, приложение вызывает history.pushState(), адрес меняется, и вы видите новый URL. Для SEO это означает, что Google может видеть разные маршруты как отдельные страницы. Но при условии, что сервер правильно обслуживает эти адреса и отправляет нужный контент.

Какая разница между hash-mode и history mode?

Hash-mode использует # в адресе: example.com/#/products. Всё после # это фрагмент, и Google долгое время их игнорировал. History mode без #: example.com/products. Выглядит как обычный сайт. Google индексирует как обычный URL. History mode работает через История API и требует правильной настройки сервера.

Нужен ли мне SSR, если я использую History mode?

Желательно. History mode позволяет Google видеть URL, но не гарантирует, что он получит контент. Без SSR сервер отправляет только пустой HTML, а контент загружается JavaScript. Если загрузка медленная, Google может не получить информацию для индексации. SSR гарантирует, что каждый маршрут отправляет готовый HTML с контентом. Это лучше для SEO и для скорости загрузки. Пользователи получают контент быстрее, а поисковые роботы видят полные страницы.

Как я узнаю, что мой SPA правильно индексируется?

Используйте Google Search Console. Посмотрите coverage report — там видно, какие страницы проиндексированы. Если вместо 100 страниц продукта индексирована только главная, вот проблема. Проверьте в «URL inspection», как Google видит конкретный маршрут. Часто там показывается пустой HTML с сообщением об ошибке. Второе — в Google Chrome DevTools запустите lighthouse и проверьте, видит ли он контент на ваших страницах. Третье — вручную откройте сайт с выключенным JavaScript и посмотрите, есть ли там контент. Если без JavaScript только пустая страница, то Google тоже может не получить контент.

React Router vs Vue Router — с какого лучше начать для SEO?

Технически оба работают одинаково. Выбирайте, какой фреймворк вам нравится. Для SEO важно не выбор роутерулятора, а что вы делаете на сервер. Добавьте SSR (Next.js для React, Nuxt для Vue), и оба варианта будут работать прекрасно. А вот если вызовете Router без SSR, оба будут иметь одинаковые проблемы. Вывод: не маршрутизатор решает, а архитектура приложения и серверная часть.