Schema.org, llms.txt, robots.txt и AI-краулеры: что реально влияет на доступность сайта для AI-поиска

Наталья Малыгина

Эксперт в области крауд-маркетинга и SERM компании Zenlink

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

Если нужный бот получает 403, страница закрыта в robots.txt или основной контент не доезжает до краулера, обсуждать специальную разметку для AI пока рано.

Поэтому сначала разберемся, какие механизмы действительно влияют на техническую доступность сайта для AI-поиска, а какие пока остаются экспериментом.

Сначала проверить, может ли бот вообще получить страницу

Для Google здесь нет отдельного набора технических требований специально под AI Overviews и AI Mode. Страница должна соответствовать обычным требованиям Google Search: быть доступной для обхода, проиндексированной и иметь возможность показываться в поиске со сниппетом. Google отдельно указывает, что никаких дополнительных технических требований для AI-функций нет.

Поэтому первая проверка мало отличается от обычного технического SEO-аудита:

• страница отвечает 200 OK;

• URL доступен без обязательной авторизации;

• нужный раздел не закрыт в robots.txt;

• на странице случайно не установлен noindex;

• canonical указывает на правильный URL;

• основной контент доступен краулеру;

• JavaScript не мешает получить критически важный текст;

• CDN или WAF – инфраструктура доставки и защиты сайта – не блокируют нужного бота.

Скучнее, чем обсуждать новые файлы для LLM. Зато именно здесь часто находится причина, почему система не может нормально получить страницу.

Логика технической проверки получается такой:

• robots.txt – можно ли обходить URL;
• HTTP и рендеринг – получает ли бот содержимое;
• noindex и canonical – как поисковику работать со страницей;
• sitemap.xml – какие URL нужно обнаружить;
• Schema.org – что находится на странице;
• llms.txt – дополнительный экспериментальный слой.

Такое разделение было заложено и в исходной структуре материала.

«Бот OpenAI» уже слишком общее понятие

Одна из частых ошибок – открыть GPTBot и решить, что этим сайт подготовлен к ChatGPT Search.

У крупных AI-платформ разные краулеры выполняют разные задачи.

Фрагмент robots.txt Zenlink: в одном файле могут быть прописаны поисковые, AI-search и другие краулеры с отдельными правилами доступа

На практике одного списка user-agent недостаточно. Например, при проверке robots.txt мы отдельно смотрим, какие правила применяются к поисковым AI-краулерам, ботам для обучения моделей и обычным поисковым роботам. Само наличие OAI-SearchBot или Claude-SearchBot в файле еще ничего не говорит, если не посмотреть, что именно им разрешено или запрещено.

OpenAI рекомендует не блокировать OAI-SearchBot, если сайт должен полноценно появляться в ChatGPT Search. При этом GPTBot отвечает за другой сценарий и может быть запрещен независимо от поискового бота.

У Anthropic разделение еще нагляднее: ClaudeBot связан с потенциальным использованием контента для обучения, Claude-SearchBot работает с поиском, а Claude-User обращается к сайту по пользовательскому запросу. Все три бота Anthropic поддерживают правила robots.txt.

Perplexity тоже разделяет автоматический поисковый обход и пользовательские запросы. PerplexityBot предназначен для поиска и ссылок на сайты в результатах Perplexity. А Perplexity-User срабатывает, когда пользователь сам инициирует получение страницы. Здесь есть важный нюанс: Perplexity прямо пишет, что такой пользовательский fetcher обычно игнорирует правила robots.txt.

Поэтому вопрос «разрешены ли AI-боты?» слишком общий. Точнее спрашивать: какому user-agent нужен доступ и для какой задачи.

И еще один момент: Allow: / означает только то, что правила robots.txt не запрещают этому боту обход URL. Это не обещание индексации, цитирования или появления страницы в AI-ответе.

robots.txt и noindex работают на разных уровнях

Эти два механизма до сих пор смешивают даже в технических ТЗ.

Если коротко:

• robots.txt задает правила обхода URL для краулеров, которые их соблюдают;

