Всё, что вам нужно знать о показателе готовности агента Cloudflare

от

На этой неделе Cloudflare перешли от просто разговоров о готовности AI-агентов к запуску инструмента, который действительно позволяет её измерить. Их новый веб-сайт, isitagentready.com, сканирует любой веб-сайт и присваивает ему оценку, основанную на том, насколько хорошо он работает с AI-агентами. Вы можете ввести адрес веб-сайта, чтобы увидеть его оценку, какие тесты были пройдены или не пройдены, и получить конкретные советы по улучшению. Это смещает разговор с простого размышления о том, готов ли веб-сайт, к наличию конкретных данных – оценки из 100 – и чётким областям для улучшения.

Купил акции на все деньги, а они упали? А Илон Маск снова написал твит? Знакомо. У нас тут клуб тех, кто пытается понять этот цирк и не сойти с ума.

Купить на падении (нет)

Оценка готовности агента представляет собой значительное изменение, но её легко неправильно истолковать, если смотреть только на общий балл. Важно копнуть глубже, чтобы понять полную картину.

Я просканировал веб-сайт nohacks.co и он получил оценку 33 из 100, что классифицирует его как Уровень 2, или ‘Осознающий Ботов’. Файл robots.txt и карта сайта оба прошли проверку, как и правила для ботов, содержащиеся в файле robots.txt, а сигналы его контента были положительными. Однако, оценка значительно упала в областях, которые не особо релевантны для простого блога – я объясню это более подробно чуть позже.

https://www.searchenginejournal.com/wp-json/sscats/v2/tk/Middle_Post_Text

Cloudflare активно выпускает инструменты для AI ‘агентов’ всю неделю, включая такие функции, как Agent Memory и систему для улучшения AI-обучения. Всего несколько дней назад они запустили новый программный комплект для создания этих агентов, и OpenAI быстро последовала их примеру, выпустив свой собственный. Теперь Cloudflare представила ‘сканер готовности’ – инструмент, который помогает владельцам веб-сайтов убедиться, что их сайты хорошо работают с этими новыми AI-агентами. По сути, если эти агенты становятся новым способом доступа людей в интернет, владельцам веб-сайтов необходимо иметь возможность протестировать совместимость своих сайтов, и этот сканер предоставляет такую возможность.

Эта статья посвящена трем конкретным вопросам: что именно оценивает сканер, как следует интерпретировать ваши результаты и где система оценки может быть запутанной или неточной, что приведет к неверной интерпретации вашего результата?

Что выпустила Cloudflare: Сканер, API и конечная точка MCP, которую агенты могут вызывать на вас.

Вы можете найти сканер на isitagentready.com. Просто вставьте URL, выберите тип веб-сайта, который вы проверяете (например, обычный контентный сайт или API), и нажмите ‘Scan’. Затем сканер проверит главную страницу веб-сайта и общие страницы, предоставив отчет с оценками и четкими результатами прохождения/непрохождения. Отчет также включает в себя такие детали, как коды состояния, ответы веб-сайта и полезные предложения на основе искусственного интеллекта для улучшений.

Сканер также доступен тремя другими способами:

  • Интегрировано в Cloudflare Radar, поэтому те же проверки выполняются параллельно с существующим URL-анализом Radar.
  • Раскрыто программно через Cloudflare URL Scanner API для автоматизации.
  • Доступен как stateless MCP-сервер по адресу /.well-known/mcp.json, поэтому любой MCP-совместимый агент может вызвать сканирование как инструмент и рассуждать над результатом.

Давайте на секунду остановимся на этом моменте. Cloudflare выпустила инструмент, который позволяет AI-агентам проверить готовность веб-сайта *перед* взаимодействием с ним. Этот сканер, по сути, позволяет агентам ‘прощупать почву’, чтобы увидеть, готов ли сайт к их посещению. Это сдвиг, когда инструменты, измеряющие веб-сайт, становятся частью самого веб-сайта.

Возвращаемся к практическому вопросу. Что именно это проверяет?

16 Проверок, 5 Категорий: Что Сканер Фактически Тестирует

Сканер организует свои тесты в пять основных областей. Вот разбивка того, что проверяет каждый тест, объяснённая простыми словами.

Обнаруживаемость (3 Checks)

