PageSpeed Insights добавил «Агентный просмотр»: сайты теперь проверяют на готовность к ИИ-агентам

В PageSpeed Insights от Google появился новый блок проверок: «Агентный просмотр». На английском это Agentic Browsing. Если раньше мы привычно смотрели на производительность, доступность, лучшие практики и SEO, то теперь рядом появляется ещё один слой: насколько сайт понятен и удобен для ИИ-агентов.

Звучит немного как фантастика из презентации про будущее, но это уже не будущее. Это вкладка в обычном PageSpeed Insights. То есть ИИ-агенты постепенно переезжают из разговоров в технические аудиты сайтов.

Я прогнал свой сайт через PageSpeed Insights и увидел новый раздел. На скриншоте по krivoshein.site результат выглядит бодро: производительность 100, доступность 92, лучшие практики 96, SEO 100, а «Агентный просмотр» показывает 3/3. Для технического блога это приятнее, чем зелёный статус systemctl после долгой ночи.

Что произошло

В Lighthouse и PageSpeed Insights появился новый набор проверок Agentic Browsing. Он оценивает не скорость загрузки страницы в привычном смысле, а то, насколько сайт пригоден для машинного взаимодействия.

Если по-человечески, проверка смотрит не только на то, как сайт видит пользователь в браузере, но и на то, насколько сайт понятен агенту: есть ли машинно-читаемое описание, нормальная доступность, стабильная разметка, корректные формы и WebMCP-интеграция, если она используется.

Важно: категория пока экспериментальная. Google прямо пишет, что Agentic Browsing и WebMCP support основаны на предлагаемых стандартах, а не на окончательно устоявшейся веб-норме. Поэтому не надо бежать ночью и переписывать весь сайт. Но посмотреть, что происходит, уже точно стоит.

Что такое Agentic Browsing

Agentic Browsing можно перевести как «агентный просмотр» или «просмотр сайта ИИ-агентом». Смысл в том, что сайт должен быть удобен не только человеку, но и программе, которая действует от имени пользователя.

Например, обычный пользователь видит кнопку «Отправить заявку», форму обратной связи, меню, карточку товара или блок с услугами. ИИ-агенту нужно понять то же самое, но через структуру страницы: HTML, accessibility tree, подписи элементов, формы, описания действий и стабильность интерфейса.

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

Причём здесь WebMCP

WebMCP это попытка дать сайтам способ явно описывать действия для ИИ-агентов. Не просто «вот форма, сам догадайся», а «вот инструмент, он нужен для записи, заявки, подписки или другого конкретного действия».

В документации Lighthouse есть проверки, связанные с WebMCP: зарегистрированные инструменты, декларативное описание форм и валидность схемы. То есть сайт может не только показывать форму пользователю, но и объяснять агенту, что эта форма делает и какие параметры ей нужны.

Простой пример декларативной формы выглядит примерно так:

 
 Ваше имя  Email  Описание задачи 

Отправить заявку

 

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

Почему это важно для SEO и продвижения

Не надо делать громкий заголовок «Google добавил новый фактор ранжирования». Это было бы красиво, но слишком нагло. В документации речь идёт об аудитах Lighthouse и PageSpeed Insights, а не о прямом сигнале ранжирования в поиске.

Но игнорировать это тоже странно. PageSpeed Insights давно стал инструментом, на который смотрят разработчики, SEO-специалисты, владельцы сайтов и клиенты. Если там появляется отдельный блок для ИИ-агентов, значит тема уже вышла из лаборатории и пришла в обычный веб-аудит.

Для продвижения это означает простую вещь: сайт должен быть понятен не только поисковому роботу и человеку, но и новым посредникам между пользователем и сайтом. Этими посредниками всё чаще становятся ИИ-ассистенты, агенты, браузерные помощники и сервисы, которые читают сайт не глазами, а структурой.

