Как открыть сайт для AI и что для этого сделать маркетингу, SEO и разработке

Редакция «Текстерры»

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

Сбой на любом этапе может сделать страницу недоступной конкретному краулеру или лишить ее возможности выступать прямым источником для AI-системы.

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

Техническая доступность строится на трех условиях

Страница должна быть доступна для обычного поиска

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

Для других AI-систем правила отличаются. ChatGPT, Perplexity, Claude и Яндекс используют собственные краулеры и пользовательские агенты. Но общий принцип сохраняется: если система не может добраться до страницы или извлечь из нее факты, рассчитывать на стабильное появление сайта в ответах рано.

AI-боты должны получать нужные правила доступа

Открыть или закрыть всех AI-ботов одним правилом будет неверно, потому что обучающие краулеры, поисковые краулеры и пользовательские агенты решают разные задачи.

У OpenAI, например, разделены несколько агентов:

• GPTBot связан с обходом публичного веба для данных, которые могут использоваться в обучении моделей.

• OAI-SearchBot используется для поисковых функций ChatGPT.

• ChatGPT-User приходит на сайт по действию пользователя, например когда человек вставляет ссылку в чат и просит проанализировать страницу.

Запрет GPTBot не означает запрет поисковой видимости в ChatGPT. Для управления поисковым присутствием нужно отдельно смотреть OAI-SearchBot. Для отказа от обучающих обходов — отдельно GPTBot. Для пользовательских сценариев — отдельно ChatGPT-User.

Похожим образом работают другие системы. Anthropic разделяет ClaudeBot, Claude-SearchBot и Claude-User. Perplexity описывает отдельные user-agent и правила robots.txt. У Яндекса ответы «Поиска с Алисой» формируются на основе проиндексированных страниц, а для запрета использования контента в AI-ответах применяется YandexAdditional или YandexAdditionalBot.

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

Страница должна быть понятна как источник

Даже доступная и проиндексированная страница может быть слабым источником, если AI-система плохо понимает, о какой компании, услуге, авторе, адресе или продукте идет речь. Здесь помогают структура страницы, внутренняя перелинковка, актуальные факты и разметка Schema.org.

Разметка не гарантирует попадание в AI-ответы. Ее задача скромнее и практичнее: помочь поисковым системам и другим машинам точнее распознать сущности на странице и связать их между собой. Например, понять, что сайт, профиль компании, филиал, эксперт и услуга относятся к одному бренду.

Проверка сайта проходит в пять этапов

Техническую доступность разумнее всего проверять по цепочке:

• Страницу можно найти.

• Страницу можно обойти.

• Для Google страницу можно проиндексировать и показать со сниппетом.

• Со страницы можно извлечь основной контент.

• Содержимое можно связать с понятными сущностями: компанией, услугой, продуктом, автором, адресом, отзывом.

Такая последовательность относится прежде всего к поисковым краулерам, которые заранее обходят страницы и добавляют их в индекс. Если URL не обнаружен, поисковый краулер до него не дойдет. Запрет в robots.txt может остановить обход страницы таким краулером, а WAF блокирует сам запрос и способен полностью закрыть доступ к содержимому. Noindex или запрет сниппета может лишить страницу возможности стать прямым источником в поисковых AI-функциях. Если основной текст подгружается через JavaScript, часть AI-краулеров может получить HTML без нужного содержания: описания услуги, условий, цен, FAQ или характеристик товара.

Пользовательские агенты работают иначе: они могут открыть конкретный URL сразу после запроса человека, поэтому предварительная индексация для такого обращения не требуется. Например, ChatGPT-User и Perplexity-User посещают страницу по действию пользователя; правила robots.txt в таких случаях могут не применяться.

Страницы должны быть доступны через внутренние ссылки, а для Google и Яндекса — также указаны в sitemap

Сначала нужно понять, как AI-краулер вообще найдет нужную страницу. Для первой проверки не обязательно брать весь сайт: достаточно выбрать 10–30 важных URL. Обычно это страницы услуг, коммерческие разделы, кейсы, экспертные статьи, FAQ, страницы филиалов, карточки продуктов и справочные материалы.

Для каждой страницы проверьте несколько вещей:

• есть ли она в sitemap;

• ведут ли на нее ссылки с других страниц сайта;

• совпадает ли адрес страницы в sitemap, меню, хлебных крошках, canonical и внутренних ссылках;

• доступна ли страница по обычной ссылке, без поиска по сайту, фильтра, формы, авторизации или закрытого раздела;

