Какое содержание получает каждый клиент
Запрос к адресу страницы возвращает статус, заголовки и тело ответа. Браузер затем может загрузить JavaScript, запросить данные и построить документ. Поэтому фраза «у меня всё видно» описывает результат работы конкретного клиента с конкретными условиями, а не универсальное содержание первоначального ответа.
Google описывает этапы обхода и рендеринга JavaScript. Между получением страницы и обработкой её содержимого есть различия, которые важно учитывать при диагностике. Другие поисковые и пользовательские агенты могут иметь иные возможности. Нельзя говорить ни «все боты видят только HTML», ни «все видят страницу как современный браузер».
Выберите один URL и один проверяемый фрагмент. Например, условия обслуживания и перечень моделей на странице услуги. Если начать с общего исследования всего сайта, легко потерять конкретную причину: пустой ответ, блокировку ресурса, ошибку API или неверную версию содержимого.
Источники: Google: основы SEO для JavaScript
Исходный HTML и DOM отвечают на разные вопросы
Исходный HTML показывает тело, полученное от сервера в проверяемом запросе. DOM после выполнения скриптов показывает результат обработки клиентом. Оба представления полезны. Первое помогает понять зависимость от JavaScript, второе — проверить, достроилось ли нужное содержание в выбранных условиях.
Сохраните адрес, время, статус, цепочку перенаправлений и среду проверки. Учитывайте авторизацию, cookie, язык и регион: разные условия могут менять выдачу. Не сравнивайте анонимный ответ роботу с личным кабинетом сотрудника, объявляя различие ошибкой индексирования.
Если используются инструменты разработчика, проверьте не только внешний вид, но и загрузку данных. Ошибка API после открытия оболочки может оставить посетителя без текста. Скриншот пустого экрана и исходный HTML при этом помогают локализовать разные этапы проблемы.
Учебный пример: текст есть только после выполнения скрипта
Возьмём вымышленную страницу /service/. Сервер возвращает оболочку с заголовком «Загрузка» и контейнером приложения. После успешного запроса данных браузер показывает условия обслуживания. Этот пример не описывает устройство нашего сайта; он демонстрирует различие состояний.
В таблице приведены короткие буквальные фрагменты. Отсутствие условий в исходном ответе устанавливает зависимость от последующей обработки, но само по себе не доказывает, что Google не проиндексирует страницу. Для такого вывода нужны результаты проверки конкретной системы и контекст.
| Проверка | Учебный фрагмент | Что установлено |
|---|---|---|
| Ответ сервера | <title>Загрузка</title><div id="app"></div> | Условия услуги в этом теле ответа отсутствуют |
| DOM после успешного выполнения | <h1>Обслуживание оборудования</h1><p>Модели уточняют до заявки.</p> | В выбранном браузере данные загружены |
| DOM при ошибке запроса | <h1>Загрузка</h1> | Есть сценарий без основного содержания |
| Желаемый содержательный ответ | <h1>Обслуживание оборудования</h1><p>Модели уточняют до заявки.</p> | Основной фрагмент доступен уже в HTML |
Желаемый ответ должен содержать действующие факты, а не отдельный устаревший текст «для роботов». Если клиентская часть затем заменяет его другой версией, возникает новая проблема согласованности. Проверяйте состояние после выполнения скриптов тоже.
Проверка Google и Яндекса: возможности не обобщают
Для Google сопоставьте фактически полученный HTML и результаты доступной проверки URL в Search Console. Обратите внимание на ресурсы, необходимые для рендеринга, заголовки, ссылки и возможные ошибки. Наличие текста в локальном браузере не заменяет проверку того, что получила конкретная система.
Яндекс отдельно документирует рендеринг страниц и проверку URL в Вебмастере. Доступность настроек и результатов нужно оценивать в своём проекте. Не следует из одного описания функции делать вывод, что все страницы любого сайта всегда обрабатываются одинаково и без дополнительных условий.
Если доступ к инструменту отсутствует или сервис временно не работает, сохраните то, что действительно удалось проверить: ответ сервера, DOM и состояние ресурсов. В отчёте прямо отделите эти факты от неизвестного состояния индекса. Поиск адреса в обычной выдаче также не заменяет полный отчёт об индексировании.
Для иных AI-агентов изучите документацию поставщика и наблюдения доступа. Не выдавайте успешный рендеринг Google за доказательство одинакового поведения ChatGPT, Claude или Perplexity. У каждой проверки должны быть свой клиент, дата и область вывода.
Источники: Google: основы SEO для JavaScript; Яндекс: рендеринг страниц; Яндекс: проверка страницы
SSG, SSR и предварительный рендеринг: что выбирать
SSG формирует страницы заранее при сборке. Это удобно для материалов, которые меняются через редакционный выпуск. SSR формирует HTML на сервере при обращении с учётом архитектуры и кэширования. Предварительный рендеринг также может подготовить содержательный документ, но требует проверки актуальности и полноты результата.
Выбор зависит от частоты изменения данных, объёма страниц, персонализации, инфраструктуры и стоимости поддержки. Для статей нередко достаточно статического результата, а для быстро меняющегося каталога требуется другой процесс обновления. Нельзя переносить одно решение на весь сайт только по слову «SPA».
Главный критерий — корректный и доступный ответ с нужным содержанием, а не название технологии. После изменения проверьте обычного пользователя, прямое открытие вложенного адреса и состояние после клиентской навигации. Гидратация не должна удалять основной текст или заменять его пустым состоянием.
| Способ | Что проверить | Риск без проверки |
|---|---|---|
| SSG | Сборка содержит текущую версию и нужные URL | Опубликована старая версия после изменения данных |
| SSR | Статус, данные и кэш для конкретного запроса | Ошибка зависимости или выдача не той версии |
| Предварительный рендеринг | Полнота текста, ссылки, дата обновления | Снимок устарел или не охватывает вложенные страницы |
| Клиентский рендеринг | Доступность ресурсов и результат для нужной системы | Оболочка загружена, содержание нет |
Статусы, canonical и ссылки проверяйте вместе с текстом
Содержательный HTML не исправляет неверный статус. Отсутствующая страница не должна выглядеть как действующая услуга только потому, что приложение вернуло общую оболочку с HTTP 200. Проверьте корректный сценарий отсутствующего адреса и перенаправления там, где они действительно нужны.
Canonical должен соответствовать выбранной стратегии адресов и не указывать случайно на другую услугу. Google рекомендует внимательно работать с canonical на JavaScript-страницах; конфликтующие значения в исходной и обработанной версии усложняют интерпретацию. Зафиксируйте ожидаемый адрес в задании и проверяйте обе версии документа.
Внутренние ссылки должны вести на реальные маршруты и быть доступны предусмотренному механизму обхода. Навигация только через обработчик клика без понятного адреса может мешать обнаружению. Отдельно проверьте прямое открытие вложенного URL: работа перехода с главной ещё не доказывает корректную серверную выдачу этой страницы.
Не смешивайте индексацию и скорость. Быстрая загрузка полезна посетителю, но измерение времени не показывает автоматически, получен ли правильный текст. Здесь приоритет — содержание, статус и адрес; производительность можно проверять отдельным заданием.
Источники: Google: основы SEO для JavaScript
Готовое задание разработчику по учебному примеру
Передайте воспроизводимый сценарий: какой адрес открывался, что ожидалось, что вернул сервер и что появилось после выполнения. Добавьте ограничения по сохранению действующего поведения. Задание «сделать SEO для SPA» не сообщает, когда работу можно принять.
В учебном случае не требуется менять услугу, форму или аналитику. Нужно обеспечить согласованный основной текст по действующему адресу и проверить связанные технические сигналы. Конкретный способ реализации разработчик выбирает после оценки системы, а не по рекламному названию подхода.
| Часть задания | Учебная формулировка |
|---|---|
| Объект | Существующая страница /service/ |
| Проблема | Исходный ответ содержит оболочку; при ошибке данных текста нет |
| Желаемый результат | Действующий основной текст и заголовок доступны в содержательном HTML |
| Сохранить | Адрес, подтверждённые условия, формы и согласованную аналитику |
| Проверить | Прямое открытие, навигацию, статус, canonical, ссылки, ошибочный адрес |
| Версии | Исходный HTML и DOM после скриптов не противоречат друг другу |
| Доказательство | Сохранённые ответы и результаты проверок до и после |
Как принять исправление и не обещать лишнего
Сравните один и тот же фрагмент до и после. Проверьте основной URL, вложенный переход, несуществующий адрес и сценарий ошибки данных. Убедитесь, что обновление содержимого достигает опубликованной версии, а не остаётся в локальной сборке или старом кэше.
Технический результат формулируют точно: текст доступен в проверенном HTML, статусы и адреса соответствуют заданию, ссылки работают. Затем отдельно проверяют обработку поисковой системой доступными инструментами. Успешная реализация SSR или SSG не является гарантией индексирования, позиции или цитаты.
Если содержание уже доступно и технические сигналы корректны, продолжение диагностики может потребовать анализа самого ответа на вопрос покупателя. Переписывать архитектуру ради общего обещания нейровидимости в такой ситуации преждевременно. Сначала установите, какую подтверждённую проблему решит следующее изменение.
Продолжить: Как отдельно проверить правила доступа роботов; Как проверить содержание прямого ответа