Старое SEO никуда не делось. Title, description, индексация, скорость, Core Web Vitals, нормальный контент и внутренняя структура всё ещё важны. Просто рядом появляется ещё один слой: agent-ready.

Что PageSpeed теперь смотрит для ИИ-агентов

В документации Lighthouse выделены несколько направлений. Они хорошо ложатся на практику обычного WordPress-сайта.

• llms.txt: машинно-читаемое краткое описание сайта в корне домена.
• WebMCP tools: явно зарегистрированные действия сайта для агентов.
• Описание форм: чтобы агент понимал, что делает форма и какие поля ей нужны.
• Accessibility tree: нормальная семантика, подписи, роли, доступность интерактивных элементов.
• Layout stability: стабильность интерфейса, чтобы элементы не прыгали во время взаимодействия.

Самое интересное здесь, что многие пункты пересекаются с нормальной веб-разработкой. Хороший HTML, доступные формы, стабильная вёрстка и понятная структура полезны всем. Просто теперь это смотрят ещё и через призму ИИ-агентов.

llms.txt: маленький файл, который становится заметным

Файл llms.txt кладётся в корень сайта. Он нужен для краткого машинно-читаемого описания: что это за сайт, какие разделы важны, где документация, где RSS, где карта сайта, где основные материалы.

Для обычного блога или сайта услуг это может выглядеть так:

 # krivoshein.site Сайт ИП Кривошеина Алексея Сергеевича. Темы: WordPress, Linux, DevOps, Nginx, Docker, Python, SEO, контекстная реклама. ## Основные разделы - Блог: https://krivoshein.site/ - Услуги: https://krivoshein.site/uslugi/ - Контакты: https://krivoshein.site/contacts/ - RSS: https://krivoshein.site/feed/ - Sitemap: https://krivoshein.site/sitemap.xml ## Для ИИ-агентов Можно использовать материалы сайта для краткого цитирования, обзора тем и перехода к первоисточнику. При использовании технических инструкций проверяйте актуальность команд и конфигураций. 

Проверить файл можно обычным curl:

 curl -I https://example.com/llms.txt curl https://example.com/llms.txt 

Ответ должен быть примерно таким:

 HTTP/2 200 content-type: text/plain; charset=utf-8 

Если файл отдаётся с ошибкой 500, 403 или странным редиректом, агентам это не понравится. Да и людям тоже. Веб любит простоту: запросил текстовый файл, получил текстовый файл.

Как добавить llms.txt на WordPress-сайт

Самый простой способ, положить статический файл в корень сайта. Например, если сайт лежит в /var/www/example.com/htdocs:

 cd /var/www/example.com/htdocs sudo nano llms.txt 

После сохранения проверяем доступность:

 curl -I https://example.com/llms.txt curl https://example.com/llms.txt 

Если используется Nginx и хочется явно задать тип ответа, можно добавить location:

 location = /llms.txt { default_type text/plain; try_files /llms.txt =404; } 

Потом проверяем конфиг и перезагружаем Nginx:

 sudo nginx -t sudo systemctl reload nginx 

Агентам нужна доступность, даже если вы не думали про доступность

Один из важных моментов в Agentic Browsing, это accessibility tree. Для ИИ-агента доступность становится чем-то вроде машинного зрения. Если кнопка не имеет понятного имени, форма не подписана, а элементы интерфейса сделаны через случайные div, агенту сложнее понять, что происходит.

Это хороший повод перестать относиться к accessibility как к «галочке для западных сайтов». Семантический HTML, нормальные label у форм, alt у изображений и понятные кнопки полезны всем: людям, поисковикам, скринридерам и теперь ещё ИИ-агентам.

Плохой пример:

 
OK
 

Нормальный пример:

  Отправить заявку  

Кнопка должна быть кнопкой. Ссылка должна быть ссылкой. Заголовок должен быть заголовком. Это не занудство, это санитария фронтенда.

Стабильность интерфейса теперь тоже важна для агентов

