Глубочайший технический аудит сайтов с помощью ИИ

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

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

Что модель делает лучше человека, а что хуже

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

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

Где модель действительно сильна:

• Закономерности в тысячах строк выгрузки. Группировка адресов по повторяющемуся сегменту пути, поиск совпадающих заголовков, выделение шаблонных типов страниц.
• Расшифровка причин исключения страниц. Формулировки панели вебмастера сжаты до пары слов, и без пояснения непонятно, что именно делать с каждой причиной.
• Разбор журнала ошибок сервера. Отделяет фоновый шум от аварий и находит повторяющиеся записи, которые в потоке строк не видны.
• Черновик регулярного выражения для редиректов. Экономит время, но результат обязательно проверяется на списке реальных адресов.

Где на неё полагаться нельзя:

• Состояние вашего сайта прямо сейчас. Доступа к серверу нет, коды ответов модель не запрашивает — любой ответ про «ваш сайт» будет придуман.
• Текущие требования поисковых систем. Знания ограничены датой обучения, и детали вроде поддерживаемых директив устаревают первыми.
• Приоритеты без данных о бизнесе. Модель не знает, какие страницы приносят вам обращения, поэтому сортирует находки по формальной тяжести, а не по деньгам.

Главная ошибка при работе с моделью — задавать вопросы без данных. «Проверь мой сайт по адресу» даст правдоподобный текст, не имеющий отношения к вашему проекту. Модель не ходит по ссылкам сама и не видит кодов ответов; всё, что она сможет, — сочинить типовой список замечаний, который подойдёт любому сайту и не поможет ни одному.

Что собрать до того, как открывать чат

Качество разбора определяется тем, что вы принесли на вход. Минимальный набор выглядит так, и на его сбор уходит час-полтора.

• Выгрузка полного обхода краулером. Адрес, код ответа, title, description, H1, каноникал, метатег robots, глубина вложенности, число внутренних ссылок. Это основа, по ней находится большая часть проблем.
• Список исключённых страниц из панели вебмастера с причинами. Причины важнее самих адресов: «дубль», «недостаточно качественная» и «ошибка при обходе» лечатся по-разному.
• Статистика обхода за месяц. Сколько адресов робот берёт в сутки и какие именно. Отсюда видно, куда уходит краулинговый бюджет.
• Фрагмент журнала доступа сервера. Сутки-двое строк с обращениями роботов: время, адрес, код ответа, размер ответа.
• Файл robots.txt и карта сайта. Текстом, целиком, а не пересказом.
• Список страниц, которые приносят обращения. Без него любая приоритизация будет абстрактной.

Отдельно предупрежу про объём. Выгрузка на десятки тысяч строк целиком в диалог не поместится, и попытка «загрузить всё» приводит к тому, что модель разбирает первые несколько сотен строк и делает вид, что видела остальное. Правильный подход — заранее агрегировать: не список из двенадцати тысяч адресов, а сводка «сколько адресов в каждом коде ответа, сколько в каждом разделе, сколько с пустым title» плюс по десять примеров каждого типа. Разбор такой сводки будет честным.

Подробнее об этом — в статье «Технический аудит сайта».

Логи сервера: источник, который обычно не открывают

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

Помогу с продвижением: SEO-продвижение для бизнеса — вывожу сайты в топ Яндекса белыми методами.

Разбор логов руками — занятие на несколько часов, и как раз здесь модель экономит больше всего. Что стоит из них вытащить:

• Распределение кодов ответов по обращениям робота. Если заметная доля запросов заканчивается кодами 404 и 301, робот тратит квоту на несуществующее.
• Какие разделы обходятся чаще всего. Регулярная находка: 70% обращений приходится на страницы фильтров и внутреннего поиска, а карточки товара робот берёт раз в месяц.
• Время ответа сервера в динамике. Плавающее время — признак упирания в лимиты хостинга, и это меняет всю картину аудита.
• Страницы, которые робот не запрашивал ни разу. Самая ценная выборка: это адреса, до которых он не дошёл, обычно из-за глубокой вложенности или отсутствия внутренних ссылок.
• Обращения к несуществующим адресам извне. Показывают, на какие старые страницы до сих пор ведут внешние ссылки.

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

Коды ответов и редиректы: где модель находит то, что пропускает глаз

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

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

Второе — мягкие ошибки: адреса, которых нет, отдают код успешной загрузки и страницу с надписью «ничего не найдено». В выгрузке они выглядят как обычные страницы, отличаются только коротким текстом и повторяющимся title. Это ровно тот случай, когда группировка по шаблону работает лучше ручного просмотра. Подробнее про то, как 404, 301 и 302 крадут вес страниц, я писал отдельно.

Третье — противоречия между сигналами. Страница закрыта метатегом robots, но лежит в карте сайта. Каноникал ведёт на адрес, который сам отдаёт редирект. Страница открыта для обхода, но недоступна по внутренним ссылкам. Каждое противоречие по отдельности выглядит мелочью, а вместе они дают роботу несогласованную картину сайта, и он выбирает поведение сам.

Тему разбирал отдельно: «Технический SEO-аудит своими руками: пошаговый чек-лист из 40 пунктов».

Дубли и параметры: разбор массива адресов

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

