Есть ли текст в HTML: проверка статьи для поиска
Как проверить текст статьи в исходном HTML и после JavaScript: заголовки, значимый абзац, ссылки, ошибки загрузки и ограничения такой проверки.
Статья может выглядеть полной в браузере и отсутствовать в начальном HTML. Бывает обратное: текст есть на сервере, но ошибка JavaScript ломает дальнейшую работу страницы. Для диагностики нужны обе версии, а не один поиск слова в исходнике.
В техническом SEO я бы выбирал значимый абзац из середины статьи и проверял его по всему пути. Заголовок и меню часто присутствуют даже в пустой оболочке. Нужен фрагмент, который доказывает наличие основного ответа.
Получите ответ по прямому адресу
Откройте URL в новой сессии и сохраните серверный ответ. Запишите HTTP-статус и конечный адрес после редиректов. Найдите H1, выбранный абзац и обычные ссылки внутри статьи. Убедитесь, что это разметка основного содержимого, а не строка в служебном скрипте, которую приложение ещё должно обработать.
Длинный документ Next.js может приходить одной строкой. Построчное извлечение легко отрежет весь текст или посчитает служебные данные вместо статьи. Используйте HTML-парсер и явно выбранный контейнер. При ручной проверке сначала посмотрите контекст найденного фрагмента.
| Ответ сервера | После JavaScript | Следующая проверка |
|---|---|---|
| Полный текст | Полный текст | Ссылки, metadata, доступность |
| Оболочка | Полный текст | Рендер и доступность зависимостей |
| Полный текст | Ошибка или пустой блок | Клиентская ошибка и гидратация |
| Оболочка | Ошибка | Загрузка данных, маршрутизация, ресурсы |
Что умеет поиск с JavaScript
Google описывает отдельный этап рендера JavaScript-страниц и отмечает пользу серверного или предварительного рендера. Не все роботы исполняют JavaScript. Поэтому утверждение «поиск всегда видит ровно то же, что мой браузер» слишком сильное.
Если основной текст приходит только после запроса данных, проверьте доступность этого запроса без вашей авторизации, блокировки ресурсов и возможные ошибки. Контент, который появляется исключительно после пользовательского действия, требует отдельной оценки. Скрытая кнопкой подгрузка не становится автоматически надёжным способом обнаружения всех материалов.
Проверьте не только абзацы
Найдите внутренние ссылки с реальными href. Затем откройте их напрямую. Клиентский переход может работать, а запрос адреса к серверу — возвращать ошибку. Это особенно заметно после публикации статической сборки с неправильно настроенной маршрутизацией.
Сверьте canonical, robots и заголовок. Отдельно посмотрите, не меняет ли клиентский код их на другую версию. Для списков с подгрузкой пригодится проверка пагинации. Если основной блок пуст, а статус успешный, проверьте признаки soft 404.
Что сохранить в результате
Запишите URL, дату, версию, статус ответа и местоположение проверенного фрагмента. Добавьте результат обычного браузерного просмотра и, когда доступно, поискового инструмента проверки URL. Снимок исходника и фактическое индексирование относятся к разным состояниям.
После исправления повторите прямое открытие, а не только переход внутри уже загруженного приложения. Затем проверьте появление адреса в sitemap и ленте. Содержательный HTML устраняет техническую неопределённость, но качество ответа и решение поисковой системы включить его в индекс проверяются отдельно.