Публикует ли веб-сайт базовые метаданные, необходимые агенту, чтобы найти, где что находится.

  • robots.txt существует. Классический файл политики сканирования. Агент, который следует robots.txt, должен иметь возможность его обнаружить и разобрать.
  • Файл sitemap.xml существует. Он либо объявлен через директиву Sitemap в файле robots.txt, либо доступен по стандартному пути. Агент, желающий перечислить страницы, использует карту сайта.

Контроль доступа ботов (3 проверки)

  • Правила AI-бота в robots.txt (RFC 9309). Содержит ли robots.txt директивы для AI-специфичных пользовательских агентов (GPTBot, ClaudeBot, PerplexityBot и т.д.).
  • Сигналы контента в robots.txt. Разрабатываемая спецификация для выражения правил доступа к URL внутри robots.txt. Распознается как User-agent: * с последующими директивами Content-signal:. Принятие пока минимально.
  • Подпись запроса Web Bot Auth. Подписи HTTP-сообщений по адресу /.well-known/http-message-signatures-directory, позволяющие агентам криптографически доказать свою личность. Это сторона Agent Name Service, Cloudflare поставлялась вместе с GoDaddy ранее на Agents Week. Принятие практически равно нулю за пределами собственных ресурсов Cloudflare.

API, Аутентификация, MCP & Обнаружение навыков (6 проверок)

  • Каталог API (RFC 9727). Машинно-читаемый индекс API-эндпоинтов веб-сайта по адресу /.well-known/api-catalog.
  • OAuth / OIDC discovery (RFC 8414). Стандартные метаданные авторизационного сервера OAuth 2.0 по адресам /.well-known/oauth-authorization-server и /.well-known/openid-configuration.
  • Серверная карта MCP (SEP-1649). Сервер протокола контекста модели, рекламирующий свои возможности по адресу /.well-known/mcp/server-card.json. SEP-1649 — это проект предложения в рамках процесса спецификации MCP.
  • Индекс навыков агента. Список навыков, вызываемых агентом, по адресу /.well-known/agent-skills/index.json. Также находится в стадии развития.
  • WebMCP (Экспериментальная версия). API JavaScript на странице, регистрирующий инструменты, вызываемые агентом, посредством navigator.modelContext. Сканер использует рендеринг в безголовом браузере для обнаружения, регистрирует ли веб-сайт какие-либо инструменты WebMCP при загрузке страницы.

Коммерция (3 Необязательные Проверки, Не Оцениваются на Некоммерческих Сайтах)

  • Протокол оплаты x402. Инфраструктура HTTP 402 Payment Required для нативных платежей агентов.
  • Профиль UCP (Универсальный протокол коммерции). Стандарт метаданных продавцов Google по адресу /.well-known/ucp.
  • Документ открытия ACP (Agentic Commerce Protocol). В /.well-known/acp.json.

Как вебмастер, я узнал, что если ваш сайт не предназначен для онлайн-продаж, наша система помечает раздел «Commerce» как необязательный. Мы все еще сканируем на предмет вещей, которые *могли бы* указывать на функциональность электронной коммерции, но если мы ничего не находим – например, корзину для покупок или варианты оплаты – мы покажем вам эти проверки commerce только для вашей информации. Не волнуйтесь, они не повлияют на общую оценку вашего сайта, если вы на самом деле ничего не продаете в Интернете.

Этот небольшой дизайнерский выбор значителен. Он показывает, что Cloudflare предвидела проблему, которую обсуждает эта статья.

Nohacks.co Оценил 33/100, Уровень 2, Обнаружение Ботов

Я провёл сканирование на nohacks.co. Результат был 33 из 100, Уровень 2 «Осведомлённость о ботах.»

Относительно этого результата: я улучшил способ доступа поисковых систем к контенту, добавив инструкции в файл robots.txt. Это повысило оценку ‘Bot Access Control’ со 50 до 100 и увеличило общий составной балл на восемь пунктов, с 25. Все остальные оценки остались такими же, как при первом сканировании. Я объясню изменение ‘Content Signals’ и мои доводы в его поддержку позже в этом разделе.

