neuropushНи `llms.txt`, ни Schema.org не заставляют модель процитировать бренд — оба инструмента снижают технические барьеры для этого, но не заменяют содержательную работу над контентом и присутствием на источниках.
llms.txt
Предложенная (не официальная, но всё шире принятая) конвенция: markdown-файл в корне домена, по аналогии с `robots.txt` и `sitemap.xml`, но адресованный не краулерам, а ИИ-агентам напрямую. В нём кратко описывается, чем занимается сайт, и перечисляются ключевые разделы со ссылками — по сути, готовый краткий брифинг для модели или агента, который хочет быстро понять структуру сайта, не обходя его целиком.
Schema.org / JSON-LD
Разметка структурированных данных снимает неоднозначность: вместо того чтобы модель угадывала из текста, что это за сущность (Organization, конкретная Question/Answer пара, Article с датой публикации), она получает эти факты явно, в машиночитаемом виде. Это одновременно помогает классическим rich-результатам в поиске и повышает шансы, что ИИ-парсер извлечёт правильный факт без искажений.
Что первично
Оба файла бесполезны, если сайт в принципе не пускает ИИ-краулеров — `robots.txt` с явным `Allow` для GPTBot, ClaudeBot, PerplexityBot, Google-Extended и подобных ботов должен стоять раньше всего остального. Дальше порядок такой: техническая доступность → структурированные данные по факту-носителям контента (FAQPage, Article, Product) → `llms.txt` как краткая карта поверх всего этого. Пропуск любого из шагов не ломает остальные, но ослабляет общий эффект.
Содержательное наполнение: почему модели вообще ссылаются
И `llms.txt`, и JSON-LD — это только инфраструктура. Решение о том, процитировать ли бренд, зависит от того, насколько обучающие данные модели или её контекст при RAG содержат однозначную, непротиворечивую информацию именно с этого сайта. Если контент на странице повторяет общеизвестные факты без уникальных формулировок или собственных данных, модель скорее выдаст обобщённый ответ без привязки к конкретному источнику. Чтобы модель выбрала сайт как референс, нужны либо редкие факты (спецификации, даты, цифры), либо изложение, которое можно вставить в ответ как самостоятельную цитату — разметка облегчает извлечение такого фрагмента, но не создаёт его из ничего.
Частота обновления и стабильность структуры
GPTBot, ClaudeBot и PerplexityBot переобходят сайты с разной периодичностью, и не мгновенно. Модели без браузинга не обновляют своё представление о мире в реальном времени вообще. Поэтому для сохранения актуальности ссылки на бренд важна не только сама разметка, но и предсказуемость структуры сайта: если страница переезжает на новый URL или меняет заголовок раздела без редиректа, старый контекст, на который уже мог сослаться агент, обрывается. Стабильный `robots.txt` и корректная обработка переездов страниц (301, а не тихий 404) снижают риск того, что модель в какой-то момент сошлётся на устаревший или недоступный адрес.
Практические препятствия при внедрении: конструкторы сайтов и хостинг
На практике внедрение `llms.txt` и корректной разметки Schema.org часто упирается в ограничения платформы, на которой размещён сайт. Конструкторы вроде Tilda или Wix не дают прямого доступа к корню домена — файл `llms.txt` физически некуда положить. Проблема решается через проксирующий слой: например, настройка Cloudflare Worker, который перехватывает запрос к `/llms.txt` и возвращает содержимое из переменной окружения или внешнего хранилища. Альтернатива — разместить файл на отдельном поддомене (например, `static.site.ru/llms.txt`), но это требует указания корректного редиректа или ссылки в настройках агента, что поддерживается не всеми ИИ-системами.
Аналогичная ситуация с JSON-LD: некоторые конструкторы (особенно старые версии или шаблоны) вырезают inline-скрипты из кода страницы, воспринимая их как потенциально небезопасные. Разметка, вставленная через HTML-блок или кастомный код, может не сохраниться после публикации. Решение — проверять финальный HTML страницы через браузерный инспектор или сервисы валидации разметки после каждого обновления. Если конструктор не поддерживает кастомные скрипты, имеет смысл выгружать разметку через Google Tag Manager (если площадка это разрешает) или через API внешнего сервиса структурированных данных, который добавляет JSON-LD на этапе сборки страницы.
Блокировка ИИ-краулеров на уровне CDN и хостинга
Распространённая проблема — владелец сайта явно разрешает ботов в `robots.txt`, но они всё равно не доходят до страниц. Причина часто в настройках Cloudflare или аналогичного CDN: по умолчанию в некоторых тарифах включена защита от ботов (Bot Fight Mode), которая блокирует или капчирует неизвестных краулеров, включая GPTBot, ClaudeBot и PerplexityBot. Даже если бот не получает 403, он может столкнуться с JavaScript-челленджем, который краулер не выполняет, и уйти без контента.
Решение: проверить логи CDN или хостинга на предмет 403/503 ошибок для User-Agent’ов ИИ-краулеров. В Cloudflare для пропуска нужных ботов можно создать правило WAF (Web Application Firewall), которое явно разрешает трафик от известных IP-диапазонов ИИ-компаний (списки публикуются OpenAI, Anthropic, Google). Альтернатива — отключить Bot Fight Mode и использовать более мягкие настройки проверки. Без этого шага вся остальная оптимизация под GEO не имеет смысла: боты просто не увидят ни контент, ни разметку, ни `llms.txt`.
Связи между блоками разметки: @id и граф сущностей
Когда на странице несколько блоков JSON-LD (например, отдельно Organization, отдельно FAQPage, отдельно Article), без явных ссылок через `@id` они воспринимаются парсером как разрозненные сущности, не связанные друг с другом. Это снижает качество извлечения фактов: модель может найти название организации и вопрос-ответ, но не поймёт, что FAQ относится именно к этой организации.
Правильная практика — строить единый граф: каждый блок получает уникальный `@id` (например, `#organization`, `#faq`, `#article`), а в родительском блоке указываются ссылки через `@id` дочерних сущностей. В случае с FAQPage, сам блок FAQPage должен быть связан с основным `@id` страницы или организации через свойство `mainEntity` или `about`. Без этих связей выигрыш от разметки частично теряется — для GEO, где важна однозначная атрибуция данных источнику, связность критична.
Частые заблуждения про llms.txt и Schema.org
Распространённое заблуждение — что `llms.txt` гарантирует цитирование бренда в ответах ИИ. Файл — это подсказка для агента, а не директива. Модель может проигнорировать его, если контент не релевантен запросу или если у неё есть более авторитетный источник в контексте. Аналогично, Schema.org не принуждает модель ссылаться на сайт — разметка лишь снижает ошибки извлечения фактов, но не меняет логику ранжирования источников внутри модели.
Другое заблуждение — что достаточно один раз настроить `llms.txt` и JSON-LD, и эффект будет бессрочным. На практике краулеры могут менять алгоритмы обхода, модели — прекращать поддержку устаревших схем (например, менять формат вывода структурированных данных), а файл `llms.txt` может быть удалён или изменён владельцем домена. Регулярная проверка (хотя бы раз в квартал) доступности файла, валидности разметки и статуса блокировок необходима для поддержания эффекта.
Третье заблуждение — что `llms.txt` заменяет sitemap.xml. Это разные инструменты: sitemap перечисляет все страницы для поисковых краулеров, `llms.txt` — краткий путеводитель для ИИ-агентов. Если на сайте 10 000 страниц, в `llms.txt` не нужно выносить их все — достаточно ссылок на ключевые разделы (категории, топ-20 статей). Остальное агент найдёт через браузинг, если контент открыт.
Частые вопросы
1. Можно ли разместить llms.txt не в корне домена, а в подпапке?
Нет, стандарт предполагает расположение в корне — по адресу `https://site.ru/llms.txt`. Размещение в подпапке (например, `/blog/llms.txt`) не поддерживается большинством ИИ-агентов. Если корень недоступен (конструктор, отсутствие FTP), используйте проксирование через Cloudflare Worker.
2. Как проверить, что JSON-LD не вырезается конструктором сайта?
После публикации откройте исходный код страницы (Ctrl+U в браузере) и найдите свой блок разметки. Если его нет — конструктор удалил скрипт. Альтернатива: используйте валидатор Schema.org (https://validator.schema.org/) — он покажет, какие данные находит на странице.
3. Нужно ли менять llms.txt при каждом обновлении контента?
Не обязательно. Файл должен содержать стабильные ссылки на ключевые разделы, а не на каждую новую страницу. Если структура сайта не меняется (категории, топ-статьи, контакты), файл остаётся актуальным. Добавлять ссылку на новую статью стоит только если она принципиально меняет тематику сайта.
4. Cloudflare блокирует GPTBot. Как это проверить?
Посмотрите логи безопасности Cloudflare (раздел Analytics → Security Events) на наличие событий с User-Agent, содержащим "GPTBot". Если они отображаются как заблокированные (403) или с челленджем — создайте правило WAF: "If User-Agent contains GPTBot → Allow". Аналогично для ClaudeBot и PerplexityBot.
5. Что делать, если конструктор не позволяет кастомный HTML (JSON-LD)?
Если конструктор полностью блокирует вставку скриптов, используйте внешний CDN с функцией инъекции скриптов (например, Cloudflare Workers + HTMLRewriter, который добавляет блок разметки перед закрывающим тегом `