Сайт читают робот и нейроответ: чек-лист из 12 пунктов с признаками нарушения

Как проверить сайт для поискового робота и нейроответа: статусы, JavaScript, canonical, Core Web Vitals на 75-м перцентиле и замеры по 84 статьям корпуса.

Коротко

Чек-лист из 12 пунктов для сайтов, которые читают поисковый робот и нейроответ: у каждого пункта есть наблюдаемый признак нарушения и способ измерения. Пороги и формулировки взяты дословно из web.dev и документации Google, цифры про наш корпус — из замера 6 октября 2026 года. Материал актуален на 07.10.2026.

• Пункты 1–5 про доступность: статус 200, текст в первом ответе, robots.txt, мета-директивы, независимость контента от исполнения скриптов.
• Пункты 6–7 про идентичность страницы: canonical в исходном HTML и осмысленный статус вместо мягкого 404 в SPA.
• Пункты 8–9 про опыт взаимодействия и вёрстку: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1 на 75-м перцентиле и прокрутка для широких таблиц и кода.
• Пункты 10–12 про считаемость: дата актуальности, самодостаточный блок «Коротко», входящие ссылки и sitemap.
• По нашему корпусу: 84 статьи на 06.10.2026: 171 таблица из 207 без обёртки прокрутки, блок «Коротко» — у 24 %, «актуален на…» — у 21 %, 6 статей вообще без входящих ссылок.

Чем этот чек-лист отличается от аудита скорости

Аудит скорости отвечает на вопрос «быстро ли открывается». Здесь вопрос другой: «виден ли контент тому, кто не запускает JavaScript, и понимает ли его тот, кто извлекает из страницы ответ для пользователя». Это разные режимы отказа: страница может быть быстрой и при этом пустой для робота, или медленной, но полностью читаемой.

Пункты собраны так, чтобы каждый проверялся за минуты и давал число, а не впечатление. Для каждого указана граница из прочитанного первоисточника или наш замер, а способ измерения повторяем тем же скриптом, что и в прошлом срезе.

Что проверяем в ответе сервера

1. Канонический URL отдаёт 200, а не цепочку редиректов

Признак нарушения: первый запрос к адресу статьи возвращает 301, 302, 404 или 5xx, либо редирект ведёт на страницу без текста. Измерение: HEAD-запрос по списку адресов и таблица статусов, где строка — URL, колонки — коды и целевой адрес.

Почему это пункт, а не деталь: Googlebot использует HTTP-статусы, чтобы понять, что при обходе что-то пошло не так, и в документации прямо советует осмысленные коды — 404 для несуществующей страницы, 401 для страниц за логином.

2. Текст страницы виден в первом HTML-ответе

Признак нарушения: в ответе без исполнения скриптов есть оболочка вида пустой контейнер, а заголовок, первый абзац и таблица догружаются клиентом. Измерение: обычный HTTP-запрос без браузера и поиск по строке из середины текста.

Ориентир из документации Google: серверный рендеринг или пререндеринг остаётся хорошей идеей, потому что он ускоряет сайт и для людей, и для обходников, а исполнять JavaScript могут не все боты. Отсюда практическая проверка: если робот без JavaScript не получает контент — пункт не пройден.

3. robots.txt не блокирует ни страницу, ни её ассеты

Признак нарушения: адрес статьи или файл, из которого она строится, подпадёт под директиву disallow. Измерение: разбор robots.txt по правилам и проверка каждого URL из выборки против них.

Граница жёсткая и цитируется дословно: «Google Search won't render JavaScript from blocked files or on blocked pages». Если закрыт шаблон или скрипт сборки страницы, контент не появится в индексе даже при корректном статусе 200.

4. Мета-директивы не запрещают индексацию там, где она нужна

Признак нарушения: noindex в HTML или в HTTP-заголовке на публичной статье, либо такой тег, унаследованный от тестовой среды. Измерение: выборка по 20 страниц и греп по тегу и заголовку.

Смысл пункта в механике очереди: все страницы со статусом 200 ставятся в очередь рендеринга, если мета-тег или заголовок не указывает не индексировать страницу. Одна унаследованная директива обнуляет всю остальную работу.