• обновляется ли дата lastmod в sitemap, когда страница действительно меняется;

• нет ли рядом старых лендингов, архивных PDF и прежних версий страницы, которые могут давать AI-системам устаревшие данные.

Особенно важно найти страницы-сироты — URL, на которые не ведут внутренние ссылки. Такая страница может быть указана в sitemap или открываться по прямому адресу. Пользователь не найдет ее через навигацию сайта, а поисковый краулер сможет обнаружить URL через sitemap. При этом отсутствие внутренних ссылок затрудняет обнаружение страницы другими краулерами и мешает поисковым системам понять ее место в структуре сайта.

Отдельно проверьте страницы, которые появляются только после выбора фильтра, отправки формы или клика по интерактивному элементу. Краулер может не повторить эти действия и не увидеть нужный контент. Если подборка, категория или услуга важна для продаж и AI-видимости, лучше сделать для нее отдельную посадочную страницу с обычным URL и обычными ссылками внутри сайта.

Краулеры должны получать корректный ответ сервера

Следующий шаг — проверить, действительно ли AI-краулер может открыть страницу. Обычной проверки в браузере для этого недостаточно: пользователь и бот могут получать от сайта разные ответы.

Для важных страниц нужно посмотреть:

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

• какой HTTP-статус получает бот: нормальный ответ 200 или ошибку 403, 404, 429, 5xx;

• нет ли длинных цепочек редиректов, циклов или перенаправлений на региональные заглушки;

• какой ответ сайт возвращает запросам с разными строками User-Agent;

• не блокируют ли доступ CDN, WAF, антибот-система или геофильтр;

• не показывает ли сайт боту капчу, проверку через JavaScript или сообщение «слишком много запросов»;

• видны ли заходы нужных ботов в access-логах сервера.

Robots.txt показывает только часть картины. В нем может быть все разрешено, но защитная система все равно не пустит AI-краулера на сайт. Например, WAF принимает его за подозрительный автоматический трафик и отдает 403. Для обычного пользователя страница открывается, а OAI-SearchBot, Claude-SearchBot или PerplexityBot получает ошибку и не может забрать контент.

Такая проблема часто не попадает в стандартную веб-аналитику. Поэтому проверку лучше делать вместе с разработчиком или администратором: отправить запрос с нужной строкой User-Agent, сверить статус, заголовки, редиректы и HTML-ответ, затем проверить официально опубликованные диапазоны IP сервиса и сопоставить запросы с серверными журналами. Такие диапазоны, например, публикуют OpenAI и Perplexity. Одной строки User-Agent недостаточно, чтобы подтвердить, что запрос действительно пришел от нужного бота: ее легко подделать, а WAF может учитывать IP-адрес. Если вместо страницы бот получает капчу, заглушку, ошибку или полупустой код, AI-система не сможет использовать материал как нормальный источник.

Страницы должны допускаться к индексации и сниппетам

После доступа к странице нужно проверить правила, которые определяют, можно ли ее индексировать, показывать в выдаче и использовать в сниппетах. Здесь легко перепутать похожие настройки, хотя они отвечают за разные задачи.

Robots.txt управляет обходом: он говорит краулеру, куда можно заходить, а куда нельзя. noindex относится уже к индексации: страница может открываться для бота, но система не должна добавлять ее в индекс. nosnippet и max-snippet:0 ограничивают использование текста страницы в сниппете. X-Robots-Tag задает такие же запреты через HTTP-заголовок — это особенно важно для PDF, изображений и других файлов, где нет обычного HTML-кода страницы. Canonical помогает поисковой системе выбрать основную версию, если есть дубли или похожие URL.

Для Google AI Overviews и AI Mode нужно отдельно проверить ограничения на сниппеты. Страница должна иметь право показываться со сниппетом, чтобы Google мог показать ее как ссылку на источник в AI Overviews или AI Mode. Поэтому nosnippet и max-snippet:0 могут закрыть странице путь в AI-блоки Google, даже если она индексируется.

Что стоит проверить:

• не остался ли noindex на важных страницах после тестового контура, редизайна или технических правок;

• нет ли X-Robots-Tag с запретом индексации на HTML-страницах, PDF и других файлах;

• не стоят ли nosnippet или max-snippet:0 на страницах, которые должны участвовать в Google AI-функциях;

• не указывает ли canonical с важной страницы услуги на общий раздел, дубль или устаревший URL;