• noindex сообщает поисковой системе, что полученную страницу не нужно включать в индекс.

Например, на странице стоит:

< meta name="robots" content="noindex" >

Но URL одновременно закрыт в robots.txt.

В такой ситуации бот может вообще не получить HTML страницы и, соответственно, не увидеть noindex. Google прямо указывает, что robots meta directives работают только тогда, когда краулер может получить страницу.

OpenAI описывает аналогичную ситуацию для ChatGPT Search: чтобы OAI-SearchBot смог прочитать метатег noindex, доступ к странице сначала должен быть разрешен.

У Google есть и отдельные директивы для управления тем, сколько содержимого может использоваться в AI Overviews и AI Mode:

• nosnippet запрещает показывать текстовый сниппет и использовать содержимое страницы как прямой источник для этих AI-функций;

• data-nosnippet позволяет закрывать от сниппета отдельные части страницы;

• max-snippet ограничивает объем текста, который Google может использовать;

• noindex исключает страницу из поиска.

Получается, часть управления AI-поиском уже давно живет внутри обычных SEO-директив. Отдельный geo-meta-super-tag для этого не понадобился.

Schema.org полезна, но не как «фактор GEO»

Schema.org – это словарь сущностей и свойств. А структурированные данные на его основе дают поисковым системам машиночитаемое описание содержимого страницы: где находится организация, автор, статья, товар, хлебные крошки и другие сущности. Google использует для этого, в частности, JSON-LD, Microdata и RDFa.

Простой пример для статьи:

{

"@context": "https://schema.org",

"@type": "Article",

"headline": "Название статьи",

"author": {

"@type": "Person",

"name": "Имя автора"

},

"datePublished": "2026-08-20"

}

Использовать такую разметку нормально. Делать из нее отдельный фактор AI-ранжирования – уже нет.

Google прямо пишет, что для AI Overviews и AI Mode не требуется специальная Schema.org-разметка. Структурированные данные должны соответствовать тому, что пользователь реально видит на странице, но сами по себе не гарантируют появление в генеративной выдаче.

В 2026 году платформа для SEO-аналитики Ahrefs попыталась проверить это на данных. Исследователи отследили 1 885 страниц, которые добавили JSON-LD, и сравнили их примерно с 4 000 контрольных страниц.

В ChatGPT и Google AI Mode статистически значимого роста цитирований после добавления Schema.org не обнаружили. Для AI Overviews исследование показало небольшое снижение относительно контрольной группы, но сами авторы отдельно предупреждают: это не доказывает, что Schema.org ухудшает AI-видимость.

У исследования есть ограничения:

• анализировались страницы, которые уже активно цитировались AI;

• речь шла именно о JSON-LD;

• разные типы Schema рассматривались вместе;

• эффект отслеживался на ограниченном временном окне.

Поэтому вывод здесь довольно спокойный: структурированные данные остаются нормальным инструментом технического SEO и помогают явно описывать сущности, но доказанного роста AI-цитирований только за счет Schema.org пока нет.

llms.txt: идея хорошая, доказательств пока меньше

Идея файла понятна: положить в корень сайта Markdown-документ, который коротко описывает проект и содержит ссылки на важные материалы.

Например:

# Example

> Краткое описание проекта

## Documentation

