Как сделать WordPress-сайт видимым для ответов ИИ (2026)

Спойлер для занятых: пошаговый план для сайта на WordPress — что уже работает из коробки, что придётся добавить руками и в каком порядке это делать, чтобы попадать в ответы движков, а не только в выдачу.

Знакомый с сайтом на WordPress спросил меня на днях: а чё ещё нужно, если у него «и так всё из коробки»? Открыл его сайт глазами бота: HTML отдаётся честно, текст на месте, дата есть, а дальше пусто — ни блока вопросов, ни файла для движков, а в robots.txt висит общий запрет, который заодно вырубает цитирующих ботов. Полез составлять список, что чинить и в каком порядке, и список этот в итоге вырос в текст ниже.

Хорошая новость и плохая

Начну с хорошей новости. Твой WordPress отдаёт готовый HTML прямо с сервера, поэтому стартовая позиция у него заметно лучше, чем у приложений, которые рисуют страницу в браузере: бот приходит и сразу видит текст, и это уже полдела!

Теперь плохая: одного HTML мало. Чтобы попадать в ответы ChatGPT, Perplexity и обзоров Google, нужно закрыть ещё несколько сигналов, и по умолчанию они не закрыты ни в одной сборке, которую я видел.

Шаг первый: разметка через плагин

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

А вот блок вопросов и ответов почти всегда приходится добавлять отдельно, хотя именно он чаще прочих попадает в ответы движков (почему его нет в плагинах по умолчанию — вопрос к плагинам, а не ко мне). Собрать его можно генератором, а вставить обычным блоком с произвольным кодом.

Если нужного типа нет ни в плагине, ни в генераторе вопросов, собери его в общем генераторе разметки и вставь тем же способом. Это некрасиво с точки зрения архитектуры, но работает и занимает пять минут, а красоту архитектуры бот всё равно не оценит.

Шаг второй: файл для движков

Файл llms.txt — это курируемая карта сайта для ИИ-движков, и лежать он должен в корне, по адресу вида сайт/llms.txt, а не где-нибудь в подпапке темы.

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

Как составить содержимое, я разбирал отдельно, а проверить результат можно валидатором за полминуты.

Шаг третий: доступ ботам

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

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

Цитирующим ботам доступ нужен обязательно! Проверить текущее состояние можно проверкой доступа, а собрать корректный файл — генератором.

Шаг четвёртый: форма текста

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

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

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

Проверить готовность черновика можно оценкой текста ещё до публикации, прямо в браузере.

Шаг пятый: автор и свежесть

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

И отдельно про дату. Некоторые движки читают именно видимую дату на странице, а не только служебные поля в коде, поэтому дату обновления стоит выводить в шаблоне, а не прятать.

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

Что ломается чаще всего

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

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

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

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

Что делать с этим всем? Проверять глазами исходный код страницы хотя бы раз в квартал. Скучно, но других способов заметить такие вещи попросту нет, сколько ни ищи!

Сколько времени займёт весь список

Разложу по часам, потому что оценка «пара дней» тут никому не помогает, а конкретика помогает.

Доступ ботам и проверка файла robots.txt — двадцать минут вместе с чтением подсказок, и это самая быстрая часть из всех перечисленных. Разметка через плагин, если он уже стоит, — ещё полчаса, включая проверку валидатором.

Блок вопросов на трёх главных страницах — час-полтора, потому что писать надо руками и по делу, а не собирать формально. Файл для движков — минут сорок на генерацию и раскладку по корню сайта.

Самая долгая часть — форма текста, и она же единственная, которую нельзя сделать один раз и забыть: каждая новая статья требует того же внимания к первым предложениям разделов. Зато с привычкой это перестаёт занимать отдельное время и просто становится частью письма.

Итого за один вечер закрывается всё, кроме текстов, и обычно этого хватает, чтобы твой сайт перестал быть невидимым для машин. Один вечер!

Проверить за минуту

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

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

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

Чего делать не стоит

Раз уж план расписан, скажу и про обратное — про действия, которые выглядят разумными и при этом только вредят.

Не стоит ставить пять плагинов «для ИИ-оптимизации» разом, потому что каждый из них добавляет свою разметку, и в итоге на странице оказывается несколько блоков одного типа, что читается как ошибка, а не как усердие. Один сеошный плагин плюс аккуратные вставки руками работают, пожалуй, заметно лучше любого набора.

Не стоит массово вешать блок вопросов на все страницы сайта: четыре одинаковых вопроса, размноженных по сотне страниц с подстановкой города или товара, обесценивают и те блоки, которые были написаны честно.

И не стоит переписывать старые статьи целиком ради новой структуры, если в них просто устарели цифры. Правка трёх чисел и переноса ответа в начало раздела обычно даёт больше, чем полная переработка текста, а стоит несравнимо дешевле.

Частые вопросы

Нужен ли отдельный плагин под всё это? Как правило, нет: хватает сеошного плагина, который уже стоит, и пары вставок руками. Отдельные решения появляются, но проверять их стоит осторожно, потому что лишний плагин — это лишний источник дублей в разметке.

Влияет ли тема оформления? Влияет, и сильнее, чем кажется. Тема решает, где выводится дата, как оформлен автор, попадает ли текст в скрытые блоки, поэтому смена темы — это всегда повод перепроверить всё заново.

А если сайт старый и статей много? Тогда бери частями, по десять-двадцать страниц с наибольшими показами. Полный охват в такой ситуации почти никогда не окупается, а верхушка списка окупается почти всегда.

Ну и общий совет напоследок: не делай весь список разом, если сайт живой и большой. Один пункт в неделю с проверкой результата даёт ту же сумму работ, но без риска сломать что-нибудь в спешке и потом искать причину по всему сайту.

Знакомому, кстати, я так и отправил — списком, по пункту в неделю. Через пару месяцев он, подозреваю, будет объяснять всё это своему разработчику, а не наоборот.

Источники

• Документация Google Search Central про обзоры и структурированные данные.
• llmstxt.org и Schema.org — форматы машиночитаемой части сайта.
• Документация Yoast и Rank Math по выводу разметки.