• нет ли soft 404: страница отдает статус 200 OK, но по содержанию похожа на пустую, ошибочную или бесполезную;

• корректно ли связаны языковые и региональные версии через hreflang, если сайт работает на нескольких языках или в нескольких регионах.

Canonical лучше проверять отдельно по каждой важной странице. Например, если страница конкретной услуги ссылается canonical на общий раздел, поисковая система может выбрать этот раздел как канонический URL и не учитывать страницу услуги как самостоятельный результат. Тогда детальная страница с условиями, кейсами и точными формулировками может не использоваться как отдельный источник.

С PDF тоже нужна отдельная проверка. Поисковые системы могут индексировать такие файлы, но управлять ими сложнее: запреты часто задаются через X-Robots-Tag, текст может быть сканом (иначе говоря, картинкой), а условия в файле вообще быть устаревшими. Коммерчески важные факты — цены, сроки, состав услуги, ограничения, регионы работы — лучше держать и постоянно актуализировать на обычной странице.

Основной контент должен извлекаться без сложных действий

Дальше проверяем, видит ли AI-краулер сам текст страницы. URL может быть доступен, страница может индексироваться, но внутри бот получит слишком мало полезного содержания: без описания услуги, условий, цен, характеристик, FAQ или ссылок на важные разделы.

Часто это связано с JavaScript. Пользователь открывает страницу в браузере и видит все как положено, потому что браузер выполняет скрипты и догружает содержимое. Краулер же может получить более простую версию страницы: HTML без основного текста или только технические блоки, из которых нельзя понять, что именно предлагает компания. Google умеет обрабатывать JavaScript, но часть AI-краулеров работает быстрее и проще: получает HTML, читает доступный текст и не повторяет весь путь пользователя на странице.

Что стоит проверить:

• есть ли основной текст услуги, цены, условия, характеристики и FAQ в HTML, который отдает сервер;

• не появляются ли важные блоки только после клика, выбора фильтра, авторизации или сложной подгрузки;

• сделаны ли ссылки через обычный href, чтобы краулер мог перейти дальше по сайту;

• не лежат ли важные данные только на изображениях, в скриншотах, PDF, презентациях или видео;

• понятна ли структура таблиц, списков, карточек услуг и FAQ в HTML;

• не скрывает ли lazy loading основной контент;

• доступны ли структурированные данные в отрендеренном HTML; для краулеров без поддержки JavaScript их желательно также выводить на сервере.

Для сайтов на React, Vue и похожих фреймворках стоит отдельно посмотреть, какой код получает бот до выполнения скриптов. Если сервер отдает только контейнер вроде <div id="app"></div> и сообщение «Загрузка…», а текст появляется позже в браузере, для части краулеров страница будет почти пустой. В таком случае нужна серверная отдача содержимого: SSR, SSG, prerendering или другой подход, который дает ботам готовый текст.

Данные должны связываться с понятными сущностями

Последний уровень проверки — насколько понятно страница описывает объекты и их свойства: компанию, услугу, продукт, автора, эксперта, филиал, адрес филиала, дату публикации и дату обновления. AI-система может прочитать текст, но ошибиться в связях: принять старую услугу за актуальную, не сопоставить сайт с профилями компании, перепутать автора с однофамильцем или не понять, к какому региону относится предложение.

Для этого используют Schema.org — словарь структурированных данных. Он помогает поисковым системам и другим машинам точнее распознавать объекты на странице.

Для AI-видимости разметка полезна там, где нужно снять неоднозначность:

• Organization связывает сайт с компанией;

• LocalBusiness уточняет адрес, телефон, график работы и регион;

• Service и Product описывают услуги и продукты;

• Article передает автора, дату публикации и дату обновления;

• Person помогает явно указать автора или эксперта;

• sameAs указывает на внешние профили бренда.

Данные в разметке должны совпадать с тем, что видит пользователь на странице.

Бонус: llms.txt может дополнить проверку

/llms.txt — экспериментальный формат. Сейчас его предлагают использовать как краткий путеводитель по важным страницам сайта. Подтвержденной поддержки со стороны крупных поисковых и AI-сервисов пока нет, поэтому файл стоит рассматривать только как дополнительный элемент.

Использовать его можно, но не нужно строить лишних ожиданий. Это дополнительная навигационная подсказка для LLM и AI-агентов, и базовую техническую доступность она не закрывает. У сайта все равно должны быть нормальные robots.txt, sitemap, Schema.org, индексируемость, HTML-структура и серверная отдача страниц.

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

