Современные сайты часто загружают карточки, меню и тексты с помощью JavaScript. Для человека интерфейс может выглядеть безупречно, но поисковому роботу важно не только то, что появилось в браузере, а то, каким образом доступна информация и откуда извлекаются ссылки.
Исходный HTML и итоговый DOM — разные состояния страницы
Когда сервер отдаёт документ, браузер получает первоначальный HTML. Затем сценарии могут добавить заголовки, карточки и навигацию. При проверке нужно сравнивать оба состояния: исходный ответ и HTML после выполнения JavaScript. Если основной материал изначально отсутствует, его доступность становится зависимой от успешной отрисовки.
Google описывает процесс как сканирование, отрисовку и индексирование. При этом рендеринг может происходить не одновременно с первым получением URL. Это означает, что наличие текста в вашем браузере ещё не гарантирует мгновенного появления всего материала в поиске. См. официальное руководство Google по JavaScript SEO.
Три сценария, которые нельзя путать
| Модель | Где находится основной текст | Основной риск |
|---|---|---|
| Серверная генерация | В исходном HTML | Ошибки шаблона и заголовков ответа |
| Гибридная отрисовка | В HTML и дорабатывается скриптами | Несовпадение состояний |
| Клиентская отрисовка | Появляется после JS | Зависимость от исполнения скрипта |
Нет необходимости объявлять клиентскую отрисовку плохой при любых условиях. Она может работать, но требует более тщательной проверки доступности, состояния загрузки и обработки ошибок.
Почему табы, кнопки и бесконечные ленты требуют проверки
Обычная ссылка <a href="/page"> даёт роботу понятный адрес. Кнопка с обработчиком клика может лишь изменять интерфейс без отдельного URL. Это особенно важно для категорий, пагинации и карточек, которые появляются после действий человека.
Если раздел существует только в виде состояния #!, не следует считать его полноценной индексируемой страницей без самостоятельного URL и содержимого. Google отдельно рекомендует для маршрутизации приложений использовать доступные адреса, а не полагаться исключительно на фрагменты URL. Для площадок с динамическими Потоками это практически важная проверка.
Статусы ошибок важнее красивой страницы «не найдено»
Приложение может показать пользователю сообщение об отсутствии материала, но вернуть HTTP 200. Для поискового робота это неоднозначное поведение, которое может привести к диагностике soft 404. Аналогичная проблема возникает, если сервер перенаправляет все неизвестные адреса на главную.
Проверьте HTTP-ответы у существующих страниц, удалённых материалов и технических маршрутов. В случае окончательно отсутствующей страницы ожидается корректный 404 либо 410, если это соответствует ситуации. JavaScript-плашка не заменяет правильный серверный ответ.
Как проводить проверку без догадок
Сначала откройте исходный код страницы и найдите основной заголовок, содержательные абзацы и ссылки на карточки. Затем сравните их с DOM после загрузки. Проверьте, нет ли ошибок в консоли, запрещённых для робота скриптов и запросов к закрытым API. Для Google используйте проверку URL и просмотр обработанного содержимого.
Если сайт построен на Tilda, дополнительно посмотрите, какие разделы создают настоящие страницы, а какие лишь фильтруют общий список. О технических ограничениях и возможностях самой платформы можно прочитать в разборе SEO на Tilda, а о разработке шаблонов и Потоков — послушать подкаст marmelad.digital на Apple Podcasts (выпуск «Как сегодня устроена разработка сайтов на Тильде»).
Отдельный риск: данные загружаются из API после открытия страницы
Представим каталог, в котором сервер отдаёт только пустой контейнер, а список товаров запрашивается скриптом. Даже когда JavaScript исполняется, запрос к API может завершиться ошибкой из-за токена, географического ограничения, защиты от ботов или времени ожидания. В обычном браузере разработчика карточки появляются, но у другого клиента итоговый HTML может быть неполным.
Поэтому тестируйте не только «работает на моём компьютере». Проверьте страницу в чистом профиле браузера, без авторизации и персональных cookie. Посмотрите сетевые запросы и сообщение сервера при проблемном ответе. Для Google полезно сравнить исходный и обработанный HTML через проверку URL. Если содержимое нестабильно, первоочередная задача — обеспечить надёжную доставку основных данных.
Что делать с изменяющимися метатегами
Если JavaScript добавляет title, description или canonical уже после загрузки, убедитесь, что эти значения не противоречат первоначальному документу. Особенно опасно, когда исходный HTML содержит noindex, а приложение пытается позднее убрать запрет: Google предупреждает, что наличие noindex может привести к пропуску дальнейшей обработки страницы. Лучше генерировать жизненно важные инструкции корректно на этапе ответа сервера.
Когда динамическая часть относится лишь к фильтрам интерфейса, нет необходимости превращать каждое состояние в индексируемый URL. Но если категория должна собирать самостоятельный спрос, для неё нужна доступная адресная страница с полезным содержимым. Это разные задачи, и решать их одним универсальным скриптом не стоит.
Когда необходима переработка архитектуры
Если большая часть важных документов обнаруживается только после кликов или последовательной прокрутки, удобнее обеспечить для них обычные HTML-ссылки и доступные URL. Если основное содержимое зависит от нестабильного внешнего API, стоит рассмотреть предварительную генерацию ключевой информации.
Не начинайте с полной замены платформы: сначала перечислите конкретные недоступные элементы, проверьте их роль в индексации и оцените минимальные изменения. Задача — сделать сайт понятным для пользователя и доступным поисковому роботу, сохранив работающее поведение интерфейса.
