Проверка сайта на ошибки: что видит AI-краулер, а посетитель нет

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

Алексей Малков

Основатель GEOAudit.org • GEO/SEO-стратег

150+ аудитов • 12 лет в digital • 100+ отзывов на фрилансе

Технический GEO-аудит Доступность для краулеров Schema.org и разметка

Профиль автора →

Ошибки сайта делятся на три слоя, и робот видит не тот, что посетитель

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

В аудитах мы раскладываем ошибки на три слоя. Деление удобно тем, что каждый слой чинят разные люди и в разной очерёдности.

• Слой 1. Код и разметка. Невалидный HTML, дубли title и H1, пустые alt, сломанный JSON-LD, битая кодировка. Чинит верстальщик. Влияет в основном на классический поиск.
• Слой 2. Доступность. Коды ответа сервера, robots.txt, редиректы, canonical, скорость, подгрузка контента через JavaScript, защита от ботов. Чинит разработчик или системный администратор. Влияет и на поиск, и на нейросети.
• Слой 3. Качество содержимого. Есть ли на странице прямой ответ, подтверждён ли он фактами, кто автор, когда обновлено, нет ли противоречий с соседними страницами. Чинит редактор. Влияет прежде всего на попадание в нейроответ.

Бесплатные чекеры живут в первом слое и частично во втором. Третий они не умеют оценивать в принципе: там нужен человек или отдельная методика. Отсюда типичная картина — проверка качества сайта даёт зелёный отчёт без единого красного пункта, а бренд не называет ни ChatGPT, ни Алиса, ни Perplexity.

Обновлено: август 2026 — переписали раздел про доступ роботов (добавили таблицу кодов ответа и актуальные имена AI-краулеров), добавили матрицу приоритетов и честный раздел о том, когда проверку можно не делать вовсе.

AI-краулеры читают первый ответ сервера и не ждут JavaScript

Главная методическая ошибка при проверке — смотреть на сайт глазами браузера. Браузер выполняет скрипты, подставляет данные из API, дорисовывает блоки. Робот в общем случае забирает то, что сервер отдал первым ответом, и уходит. Поэтому проверять нужно исходный HTML: «Просмотр кода страницы» в браузере или запрос через curl из консоли. Если нужного текста там нет — для части краулеров его не существует. Раньше по цепочке лежит другой класс отказов — просроченный сертификат, капча для незнакомого user-agent, таймаут в часы пиковой нагрузки: такие сбои доступности и HTTPS в исходном коде не видны вообще, их ловят только со стороны сервера.

Googlebot умеет рендерить страницу и возвращаться за результатом скриптов. Большинство краулеров, которые собирают данные для генеративных моделей, такой гарантии не даёт. Отсюда практическое правило: цена, адрес, характеристики, ответ на вопрос и контакты должны быть в исходном HTML, а не появляться после загрузки. Сайты на JS-фреймворках без серверного рендеринга ломаются на этом чаще всего — подробнее про механику разбирали в материале об индексации сайта и AI-краулерах.

Кто именно к вам ходит

В логах сервера и в robots.txt имеет смысл узнать в лицо несколько user-agent, помимо привычных Googlebot и YandexBot:

• GPTBot — краулер OpenAI для обучения моделей.
• OAI-SearchBot и ChatGPT-User — обход и переходы в поиске ChatGPT.
• PerplexityBot — сбор источников для ответов Perplexity.
• ClaudeBot — краулер Anthropic.
• Google-Extended — не отдельный бот, а токен в robots.txt: им управляют доступом к данным для генеративных сервисов Google.
• YandexBot — отдельного «бота Алисы» нет: нейроответ собирается на базе того же индекса, что и обычная выдача. Закрыли YandexBot — потеряли и позиции, и шанс на упоминание в ответе.

Типовая ошибка — блокировка «всех незнакомых» на уровне WAF или облачной защиты. Сайт при этом открывается в браузере идеально, а боту прилетает 403. Формально это не ошибка сайта: HTML валиден, страница жива. Фактически сайта для нейросети нет. Разбор того, кого пускать и кого закрывать, у нас лежит отдельно — в материале про robots.txt и AI-краулеров.

Тихие ошибки: то, что не подсвечивает ни один валидатор

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