Вот что определило оценку каждой категории:

  • Обнаруживаемость: 67. robots.txt и sitemap.xml пройдены. Заголовки ссылок не прошли, потому что этот веб-сайт не выдает Link: заголовки в своих ответах.
  • Содержание: 0. Ведение переговоров по Markdown не настроено. Веб-сайт возвращает HTML независимо от заголовка Accept.
  • Контроль доступа ботов: 100. Обе проверки пройдены. Правила для AI ботов в robots.txt (у меня есть явные правила для AI user agents) и сигналы контента в robots.txt (я добавил их после первого сканирования). Запрос подписи аутентификации Web Bot Auth указан в этой категории как информационная проверка, но не учитывается в 2/2.
  • Коммерция: оценка отсутствует. nohacks.co не имеет электронной коммерции. Проверки Коммерции завершились неудачно, но категория правильно исключена из итоговой оценки.

Этот сайт получил оценку 33 при сканировании с помощью инструмента от ведущего эксперта в области сайтов, совместимых с ИИ. Я считаю, что сайт хорошо построен для использования с AI-агентами. У него есть чёткий и хорошо организованный файл robots.txt, и его контент доставляется как чистый, легко читаемый HTML с логичной структурой. Карта сайта актуальна, и веб-адреса не меняются часто. Всего неделю назад я бы сказал, что он в значительной степени, или полностью, готов к использованию с AI-агентами, в зависимости от конкретной задачи.

И всё же: 33, Уровень 2.

Сканер точно отслеживает необходимые данные. Однако, фокусировка исключительно на общем счете – не лучший способ улучшить результаты.

Что касается исправления Content Signals, которое связано с обсуждением непреднамеренных последствий позже, важно понимать его ограниченное использование. Content Signals — это идея Cloudflare, которая в основном используется поисковыми роботами, связанными с Cloudflare. Я колебался, внедрять ли её, потому что меня беспокоило поощрение «обхода» системы — именно та проблема, которую рассматривает эта статья. Однако в конечном итоге я почувствовал, что это оправдано по двум причинам. Во-первых, это чёткое заявление о политике в отношении того, как следует обрабатывать мой контент, и это заявление имеет ценность, даже если техническая спецификация не будет полностью принята. Это отличается от добавления бессмысленных элементов только для улучшения оценки. Во-вторых, поскольку наш веб-сайт ориентирован на подготовку контента для AI-агентов, открытое заявление о нашей контентной политике является стандартной редакционной практикой, независимо от того, признаёт ли какой-либо конкретный поисковый робот это или нет. Изменение включало одно обновление нашего файла robots.txt, и любой желающий может просмотреть эти директивы, если ему интересно.

Один и тот же веб-сайт получает 33 или 67 баллов в зависимости от выбранной предустановки.

При сканировании с настройкой ‘All Checks’, nohacks.co получил 33 балла из 100 и был классифицирован как ‘Bot-Aware’ (Уровень 2). Однако, используя настройку сканирования ‘Content Site’ на том же веб-сайте и в тот же день, оценка выросла до 67, оставаясь на уровне ‘Bot-Aware’ (Уровень 2). Это почти удваивает первоначальный результат, подчеркивая, что разница в 34 балла не связана с различиями между веб-сайтами, а скорее с разными настройками сканирования, которые использовались.

Вот что изменяет предустановка Content Site в конфигурации сканирования:

Запуск этого пресета на nohacks.co дал следующий результат:

Четыре из шести проверок готовности пройдены. Две, которые не прошли, чётко указывают на области, которые нам нужно исправить: настройка заголовков ссылок через нашу серверную конфигурацию и правильная обработка Markdown-контента с использованием наших серверов или сети доставки контента. К счастью, это не будущие функции – мы можем решить их с помощью нашей текущей системы. Это прямая оценка того, где мы находимся с точки зрения совместимости агентов: у нас есть две конкретные проблемы, над которыми мы можем немедленно начать работать.

Правильный переключатель скрыт, а исходный счёт неверен.

Сканер работает как и ожидалось. Он правильно определяет, что блоги не требуют серверных карт, а архивы подкастов не нуждаются в каталогах API. Настройка ‘Content Site’ предназначена не только для внешнего вида; она упрощает сканирование, устраняя ненужные проверки и сосредотачиваясь на стандартах, релевантных для контентных веб-сайтов, обеспечивая более точную оценку.

Основная проблема заключается в том, что настройка сканирования по умолчанию неочевидна. Когда кто-то посещает isitagentready.com и вводит адрес веб-сайта, автоматически запускается комплексное сканирование под названием ‘All Checks’. Возможность переключиться на сканирование, сфокусированное только на контенте или API, спрятана в меню ‘Customize’, которое большинство людей не найдут. Пользователи просто нажимают ‘Scan’, видят полученный результат и делятся им. Этот общий результат, который можно увидеть в социальных сетях и использовать для сравнений, всегда является результатом ‘All Checks’.

