Для SEO-проверки одностраничного приложения сравните каждый важный маршрут при прямом открытии и при переходе внутри сайта. Запишите ответ сервера, содержимое и метаданные, а затем отдельно проверьте отсутствующий адрес. SPA может иметь много самостоятельных URL: отсутствие полной перезагрузки при переходе не делает их одной поисковой страницей.
Проверка нужна не только для ответа «работает ли JavaScript». Маршрут может открываться правильно из меню, но после обновления страницы показывать пустую оболочку. Бывает и обратная ситуация: товар виден, а после перехода остаются title и canonical предыдущей категории. Результаты браузера и фактическую индексацию Google проверяют отдельно.
Составьте инвентарь маршрутов и ожидаемых ответов
Возьмите из CMS, каталога, внутренних ссылок и карты сайта адреса, которые должны открываться посетителю. Отметьте тип страницы, язык, основной контент, целевой URL и допустимые параметры. Включите категорию, товар, страницу без товара и несколько пограничных состояний: пагинацию, выбранный вариант или фильтр, если приложение создаёт для них отдельные адреса.
Разделите публичные страницы и закрытые действия. Корзину и личный кабинет не нужно считать поисковыми посадочными только потому, что у них есть маршрут. Для каждого публичного адреса запишите, что ожидается увидеть при прямом входе, какой переход ведёт к нему из приложения и какие метаданные должны соответствовать содержимому.
Рассмотрим условный магазин. Его /catalog/ показывает список товаров, /product/item/ – карточку, а /missing/ не существует. Адреса и наблюдения вымышлены: они нужны для разбора проверки, а не описывают работу конкретного сайта.
| Маршрут | Способ входа | HTTP | H1 и title | Canonical | Контент | Дефект |
|---|---|---|---|---|---|---|
| /catalog/ | Прямое открытие | Документ: 200 | Каталог и его title | /catalog/ | Список загружен | В примере не обнаружен |
| /product/item/ | Прямое открытие | Документ: 200; данные: 200 | Название товара и его title | /product/item/ | Карточка появилась после загрузки данных | Нужно отдельно проверить доступность скриптов и данных |
| /product/item/ | Переход из каталога | Нового ответа документа нет; данные: 200 | H1 товара, title каталога | Остался /catalog/ | Карточка видна | При переходе не обновились метаданные |
| /missing/ | Прямое открытие | Документ: 200; данные: 404 | Сообщение об отсутствии | Не задан | Приложение показывает ошибку | Внешний ответ сообщает об успехе; возможен soft 404 |
| /catalog/ | Возврат кнопкой «Назад» | Нового ответа документа может не быть | Каталог и его title | Остался /product/item/ | Список восстановлен | Canonical не соответствует текущему состоянию |
В таблице показаны разные состояния одной условной реализации. Код внутреннего запроса за товаром не заменяет код ответа на сам адрес страницы. При клиентском переходе новый HTML-документ может вообще не запрашиваться; поэтому его статус нельзя брать из ответа API.
Проверьте прямое открытие и ответ сервера
Откройте каждый выбранный адрес в новой вкладке и обновите страницу. В инструментах разработчика включите сохранение сетевого журнала и найдите запрос типа document. Запишите исходный URL, код ответа, возможную цепочку перенаправлений и конечный адрес. Отдельно посмотрите запросы скриптов и данных, если без них страница не появляется.
Для существующей карточки в примере сервер отдаёт документ с кодом 200, а затем приложение получает данные товара. Сам по себе успешный ответ ещё не означает, что название и описание присутствуют в первом HTML или попали в индекс. Сопоставьте исходный ответ с отрисованным DOM и видимой страницей. Найдите конкретное название, описание и ссылку на категорию, а не только общий контейнер приложения.
Если товар виден после перехода из каталога, но не появляется при открытии адреса напрямую, проверьте маршрутизатор, загрузку данных и обработку ошибок. Зафиксируйте запрос, состояние и время наблюдения. Не назначайте причину только по внешнему признаку: одинаковая пустая область может возникать из-за разных сбоев.
Сравните переходы, метаданные и историю
Из каталога перейдите по ссылке на карточку. Запишите адрес в строке браузера, H1, title, описание, canonical и основной текст после завершения загрузки. Сравните их с результатом прямого открытия той же карточки. Для SEO-значимого маршрута значения должны описывать текущую страницу и согласовываться с её назначением.
В условном примере контент товара появился, но title и canonical остались от каталога. Это дефект состояния приложения, который нужно воспроизвести и передать разработчику вместе с последовательностью перехода. Затем проверьте карточку напрямую: Google получает адрес отдельным запросом, поэтому результат клиентского перехода сам по себе не доказывает, какой документ Google получил для этого URL.
Нажмите «Назад», затем «Вперёд» и снова сравните адрес, контент и метаданные. При быстром переходе возможна краткая промежуточная загрузка; важно зафиксировать итоговое состояние и ошибки, которые не исчезают после неё. Проверьте и переход на соседний товар, чтобы убедиться, что приложение не сохраняет старое название или canonical.
Если сайт использует языковые версии или выбранный вариант товара, повторите сценарий для нужного состояния. Сверяйте одинаковый язык и предложение: иначе различие содержимого может быть следствием условий проверки, а не ошибки маршрута.
Разберите отсутствующий маршрут
Откройте вымышленный адрес напрямую и посмотрите ответ самого документа. Для действительно отсутствующей страницы предпочтителен подходящий код отсутствия, например 404, вместе с понятным сообщением и рабочей навигацией. Для удалённого материала с известным окончательным статусом может применяться 410.
В нашем случае запрос данных возвращает 404, но сервер приложения отправляет оболочку с кодом 200. Надпись «не найдено» не меняет внешний ответ. Такое сочетание может быть распознано как soft 404. Вместе с разработчиком проверьте возможность отдавать корректный статус для отсутствующего маршрута на сервере или на уровне маршрутизации.
Если клиентская архитектура пока не позволяет вернуть нужный статус, документация Google описывает альтернативы: перенаправление на адрес, возвращающий 404, либо добавление noindex к экрану ошибки с помощью JavaScript. Это решения для разбора конкретной реализации, а не доказательство, что любой экран ошибки уже исключён из индекса. Проверьте конечный ответ, итоговый DOM и отсутствие влияния на реальные карточки. Подробнее различия ответов разобраны в статье о 404 и soft 404.
Ошибка получения данных действующего товара – отдельная ситуация. Не превращайте временный сбой API в окончательное удаление страницы без проверки причины и согласованного поведения приложения.
Проверьте ссылки и доступность отрисовки
Найдите ссылку из категории на товар в исходном или отрисованном документе. Для обычного перехода у элемента должен быть проверяемый адрес в href, например <a href="/product/item/">Карточка товара</a>. Клиентский обработчик может перехватывать такой переход и обновлять интерфейс без полной перезагрузки. Проверьте, что адрес открывает нужный товар и при прямом входе.
Контейнер, который реагирует только на нажатие, и адрес с фрагментом для загрузки другого содержимого требуют отдельного разбора. Внешний вид кликабельной карточки не подтверждает, что поисковый робот может извлечь из неё нужный URL. Сверьте обнаруженные ссылки с инвентарём и убедитесь, что важные маршруты не зависят только от поиска внутри сайта или действий пользователя.
Для доступного вам ресурса Search Console используйте проверку конкретного URL: сопоставьте сведения об индексированной версии с результатом проверки текущей страницы, посмотрите доступный отрисованный HTML, загруженные ресурсы и сообщения. Набор показанных данных зависит от результата и режима проверки. Если скрипт или источник данных недоступен, исследуйте ответ и условия доступа; загрузка страницы в вашем браузере не подтверждает автоматом такой же результат у Google.
Зафиксируйте исправление и повторите сценарии
- Для каждого дефекта сохраните адрес, дату, язык, версию приложения, путь пользователя и ожидаемое состояние. Приложите код ответа документа и отдельно результат запроса данных.
- Укажите фактическое расхождение: например, карточка открывается, но после перехода содержит canonical категории. Возможную причину отметьте как гипотезу до проверки разработчиком.
- После исправления повторите прямой вход, переход из каталога, возврат по истории и открытие отсутствующего адреса. Проверьте соседнюю карточку и вторую языковую версию.
- Сверьте содержимое, ссылки, метаданные и ответы по тем же условиям. Затем отдельно наблюдайте данные Google: техническая приёмка и результат живой проверки не гарантируют фактическую индексацию или позиции.
Приёмка завершена, когда проверенные маршруты дают ожидаемое содержимое и согласованные сигналы, а отсутствующая страница обрабатывается по согласованному правилу. Выбор между серверной и клиентской отрисовкой требует отдельной оценки данных и поддержки; сам тест маршрутов не назначает архитектуру за команду.
Нужна помощь с вашим проектом?
Оставьте имя и телефон. Свяжусь с вами, чтобы обсудить задачу, объём работ и следующий шаг.
