Роками 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 виконує категорію на боці Google. Для перевірок на рівні сторінки не потрібні ні особливі версії 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 Search не використовує llms.txt. У власному посібнику Google з оптимізації для ШІ прямо сказано, що файл не приносить сайту ні користі, ні шкоди для видимості та позицій, бо Google Search їх ігнорує. Пишіть його для агентських інструментів, які читають цю конвенцію, а не заради рейтингу.
Стабілізуйте макет, щоб агенти могли прицілитися
Зсув макета став важливішим, ніж раніше. Агент, який знаходить кнопку й потім клікає за її координатами, промахнеться, якщо реклама, банер або зображення, що пізно завантажилося, зсуне цю кнопку на 200 пікселів униз між цими двома моментами.
Що робити: задайте явні ширину й висоту (або співвідношення сторін) для зображень і вбудованих блоків, резервуйте фіксоване місце під рекламні слоти й банери згоди, не вставляйте новий контент над наявним після завантаження та анімуйте через 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 Search ваш дріб 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 та інструменти ШІ-пошуку, про те, які перевірки варті вашого часу і як вбудувати їх у робочу рутину.