Практичнее поступить так: сначала привести в порядок базовую техническую доступность, затем при необходимости добавить /llms.txt — как карту главных страниц, документации, условий, справочных материалов и актуальных источников.

Зоны ответственности нужно разделить между командой

Маркетолог задает бизнес-логику доступности

Маркетологу не нужно самому править robots.txt или настраивать WAF. Его задача — определить, какие страницы и факты важны для бизнеса.

Что делает маркетолог:

• выбирает 10–30 приоритетных URL для проверки;

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

• определяет критичные факты: услуги, цены, сроки, регионы, условия, кейсы, сертификаты, эксперты, гарантии;

• находит устаревшие источники: архивные лендинги, старые PDF, прежние услуги, страницы мероприятий, неактуальные презентации;

• решает, какие материалы нужно обновить, закрыть, объединить или удалить;

• описывает, какие разделы должны быть недоступны для AI-систем: личные кабинеты, внутренние базы, служебные документы, конфиденциальные материалы.

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

SEO отвечает за обнаружение, индексацию и контроль правил

SEO-специалист проверяет, проходит ли страница путь от URL до допустимого источника.

Что делает SEO:

• анализирует sitemap и внутреннюю перелинковку;

• ищет страницы-сироты;

• проверяет robots.txt для поисковых и AI-краулеров;

• проверяет meta robots, X-Robots-Tag, canonical, hreflang;

• смотрит HTTP-статусы, редиректы, soft 404 и дубли;

• проверяет, какие страницы попали в Google Search Console и Яндекс Вебмастер;

• валидирует Schema.org;

• смотрит, нет ли запретов на сниппеты у страниц, важных для Google AI-функций;

• анализирует access-логи вместе с разработчиком или администратором.

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

Разработчик отвечает за фактическую отдачу страниц ботам

Разработчик проверяет, что сайт реально отдает ботам, а не только то, что написано в правилах.

Что делает разработчик:

• проверяет ответ сервера через curl и другие инструменты с нужными user-agent;

• смотрит HTTP-статус, заголовки, редиректы и HTML;

• проверяет CDN, WAF, антибот-правила, капчи, rate limits и геоблокировки;

• настраивает доступ для нужных поисковых и AI-ботов;

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

• исправляет шаблоны sitemap, canonical, hreflang, meta robots и JSON-LD;

• проверяет, что CSS и JS, нужные для рендеринга, открыты;

• настраивает логирование визитов краулеров;

• добавляет проверки в релизный процесс.

Здесь обязательно проверить конкретный ответ сервера для конкретного агента: OAI-SearchBot, Googlebot, YandexBot, YandexAdditionalBot, Claude-SearchBot, PerplexityBot и других ботов, значимых для проекта.

Мы подготовили компактную таблицу, которая помогает совместить зоны проверки и зоны ответственности разных специалистов.

После релизов контроль должен возобновляться

Проверка должна стать частью регулярных работ, так как доступность может нарушиться после любых изменений: редизайна, переезда на новую CMS, обновления шаблона, внедрения CDN, усиления антибот-защиты, чистки старых разделов, правок robots.txt, генерации нового sitemap.

Минимальный порядок работы:

• Собрать список важных URL.

• Зафиксировать для каждого URL его роль: услуга, кейс, статья, FAQ, продукт, филиал, эксперт.

• Проверить цепочку: найти → обойти → проиндексировать → извлечь → понять.

• Разделить задачи по ответственным: маркетинг, SEO, разработчик.

• Исправить критичные блокировки и конфликты.

• Проверить ответ сервера и логи после внедрения.

• Повторять экспресс-проверку после крупных релизов.

• Раз в месяц смотреть визиты ключевых краулеров и статусы ответов.

Если нужна отдельная работа с содержанием страниц, технический аудит стоит связывать с факт-матрицей: какие сведения о компании должны быть доступны, где они лежат, какие источники противоречат друг другу, какие страницы должны стать основными для AI-систем. О подготовке страниц как источников AI-ответов мы рассказывали на вебинаре «Контент для AI-ответов: как сделать страницу источником».

Техническая доступность не делает страницу автоматически лучшим источником для AI — но она дает сайту шанс быть найденным, обработанным и правильно понятым.

Читайте также:

Техническая доступность сайта: как проверить, видит ли его поиск и AI

Как выстроить структуру страницы, чтобы ее понимали люди, поиск и AI-системы

Как SEO делает бренд заметнее, понятнее и убедительнее