- [Документация](https://example.com/docs)

- [API](https://example.com/api)

По замыслу получается небольшая карта сайта в удобном для LLM и AI-агентов формате.

Но llms.txt пока остается предложенной спецификацией. Это не аналог robots.txt, не механизм контроля доступа и не утвержденный веб-стандарт. Сам файл ничего не разрешает и ничего не запрещает.

Для Google ситуация сформулирована довольно прямо: специальные machine-readable AI-файлы вроде llms.txt не нужны, чтобы сайт мог появляться в AI Overviews или AI Mode.

А в июне 2026 года Ahrefs опубликовал исследование уже по реальным запросам к серверам.

В выборку вошли 137 210 доменов. Около 28% из них имели валидный llms.txt, но 97% этих файлов за май 2026 года не получили вообще ни одного запроса.

Даже среди оставшихся 3% картина оказалась не особенно впечатляющей для AI Search:

• 96% запросов к файлам приходили от ботов;

• только 19,5% всех обращений к читаемым llms.txt были от идентифицированных AI-инструментов;

• AI retrieval bots вроде OAI-SearchBot, PerplexityBot и поискового бота Claude дали лишь небольшую долю запросов;

• исследователи не обнаружили попыток AI-ботов самостоятельно искать llms.txt на сайтах, где такого файла не существовало.

Это не означает, что формат бесполезен навсегда. Его могут использовать AI-агенты, инструменты для разработчиков или будущие системы.

Но на сентябрь 2026 года оснований включать llms.txt в обязательный набор технических работ по GEO мало.

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

Sitemap.xml все еще скучный, но полезный

На фоне новых GEO-терминов sitemap.xml выглядит почти архаично. Но свою задачу он выполняет.

Sitemap помогает поисковой системе обнаруживать URL, которые сайт предоставляет для обхода. При этом наличие страницы в sitemap не гарантирует ни crawling, ни indexing.

В sitemap логично держать канонические URL, которые действительно предполагается индексировать.

С lastmod работает тот же принцип: дата полезна, если отражает реальное изменение страницы. Автоматически обновлять ее каждый день на всех URL смысла мало.

Сам sitemap.xml при этом решает совсем другую задачу, чем robots.txt и Schema.org:

• robots.txt – правила обхода;
• sitemap.xml – обнаружение URL;
• canonical / noindex – работа с конкретной страницей;
• Schema.org – описание содержимого.

Смешивать это в один пункт «оптимизация под AI» не очень полезно.

С JavaScript лучше не спорить теоретически

Еще одна распространенная формулировка: «AI-краулеры не умеют JavaScript».

Для практической работы она слишком общая.

Google JavaScript рендерить умеет. У других краулеров возможности могут отличаться, а некоторые AI-системы получают документы через поисковые индексы или собственные механизмы поиска и получения контента. Google отдельно описывает crawling, rendering и indexing как разные этапы обработки JavaScript-страниц.

Типичный пример:

< body >

< div id="content" >< /div >

< script >

loadArticle();

< /script >

< /body >

В браузере пользователь может прекрасно видеть текст. Но это еще не означает, что нужный краулер получил то же содержимое.

Поэтому на конкретном сайте полезнее проверить:

1. HTTP-ответ.

2. Исходный HTML.

3. Результат рендеринга.

4. Серверные логи.

5. Настройки CDN и WAF.

6. Запросы от нужного user-agent.

Последний пункт особенно важен. User-agent сам по себе можно подделать, поэтому для критичных проверок стоит сопоставлять его с опубликованными IP-диапазонами или другими механизмами верификации, если платформа их предоставляет.

Иногда расследование «почему AI не видит сайт» заканчивается гораздо раньше Schema.org и llms.txt: сервер просто возвращает нужному краулеру 403 Forbidden.

В каком порядке проверять сайт перед GEO-экспериментами

Если собрать все вместе, технический аудит удобнее вести от базовых вещей к экспериментальным:

• нужные страницы отвечают 200 OK;

• контент доступен без обязательной авторизации;

• robots.txt не блокирует нужного поискового краулера;

• проверен конкретный user-agent, а не абстрактный «AI-бот»;

• CDN и WAF не режут его запросы;

• на странице нет случайного noindex;

• canonical указывает на нужную версию URL;

• sitemap содержит необходимые канонические страницы;

• основной текст присутствует в содержимом, которое реально получает бот;

• проверен JavaScript-рендеринг;

• серверные логи подтверждают фактический обход;

• структурированные данные валидны и соответствуют видимому контенту;

• llms.txt, если он нужен проекту, идет уже после базовых проверок.

Получается немного иронично: поиск заметно изменился, появились AI Overviews, AI Mode, ChatGPT Search, отдельные AI-краулеры и новый термин GEO.

А значительная часть технических проблем с «видимостью для AI» по-прежнему решается хорошим техническим SEO.