Как мы сделали FAQPage JSON-LD для AI Control, чтобы ИИ было проще нас цитировать

Откройте любую карточку тарифов или страницу с условиями — почти наверняка внизу найдётся блок «Частые вопросы». Аккуратный аккордеон: кликаете на вопрос, он разворачивается, под ним — ответ. Дизайнер подобрал отступы и анимацию, вопрос выделен жирным, ответ — обычным текстом. С точки зрения человека всё однозначно: вот вопрос, вот ответ, тут начало, там конец.

А теперь представьте, что на ту же страницу «смотрит» не человек, а система, которая готовит ответ для ChatGPT, Perplexity или Google AI Overviews. У неё нет ощущения «вот аккордеон». Она видит разметку: может быть, это details/summary, может — div с классом faq-item и парой вложенных блоков внутри, а может — компонент, который рендерит текст ответа только после клика, и в исходном HTML его вообще нет. Чтобы понять, где кончается вопрос и начинается ответ, системе приходится угадывать — по вёрстке, по визуальной близости элементов, по паттернам, которые она уже видела на тысячах других сайтов.

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

Разница похожа на то, как по-разному читают один и тот же рецепт повар и случайный прохожий. Повар сразу видит, где перечислены ингредиенты, а где — шаги приготовления, потому что привык к формату рецептурной карточки. Прохожему придётся вчитываться и разбираться, что тут вообще к чему относится. FAQPage JSON-LD — это и есть рецептурная карточка в чистом виде: без красивой фотографии блюда, зато с явными полями «вопрос» и «ответ», которые не нужно домысливать по вёрстке.

Чинить тут нужно не аккордеон — он и так прекрасно работает для людей. Нужно добавить под той же самой видимой вёрсткой второй, параллельный слой: явные, однозначные данные о том, что именно является вопросом, а что — ответом, без необходимости что-либо угадывать. Это и есть FAQPage JSON-LD.

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

schema.org — это общий словарь разметки, который в своё время совместно предложили крупные поисковики, чтобы у сайтов появился стандартный способ описывать содержимое страницы машинно-читаемым образом — независимо от того, как это содержимое оформлено визуально. В словаре сотни типов: Product, Article, Organization — и среди них FAQPage.

JSON-LD — один из форматов, в котором эти данные можно встроить в страницу. Технически это обычный блок script с типом application/ld+json в head документа: он не показывается пользователю в браузере, но его может прочитать напрямую любой краулер или парсер — как структуру данных, а не как текст, который сначала нужно проинтерпретировать.

Применительно к FAQ это выглядит так: тип FAQPage сообщает «на этой странице есть список вопросов и ответов». Внутри — массив Question, у каждого элемента есть name (текст вопроса) и acceptedAnswer — вложенный объект типа Answer с полем text (текст ответа). Никакой неоднозначности: не «вероятно, это вопрос, потому что он жирный и стоит перед абзацем», а буквально поле с именем name, в котором лежит строка с текстом вопроса.

Важный момент, который легко упустить: этот JSON-LD не заменяет видимый аккордеон, он существует рядом с ним. Один и тот же контент на странице оказывается описан дважды — один раз в HTML и CSS для человека, который кликает и читает, второй раз в JSON для парсера, который читает напрямую, без клика и без интерпретации вёрстки. Разметка и видимый UI не конкурируют, а обслуживают разных «читателей» одной и той же страницы.

Формально тут ничего не изменилось: Google использовал FAQPage JSON-LD для расширенных сниппетов в обычной поисковой выдаче ещё до того, как ИИ-поиск стал заметной темой. Но раньше ставки были ниже — разметка просто улучшала то, как выглядит сниппет в результатах. Теперь тот же самый механизм отчасти решает, попадёт ли конкретная формулировка в текст ответа, который пользователь прочитает и, возможно, вообще не станет переходить по ссылке дальше. Цена аккуратной разметки выросла, хотя сама разметка не изменилась ни на строчку.

В AI Control есть собственная страница с ответами на частые вопросы, и у неё тоже есть JSON-LD. Единственный надёжный способ быть уверенным, что видимый текст и то, что лежит в script-блоке application/ld+json, никогда не разойдутся — не писать их отдельно. В коде есть один источник правды: массив объектов { question, answer }, из которого рендерится видимый аккордеон и из которого же генерируется схема. Вот сама функция-билдер:

export function buildFaqPageSchema({ questions }) {
    return {
        '@type': 'FAQPage',
        mainEntity: questions.map(({ question, answer }) => ({
            '@type': 'Question',
            name: question,
            acceptedAnswer: { '@type': 'Answer', text: answer },
        })),
    };
}

