Перейти к содержанию

Что SKU.md уже может дать независимому магазину и как сослаться на него из llms.txt, agents.md и Sitemap

Заметки о спецификации

Трезвый взгляд на роль SKU.md в покупках через диалог с AI и рекомендуемый способ указать на /sku.md из llms.txt, agents.md, sitemap.xml, robots.txt и главной страницы.

Покупатель просит AI-ассистента подобрать двухместную палатку легче 1,5 кг. Ассистент ищет, открывает несколько страниц и пытается извлечь ответ из разметки темы, всплывающих окон, виджетов отзывов и скриптов. Карточку на крупном маркетплейсе часто проще разобрать, чем страницу на сайте самого бренда, хотя исходные характеристики писал именно бренд.

Именно этот разрыв SKU.md пытается сократить для независимых магазинов. В статье разобрано, что формат 1.0.0-beta реально может сделать уже сейчас, а затем показан рекомендуемый способ сослаться на него из файлов, которые многие магазины уже публикуют.

Что SKU.md может сейчас

SKU.md — независимое экспериментальное предложение. Ни один крупный AI-ассистент или поисковик не объявлял, что читает /sku.md, поэтому публикация файла не является сигналом ранжирования. В руководстве Google по AI-функциям Поиска сказано, что специальные Markdown-файлы для AI не помогают и не мешают видимости в Google. Если держать эту границу в голове, практическая польза видна яснее.

Проблема диалоговых покупок Что предлагает SKU.md
Страницы товаров тяжёлые, агенту трудно их прочитать Несколько килобайт простого Markdown со стабильными фактами о товаре
Ассистент додумывает размеры, материалы или совместимость У каждого факта есть ссылка Source, которую можно открыть и проверить
В ответы попадают устаревшие цены и остатки Цена, остатки, доставка, налоги и оформление заказа намеренно не входят в файл
Покупатели спрашивают, кому подходит товар и с чем он совместим Необязательные разделы Guidance, Limitations, Compatibility и Questions
Небольшой бренд трудно распознать как отдельную сущность Корневой каталог называет магазин, кратко описывает его и ссылается на коллекции

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

Существующие файлы сайта, такие как llms.txt, agents.md и Sitemap, указывают на один каталог SKU.md, а каталог ведёт к знаниям о товарах с источниками
Несколько файлов, которые магазин уже отдаёт, могут указывать на один каталог. Единственной точкой входа в знания о товарах остаётся этот каталог.

Зачем нужны ссылки

Спецификация закрепляет каталог по точному пути /sku.md. Читатель, знающий это соглашение, может запросить файл напрямую, но большинство о нём пока не знает. Поэтому полезно упомянуть файл там, куда краулеры и агенты уже заглядывают: в llms.txt, agents.md, XML Sitemap, robots.txt и на главной странице.

Описанные ниже соглашения — рекомендации для 1.0.0-beta. Они не меняют требований соответствия. Каждая ссылка ведёт на корневой /sku.md, а каталог по-прежнему должен самостоятельно проходить проверку. Ссылка лишь подсказывает, что файл существует, и не доказывает, что факты в нём верны.

llms.txt

Предложение llms.txt описывает Markdown-файл по адресу /llms.txt с заголовком H1, коротким описанием и разделами H2, где ссылки записываются в виде - [name](url): notes. Добавьте один раздел с названием Product knowledge и единственной ссылкой на каталог:

# Example Outdoor Gear

> Lightweight outdoor equipment for hikers.

## Product knowledge

- [SKU.md catalog](https://www.example-outdoor.com/sku.md): Source-backed product knowledge (SKU.md 1.0.0-beta). Confirm price, stock, and shipping on the linked product pages.

Оставьте название раздела и текст ссылки на английском, как в примере, чтобы инструменты находили запись без догадок. Указывайте здесь только корневой каталог. Документы со знаниями о товарах доступны из каталога, а их повтор в llms.txt лишь создаёт ещё один список, который придётся поддерживать.

Некоторые платформы сами генерируют llms.txt для продавца. Например, в документации Shopify сказано, что управляемый платформой файл повторяет содержимое /agents.md. Добавляйте раздел только там, где платформа позволяет редактировать файл, и проверяйте реальный ответ после каждой смены темы или приложения.

agents.md

agents.md — простой Markdown-файл с инструкциями для агентов. Магазину достаточно короткой инструкции: где лежат стабильные знания и где обязательно проверять актуальные данные.

## Product knowledge

SKU.md catalog: [https://www.example-outdoor.com/sku.md](https://www.example-outdoor.com/sku.md)

Use the catalog and the product knowledge documents it links for stable, source-backed facts. Confirm price, stock, shipping, tax, and checkout on the live product page before answering or acting.

Строка, начинающаяся с SKU.md catalog:, и есть ссылка. Абзац под ней объясняет агенту, как обращаться с содержимым. Если остальную часть файла ведёт платформа, пишите своими словами, но сохраняйте префикс SKU.md catalog:.

sitemap.xml и robots.txt

Протокол Sitemaps перечисляет URL, о которых сайт хочет сообщить краулерам. В Sitemap можно включить любой URL на том же хосте, поэтому каталог может стоять рядом с HTML-страницами магазина:

<url>
  <loc>https://www.example-outdoor.com/sku.md</loc>
  <lastmod>2026-08-11</lastmod>
</url>

В lastmod укажите дату последнего изменения содержимого каталога. Если каталог ссылается на Product knowledge Sitemap (в 1.0.0-beta он может перечислять до 31 документа о товарах), объявите его и в robots.txt:

Sitemap: https://www.example-outdoor.com/sitemap.xml
Sitemap: https://www.example-outdoor.com/sku-knowledge.xml

Перечисление URL лишь делает его доступным для обнаружения. Индексировать ли Markdown-ресурс и как именно, решает каждый поисковик. Документ со знаниями о товаре повторяет факты со своей HTML-страницы товара, но обязательная ссылка Product ведёт на эту страницу, и канонической страницей в поисковой выдаче остаётся HTML-страница товара.

Главная страница и HTTP-заголовки

Спецификация уже позволяет странице товара объявлять своё Markdown-представление через <link rel="alternate" type="text/markdown">. Тот же приём работает на главной странице для каталога. Добавьте title="SKU.md", чтобы читатель мог отличить каталог от Markdown-зеркала отдельной страницы:

<link rel="alternate" type="text/markdown" title="SKU.md" href="https://www.example-outdoor.com/sku.md">

Магазин, который управляет заголовками ответа, может передать то же отношение в HTTP-заголовке Link главной страницы:

Link: <https://www.example-outdoor.com/sku.md>; rel="alternate"; type="text/markdown"; title="SKU.md"

Ссылки должны соответствовать действительности

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

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

Если корневой путь недоступен

Некоторые платформы пока не могут отдавать точный ответ по /sku.md. По правилам 1.0.0-beta такие магазины ещё не могут опубликовать соответствующий каталог, и ссылка на другой путь этого не меняет. RFC 0001 предлагает разрешить описанным ссылкам объявлять каталог по другому пути того же источника, а также вводит структурированные идентификаторы и необязательную ориентировочную цену с датой. Пока ни один релиз его не принял, направляйте ссылки на корневой путь.

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