Как агенты обнаруживают ресурсы llms.txt v2
Предложение v2 определяет два отношения ссылок для обнаружения. В нашем базовом измерении учитывается, как часто они встречались на страницах, связанных с ответами корневых файлов, где H1 был первым элементом.
Последнее обновление:
alternate ведёт с HTML-страницы к её чистому представлению в Markdown. describedby ведёт с этой страницы к наиболее конкретному применимому llms.txt. Вместе они делают ресурсы v2 обнаруживаемыми без угадывания путей, но действовать по ним будут только клиенты, реализующие предложение.
Ключевые выводы
- 31 из 286 доступных страниц выборки рекламировали Markdown.
- Четыре объявления
rel="describedby"в HTML или заголовке HTTP Link.- Обнаружение не означает использование, цитирование или влияние на ранжирование Google.
Каковы два сигнала обнаружения?
HTML-страница может добавить <link rel="alternate" type="text/markdown" href="..."> для представления с той же основной информацией в Markdown. Она может добавить <link rel="describedby" href=".../llms.txt"> для карты, охватывающей эту страницу.
Предложение также допускает эквивалентные HTTP-заголовки Link. Заголовки полезны для ресурсов, не являющихся HTML, а HTML проще проверять и генерировать из общей разметки. Используйте абсолютные или корректно разрешаемые URL, сохраняйте доступность обоих ресурсов и не рекламируйте устаревшее преобразование.
Что предоставили 294 страницы?
Наш тест от 12 августа отобрал до трёх связанных страниц из каждого из 113 корневых ответов, соответствовавших правилу отбора ответов с H1 в начале. Он запросил 294 страницы и получил 286. Тридцать одна доступная страница объявляла альтернативу Markdown, а четыре — rel="describedby". Детектор проверял и HTML, и заголовки HTTP Link.
Результат устанавливает датированную базовую линию для этой конкретной выборки. Он не показывает, что у остальных страниц нет Markdown по не рекламируемому URL, и не охватывает каждую страницу каждого хоста. Совокупность и методика опубликованы в v2-adoption-stats.json.
Как безопасно реализовать связи
Генерируйте Markdown из того же источника, что и HTML. Для маршрута с завершающей косой чертой v2 предлагает представление index.md или index.html.md. Оставляйте HTML каноническим для Поиска, а Markdown рассматривайте как альтернативное представление, а не конкурирующую редакционную страницу.
Разрешайте describedby по области. Для англоязычной продуктовой страницы можно использовать /llms.txt, для страницы документации — /docs/llms.txt, а локализованный раздел может использовать собственный файл для конкретного пути. Проверяйте итоговый собранный HTML, а не только переменные шаблона.
Добавьте в CI проверки отсутствующих альтернатив, ресурсов не с кодом 200, неверных MIME-типов и связей, выходящих за предполагаемую область. Валидатор проверяет синтаксис файла, а контрольный список миграции v2 описывает порядок запуска.
Чего эти связи не могут
Они не могут заставить сканер загрузить ресурс, обойти настройки robots, безопасно сделать частную информацию общедоступной или улучшить позиции в Поиске. Google прямо говорит, что Поиск не использует специальные текстовые AI-файлы для своих генеративных функций.
Практический результат скромнее: совместимый агент может обнаружить более чистое представление и отобранную карту через стандартные веб-ссылки. Прежде чем заявлять большее, измерьте запросы в журналах.
Для контекста начните с материала что такое llms.txt и сравните связи с реальными рабочими примерами.
Обязателен ли rel="describedby"?
Нет. Это часть механизма обнаружения в предложении v2, а не минимального синтаксиса файла.
Можно ли использовать заголовки HTTP вместо HTML?
Да. Предложение описывает оба варианта. Выберите уровень, который можете надёжно генерировать и тестировать.
Должен ли Markdown сам объявлять себя каноническим?
Для Поиска оставляйте HTML-страницу каноническим общедоступным документом. Ресурс Markdown должен явно указывать свой источник и сохранять эквивалентность содержимого.