Как человек, который управлял множеством контентных сайтов, я заметил кое-что касательно этих сканирований. Когда вы проводите стандартное сканирование, не вдаваясь в детали, общий балл безопасности, как правило, оказывается слишком низким. Я видел это на nohacks.co – он показывал 33, что просто не соответствовало типичному контентному сайту. Более точный балл, 67, на самом деле исходит из пресета ‘Content Site’ – он скрыт в выпадающем меню. Начальный балл, который вы видите на главной странице, вводит в заблуждение. Раздражает видеть два разных результата от одного и того же сканера на одном и том же сайте, но вам действительно нужно копать глубже, чтобы найти правильный.

Как человек, который уже некоторое время занимается управлением веб-сайтами, позвольте мне сказать вам, если вы запускаете сканер веб-сайтов и планируете публиковать результаты, есть решающий шаг, который вам *необходимо* предпринять. Прежде чем делиться каким-либо результатом, перейдите в раздел ‘Customize’ и выберите предустановку, которая лучше всего подходит для вашего веб-сайта – это контент-ориентированный сайт, API или что-то другое? Затем повторно запустите сканирование. Поверьте мне, если вы пропустите этот шаг, результат, которым вы поделитесь, не будет точно отражать реальную готовность вашего сайта. Разница между публичным результатом и истинным результатом будет больше для сайтов с большим количеством контента, чем для API. И что важно, *всегда* углубляйтесь в детали каждой отдельной проверки, прежде чем делиться сводным результатом. Убедитесь, что вы знаете, *какая* предустановка сгенерировала это число.

Просто для ясности, я сосредоточен на достижении оценки в 100 баллов, хотя и предвижу следующее предупреждение о приоритете метрик над содержанием. Мне нужно внести всего две небольшие корректировки, чтобы этого добиться – обе должны занять около пяти минут. Эти изменения на самом деле улучшат работу системы (лучшее обнаружение и более быстрая обработка), так что дело не только в повышении оценки. Конечно, так сказал бы каждый, кто пытается обмануть систему! Публичные оценки невероятно заманчивы, и легко в них увязнуть – даже те, кто пишут об их недостатках, пытаются улучшить свои собственные результаты.

Меры по подготовке агентов к доставке, а не сообщения.

Сканер готовности агента проверяет, насколько хорошо система *предоставляет* информацию – такие вещи, как поиск контента, обработка запросов, предоставление доступа ботам, поиск API и поддержка функций покупок. Однако он не оценивает фактическое *содержимое* отправляемых сообщений.

Как SEO-эксперт, я часто говорю о создании контента, который *находит отклик* у пользователей – чёткие заголовки, убедительные описания и ответы, которые действительно удовлетворяют их поисковые запросы. Именно здесь вступают в силу SEO и оптимизация коэффициента конверсии (CRO) – всё сводится к улучшению самого *сообщения*. Но то, что я замечаю всё чаще сейчас, – это акцент на том, могут ли поисковые системы действительно *получить доступ* к этому контенту. Забудьте о качестве на секунду – могут ли они вообще *до него добраться*? Могут ли они понять формат, проверить доступ и справиться с технической стороной вещей, таких как API-вызовы и оплата за информацию? Это совершенно другая игра, и она становится всё более важной наряду с сильным контентом.

Ключевое различие заключается в том, *как* доставляется контент, а не только в том, что он говорит. Традиционная веб-оптимизация (например, SEO и CRO) фокусируется на самом сообщении – делая его ясным и убедительным. Но подготовка к AI ‘агентам’ (например, чат-ботам или поисковым ботам) заключается в том, *как* это сообщение доставляется нечеловеческому читателю. Два веб-сайта могут иметь абсолютно одинаковые слова, но один, построенный с использованием стандартных веб-технологий (предоставляющих четкую структуру и данные), будет гораздо легче понятен агенту, чем веб-сайт, построенный как сложное, JavaScript-тяжелое приложение. Контент одинаков, но метод доставки существенно влияет на то, насколько хорошо агент может его обработать, и, следовательно, насколько хорошо веб-сайт будет работать для задач, управляемых AI. Другая доставка означает другой балл, и это совершенно верно – агент взаимодействует с *доставкой*, а не только с сообщением.