Layout stability раньше чаще обсуждали в контексте CLS и Core Web Vitals: чтобы страница не прыгала при загрузке, а пользователь не нажимал случайно не туда. Для ИИ-агентов логика похожая.

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

Что стоит сделать:

• указывать размеры изображений;
• не вставлять тяжёлые блоки выше основного контента без резервирования места;
• аккуратно работать с рекламой;
• не менять DOM хаотично после загрузки;
• не рисовать ключевые кнопки только после долгого JavaScript-ритуала.

Тут всё как обычно: если сайт ведёт себя стабильно, его легче использовать и людям, и машинам.

Проверка своего сайта руками

Кроме PageSpeed Insights, можно быстро проверить несколько вещей с сервера или локальной машины.

Проверяем llms.txt:

 curl -I https://example.com/llms.txt curl https://example.com/llms.txt | head -40 

Проверяем robots.txt:

 curl https://example.com/robots.txt 

Проверяем sitemap:

 curl -I https://example.com/sitemap.xml 

Проверяем RSS:

 curl -I https://example.com/feed/ 

Проверяем основные заголовки:

 curl -I https://example.com/ 

Если сайт готовился под ИИ-агентов чуть глубже, можно добавить Link headers, чтобы явно подсказать важные машинные точки входа:

 add_header Link '; rel="alternate"; type="text/plain"' always; add_header Link '; rel="sitemap"; type="application/xml"' always; add_header Link '; rel="alternate"; type="application/rss+xml"' always; 

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

Что это значит для WordPress-разработчика

Для WordPress это направление вполне практичное. Особенно если сайт не просто визитка, а блог, база знаний, каталог, сайт услуг или документация к продукту.

Я бы смотрел на такую базовую подготовку:

• нормальные title и description;
• открытый sitemap;
• рабочий RSS;
• понятная структура рубрик;
• адекватные заголовки H1, H2, H3;
• alt у важных изображений;
• доступные формы;
• стабильная вёрстка без прыжков;
• llms.txt в корне сайта;
• по возможности, отдельные Markdown-версии ключевых материалов;
• чистые страницы без мусора в HTML.

Для моего сайта эта тема ложится естественно. Технический блог, инструкции, команды, конфиги, WordPress и DevOps. Если ИИ-агент читает такой сайт, пусть видит структуру нормально, а не копается в HTML как археолог с фонариком.

Чего делать не надо

Самая плохая реакция на новую проверку, начать срочно накручивать видимость. Например, сгенерировать огромный llms.txt на 200 килобайт, добавить фейковые WebMCP-инструменты, напихать в заголовки всё подряд и радоваться зелёному кружку.

Так делать не стоит. Если сайт ничего не продаёт через форму, не надо изображать сложный агентный интерфейс. Если нет API, не надо придумывать API ради красивой проверки. Если нет нормального контента, llms.txt его не создаст.

Agent-ready это не магическая кнопка продвижения. Это техническая готовность сайта к новому способу взаимодействия. Сначала нормальный сайт, потом агентная обвязка. Не наоборот.

Мой вывод

Появление «Агентного просмотра» в PageSpeed Insights, это важный маркер. ИИ уже не просто где-то рядом с поиском, текстами и чатами. Он постепенно входит в обычные инструменты веб-аудита.

Это не значит, что завтра все сайты без WebMCP улетят в подвал выдачи. Но это значит, что направление понятно: сайты будут оценивать не только по скорости, SEO и доступности для человека, но и по удобству для ИИ-агентов.

Для разработчиков и владельцев сайтов это хороший момент заняться базовой технической гигиеной: структура, доступность, стабильность, sitemap, RSS, llms.txt, аккуратные формы и понятные машинные точки входа.

ИИ-агенты не отменяют классическое SEO. Они добавляют ещё один слой. И судя по тому, что PageSpeed Insights уже показывает отдельный блок под Agentic Browsing, этот слой лучше не игнорировать.

Источники и ссылки