Технический аудит сайта под ИИ: чек-лист из 9 шагов

Зачем аудит перед началом GEO-работ

Прежде чем заниматься контентом и дистрибуцией, стоит убедиться, что сайт технически доступен для AI-краулеров — иначе даже отличный контент останется невидимым. Ниже — методика, по которой проводится такой аудит на практике.

Шаг 1–2: логи сервера и robots.txt

Начните с логов сервера — они показывают, заходят ли на сайт AI-боты (GPTBot и другие) вообще. Затем проверьте robots.txt: убедитесь, что нужные боты не заблокированы случайно, а закрытые разделы (админка, служебные страницы) остаются закрытыми и для них.

Шаг 3–4: индексируемость и рендеринг

Проверьте коды ответа сервера на ключевых страницах и их индексируемость. Затем проверьте рендеринг — через `curl -A «GPTBot»` и через URL Inspection Tool в Google Search Console — чтобы убедиться, что важный контент присутствует в HTML-ответе, а не только после исполнения JavaScript.

Шаг 5–6: дубли и структурированные данные

Найдите дубли страниц — инструменты вроде Netpeak Spider или Screaming Frog выявляют полные дубли по хешу и проблемы с canonical. Затем проверьте, внедрена ли Schema.org разметка (FAQPage, Article, Organization) на приоритетных страницах и корректно ли она валидируется.

Шаг 7–8: скорость и архитектура

Проверьте скорость загрузки и показатели Core Web Vitals — особенно TTFB, который напрямую влияет на LCP. Затем проверьте архитектуру сайта: глубину вложенности важных страниц (в идеале — не более 3 кликов от главной) и наличие страниц-сирот, до которых не ведет ни одна внутренняя ссылка.

Шаг 9: повторная проверка

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

Как приоритизировать находки аудита

Не все проблемы одинаково критичны.

Вопросы скорости и разметки Schema.org важны, но обычно дают эффект на более длинной дистанции, чем устранение блокировок и проблем рендеринга.