Это объясняет, почему подготовка ваших систем к AI-агентам отличается от улучшения поисковой оптимизации (SEO) или оптимизации коэффициента конверсии (CRO). Вы можете сделать свои системы более удобными для AI, не меняя контент вообще. И наоборот, у вас может быть отличный контент для людей и поисковых систем, но он все равно не будет хорошо работать с AI-агентами, если ваши базовые системы не настроены для их обработки. SEO и CRO фокусируются на самом контенте, в то время как готовность к AI фокусируется на том, как этот контент доставляется. Это связанные, но отдельные области, и их путаница часто приводит к ненужным изменениям контента вместо решения реальной проблемы.

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

3 риска Гудхарта, встроенные в оценку готовности агента

Закон Гудхарта объясняет, что как только вы начинаете использовать метрику как цель, она теряет свою полезность. Хотя показатель готовности агента (Agent Readiness Score) изначально был хорошо продуман, сейчас это публичная цифра, которая сравнивается и распространяется, что приводит к трем распространенным негативным последствиям на практике.

Одна потенциальная проблема заключается в том, что владельцы веб-сайтов могут сосредоточиться на улучшении своих оценок вместо того, чтобы фактически улучшать взаимодействие своего сайта с пользователями. Они могли бы добавлять ненужные функции только для удовлетворения системы оценки – например, компонент-заполнитель или список навыков без какого-либо реального контента – или даже развертывать инструменты, которые на самом деле *не* делают ничего, просто чтобы пройти проверки системы. Это означает, что оценка может увеличиться, но фактический опыт для пользователей, посещающих веб-сайт, останется неизменным.

Существует риск того, что компании начнут предлагать услуги, чтобы просто *улучшить* Agent Readiness Score, сосредотачиваясь на самом показателе, а не на создании надежной AI-системы. Мы уже видели подобную закономерность – с поисковой оптимизацией (SEO) люди сосредоточились на манипулировании PageRank, а затем Core Web Vitals, вместо создания действительно хороших веб-сайтов. Хотя Agent Readiness Score – хорошо разработанная метрика, вероятно, она столкнется с теми же проблемами: люди попытаются обмануть систему, вместо того чтобы сосредотачиваться на реальных улучшениях.

Третья потенциальная проблема заключается в том, что, придавая вес новым, несогласованным стандартам в своей оценке, сканер может ускорить их принятие до того, как они будут полностью разработаны и надежны. Например, сканер в настоящее время проверяет наличие файла с именем llms.txt, который является предлагаемым способом для веб-сайтов обмена контентом с языковыми моделями искусственного интеллекта. Однако llms.txt не является официальным стандартом – ему не хватает надзора, и существует множество различных идей о том, как он должен быть построен. Присвоение ему оценки поощряет его использование, даже если он не получил широкого признания. Владелец веб-сайта, пытающийся улучшить свою оценку, может непреднамеренно помочь преждевременному предложению стать стандартом до того, как оно будет полностью завершено.

Я видел множество оценок производительности веб-сайтов, которые появлялись и исчезали, и, честно говоря, они *всегда* подвергаются манипуляциям или неправильной интерпретации. Что отличает Agent Readiness Score от Cloudflare, так это то, что они действительно открыто говорят о том, как он рассчитывается. Они не просто дают вам одно число; вы можете углубиться в детали каждой проверки, что имеет огромное значение. Кроме того, они разумно избегают присвоения оценок некоммерческим сайтам по коммерческим метрикам. Эта прозрачность — это большое дело, и я думаю, что это стоит сохранить. Я знаю, что владельцы веб-сайтов и агентства естественным образом будут сосредотачиваться только на этом общем балле, но важно помнить, что детали имеют значение.

Не делайте этого.

6 Weekend Fixes That Map To Real Agent Runtimes