5. Ценность страницы не зависит от исполняемого скрипта

Признак нарушения: таблицы с ценами, калькулятор или каталог, которых нет ни в HTML, ни в структурированной выдаче. Измерение: открыть статью в браузере с отключённым JavaScript и попытаться пересказать её содержание.

Этот пункт часто путают с пунктом 2: там проверяется наличие текста, здесь — наличие данных. Форма поиска по каталогу может работать, а содержимое каталога для внешнего читателя оставаться недоступным.

Почему canonical и статусы нельзя проверять в одну строку

6. Canonical задан в исходном HTML и не переписывается скриптом

Признак нарушения: в HTML одна ссылка canonical, после исполнения JavaScript — другая. Измерение: сравнить значение тега в ответе сервера и в DOM после загрузки.

Формулировка из документации: задать canonical через JavaScript можно, но не стоит менять его на значение, отличное от указанного в исходном HTML; лучший способ — HTML. Отдельно сказано, что внедрённый скриптом canonical поисковая система подхватывает при рендеринге, то есть расхождение двух значений робот увидит.

7. Пустой раздел возвращает осмысленный статус, а не мягкий 404

Признак нарушения: запрос на несуществующую статью отдаёт 200 и оболочку с текстом «ничего не найдено». В SPA такое типично: сервер не знает клиентских маршрутов, и статус подобрать практично не всегда.

Из документации: чтобы сообщить, что страницу нельзя обойти или проиндексировать, нужен осмысленный код, и один из выходов для клиентской маршрутизации — JavaScript-редирект на адрес, по которому сервер отвечает 404. Проверка: запросить заведомо вымышленный адрес и посмотреть финальный код.

Какие пороги скорости считать проходными

8. LCP, INP и CLS в целях на 75-м перцентиле

Значения приведены дословно по странице web.dev про Core Web Vitals и пересчёту не подлежат: LCP должен происходить в пределах 2,5 секунды от начала загрузки страницы, INP — 200 миллисекунд или меньше, CLS — 0,1 или меньше.

Мера тоже указана: чтобы попадать в цели у большинства пользователей, ориентир — 75-й перцентиль загрузок страницы с раздельным разбиением по мобильным и десктопным устройствам. Инструменты, оценивающие соответствие, считают страницу прошедшей при всех трёх метриках в целях на этом перцентиле.

Признак нарушения в отчёте: средняя вместо перцентиля, общий срез без разбиения на мобильные и десктопные сессии, или «прошедшая» страница при одной метрике ниже цели. Измерение: полевые данные по выборке шаблонов, а не один запуск на десктопе.

9. Широкие таблицы и блоки кода прокручиваются, а не растягивают страницу

Признак нарушения: горизонтальная прокрутка всей страницы на мобильном вьюпорте. Измерение — скриншоты и замер ширины документа на 390 px; это наш метод, а не порог из документации.

Как это выглядит на живом массиве, если прогнать признак по всему корпусу: 207 таблиц, из них 171 без обёртки с горизонтальной прокруткой, то есть 83 %. Блоков кода 24, без обёртки — 20. Число статей с хотя бы одной незащищённой таблицей — 64 из 84.

Что должно быть в ответе для нейроответа

10. Дата актуальности фактов

Признак нарушения: в тексте есть числа и нормы без даты, а в разметке строки вида «материал актуален на ДД.ММ.ГГГГ». Измерение: греп по фразе и по формату даты внутри первой половины статьи.

Наш срез по корпусу на 06.10.2026: строка «актуален на…» найдена в 18 из 84 статей — 21 %. Для новостических шаблонов это тот пункт, который дешевле всего чинится процедурой публикации и дороже всего не чинится.

11. Самодостаточный блок с ответом в начале

Признак нарушения: первый раздел статьи — вводный абзац без фактов, а выводы распределены по тексту. Практичный тест: можно ли взять один фрагмент страницы и пересказать по нему ответ, не дочитывая до конца.

