В общем, базовая история с аудитом страниц: мы каждый месяц отправляли подрядчику несколько страниц на проверку. Отбирали несколько максимально разных. Если находились проблемы на одной, мы также правили и на однотипных. В месяц так проверяли 4–6 страниц. И тут, из очевидных минусов — оплата подрядчика и ожидание.
Учитывая, что по сути нужно проверять однотипные вещи, вроде title, description, H1 и, например, ошибки в консоли, то я подумал, почему бы не попробовать отдать это агенту. Да, в деталях всё не так просто, но общая процедура каждый раз плюс‑минус одинаковая, а значит, можно настроить сценарий.
Так появилась идея научить нашего AI‑ассистента делать аудит новых страниц самостоятельно. Не в стиле «посмотри сайт и скажи, что думаешь», а по нормальной процедуре, с фиксированным результатом. На выходе я хотел получать гугл‑таблицу с чек‑листом и PDF со скриншотами проблемных мест.
Сначала казалось, что это задача на пару дней. Берём несколько готовых навыков, подключаем технический аудит, показываем агенту шаблон отчёта и просим его всё аккуратно заполнить. На практике оказалось всё сложнее.
Первая проблема возникла в отчёте
Первый аудит я запустил на странице GeoERP на нашем сайте. Агент действительно прошелся по странице, собрал часть данных и начал формировать отчет. Потом я открыл Google Sheets и понял, что он решил не заполнять шаблон, а переписать диапазоны целиком. Вместе с формулами, стилями, чекбоксами и валидацией.
То есть сама проверка страницы была еще не самой большой проблемой. Проблемой оказалось объяснить агенту, что гугл‑таблица это не черновик, где можно заниматься творчеством.
После этого появились первые жесткие правила:
«Таблицу нельзя создавать с нуля, только копировать готовый шаблон через gog sheets copy. Заполнять можно только конкретные ячейки в колонках A и C. Формулы, стили, чекбоксы, validation и строки разделов трогать нельзя. Если есть замечания, PDF со скриншотами обязателен. Название отчета тоже фиксированное, чтобы потом это все можно было нормально искать в папке аудитов.»
Первый важный вывод, довольно банальный, но всё же. Для AI‑агента недостаточно написать «заполни отчет». Надо описать, причём очень чётко, где именно он имеет право действовать, а где вообще нельзя ничего трогать.
Дальше стало понятно, что одного HTML мало
Вторая проблема была ожидаемой. Часть проверок можно сделать по HTML и метаданным, но аудит страницы этим не заканчивается. Нужно видеть, что реально происходит в браузере. Как выглядит первый экран, не ломается ли вёрстка на мобильном, есть ли ошибки в консоли, как ведут себя формы, не перекрывает ли модалка половину интерфейса, кликабельны ли CTA и так далее.
Поэтому в процесс добавился Playwright. Он делает скриншоты в нескольких разрешениях, проверяет страницу в браузере и помогает фиксировать проблемы не только текстом, но и картинками. Сейчас используются следующие разрешения — 1920×1080, 1440×900, 1366×768, 2560×1440 и 390×844. Набор не идеальный, но для первичного аудита хватает, особенно когда нужно быстро поймать очевидные проблемы на десктопе и мобилке.
Технический аудит я завёл через squirrelscan. Он дает health score, находит часть SEO‑проблем, ошибки безопасности, битые ссылки и проблемы производительности. Для accessibility добавил axe‑core, для JSON‑LD отдельную локальную проверку, для визуальной регрессии связку Playwright screenshots и pixelmatch.
В итоге навык по аудиту стал скорее мета‑навыком, который собирает несколько проверок в один сценарий. Там есть технический аудит, SEO, проверка доступности и структурированных данных, CRO, дизайн, формы, консоль, network errors и отчетность. Сам по себе ни один из этих модулей не делает ничего сложного, но вместе они дают нормальный воспроизводимый процесс.
Самое скучное оказалось самым важным
Где‑то на этом этапе я понял, что делаю не «AI, который проверяет сайты», а обычный рабочий регламент. Просто исполнителем стал агент.
Это сильно меняет подход. Если человеку можно сказать «заполни как обычно», то агенту надо объяснить, что именно значит «как обычно».
То есть, в каком порядке идти:
-
какие инструменты проверить до старта,
-
что делать, если Lighthouse недоступен,
-
что делать, если squirrelscan завис на 180 секундах,
-
как оформить ограничение проверки,
-
когда можно делать вывод, а когда нужна необходимость правок
А также, при обновлении агента были случаи, когда настройки инструментов или сам инструмент терялись, поэтому появился preflight. Перед аудитом агент проверяет доступность squirrel, Playwright, gog, Google Sheets, Google Drive и самой целевой страницы. Если что‑то недоступно, то агент сначала должен восстановить инструменты, и только после этого проводить аудит, иначе отчет будет не полным и придется повторять операцию. Инструмент фиксируется в ограничениях, а проверка продолжается по тем данным, которые реально можно собрать.
Например, Lighthouse CLI в нашем окружении чаще всего отсутствовал, поэтому performance приходилось брать через squirrelscan как fallback. Chromium на одном этапе не запустился из‑за отсутствующих системных библиотек. Visual regression при первом запуске не может сравнить страницу с baseline, потому что baseline еще нет. Формы нельзя отправлять без разрешения, иначе можно насоздавать ложных лидов и триггернуть алерты. Все это не ошибки страницы, но важные ограничения проверки, которые должны быть четко написаны в отчете.
И вот когда я зафиксировал четкий порядок действий, агент начал становится полезным.
Что получилось после нескольких итераций
За первые дни я прогнал несколько страниц. На одной из них агент нашел опечатки в тексте, поля калькулятора без подписей, слабую производительность на десктопе, проблемы с accessible names у соц‑иконок. На другой странице нашел слишком общий title, description, который не совпадал с содержанием, тяжелые WebP и ошибку в JSON‑LD. На главной странице нашего сайта всплыли изображения без alt, проблемы с ARIA dialog, focusable‑элементы внутри aria‑hidden и слишком длинный title.
Позже добавил модульные проверки, потому что базового набора стало не хватать для полноценного аудита. Часть инструментов уже были подключены раньше (упоминал их выше), но здесь я просто оформил их как отдельные модули с более четкими правилами использования и результатами. После этого стало проще отделять сомнительные ошибки от конкретных, воспроизводимых проблем, которые можно показать в отчёте и приложить скрин.
На текущий момент навык собрал 5 завершённых аудитов, объединяет 9 направлений проверки и делает один отчёт примерно за 10–15 минут. После публикации новой страницы он сам запускает аудит, собирает отчёт, сохраняет в гугл таблице и PDF в папку на диске. То есть мы не ждём внешнего аудита по несколько дней, а быстро правим какие‑то базовые ошибки перед тем, как страница нормально проиндексируется.
Что ломалось на первых этапах
-
Самая частая боль была с отчетностью. Агент постоянно добавлял что‑то лишнее в таблицах. Поэтому, сейчас он работает только по шаблону — структура не меняется, заполняются только разрешенные ячейки.
-
Нестабильность инструментов. Squirrelscan иногда не завершался за 180 секунд. Lighthouse отсутствовал. Chromium не стартовал без нужных библиотек. В обычном скрипте это легко превращается в падение процесса. В AI‑навыке это надо оформить как часть процедуры. Если инструмент недоступен, агент не делает вид, что все проверил, а пишет ограничение.
-
Граница между проверкой и действием. Например, формы можно анализировать, но не стоит отправлять тестовые заявки без явного разрешения. Cookie banner можно проверить в режиме чтения, но не нужно начинать кликать accept и reject, если задача была просто провести аудит. Это кажется очевидным, пока не начинаешь автоматизировать процесс. Потом внезапно понимаешь, что «не делай лишнего» тоже надо описывать явно.
Что я бы сделал иначе на старте
Может кому будет полезно, если только начинаете.
-
Если бы начинал заново, я бы не пытался сразу собрать большой навык. Сначала сделал бы минимальный сценарий из трёх вещей: preflight, один источник технического аудита и корректное заполнение отчёта. Только после этого добавлял бы Playwright, axe, schema, visual regression и всё остальное.
-
Ещё раньше бы зафиксировал формат ограничений. В аудите это критично. Агент должен понимать не только что найдено, но и что не удалось проверить. Иначе отчёт выглядит слишком «уверенно», а это опасно.
-
Точно раньше отделил бы «находку» от «рекомендации». Агент может найти проблему, но рекомендация должна быть привязана к контексту страницы. Например, «добавить alt» это не рекомендация, а заглушка. Нормальная рекомендация должна объяснять, к какому изображению, зачем и какой alt там нужен. Это отдельный слой качества, и его нельзя получить только подключением инструмента.
Главный вывод
После этой задачи я ещё сильнее убедился, что AI‑навык это не промпт. Промпт это максимум входная дверь. Дальше начинается обычная инженерная работа — порядок шагов, ограничения, обработка ошибок, формат результата, тестовые кейсы, примеры хороших и плохих ответов, правила остановки и так далее.
По ощущениям это очень похоже на обучение нового сотрудника. Если дать ему задачу «проверь сайт», результат будет каждый раз разный. Если дать регламент, примеры, инструменты и обратную связь на реальных задачах, постепенно появляется воспроизводимость.
Сейчас это ещё не идеальный аудитор и точно не замена полноценной экспертизе. Но как автоматическая первичная проверка новых страниц, вполне неплохо — он быстро ловит очевидные технические, SEO, accessibility и визуальные проблемы, аккуратно складывает их в отчёт.
Дальше уже буду докручивать. Хочу улучшить visual regression, аккуратнее обработать формы, добавить нормальный scoring по типам проблем и лучше связать рекомендации с конкретными блоками страницы.
Спасибо за внимание, если понравилось, могу рассказать и про другие наши наработки.
ссылка на оригинал статьи https://habr.com/ru/articles/1054836/