Google выпустил две новые спецификации с разницей в несколько недель. Вот что на самом деле делают OKF и ARD, чем они отличаются от LLMs.txt и MCP и что оптимизаторам следует делать дальше.
<п>Последние несколько недель были шумными. Google представил нечто под названием «Формат открытых знаний». Затем разработчики Google анонсировали спецификацию обнаружения агентных ресурсов (ARD).
Между тем, в каждой SEO-ленте LinkedIn кто-то либо объявляет уценку о будущем сети, либо объясняет, почему вы должны все это игнорировать.
<с>Истина, как обычно, находится где-то поинтереснее, чем любой другой лагерь.
В сети развивается параллельная машиночитаемая инфраструктура (MCP/WebMCP, OKF, ARD, LLMs.txt…) и оптимизаторы, которые понимают, что на самом деле делает каждый уровень, а не рассматривают все это как “AI SEO” или серебряная пуля, примут более правильные решения о том, где проводить время.
Сначала: Слоеный пирог
<п>Под лозунгом «готовность вашего сайта к искусственному интеллекту» обсуждается как минимум шесть различных вопросов. Они располагаются на разных уровнях и служат разным целям:
<ул>
<блоковая цитата>
“Если кто-то уже есть на вашем веб-сайте, возможно, вам поможет какая-то автоматизированная система. Если так, я хочу пойти в Мартинс Сплитт и купить фотографию, затем система LLM может зайти на ваш сайт и посмотреть, например, как вы покупаете фотографию? Может быть, у него есть какие-то рекомендации для меня как агента по покупке фотографий. В этом есть смысл.”
<ул>
<п>В сфере электронной коммерции есть еще один уровень, который стоит назвать отдельно – фид товаров – вполне возможно, будущее открытия розничной торговли.
Каждый слой делает что-то свое.
Я мог бы продолжать дополнять этот список; каждые пять минут появляется новый слой. Я останавливаюсь здесь. Это раздувается.
Что такое OKF на самом деле (и не является ли это)
Сам формат почти обезоруживающе прост: каталог файлов уценки, каждый из которых имеет небольшой YAML-заголовок, объявляющий тип, заголовок, описание, ресурс и некоторые теги. Файлы связаны друг с другом, как и любой другой документ с уценкой. Вот и всё.
Как написано в блоге Google, OKF — это «просто уценка, только файлы, просто заголовок YAML».
SEO Сугантан Моханадасан дает четкое объяснение этому. Он описывает OKF как один этаж в стеке, который теперь включает sitemap.xml (какие URL-адреса существуют), LLMs.txt (какие страницы вы больше всего хотите прочитать) и OKF (сама библиотека). Они скорее накапливаются, чем конкурируют.
<с>Путаница возникает не тогда, когда вы смотрите на то, что такое OKF, а на то, что он делает и на каком уровне агентурного и поискового хаоса он находится. <п>На мой взгляд, OKF — это не поисковая система. Это не заменяет ползание. И лично я не вижу будущего, в котором системы искусственного интеллекта больше не будут обрабатывать огромные объемы HTML или где поиск и RAG не будут представлять собой многоэтапный сложный конвейер, состоящий из самостоятельно сообщаемых и “необоснованных” сигналы.
Любая система, о которой сообщают сами люди, может и будет подвергаться игре. Поэтому думать, что вы можете просто разместить на своем сайте кучу файлов с уценкой и стать предпочтительным выбором в поиске и обнаружении, надуманно.
OKF является источником более высокого сигнала среди многих. Это может снизить стоимость анализа и улучшить качество сигнала, но не заменяет существующие конвейеры.
<стр>Здесь также стоит быть честным: OKF был создан для групп данных, а не для маркетинговых сайтов.
Он появился как способ обмена внутренними знаниями, то есть схемами таблиц, модулями Runbook, определениями метрик, между агентами ИИ внутри организаций. Направить его на общедоступный веб-сайт мне кажется, что мы снова перепрофилируемся.
<п>Франсуа Вандерсейпен дает наиболее точную точку зрения на то, чем на самом деле является OKF, а чем не является: ориентированный граф файлов уценки — это сеть документов, а не граф знаний (по крайней мере, не в его самом чистом смысле). Настоящий KG имеет явные типизированные отношения с возможностью запроса. OKF оставляет на усмотрение производителя то, что подразумевает ссылка, и LLM по-прежнему должен делать выводы о семантике каждый раз, когда он ее читает.
Снимок экрана с LinkedIn, июль 2026 г.
Для меня это указывает на суть того, как я понимаю Интернет и что мы делаем как SEO-специалисты. OKF не меняет стек. Он добавляет к нему еще один вход.
Это не короткий путь. Ярлыков нет.
Параллель Schema.org и почему это важно
Одним из шаблонов, которые нужно понять здесь, является тот, через который уже прошел Schema.org.
Структурированные данные следовали по предсказуемой дуге:
<п>Принятие – повышение рейтинга – широкое использование (и игры) – обучение платформе – уменьшенная зависимость как сигнал ранжирования.
Схема часто задаваемых вопросов использовалась в поисковой выдаче, затем Google прекратил поддержку расширенных результатов часто задаваемых вопросов. Платформы учатся на сигналах, объединяют уроки в алгоритм, и явная разметка становится менее необходимой.
OKF и LLMs.txt могут идти по одному и тому же пути. Они наиболее ценны на раннем этапе, как четкие сигналы в мире, где системы искусственного интеллекта все еще учатся анализировать сеть.
Со временем, если форматы работают, системы учатся. Явная разметка становится избыточной или остается слоем проверки. Например, в электронной коммерции, в частности, согласование схемы и фида становится все более важным. Еще один шаг в призыве к совместному владению фидом продуктов между SEO и платными командами!
<п>Здесь также стоит остановиться на более тонком моменте, касающемся связи между Schema.org и Discovery. Подробное исследование вариантов продуктов Ярно ван Дрила в журнале Search Engine Journal хорошо иллюстрирует это: в течение многих лет у Google Search и Google Merchant Center были противоречивые требования к структурированным данным, что вынуждало издателей дублировать разметку. Schema.org развивается, чтобы закрыть пробелы, но это медленно, сложно, и реализация по-прежнему часто приводит к беспорядку.
Структурированные данные никогда не были простым рычагом ранжирования. OKF тоже не будет.
<х2>Стоит ли конвертировать свой сайт в Markdown?
От меня категорически нет. Это не значит, что я не буду его тестировать и применять осторожно! <стр>И Джон Мюллер сказал это в подкасте Search Off the Record:
“Когда дело доходит до таких вещей, как поисковая система или, возможно, также общая система LLM, наличие веб-сайта, который использует обычный HTML для страниц, имеет решающее значение. Потому что поисковая система или сканер может просто перейти на эту страницу. Он может распознавать все остальные ссылки на веб-сайте.”
<п>Структурная информация в HTML – навигационные ссылки, нижние колонтитулы, иерархия заголовков, внутренние ссылки – это то, как сканеры понимают форму вашего сайта. Файлы Markdown удаляют все это. Вы нарушите открытие, чтобы немного улучшить машиночитаемость отдельных страниц.
Недавно на LinkedIn я даже увидел исследование, показывающее, как «Ваша навигация может съедать ваш бюджет LLM (на самом деле это ChatGPT Deep Research) на чтение». Интересные выводы, но, пожалуйста, не удаляйте навигацию, чтобы “сэкономить токены”!
Снимок экрана с LinkedIn, июль 2026 г. <п>Джоно Олдерсон блестяще выражает эту мысль: «Страница — это не просто вместилище для слов. Это редакционный артефакт». Иерархия, акцент, размещение, что на первом месте, что заметно, что спрятано в сноске … это некрасивые украшения для людей. “Это сигналы о значении”
“Когда вы выравниваете страницу с уценкой, вы не просто убираете беспорядок. Вы удаляете суждение и удаляете контекст». И в тот момент, когда вы публикуете только машинное представление, вы создаете вторую кандидатскую версию реальности.
Скучное исправление все еще работает: семантический HTML, четкая структура, чувствительная иерархия, контент, который существует при загрузке страницы.
<п>Джон Мюллер широко освещает дебаты по поводу уценки в подкасте: проблема параллельных версий, уроки динамического рендеринга, которые мы уже усвоили на собственном горьком опыте, и почему поддержка теневой версии вашего сайта для ИИ удваивает вашу нагрузку на обслуживание и создает кошмар отладки, о котором вам никто не расскажет.
Единственное исключение, которое вырезает Мюллер, — это документация для разработчиков:
<блоковая цитата>
“Если у вас есть что-то вроде документации разработчика, где, опять же, если агент или система LLM уже знает о вашем веб-сайте, а пользователь спрашивает, как мне использовать этот API? Тогда, если вы дадите системе LLM файл Markdown, ее будет намного проще понять.”
Теперь я определенно вижу здесь простой вариант использования.
Чем на самом деле занимается ARD
Спецификация Agentic Resource Discovery, анонсированная Google 17 июня 2026 года, представляет собой совершенно другое существо. Оно прибыло всего на пару дней позже OKF, и это не совпадение, и уже наделало много шума.
Проблема, которую решает ARD, является координационной. Прямо сейчас агент должен быть подключен к каждому инструменту, серверу MCP или API, который он использует, прежде чем он сможет что-либо с ним делать.
Это работает, когда вы подключаете несколько известных сервисов. Масштабирование прекращается в тот момент, когда количество доступных возможностей выходит за рамки того, что любая команда может предварительно настроить вручную.
<п>ARD переносит это открытие из установки в среду выполнения. Агент находит то, что ему нужно, тогда, когда ему это нужно, а не только знает, о чем ему было сказано заранее.
Он построен на двух примитивах:
<ул>
<стр>Если OKF — это упаковка знаний для потребления, то ARD — это рекламные возможности для связи. <п>Это параллельные усилия на разных уровнях формирующегося агентного стека. Оба были выпущены в нескольких дюймах друг от друга и теперь со скоростью света приняты некоторыми очень крупными игроками в игре, например, Hugging Face и их Discover Tool.
Возможно, это более прагматичная ставка, чем уровень формальной логики, который существовал до него и никогда не достигал веб-масштаба. Время покажет.
Гэп, на который стоит посмотреть
<п>Через несколько дней после выпуска обеих спецификаций участник открыл сопутствующие проблемы в репозиториях ARD и OKF, указав, что чего-то не хватает: не существует согласованного типа носителя для пакета OKF, поэтому в каталоге может быть указан один из них, но он не может фактически распознать его как OKF, не проверив содержимое.
А пока издатели уже рекламируют находящиеся в производстве бандлы, используя свои промежуточные типы, которые, как отмечается в самом выпуске, не согласуются друг с другом.
На первый взгляд это выглядит как небольшая просьба, просто просьба об общем ярлыке.
После небольшого погружения в эту кроличью нору оказывается, что это вполне нормальная практика. Ожидание полного согласия, прежде чем кто-либо что-либо выпустит, — это именно то, как спецификация умирает в комитете, а быстрая доставка и исправление по мере реального внедрения — это давняя стратегия.
<п>Но OKF отличается, потому что то, что происходит после выборки, отличается. Артефакт, стоящий за этим ярлыком, представляет собой пакет, который автономный агент должен принимать, проверять и потенциально использовать в системе обнаружения, созданной специально для подключения агента к агенту и агента к инструменту. Ошибитесь в типе или предоставьте агенту возможность сделать это вывод, и риск не будет заключаться в ошибке синтаксического анализа; это система, действующая на то, чему ей не следовало доверять, и никто предварительно не проверяет результат.
<п>Я задаюсь вопросом о риске, связанном с урегулированием этого вопроса позже, а не раньше в этом случае. Я думаю, это зависит от того, насколько быстро проблема будет решена по сравнению с тем, насколько быстро она будет принята.
Что это значит, если вы SEO-специалист
<стр>Несколько честных выводов и мои текущие мысли:
Для большинства маркетинговых и контентных сайтов мало что изменилось. HTML, хорошо структурированный для людей, по-прежнему является подходящей основой. Форма обратной связи и понятная архитектура сайта послужат вам лучше, чем любой пакет OKF. Обнаружение по-прежнему зависит от ссылок, авторитета, пользовательских сигналов и amp;hellip; и индексирование.
LLMs.txt — это указатель, а не инструмент SEO. Это полезно, поскольку помогает агенту перемещаться по вашему сайту, когда он уже там. Скорее всего, это не имеет большого значения для того, как агенты вас найдут. И, вероятно, никогда не будет.
MCP/WebMCP. Ни то, ни другое сегодня не является актуальным для большинства маркетинговых сайтов, но если вы создаете что-либо с программными интерфейсами или потоками электронной коммерции и хотите, чтобы агенты перемещались, это направление, в котором движется инфраструктура.
OKF имеет большой смысл, если вы опираетесь на структурированные внутренние знания, то есть документацию, ссылки на API, спецификации продуктов и hellip; и вы хотите облегчить агентам потребление. Бесплатный генератор OKF, созданный Сугантаном, создаст пакет и в качестве дополнительного преимущества предоставит вам графическое представление вашей внутренней структуры ссылок. Один только структурный аудит, кажется, того стоит. Но сначала я буду запускать его на своем веб-сайте, а не на веб-сайте моего клиента.
<п><сильный>ARD стоит посмотреть, если вы создаете сервисы с программными интерфейсами. Если у вас есть инструменты, агенты или API, которые вы хотите, чтобы другие агенты могли обнаружить, ARD — это новый стандарт того, как это сделать. Просто знайте, что уровень идентификации под ним, на что на самом деле смотрит агент, когда он находит вашу запись в каталоге, все еще определяется в реальном времени, поэтому я бы рассматривал это как инфраструктуру, за которой нужно внимательно следить, а не строить критические пути прямо сейчас.
Цикл принятия схемы может повториться. Эти форматы наиболее ценны сейчас, как ранние сигналы. Внедрите их, если можете сделать это дешево. Не стройте свою стратегию вокруг того, чтобы они сохраняли ценность навсегда, и не рассчитывайте на них как на серебряную пулю.
В конечном итоге, остерегайтесь блестящих вещей– если у вашей компании есть проблемы покрупнее, например, ужасный веб-сайт, бренд, который никто не знает и о котором никто не заботится, аудитория, которую вы не понимаете … тогда сначала разберись с этим, прежде чем ты увязнешь в этих новых блестящих штучках.
Основной сдвиг
Все это указывает на то, что сеть действительно вырастает вторым слоем или третьей головкой, написанной для машин наряду с той, что написана для браузеров и людей.
Sitemap.xml сообщал сканерам, какие URL-адреса существуют. Robots.txt указал им, куда не следует идти. LLMs.txt, OKF и ARD представляют собой аналогичную инфраструктуру для агентских систем: подсказки по навигации, упаковку контента и обнаружение возможностей.
Сегодня ничего из этого не является обязательным. Ничто из этого не заменит прочного HTML, авторитетного контента, конфиденциальной структуры или того, что на самом деле скрывается за всем этим: бренда, который стоит найти.
Но оптимизаторы, которые понимают, что на самом деле делает каждый уровень, а не рассматривают его как единый недифференцированный “AI SEO” категории, сделают более точные ставки на то, где провести время.
Мои деньги вкладываются во второй уровень, параллельную инфраструктуру, написанную для машин, а не замену того, что уже существует.
Третий сценарий, в котором агентные системы полностью расходятся с человеческой сетью, потребует другого набора ставок, чем любой из нас в настоящее время делает.
Большое спасибо Ярно ван Дрилу, Джоно Алдерсону, Крису Грину, Сугантану Моханадасану, Кристине Шахингер, Джанлуке Фиорелли, Виктору Пэну, Рене Бигелоу (и всем, кого я пропустил) за блестящие дискуссии по этой теме в течение последних нескольких недель.
