Годами PageSpeed Insights оценивал производительность, доступность, рекомендации и SEO. В 2026 году в этом ряду тихо появился пятый пункт — Agentic Browsing. Он отвечает на вопрос, который остальные четыре категории игнорируют: может ли ИИ-агент действительно работать с этой страницей?
Это руководство о том, как применить проверку на своём сайте: запустить её, понять, что на самом деле говорит каждый аудит, и уйти со списком исправлений.
Что вы получите в итоге
Для кого это: для SEO-специалистов, разработчиков и владельцев сайтов, которым важно знать, как ведут себя страницы, когда их просматривает агент, а не человек.
Что у вас будет в конце: реальный результат Agentic Browsing для вашего сайта, разбор каждого аудита по статусам — пройдено, не пройдено, неприменимо — и приоритизированный список исправлений.
Что нужно для старта: публично доступный адрес страницы, около десяти минут на первый запуск и доступ к коду, если вы планируете что-то исправлять в тот же день.
Критерий готовности: вы можете объяснить дробный результат аудит за аудитом и определить, какие сбои действительно мешают агенту выполнить задачу на вашей странице.
Откуда взялась эта проверка и почему сейчас
Категории Agentic Browsing год назад не существовало. Внедрение шло в три этапа, и все они задокументированы Google:
- 7 мая 2026 года: Lighthouse 13.3 добавляет категорию в конфигурацию по умолчанию, и она становится частью стандартного запуска.
- 22 июня 2026 года: блог Chrome for Developers объявляет о ней в материале о наборе инструментов для подготовки сайта к работе агентов, вместе с DevTools для агентов и рекомендациями по WebMCP.
- 20 июля 2026 года: Lighthouse 13.4.1 включает категорию для API-пути PageSpeed Insights и сообщает, что релиз доберётся до PageSpeed Insights в течение двух недель. Значит, публичный запуск пришёлся на начало августа 2026 года.
Когда я запускал проверку 11 сентября 2026 года, в подвале отчёта было указано эмулированное устройство и Lighthouse 13.4.1, а Agentic Browsing стоял прямо рядом с SEO. То есть функция работает в общем доступе, а не только для избранных. И при этом она честно помечена как незавершённая: в описании категории прямо сказано, что раздел ещё в разработке и может меняться.
Одна практическая деталь перед стартом: PSI выполняет эту категорию на своей стороне. Для проверок уровня страницы не нужны ни особые версии Chrome, ни участие в origin trial. Требования к версии возникают, только если запускать категорию локально в Chrome DevTools.
Запустите проверку на своём сайте
- Откройте pagespeed.web.dev и вставьте адрес страницы. Сначала запустите проверку для мобильных, затем повторите для десктопа: два лабораторных запуска оцениваются отдельно.
- Дождитесь окончания лабораторных данных. Полевые данные вверху приходят из Chrome UX Report и загружаются быстро. Запуск Lighthouse ниже занимает больше времени, и именно там находятся категории.
- Найдите строку с оценками. Вы увидите производительность, доступность, рекомендации, SEO, а затем Agentic Browsing — в виде дроби, а не оценки от 0 до 100.
- Разверните категорию. Список аудитов группируется в разделы Agent Accessibility, WebMCP и привычные блоки пройденных и неприменимых проверок.
- Откройте каждый проваленный аудит. Любая строка раскрывается и показывает конкретное правило, элемент или файл, из-за которого возник сбой, — именно это нужно для задачи на исправление.
Пятая категория стоит в одном ряду с оценками, которые SEO-команды проверяют каждый день. Снимок сделан в PageSpeed Insights 11 сентября 2026 года.
Проверка качества: прежде чем сравнивать результаты с коллегой, уточните версию Lighthouse в деталях запуска. PSI обновляет Lighthouse по собственному графику, и категория продолжает меняться от версии к версии.
Если что-то пошло не так: иногда PSI возвращает тайм-аут RPC на тяжёлых страницах. У меня это случилось на большом сайте прямо во время исследования. Повторите запуск или проверьте страницу в локальном Lighthouse.
Как правильно читать дробный результат
У Agentic Browsing нет взвешенной оценки от 0 до 100, и это сделано намеренно. Документация Lighthouse объясняет: стандарты агентного веба ещё формируются, поэтому акцент делается на практичных сигналах, а не на рейтинге.
Вот арифметика, которая действительно важна:
Отображение | Что означает |
|---|---|
3/3 | Все оцениваемые проверки пройдены. Неприменимые аудиты не учитываются. |
1/3 | Одна пройдена, две провалены. В знаменателе только пройденные и проваленные аудиты. |
0/3 | Пока не пройдено ничего из оцениваемого. Частая картина при первом запуске на тяжёлой странице с рекламой. |
Дроби нет | Все аудиты неприменимы или категория не запускалась. Проверьте детали запуска. |
Ловушка в том, чтобы прочитать 1/3 как «готовность к агентам 33 процента». Это не процент от чего-либо. Это счётчик: из трёх проверок, которые можно было оценить на этой странице, одну она прошла, а аудиты, которые не применились, вообще не попали в расчёт. В отчёте, который я разбирал, запустилось шесть аудитов, три оказались неприменимы, а оставшиеся три дали результат 1/3.
Результат меняется и между запусками на одной и той же странице. Lighthouse называет три причины: динамическая регистрация инструментов (инструменты WebMCP, зарегистрированные из JavaScript, могут попасть в отчёт или пропасть в зависимости от момента), изменения DOM, которые перестраивают дерево доступности, и сдвиги макета из-за рекламы, изображений без размеров или вставленного контента. Если ваш результат колеблется, скорее всего, дело в этом.
Разберите шесть аудитов
Текущая сборка PSI запускает шесть аудитов. Готовится ещё один: в ветке разработки Lighthouse уже добавлена проверка ai-catalog.json (Agent Resource Discovery) в новой группе Agent Discoverability, так что считайте этот список зависящим от версии.
Аудит | Что проверяет | Что означает «неприменимо» |
|---|---|---|
Дерево доступности некорректно | Подмножество правил доступности с фокусом на агентов: программные имена и метки, валидная структура ARIA и элементы, которые остаются интерактивными, будучи скрытыми от дерева | Никогда; оценивается всегда |
llms.txt не соответствует рекомендациям | Что | Файл вернул 404. Отсутствие llms.txt считается допустимым, а не сбоем |
Совокупный сдвиг макета | Визуальную стабильность, чтобы агенты, действующие по позиции элементов, не нажимали не туда во время сдвига | Никогда; оценивается всегда |
WebMCP-инструменты зарегистрированы | Регистрирует ли страница инструменты WebMCP через декларативный или императивный API | Инструменты WebMCP не обнаружены |
Покрытие WebMCP-форм | Декларативные формы, у которых не хватает разметки инструментов | То же самое |
Валидность WebMCP-схем | Публикуют ли зарегистрированные инструменты корректные схемы входа и выхода | То же самое |
Развёрнутый вид категории: два сбоя, один пройденный аудит и три неприменимые проверки. Список сбоев — самый короткий путь к задаче.
Три аудита WebMCP со статусом «неприменимо» в 2026 году — норма. WebMCP это предложенный стандарт на стадии origin trial и раннего превью, и у него два API: декларативный, который размечает обычные HTML-формы, и императивный, который регистрирует инструменты из JavaScript. Большинство сайтов пока не внедрили ни то, ни другое, поэтому в отчётах там обычно три серых круга. Серый — это не красный. Не считайте это сбоем.
Что исправлять по итогам проверки
Четыре темы исправлений покрывают шесть аудитов. Три строки WebMCP требуют внимания, только если вы действительно выпускаете инструменты для агентов.
Сделайте дерево доступности читаемым для агентов
Агенты опираются на дерево доступности как на основную карту вашей страницы. В нём перечислены роли, имена и состояния. Кнопка без доступного имени — тупик и для них, и для пользователей скринридеров.
Что делать: пройдите по проваленным правилам из развёрнутого аудита. Обычные подозреваемые: кнопки только с иконкой, поля формы без метки, ссылки с текстом вроде «нажмите здесь», некорректные комбинации ролей ARIA и дублирующиеся идентификаторы, на которые ссылается ARIA. Предпочитайте семантический HTML, добавляйте атрибут for к меткам и задавайте кастомным виджетам явные роли и tabindex там, где нативный элемент невозможен.
Ожидаемый результат: аудит переходит в пройденное состояние, и обычная оценка доступности тоже часто растёт, потому что версия для Agentic Browsing — это сфокусированное подмножество тех же проверок.
Если застряли: когда список исправлений разрастается до сотен элементов, не гоняйтесь за каждым. Исправьте общий компонент, например кнопку только с иконкой в шапке, и запустите проверку заново. Один компонент часто закрывает десятки строк.
Опубликуйте llms.txt, который проходит проверку формата
Здесь есть ловушка, в которую попадают аккуратные люди. Аудит проверяет не только наличие /llms.txt. Он проверяет содержимое файла, и файл с голыми адресами проваливается, потому что проверка ищет ссылки в формате Markdown.
Что делать: создайте /llms.txt в корне домена с заголовком H1 и настоящими Markdown-ссылками:
# Название компании
Короткое описание того, что содержит сайт и как им пользоваться.
## Ключевые страницы
- [Обзор продукта](https://example.com/product)
- [Цены](https://example.com/pricing)
- [Документация](https://example.com/docs)Ожидаемый результат: аудит станет зелёным. Ответ 404, наоборот, показывается как неприменимый, и сегодня это допустимо. Ответ 500-й серии или ошибка загрузки — настоящий сбой, который нужно исправлять на стороне сервера.
Проверка качества: загрузите свой /llms.txt в терминале и посчитайте ссылки. Если они выглядят как https://example.com/pricing без квадратных скобок, аудит провалится, даже когда файл опубликован и читается людьми.
Честная оговорка: Google Поиск не использует llms.txt. В собственном руководстве Google по оптимизации для ИИ прямо сказано, что файл не приносит сайту ни пользы, ни вреда для видимости и позиций, потому что Google Поиск их игнорирует. Пишите его для агентных инструментов, которые читают эту конвенцию, а не ради рейтинга.
Стабилизируйте макет, чтобы агент мог попасть по цели
Сдвиг макета стал важнее, чем раньше. Агент, который находит кнопку и затем кликает по её координатам, промахнётся, если реклама, баннер или поздно загрузившееся изображение сдвинет кнопку на 200 пикселей вниз между этими двумя моментами.
Что делать: задайте явные ширину и высоту (или aspect-ratio) для изображений и встраиваемых блоков, резервируйте фиксированное место под рекламные слоты и баннеры согласия, не вставляйте новый контент выше существующего после загрузки и анимируйте через transform, а не через свойства, вызывающие пересчёт макета.
Ожидаемый результат: совокупный сдвиг макета ниже 0,1 в лабораторном запуске — тот же порог, что используется в Core Web Vitals.
Проверка качества: блок про причины сдвига макета в разделе производительности называет конкретные элементы. Начните оттуда, а не с догадок.
Решение по WebMCP можно отложить
Три аудита WebMCP оцениваются, только если сайт регистрирует инструменты. Если у вас есть бронирование, оформление заказа, форма поддержки или любая структурированная задача, которую агент мог бы выполнить, WebMCP стоит прототипировать: он прямо говорит агенту, какой инструмент вызывать, вместо того чтобы заставлять угадывать по DOM. Chrome поставляет эту функцию за origin trial и локальным флагом для тестирования, так что это реальная опция, а не мысленный эксперимент.
Если автоматизировать нечего, не трогайте WebMCP. В трёх серых кругах нет ничего страшного. Единственное, чего делать не стоит, — регистрировать декоративный инструмент, чтобы дробь выглядела лучше. Эта категория — сигнал готовности, и подыгрывание ей лишает её смысла.
Проверьте исправление
Запустите тот же адрес в PSI снова и сравните три вещи, а не одну: дробь, статусы конкретных аудитов и тип устройства. Исправление может сдвинуть дробь, не решив проблему, которая вас волновала, а мобильная и десктопная версии дают отдельные лабораторные результаты.
Чтобы ускорить итерации, запускайте Lighthouse локально вместо ожидания PSI. Категория входит в Lighthouse 13.3 и новее, поэтому локальная установка её подхватит. Если вам нужна версия в панели DevTools, документация Google отмечает, что для тестирования категории требуется Chrome 150 или новее, а для аудитов WebMCP нужно ещё и участие в origin trial.
Ведите короткую запись до и после. Достаточно строки с датой вроде «2026-09-11: мобильные 1/3, провалены дерево доступности и llms.txt». Она подскажет, настоящая ли это регрессия позже или просто колебание между запусками.
Чем эта проверка не является
Три вещи, которых она не делает, потому что путаница вокруг них очень распространена:
- Это не фактор ранжирования. Google называет категорию информационной и не включённой в бенчмарки. На позиции в Google Поиске ваша дробь Agentic Browsing не влияет.
- Это не оценка видимости в ИИ. Она измеряет, может ли агент работать со страницей, и ничего не говорит о том, ссылаются ли на вас ChatGPT или Perplexity в ответах.
- Это не вердикт «прошло или не прошло» для сайта. Низкая дробь на простой маркетинговой странице обычно означает, что оценивать было почти нечего, а не то, что агенты заперты снаружи.
Полезная оптика такая: категория проверяет, выдерживает ли сайт, когда посетитель — не человек. Всё, что она вознаграждает, стоит делать и так: семантический HTML, стабильный макет, подписанные элементы управления. Руководство Google о дружелюбности к агентам заканчивается тем же выводом: то, что делает сайт готовым для агентов, делает его лучше и для людей.
Оставьте её в цикле регулярных проверок
Готовность к агентам — из тех областей, где платформа движется быстрее чек-листа. Две привычки помогут оставаться в курсе, не превращая это в проект:
- Перезапускайте проверку после любых изменений шаблона, навигации, форм или оформления заказа. Именно такие правки двигают дерево доступности и стабильность макета.
- Отслеживайте дробь по шаблонам, а не по отдельным адресам. Десять карточек товара с одинаковым результатом — это проблема шаблона, и одно исправление решает все десять.
Проверка PSI намеренно узкая: шесть аудитов, одна страница за раз. Если нужна более широкая картина, включая правила robots, карточки MCP-серверов, обнаружение OAuth и сигналы агентной коммерции, у Auspia есть бесплатная проверка Agent Readiness: она сканирует адрес по этим протокольным стандартам и показывает таблицу сравнения.
Частые вопросы
Влияет ли оценка Agentic Browsing на позиции в Google? Нет. Google описывает категорию как информационную, и она не входит в системы ранжирования поиска. Относитесь к ней как к проверке готовности для агентов, а не как к SEO-оценке.
Почему дробь изменилась между двумя запусками на одной странице? Динамическая регистрация инструментов, изменения DOM, перестраивающие дерево доступности, и поздние сдвиги макета дают разброс между запусками. Повторите тест и сравнивайте список аудитов, а не только дробь.
Почему все три аудита WebMCP показываются как неприменимые? Потому что ваша страница не регистрирует инструменты WebMCP. В 2026 году это ожидаемое состояние для большинства сайтов, и это не сбой.
Отсутствие llms.txt — это проблема? Для этого аудита нет. Ответ 404 считается неприменимым. А вот файл, который существует, но оформлен с ошибками, проваливается, поэтому если публикуете — публикуйте правильно.
Можно ли запускать это в CI? Да, как только категория появится в вашей версии Lighthouse. Аудиты по замыслу детерминированы, и именно это делает их пригодными для проверок в пайплайне. Учтите, что части WebMCP зависят от поддержки браузера и участия в origin trial, поэтому в большинстве CI-окружений они, скорее всего, будут показаны как неприменимые.
Нужен ли Chrome 150, чтобы всем этим пользоваться? Нет. PageSpeed Insights выполняет проверку на своей стороне. Требование Chrome 150 касается локального запуска категории в DevTools.
Автор: Alice Monroe, аналитик инструментов AI SEO в Auspia, исследует более 150 инструментов. Пишет об SEO и инструментах ИИ-поиска, о том, какие проверки стоят вашего времени и как встроить их в рабочую рутину.
