SPA меняет содержимое интерфейса без полной перезагрузки документа при каждом переходе. Это не означает, что первый ответ сервера обязан быть пустым: приложение может сочетать клиентскую навигацию с серверным рендерингом или статической генерацией. Для SEO проверяют фактические URL и содержимое, а не название технологии.
Какие экраны должны находиться в поиске
Составьте список публичных страниц: категории, товары, услуги, статьи. У каждой содержательной страницы должен быть устойчивый адрес, который можно открыть напрямую и передать другому человеку. Состояние раскрытого меню или личной корзины не обязательно превращать в отдельную поисковую страницу.
Для переходов между индексируемыми страницами используйте доступные ссылки с href. Маршруты, основанные только на фрагментах после #, не стоит использовать как основной способ адресации разных страниц для Google. Подробнее — основы JavaScript SEO.
Выбор способа рендеринга
| Подход | Что получает первый запрос | Что оценить |
|---|---|---|
| CSR | Документ, содержимое которого формирует браузер | Доступность скриптов и API, задержку получения текста, ошибки выполнения |
| SSR | HTML, сформированный сервером для запроса | Время ответа, нагрузку, кеширование, дальнейшее подключение интерактивности |
| SSG | Предварительно сформированный HTML | Обновление данных, число маршрутов, процесс сборки |
| Смешанный подход | Разные способы для разных страниц | Согласованность маршрутов, метаданных и данных |
Ни один вариант не гарантирует индексацию. Например, быстрый серверный HTML не поможет, если URL закрыт от обхода, а статическая страница с устаревшими условиями не решит задачу покупателя.
Проверьте исходный HTML и результат выполнения
Для каждого шаблона сравните ответ сервера и отрисованную страницу. Найдите основной заголовок, содержательный текст, ссылки и важные характеристики. Затем повторите проверку при медленном ответе API и ошибке загрузки данных.
Google обрабатывает JavaScript, но загрузка ресурсов и выполнение могут завершаться не так, как в вашей авторизованной сессии. Не скрывайте основное содержание за обязательным кликом или входом, если страница должна быть публичной. Для Яндекса отдельно используйте инструменты проверки рендеринга.
Если исходный HTML содержит noindex, не рассчитывайте, что его удаление скриптом обязательно исправит ситуацию: Google может не выполнять рендеринг такой страницы. Управляйте состоянием индексации последовательно.
Маршруты и HTTP-ответы
Прямое открытие страницы, переход внутри приложения и обновление браузера должны приводить к одному содержанию. Особое внимание — правилу, которое возвращает оболочку приложения для любого URL. Оно может случайно превращать несуществующие страницы в ответы 200.
| Проверка | Ожидаемый результат |
|---|---|
| Существующий публичный URL | Нужная страница с корректным ответом |
| Несуществующий путь | Понятная ошибка и соответствующий статус сервера |
| Постоянно переехавший URL | Подходящий постоянный редирект на содержательную замену |
| Закрытый экран | Проверка доступа без утечки личных данных |
| Назад, вперёд, обновление | Согласованное состояние маршрута и содержимого |
Метаданные и разметка каждого маршрута
Проверяйте title, description и canonical при прямой загрузке и после переходов. Они должны относиться к текущей странице, а не оставаться от предыдущего экрана. Уникальность нужна по смыслу: не добавляйте разные номера к одинаковым описаниям ради формального отличия.
Google может обрабатывать структурированные данные, созданные JavaScript, но нужно проверить доступный ему результат. Сведения в JSON-LD согласуют с видимым содержанием. Для превью ссылок на других площадках проверьте отдельные метаданные и реальное отображение: не все роботы выполняют JavaScript одинаково.
Когда менять архитектуру
Сначала подтвердите проблему: содержимое отсутствует в ответе или рендере, данные зависят от недоступного API, маршруты отдают неверные статусы. Если причина в шаблоне, исправление шаблона может быть достаточным; переписывать весь сайт без диагностики не требуется.
Google рассматривает отдельную выдачу отрисованной версии роботам — dynamic rendering — как обходное решение, а не рекомендуемую долгосрочную архитектуру. Не путайте это со статической генерацией одинаковой страницы для всех. Основание: документация Google.
Контроль после выпуска
Сохраните выборку URL и результаты до изменения. После выпуска повторите прямую загрузку, переходы, ошибки и проверку отрисованного текста. Затем отслеживайте обход и индексацию в системах вебмастеров.
Скорость измеряйте отдельно: SSR может сократить ожидание содержания, но добавлять нагрузку на сервер; тяжёлые скрипты могут по-прежнему мешать отклику. Поисковые результаты оценивают после обработки изменений и с учётом других событий, а не по одному успешному тесту страницы.
Применить к сайту
Для SPA полезно начать с выборки разных маршрутов и сравнения ответа сервера с отрисованным документом. По результату можно определить необходимую доработку без предположений по названию стека.
Вопросы и ответы
React или Vue мешают SEO?
Само название библиотеки не определяет результат. Важны маршруты, содержимое, способы его получения и корректность настроек.
Нужно ли внедрять SSR на каждой странице?
Нет. Способ рендеринга выбирают по задаче, частоте обновлений, инфраструктуре и измеренной проблеме. Закрытый интерфейс и публичный каталог могут иметь разные требования.
Достаточно ли увидеть текст в своём браузере?
Нет. Проверьте прямой неавторизованный запрос и результат в инструментах поисковых систем, а также сценарии ошибки и задержки данных.
Добавить комментарий