Что мы встречаем чаще всего:

• Факт живёт в картинке. Цена, состав услуги, таблица характеристик, часы работы — всё это набрано в изображении или инфографике. Для читателя нормально, для модели пусто.
• Ответ спрятан в аккордеон, который открывается скриптом. Текст есть в разметке — хорошо. Текста нет в исходном HTML — считайте, что его нет.
• Разметка не совпадает с текстом. В JSON-LD одна цена и один рейтинг, на странице другие. Такое расхождение снимает доверие к странице целиком, а не только к разметке. Тот же эффект даёт формально заполненная разметка Organization и WebSite, где значения проставлены «для галочки» и расходятся с реальными данными компании. Как собирать разметку под нейроответы, разбирали в гайде по Schema.org для GEO.
• Противоречия между страницами. Разные телефоны в шапке и на контактах, разный год основания в «О компании» и в блоге, старые цены в архивной статье. Модель сводит факты со всего сайта и на противоречии предпочитает не утверждать ничего.
• Нет даты и автора. Страница без даты обновления и подписи выглядит одинаково и для читателя, и для модели — как текст неизвестной свежести.
• Технический дубль. Один материал доступен по трём адресам (с параметром, со слешем, на поддомене), canonical не проставлен. Сигналы делятся, ни один URL не набирает веса.
• Нет машиночитаемого входа. Файл llms.txt не заменяет нормальную структуру, но помогает модели быстрее найти ключевые разделы.

За 150+ аудитов картина повторяется: собственник ждёт разбора контента, а первые находки лежат в доступе. Сайт быстрый, красивый, валидный — и наглухо закрыт для половины краулеров правилом, которое админ поставил год назад против парсеров. Мы начинаем проверку не с текстов, а с ответа сервера на запрос от чужого user-agent: если тут дыра, остальное считать бессмысленно.

Алексей Малков

Основатель GEOAudit.org

Что чинить первым: матрица приоритетов

Список ошибок без приоритетов бесполезен: разработчик начнёт с того, что проще, а не с того, что дороже стоит. Мы сортируем находки по тому, что именно ошибка блокирует — попадание в выдачу, попадание в нейроответ или ни то, ни другое.

Приоритет 4 в этой таблице не означает «не чинить». Он означает «не начинать с этого». Порядок важнее полноты: пока сайт отдаёт роботу 403, идеальные alt-атрибуты не дадут ничего. Полный перечень пунктов, который мы проходим руками, собран в чек-листе GEO-аудита, а в техническом GEO-аудите таких пунктов 42 — от доступа краулеров до разметки и структуры.

Порядок проверки: семь шагов за один вечер

Этот порядок мы даём клиентам, когда они хотят посмотреть сами до заказа аудита. Он не заменяет полноценную проверку, но снимает самые дорогие вопросы.

1. Прочитайте robots.txt глазами. Откройте /robots.txt и найдите все Disallow и все имена ботов. Отдельно проверьте, не закрыт ли сайт целиком через User-agent: * с Disallow: / — так бывает после переноса с тестового сервера.
2. Снимите коды ответа. Главная, две-три категории, карточка товара или услуги, статья блога. Смотрите не браузером, а запросом: важен именно первый ответ сервера.
3. Откройте исходный код ключевой страницы. Найдите поиском по коду цену, телефон и первый абзац текста. Не нашли — контент подгружается скриптом, это второй приоритет.
4. Проверьте разметку. Валидатор структурированных данных покажет ошибки JSON-LD. Дальше сверьте руками: то, что в разметке, должно совпадать с тем, что видит человек на странице.
5. Прогоните базовые чекеры. Скорость, мобильная версия, мета-теги, битые ссылки. Какой сервис под какую задачу — разбирали в обзоре бесплатных сервисов проверки сайта; про их границы — в материале про онлайн-анализ сайта.
6. Посмотрите логи за две недели. Кто из ботов приходил, какие коды получал, как двигался по сайту и до каких разделов не дошёл. Это единственный способ узнать правду о доступности, а не догадываться о ней.
7. Задайте нейросетям свои вопросы. Пять-семь запросов, по которым к вам приходят клиенты, в ChatGPT, Алисе и Perplexity. Запишите, кого называют и на какие сайты ссылаются. Это уже не техническая проверка, но именно она показывает, окупится ли починка.