Признак в выгрузке	Источник	Способ лечения
Одинаковый title у десятков адресов с параметрами	Фильтры и сортировки каталога	Каноникал на основную категорию, запрет обхода параметров сортировки
Один товар в нескольких путях	Товар привязан к нескольким категориям	Единый адрес карточки, каноникал с остальных
Адреса с рекламными метками в индексе	Переходы из рассылок и объявлений	Директива Clean-param, каноникал без параметров
Пары адресов со слэшем и без	Сервер отдаёт обе версии кодом 200	Одно правило редиректа на весь сайт
Страницы с пометкой «вложение» в WordPress	Каждое изображение порождает страницу	Отключение страниц вложений или редирект на запись
Тысячи адресов вида поиска по сайту	Внутренний поиск открыт для обхода	Запрет в файле robots.txt

Полезная формулировка запроса: не «найди дубли», а «сгруппируй эти адреса по повторяющемуся сегменту пути и по совпадению title, для каждой группы укажи предполагаемый источник и число адресов». Первый вариант даёт рассуждение о дублях вообще, второй — таблицу, с которой можно идти к разработчику.

Как сформулировать запрос, чтобы получить разбор, а не пересказ

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

1. Роль и ограничение. Указать, что нужен разбор приложенных данных, а не общие рекомендации, и что выводы, не подтверждённые данными, помечаются как гипотезы.
2. Контекст проекта. Тип сайта, число страниц, движок, какие страницы приносят обращения, что менялось за последние месяцы. Без этого приоритеты будут случайными.
3. Сами данные. Агрегированные сводки плюс примеры. Формат лучше задать явно: таблица со столбцами, а не свободный текст.
4. Форма ответа. Что должно быть на выходе: перечень находок, для каждой — признак в данных, вероятная причина, способ проверки и оценка влияния. Требование «указать способ проверки» отсекает большую часть выдуманных выводов, потому что заставляет модель привязываться к тому, что можно измерить.

Отдельный приём, который сильно повышает качество: просить не список, а разбор противоречий. Формулировка «найди в этих данных места, где сигналы противоречат друг другу, и объясни, что робот увидит в каждом случае» даёт находки, которых нет ни в одном шаблонном чек-листе. Такой же приём работает при подготовке сайта к продвижению в нейросетях и AI-поиске: там тоже важнее согласованность данных, чем формальное наличие тегов.

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

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

Если нужна помощь по теме — обучение SEO-продвижению.

Три типа ошибок, которые я вижу регулярно:

Смежный материал по теме — «Я провёл аудит 500 сайтов — вот 5 ошибок, которые есть у каждого».

• Устаревшие рекомендации. Директивы и атрибуты, которые уже не поддерживаются, продолжают жить в текстах, на которых обучалась модель. Признак — совет добавить что-то в код без объяснения, что именно это меняет.
• Правдоподобные, но выдуманные числа. Конкретные пороги вроде «страница должна загружаться быстрее 1,8 секунды» звучат авторитетно и не имеют источника. Ориентиры существуют, но их берут из документации, а не из ответа в чате.
• Регулярные выражения, которые ловят лишнее. Правило редиректа, составленное моделью, часто работает на примере и захватывает половину сайта на практике. Проверять обязательно на списке из полусотни адресов до применения.

Рабочее правило простое: модель формулирует гипотезу, проверка делается инструментом. Сказала, что раздел не обходится, — смотрим статистику обхода. Сказала, что страницы дублируются, — проверяем коды ответов и каноникал руками на пяти примерах. Сказала, что виновата скорость, — меряем время ответа сервера. Ни одна правка не уходит на сайт без подтверждения. Этот же принцип лежит в основе обычного технического SEO-аудита своими руками — просто там гипотезы вы формулируете сами.

От находок к плану правок

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

Находка	Что ломает	Когда чинить
Раздел закрыт от индексации по недосмотру	Страниц нет в поиске вовсе	Немедленно
Несуществующие адреса отдают код успеха	Индекс забивается пустышками	Немедленно
Обход уходит на фильтры вместо карточек	Новые страницы месяцами не появляются в поиске	В первую неделю
Время ответа сервера выше секунды	Медленный обход, потеря посетителей	В первую неделю
Цепочки редиректов в три шага	Потеря сигналов и лишние запросы	В первый месяц
Одинаковые title у страниц каталога	Страницы конкурируют между собой	В первый месяц
Отсутствие микроразметки	Сниппет беднее соседних в выдаче	Планово

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

Частые вопросы

Может ли модель заменить краулер?
Нет. Краулер обходит сайт и собирает факты, модель работает только с тем, что ей дали. Это разные звенья одной цепочки: сначала обход, потом разбор. Попытка пропустить первый шаг превращает аудит в сочинение на тему.

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

Что делать, если модель и краулер противоречат друг другу?
Верить измерению. Краулер показывает, что реально ответил сервер в момент запроса, модель рассуждает по тексту выгрузки и может неверно понять формат. Расхождение обычно означает, что данные подготовлены неаккуратно: перепутаны столбцы, обрезана часть строк, потеряна кодировка.

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

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

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

Коротко

• Модель не заменяет краулер и панель вебмастера: она разбирает уже собранные данные, а не ходит по сайту сама.
• Качество аудита определяется входными данными — обход краулером, исключённые страницы с причинами, статистика обхода, логи сервера и список страниц, приносящих обращения.
• Большие выгрузки нужно агрегировать до отправки: сводка по типам плюс примеры работает лучше, чем попытка загрузить десять тысяч строк.
• Логи сервера — самый недооценённый источник: там видно, куда робот тратит обход и какие страницы он не запрашивал ни разу.
• Запрос строится из роли, контекста проекта, данных и требуемой формы ответа; требование указывать способ проверки отсекает выдуманные выводы.
• Любая находка модели — гипотеза, которая подтверждается инструментом, и только после этого превращается в правку.

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