AI Readiness / GEO-аудит сайта: что проверять технически

Что здесь называется AI Readiness / GEO-аудитом

Термин GEO используют по-разному, поэтому полезнее не начинать с названия. В этом руководстве под AI Readiness / GEO-аудитом понимается проверка технических условий, от которых зависит способность автоматизированной системы обнаружить публичный URL, получить его содержимое и однозначно прочитать ключевые сигналы страницы.

Такой аудит не пытается угадать закрытые алгоритмы и не выдаёт корреляции за факторы ранжирования. Он работает с наблюдаемыми HTTP-ответами, robots-политикой, sitemap, canonical, индексирующими директивами, HTML и структурированными данными.

Шаг 1. Доставка: страница должна нормально открываться

Начните с HTTP: корректный публичный URL, ожидаемый статус, HTTPS, предсказуемые редиректы, отсутствие случайной авторизации и блокировок CDN/WAF. Если система не может стабильно получить документ, анализ разметки и контента становится вторичным.

Отдельно проверьте, что основной материал присутствует в первоначальном HTML. JavaScript может дополнять интерфейс, но критические заголовки, текст и ссылки не должны зависеть от хрупкой цепочки клиентских запросов без необходимости.

Шаг 2. Обнаружение: внутренние ссылки, robots.txt и sitemap

Проверьте, можно ли добраться до важной страницы обычными HTML-ссылками и отражена ли структура сайта в sitemap.xml. Затем прочитайте robots.txt как политику обхода: какие публичные разделы разрешены поисковым и ИИ-роботам, а какие закрыты сознательно.

Для ChatGPT отдельно проверьте OAI-SearchBot. OpenAI рекомендует не блокировать этот токен, если владелец хочет, чтобы содержимое могло участвовать в поисковых сводках и фрагментах ChatGPT. Политика GPTBot для model-use — отдельный вопрос и не должна автоматически копироваться на OAI-SearchBot.

Шаг 3. Индексирование: noindex, canonical и дубликаты

Проверьте robots meta и X-Robots-Tag. Noindex — явный сигнал не показывать страницу в поддерживающей его поисковой системе; он отличается от запрета обхода в robots.txt. Затем проверьте canonical и убедитесь, что он не уводит на другой домен, протокол, языковую версию или случайный дубль.

Canonical особенно важен на сайтах с фильтрами, параметрами, несколькими хостами и одинаковым содержимым по разным URL. Цель аудита — не «добавить canonical везде», а убедиться, что указанный предпочтительный URL соответствует реальной публичной версии страницы.

Шаг 4. Понимание страницы: HTML и Schema.org

Проверьте уникальный title, осмысленный H1, явный основной текст, логичную иерархию разделов и ссылки на связанные материалы. Затем проверьте Schema.org: разметка должна описывать реальные сущности страницы и не расходиться с видимым содержимым.

JSON-LD удобен как отдельный машиночитаемый слой, но сам по себе не делает страницу «готовой для ИИ». Сильный результат получается, когда HTML и структурированные данные говорят об одной и той же сущности одинаковыми фактами.

Шаг 5. Соберите проблемы по причинной цепочке

Такой порядок полезнее единого «GEO score»: он показывает, какое препятствие находится раньше в цепочке и способно сделать последующие улучшения бессмысленными до исправления причины.

• Сначала исправляйте недоступность, ошибочные статусы и блокировки.
• Затем — robots/noindex/canonical и обнаружение URL.
• После этого — отсутствие основного содержимого в HTML и проблемы JavaScript-доставки.
• И только затем — качество Schema.org, метаданных и дополнительных машиночитаемых сигналов.

Что не стоит включать в обязательный чек-лист

Не делайте обязательными новые или экспериментальные форматы только потому, что они связаны с ИИ. Например, наличие llms.txt или WebMCP можно отслеживать отдельно, но отсутствие этих сигналов не должно автоматически превращать обычный технически доступный сайт в «не готовый».

Также не смешивайте безопасность доставки, обучение моделей и поисковое обнаружение в один показатель. Это разные задачи с разными управляющими сигналами и разными последствиями.