Валидный код не гарантирует попадания в нейроответ

Вопрос, который почти не разбирают в статьях про проверку: сайт прошёл валидатор, ошибок ноль, скорость зелёная — почему его всё равно не называют? Потому что валидатор проверяет синтаксис, а модель выбирает источник по другим признакам. Синтаксическая чистота — условие необходимое, но не достаточное.

Что смотрит модель, помимо доступности:

• Есть ли готовый ответ. Абзац, который можно процитировать целиком, без склейки из пяти мест страницы.
• Подтверждается ли факт снаружи. Одинаковые данные о компании на сайте, в справочниках, в отраслевых каталогах и в профилях. Расхождение — повод не упоминать.
• Понятно ли, кто говорит. Автор, должность, опыт, ссылки на профили. Анонимный текст проигрывает подписанному при прочих равных.
• Насколько свежие данные. Дата обновления и актуальные цифры важнее объёма текста.
• Узнаваемость бренда. Название, которое встречается в разных источниках, попадает в ответ чаще безымянного сайта с тем же контентом.

Поэтому после технической проверки мы всегда делаем второй заход — смотрим на сами ответы нейросетей по запросам клиента и считаем, в какой доле из них бренд вообще появляется. Это отдельная работа: базовая диагностика AI-видимости занимает сутки и стоит 0 ₽ — её достаточно, чтобы узнать, есть ли проблема, до любых вложений в разработку.

Когда проверять сайт на ошибки не нужно

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

• Сайт в процессе редизайна. Смысла вылизывать версию, которую через месяц выкинут, нет. Исключение — доступ роботов и коды ответа: их проверяют на новой версии до релиза, а не после.
• Сайт-визитка на одну страницу без контента. Чинить нечего: ошибка тут не техническая, а стратегическая. Сначала нужен качественный материал, который можно цитировать, потом проверка.
• В нише никто не спрашивает нейросеть. Технически чистый сайт не создаёт спрос. Если ваши клиенты приходят по звонку с рекомендации, деньги разумнее вложить в другое.
• Нет ресурса на правки. Аудит без разработчика превращается в красивый PDF. Мы иногда просим клиента отложить работу на месяц, пока не появится тот, кто внедрит.

Что не сработает

• Массовая генерация разметки «на все страницы». Schema, не сверенная с видимым текстом, добавляет расхождений, а не доверия.
• Закрыть всех ботов «на всякий случай». Так теряют не нагрузку, а упоминания. Управлять доступом нужно точечно, по именам.
• Погоня за 100 из 100 в тестах скорости. Разница между хорошим и идеальным баллом почти не влияет ни на выдачу, ни на обход, а стоит дорого.
• Разовая чистка «под ключ». Ошибки возвращаются с каждым релизом. Работает регламент: короткий список проверок после каждого выката.

Что делать с результатом проверки

Отчёт полезен ровно настолько, насколько он превращается в задачи. Разложите находки по трём корзинам и работайте по ним, а не по списку целиком.

1. Блокеры. Всё, что закрывает сайт роботам: robots.txt, 403 и 5xx, контент только в скриптах. Срок — дни, исполнитель — разработчик.
2. Потери. Дубли, canonical, скорость, расхождения разметки и текста. Срок — недели, исполнитель — разработчик и редактор вместе.
3. Рост. Прямые ответы в первых абзацах, авторство, даты, факты, которые можно проверить. Срок — постоянно, исполнитель — редактор.

Дальше — контрольная точка. Через неделю после правок повторите шаги 1, 2 и 6 из порядка выше, а через месяц — седьмой: задайте нейросетям те же вопросы и сравните, изменился ли список названных компаний. Это и есть измеримый результат, а не «стало лучше».

Если разбираться самому некогда, эту часть закрывает технический GEO-аудит — от 40 000 ₽: доступ краулеров, разметка, скорость, структура и список правок с приоритетами, который можно отдать разработчику без перевода. Технический разбор — только один из пяти форматов: если вопрос звучит не «что чинить на сайте», а «называют ли нас нейросети вообще», нужен другой вид GEO-аудита под другую задачу.

FAQ