Мы проверяем наличие блока «Коротко» как отдельный признак: в нашем корпусе на срез 6 октября он есть у 20 статей из 84, это 24 %. Причина низкого процента — не дизайн, а история: старые материалы писались до того, как шаблон стал правилом.

Как убедиться, что страницу вообще находят

12. Входящие ссылки и адрес в sitemap

Признак нарушения: на статью не ссылается ни одна другая страница сайта, и она попала в индекс только через sitemap. Измерение: посчитать входящие по всем internal-ссылкам корпуса и сверить список адресов с картой сайта.

По нашему замеру от 6 октября: у 65 статей из 84 две и более входящих ссылки (77 %), хотя бы одна — у 78 (93 %), полностью изолированы 6. В sitemap на этот же день 115 адресов. Изолированная статья не «плохая» — она просто не получает обхода по внутренним ссылкам.

Почему мы прогоняем чек-лист по всему корпусу, а не по одной странице

Потому что девять пунктов из двенадцати — свойства шаблона и процесса, а не отдельной страницы. Одна и та же ошибка воспроизводится на сотнях адресов, а чинится одной правкой в сборке. Замер по массиву показывает масштаб: 83 % таблиц без прокрутки — это не недосмотр редактора, а отсутствие обёртки в шаблоне.

Вторая причина: по массиву видно, какие пункты лечатся кодом, а какие — процедурой. Дата актуальности и блок «Коротко» не появляются сами, они требуют шага в регламенте публикации, и их доля — индикатор соблюдения регламента, а не вёрстки.

Как оформить проверку и передать подрядчику

Форма, которую мы используем в приёмке: 12 строк, четыре колонки. Итог — не «всё хорошо», а число непройденных пунктов и адрес, где нарушение воспроизводится.

Дальше работает правило гейта: правку шаблона принимаем, если повторный прогон по тому же списку адресов даёт ноль по этому пункту. Автоматизация этих проверок — отдельная задача, и как она выглядит в сборке, разобрано в материале про гейты качества.

Чего в этом чек-листе нет

• Нет порогов, которых нет в прочитанных источниках: ни «не более 100 КБ HTML», ни «90/10 по CLS», ни обязательного hreflang.
• Нет требований Яндекса: первоисточник по этой теме в этом дне мы не читали и не переносим формулировки Google на другую поисковую систему.
• Нет обещаний по позициям: пункты проверяют доступность и считаемость, а не результат в выдаче.
• Нет чек-листа по контенту: объём, уникальность фактуры и редактура — другой слой проверки.
• Наши корпусные цифры — срез конкретного дня и конкретного массива, они не отраслевая норма и воспроизводятся скриптом, а не ссылкой на исследование.

Про скорость и вес страницы по отдельности — «Технический аудит скорости сайта: что чинить первым». Про вёрстку на мобильном вьюпорте по живому замеру — «Мобильная вёрстка блога: что показал замер на 390 px». Про приёмку этих пунктов у подрядчика — «Приёмка сайта и приложения у подрядчика: 24 пункта». Про различие SEO и GEO на замерах — «GEO — это просто SEO под новой вывеской?». Как это автоматизируется в сборке — «Гейты качества при сборке сайта».

Если нужен не список, а прогон по вашему сайту с таблицей результатов и датой пересреза — посмотрите формат такой работы в кейсе Аудит скорости коммерческого сайта, 26 пунктов в ТЗ и обсудите задачу на AI-SEO. Начать можно с вопроса по вашему сайту через форму контактов.

Источники

• web.dev, «Core Web Vitals» — определения LCP, INP, CLS, целевые значения и правило 75-го перцентиля с разбиением по устройствам — web.dev. Снимок страницы сохранён 06.10.2026.
• developers.google.com, «JavaScript SEO basics» — очередь краулинга и рендеринга, влияние disallow, статусы 200 и non-200, canonical, мягкий 404 в SPA — developers.google.com.
• Замер по нашему корпусу: 104 записи, 84 статьи со сплошным текстом, срез 06.10.2026; скрипт считает таблицы и блоки кода без обёртки прокрутки, наличие блока «Коротко» и строки «актуален на…», входящие ссылки, изолированные страницы; количество адресов сверено с картой сайта.