Google Lighthouse проверяет сайты для AI-агентов
В Lighthouse v13.3.0 появилась экспериментальная категория Agentic Browsing. Разбираем, что она проверяет и почему llms.txt не стал SEO-фактором.
По состоянию на 27 мая 2026 года Google Lighthouse уже проверяет не только привычные вещи вроде производительности, доступности и SEO. В Lighthouse v13.3.0 появилась экспериментальная категория Agentic Browsing. По сути, это аудит Google Lighthouse для AI-агентов: он оценивает, насколько страница подходит для машинного взаимодействия.
Внутри проверки есть WebMCP, accessibility tree, CLS и llms.txt. Звучит как новая гонка за «AI SEO», но это неверная рамка. Официальная документация Chrome описывает аудит как developer-сигнал готовности сайта к агентам, а Google Search Central отдельно пишет, что для AI Overviews и AI Mode не нужны специальные AI-файлы, новая разметка или отдельные технические требования.
Что добавили в Google Lighthouse
В релизе Lighthouse v13.3.0 от 7 мая 2026 года заметное изменение сформулировано коротко: в default config добавили новую категорию agentic browsing. The Decoder 21 мая вынес это в новость про то, что Google начал тестировать сайты на совместимость с AI-агентами.
Ключевое слово здесь: «экспериментальная». В документации Chrome сказано, что категория Agentic Browsing и поддержка WebMCP основаны на proposed standards. Поэтому Lighthouse не выдаёт привычный weighted score от 0 до 100, как в Performance или Accessibility. Вместо этого отчёт показывает долю пройденных проверок, статусы pass/fail и информационные счётчики.
Для разработчика это важное отличие. Сейчас Agentic Browsing не стоит читать как «ещё один рейтинг, который надо довести до 100». Это набор воспроизводимых технических сигналов, которые можно отслеживать в QA и CI/CD, пока стандарты агентного веба ещё формируются.
Что именно проверяет Agentic Browsing
Смысл новой категории простой: агенту нужна не красивая страница, а предсказуемый интерфейс. Он должен понять, где кнопка, что делает форма, какое поле обязательно, не спрятан ли интерактивный элемент от accessibility tree и не уедет ли кнопка в момент клика.
| Проверка | Что смотрит Lighthouse | Зачем это AI-агенту |
|---|---|---|
| WebMCP | Регистрацию инструментов через Chrome DevTools Protocol WebMCP domain, включая declarative tools в HTML и imperative tools в JS. | Явный контракт: агенту не приходится угадывать, что делает форма или действие на странице. |
| Accessibility tree | Программные имена, подписи, роли, связи parent-child и видимость интерактивных элементов для accessibility tree. | Для агента это основная карта интерфейса. Если кнопка видна глазами, но не описана в дереве доступности, задача может сорваться. |
| CLS | Сдвиги макета через Cumulative Layout Shift. | Многие агенты используют скриншоты или координаты. Если элементы прыгают, агент кликает не туда. |
llms.txt |
Наличие машинно-читаемого Markdown-файла в корне сайта. Если сервер отдаёт 404, аудит помечается как N/A, потому что файл пока необязателен. | Файл может дать агенту краткую карту сайта и ключевые ссылки, но сам по себе не делает страницу удобной для действий. |
Самый практичный вывод не про llms.txt, а про старую дисциплину фронтенда. Семантический HTML, нормальные label, стабильные размеры изображений и предсказуемые формы внезапно становятся не только вопросом UX и доступности, но и вопросом машинной навигации.
llms.txt не стал новым SEO-фактором
Именно вокруг llms.txt легко построить миф: раз Lighthouse проверяет файл, значит Google требует его для AI-поиска. Официальные документы говорят другое.
На странице Chrome for Developers про llms.txt audit файл назван emerging convention для краткого машинно-читаемого описания сайта. Там же сказано: если файла нет и сервер отвечает 404, проверка получает статус Not Applicable, потому что размещение llms.txt сейчас optional.
А в документации Google Search Central по AI Overviews и AI Mode позиция ещё жёстче: для появления в этих функциях не нужны новые machine-readable files, AI text files или специальная schema.org-разметка. Страница должна быть индексируемой, подходить для показа со сниппетом и соответствовать обычным требованиям Google Search.
Поэтому корректная трактовка такая: llms.txt может быть полезен как справочная карта для агентов, особенно у документации, маркетплейсов и сервисов с большим числом разделов. Но Lighthouse не превратил его в кнопку «получить трафик из AI Overviews».
Что это меняет для веб-разработчиков
Для разработчиков Agentic Browsing похож на ранний чеклист агентной пригодности. Если сайт уже нормально проходит accessibility-аудиты, не двигает элементы после загрузки и не строит формы на хрупких div-конструкциях, база есть. Если форма бронирования, подписки или покупки понятна только человеку, который видит дизайн, агенту будет тяжелее.
Минимальный практический набор выглядит так:
- проверить формы: у каждого поля есть
name, связанныйlabelи понятная роль; - убрать неожиданные сдвиги макета: задавать размеры медиа, аккуратно вставлять рекламу и динамические блоки;
- не прятать интерактивные элементы от accessibility tree;
- экспериментировать с WebMCP только там, где нужен явный машинный контракт для формы или действия;
- делать
llms.txt, если у сайта действительно есть структура, которую стоит кратко объяснить агенту.
Это хорошо стыкуется с тем, как уже развиваются ИИ-агенты в браузере: агенту нужно не просто прочитать страницу, а надёжно выполнить действие. А блок WebMCP логически продолжает разговор про MCP как стандарт интеграции ИИ с инструментами, только на уровне веб-страницы и браузерного интерфейса.
Что это значит для AI SEO и GEO
Для SEO-команд новость полезна не как повод срочно писать llms.txt на все сайты, а как напоминание: AI-видимость всё меньше похожа на набор мета-трюков. Google Search Central в своём гайде для AI-функций снова перечисляет базовые вещи: разрешённое сканирование, внутренняя перелинковка, текстовая доступность важного контента, хороший page experience, качественные изображения и структурированные данные, которые совпадают с видимым текстом.
Agentic Browsing добавляет к этому слой «может ли машина действовать на странице». Это уже ближе к продуктовой и инженерной работе: навигация, формы, стабильность интерфейса, доступность, явные контракты. В этом смысле Google идёт рядом с другими попытками описать интерфейсы для агентных действий, включая Google A2UI.
Хорошая стратегия для сайта сейчас: не подменять базовое SEO файлом для LLM, а сделать страницу понятной сразу для трёх читателей: человека, поискового робота и агента, который должен выполнить задачу. Lighthouse Agentic Browsing полезен именно как ранний датчик третьего сценария.
Главный вывод
Google Lighthouse для AI-агентов пока работает осторожно: без финального стандарта, без классического score 0-100 и без обещаний влияния на поиск. Но направление видно. Сайты всё чаще будут оценивать не только как документы для чтения, но и как интерфейсы для действий.
Если у команды есть ресурс на один шаг, начинать стоит не с хайпового llms.txt, а с доступности и стабильности: нормальные подписи, предсказуемые формы, отсутствие резких сдвигов, понятная структура. Это поможет людям уже сейчас, а агентам - когда их браузерные сценарии станут массовыми.