Функция не делает ничего «умного» — она не парсит HTML и не пытается угадать, что является вопросом. Она берёт тот же массив, который уже используется для отрисовки интерфейса, и раскладывает его в форму, которую ожидает schema.org: @type FAQPage, внутри mainEntity — массив Question, у каждого элемента name (вопрос) и вложенный acceptedAnswer (ответ). Если вопрос меняется в источнике, он автоматически меняется и в видимом UI, и в разметке, потому что оба берутся из одного и того же массива. Разойтись им физически негде. Это ровно десять строк кода, и в них нет ничего специфичного для AI Control — ту же функцию можно было бы один в один перенести на любую другую страницу с похожим FAQ.

Чтобы это не оставалось абстракцией, вот как выглядит результат для двух реальных вопросов — про то, как AI Control отслеживает видимость бренда в ответах ИИ:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Что такое AI Control?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "AI Control — модуль SEO Control, который отслеживает, как бренд и его конкуренты упоминаются в ответах ChatGPT, Perplexity, Copilot, Gemini и Google AI, используя реальные промпты, а не их симуляцию."
      }
    },
    {
      "@type": "Question",
      "name": "Что значит \"реальный запрос\" в AI Control?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Это запрос, который действительно отправляется в выбранную ИИ-систему и возвращает настоящий ответ, а не оценка на основе предположений о том, как система могла бы ответить."
      }
    }
  ]
}

Сама функция возвращает объект без @context — это поле добавляется уровнем выше, там, где блок объединяется с остальной структурированной разметкой документа, чтобы не дублировать @context на каждый отдельный фрагмент. Но суть не меняется: name и acceptedAnswer.text в примере выше — это буквально те же строки, которые пользователь видит в раскрытом аккордеоне, просто без HTML вокруг них.

На практике FAQPage редко живёт в одиночестве: на той же странице обычно есть и WebPage, и иногда Organization со своим набором полей. Поэтому билдер возвращает только фрагмент — объект с @type и mainEntity, — а не целиком готовый документ: страница сама решает, с чем его объединить и куда добавить общий @context. Это обычный паттерн для генерации структурированных данных: небольшие функции собирают фрагменты, а не монолитный JSON заново на каждую страницу.

Если смотреть на устройство такой страницы сверху вниз, получаются два параллельных слоя, которые описывают один и тот же контент, но для разных «читателей»:

Верхний слой — то, что видит и трогает человек: кликабельный аккордеон, анимация разворачивания, визуальная иерархия «вопрос сверху, ответ снизу». Нижний слой — то же самое содержимое, но уже без визуального оформления, в чистом виде данных: недоступное взгляду, но полностью доступное для чтения машиной. Между слоями нет конфликта версий, потому что оба генерируются из одного и того же массива на этапе сборки страницы. Человек кликает — открывается аккордеон. Парсер запрашивает страницу — находит script application/ld+json и читает структуру напрямую, не разбирая DOM видимой части вообще.

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

Разметка не спасёт плохо сформулированный вопрос. FAQPage JSON-LD честно передаёт системе ровно то, что в него положили, — если ответ расплывчатый или требует контекста соседних абзацев, разметка аккуратно упакует этот расплывчатый ответ и отдаст его как есть. Разница между вопросом, который реально работает для AEO, и вопросом, который работает только визуально, — в самодостаточности текста:

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

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

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

Важно быть честным: FAQPage JSON-LD не покупает место в ответе ChatGPT и не гарантирует, что Perplexity подтянет именно вашу формулировку. Это не ранжирующий фактор в духе «добавили разметку — выросли в выдаче». Всё, что она делает, — убирает один конкретный источник неопределённости: вместо того чтобы угадывать структуру по вёрстке, система получает готовую, однозначную структуру.

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

Здесь же стоит разделять понятия: то, что ИИ-система один раз привела текст с вашей страницы как ответ, — не то же самое, что ссылка, и не то же самое, что обычное упоминание бренда без атрибуции. Разница между упоминанием, цитированием и обратной ссылкой важна именно потому, что разметка FAQPage напрямую работает только с одним из этих трёх сценариев — с тем, что система дословно или почти дословно использует вашу формулировку ответа.

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

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

Если хотите повторить то же самое у себя, порядок действий простой и не требует отдельной инфраструктуры:

1. Сначала напишите реальный контент: самостоятельные вопросы и полные ответы, которые имеют смысл без остального текста страницы.
2. Используйте один и тот же массив question/answer и для видимого UI, и для генерации схемы — не ведите два независимых текста.
3. Соберите JSON-LD функцией-билдером, а не вручную построчно: меньше ручной работы — меньше шанс ошибиться в структуре.
4. Вставьте результат в тег script с типом application/ld+json внутри head страницы.
5. Проверьте результат валидатором структурированных данных перед тем, как выкатывать изменение в прод.
6. При любой правке контента меняйте только исходный массив — и UI, и разметка обновятся сами, без риска рассинхрона.
7. Периодически перечитывайте сами вопросы и ответы: практический чек-лист по AEO не ограничивается разметкой — формулировки и факты в итоге важнее синтаксиса.
8. Не добавляйте разметку на страницы без настоящего FAQ — если там попросту нечего размечать, это будет выглядеть как попытка манипулировать выдачей, а не как помощь читателю.