Вот шесть ключевых вещей, которые веб-профессионал должен сделать при запуске сканера, перечисленные от наиболее важной к наименее важной:

  1. Запустите сканирование вашего сайта. Это займет около 30 секунд. Обратите внимание на оценку и откройте подробный отчет. Детализация – это место, где находится сигнал.
  2. Исправьте проваленные проверки, которые отправляются против реальных сред выполнения агентов сегодня. Это те, отсутствие которых измеримо вредит вашему веб-сайту для агентов, посещающих его прямо сейчас:
    • robots.txt. Если отсутствует, добавьте его. Если присутствует, убедитесь, что он содержит конкретные правила для AI-агентов (GPTBot, ClaudeBot, PerplexityBot, Google-Extended и т. д.).
    • sitemap.xml. Если отсутствует, сгенерируйте его и свяжите его из robots.txt. Поддерживайте его в актуальном состоянии.
    • Markdown content negotiation. Настройте свой источник или CDN для возврата text/markdown, когда заголовок Accept запрашивает это. Cloudflare’s own AI Crawl Control имеет первоклассную поддержку для этого. Другим поставщикам требуется пользовательская серверная логика.
    • Structured data. Отправляйте schema.org JSON-LD для типов контента, которые публикует ваш веб-сайт (Article, Product, Organization, BreadcrumbList). Это не оцениваемая проверка, но это самое эффективное исправление для поведения цитирования во всех развернутых средах выполнения агентов.
  3. Относитесь к форматам на стадии предложения как к списку для наблюдения, а не к контрольному списку. llms.txt, Content Signals in robots.txt, Web Bot Auth, API Catalog, MCP Server Card, Agent Skills, WebMCP, ACP, UCP – все это реальные рабочие стандарты в некотором смысле. Они пока не используются в реальном поведении агентов в масштабе. Наблюдайте за ними. Внедряйте их, когда вашей системе есть для чего, а не потому, что сканер их помечает.
  4. Игнорируйте составное число в вашем собственном отслеживании. Отслеживайте индивидуальные результаты проверок с течением времени. Веб-сайт, который переходит от 3 из 5 успешно пройденных проверок в реальном времени к 5 из 5, значительно улучшился, даже если составной показатель едва изменился из-за того, что 10 проверок на этапе предложения все еще не пройдены.
  5. Пересканируйте после изменений. Сканер быстрый, бесплатный и доступен через URL Scanner API, если вы хотите включить проверки регрессии в ваш конвейер развертывания.
  6. Не тратьте деньги на консалтинговые услуги по оптимизации Agent Readiness Score. Работа достаточно проста, чтобы полуденный аудит и целенаправленный спринт исправления оказались эффективнее любого готового решения.

Сканер — это инструмент. Работа остаётся работой.

Специализированные сканеры уже в пути: отслеживайте, что тестирует каждый сканер.

Здесь измерение того, насколько хорошо веб-сайт обрабатывает ботов, становится сложным. Различные службы сканирования будут давать веб-сайтам разные результаты. Например, Cloudflare проверяет наличие конкретных защит от ботов, в то время как Google и Perplexity ищут немного другие вещи. Это означает, что веб-сайт может получать разные оценки от каждого сканера. Общий показатель ‘готовности’, который и так не всегда надежен, будет зависеть от того, какая служба сканирования используется.

Важными сигналами, на которые стоит обратить внимание, являются проверки безопасности, которые отображаются во всех инструментах сканирования. Они представляют широко принятые стандарты. Проверки, уникальные для сканера Cloudflare, отражают их прогнозы будущих потребностей в безопасности – некоторые окажутся успешными, но многие нет.

Как SEO-эксперт, я всегда ищу надежные сигналы, и поэтому я почувствовал уверенность сразу же написать о новом инструменте Cloudflare. То, что Cloudflare делает с их Agent Readiness Score – это солидно – идея о том, что мы можем фактически *измерить* насколько хорошо сайт подготовлен к таким вещам, как Core Web Vitals, совершенно верна. Рассматривайте эту первую оценочную карту как только начало. Она будет сильно развиваться по мере того, как разные поставщики будут совершенствовать свои подходы. Мой совет веб-профессионалам? Изучите эту первоначальную оценочную карту, исправьте проблемы, которые она точно определяет, обратите внимание на то, что она помечает как потенциальные проблемы, и – самое главное – отслеживайте, какие проверки постоянно появляются во всех этих сканерах в течение следующих шести месяцев. Именно там вы найдете действительно важные сигналы.

Этот постоянно обновляемый список — реальный показатель готовности агентов. Итоговый балл — это маркетинговый слой.

Запустите сканирование. Прочитайте отчёт. Исправьте то, что важно. Обратите внимание на то, что может быть важно.

Смотрите также

2026-05-24 15:15