Недавно на сайте одного из клиентов мы с командой по всем правилам поставили speakable — разметку, которая подсказывает голосовому ассистенту, какие куски страницы читать вслух: короткий ответ в начале, три ответа из FAQ, всё в валидном коде, а селекторы точно на нужных блоках. Алиса зачитывала ответ ноль раз. Причина оказалась глубже разметки: страница висела на 14-м месте обычной выдачи Яндекса. Ниже разбираю, как размечать под голос правильно, на что это реально влияет и на каких граблях я терял время.
Как Алиса собирает ответ: сначала обычный поиск Яндекса, потом озвучка
Алиса строит голосовой и текстовый ответ по цепочке ИИ → поиск → ИИ. Единого языкового движка с собственным индексом под капотом нет: модель выбирает тип ответа и формулирует план, задаёт запросы в обычный поиск Яндекса, поиск выдаёт результаты в привычном порядке, и только после этого модель отбирает источники и собирает из них ответ (Ашманов и партнёры, «Поиск с Алисой»).
Отсюда цифры, которые я теперь проверяю первым делом, когда слышу «нас не читает Алиса»: топ-20 обычной выдачи почти обязателен, топ-10 желателен, топ-5 заметно лучше. После пятой позиции шансы резко падают, а к концу второй десятки стремятся к нулю. Общие характеристики сайта — возраст домена, показатели качества, размер — в отборе не участвуют: модель смотрит только на текст конкретной найденной страницы. Порядок источников внутри готового ответа с позицией в обычной выдаче почти не связан, поэтому попасть в ответ важнее, чем занять в нём первую строчку.
Разметка на этом этапе бессмысленна в отрыве от позиции. Пока страница не в топ-20 по целевому запросу, Алиса её не видит физически: она не входит в пул кандидатов, из которого модель вообще выбирает источники.
Что такое speakable-разметка и что она реально даёт
speakable — это свойство из словаря разметки schema.org (тем же словарём размечают товары, статьи, рейтинги). Оно указывает голосовому ассистенту, какие блоки страницы — по их CSS-селекторам — пригодны для зачитывания вслух (schema.org/SpeakableSpecification). Позиции в поиске это не даёт. Роль разметки скромнее: подсказать модели, какой фрагмент текста готов к произнесению без дополнительной обработки.
У Google speakable официально поддержана в статусе беты и ограничена новостями и небольшим набором языков (Google Search Central) — для обычного коммерческого сайта это не рабочий канал. У Яндекса ситуация жёстче: в открытой документации по разметке speakable не упомянут вообще (yandex.ru/support/webmaster) — раздел про schema.org там есть, а про speakable ни слова. Решающий фактор для голосового ответа — позиция в топ-20 плюс структура «вопрос — прямой ответ» в самом тексте; тег в JSON-LD тут вторичен.
Я всё равно ставлю разметку на денежных страницах клиентов. Она недорога технически, ничему не вредит и в теории облегчает работу той модели, которая когда-нибудь начнёт её честно учитывать. Продавать это как рычаг видимости нельзя, я так и говорю клиенту: дешёвая гигиена техфундамента, отдельной услуги из неё не сделать.
Как разметить страницу под голос
Разметка ставится на 1–2 блока страницы, не на весь текст целиком. Кандидаты: прямой ответ в первых 40–60 словах (короткий вводный абзац вверху статьи) и 2–3 самых частых ответа из FAQ. Я вешаю на эти блоки CSS-класс заранее: .tldr для лида, .faq-answer--top для отобранных ответов, и указываю их в cssSelector:
{ "@context": "https://schema.org", "@type": "WebPage", "url": "https://example.ru/blog/kak-vybrat-crm", "speakable": { "@type": "SpeakableSpecification", "cssSelector": [ ".tldr", ".faq-answer--top" ] } }
Этот блок кладётся в <head> страницы отдельным <script type="application/ld+json">, рядом с уже существующей разметкой Article или FAQPage — они не конфликтуют, просто описывают разные аспекты одной страницы. Валидирую через Schema Markup Validator: он проверит синтаксис разметки, но не то, реально ли селектор находит нужный блок на живой странице. Это отдельная ручная проверка через инструменты разработчика в браузере (DevTools).
Три проблемы, на которых я потерял время:
Речь ставил на весь
<article>. Лимит на секцию: 20–30 секунд озвучки, примерно 40–60 слов. Целый лонгрид под этим селектором ассистент либо обрежет случайным образом, либо проигнорирует блок целиком.Селектор указывал на класс, которого не было в финальной вёрстке. CMS переименовала обёртку при выкладке, разметка прошла валидатор (он не знает про реальную структуру страницы), а на живом сайте селектор указывал в пустоту.
Ждал результата раньше, чем страница попала в топ-20. Разметка стояла корректно неделями, а изменений не было, потому что причина крылась в позиции по запросу.
Голосовой запрос ≠ текстовый
Пользователь набирает в поиске «speakable разметка яндекс», а колонке произносит «алиса как сделать чтобы сайт читали голосом». Голосовой запрос длиннее текстового в среднем в полтора-два раза, формулируется как целый разговорный вопрос и почти всегда оказывается редкой, нестандартной формулировкой — мимо самых частых запросов, по которым все оптимизируются. Ассистент строит ответ из первых 40–60 слов релевантного блока, и если этот фрагмент раскрывает общую тему вместо ответа на конкретный вопрос, зачитывать нечего.
Формат, который у меня стабильно работает и на голос, и на текстовые ИИ-ответы: вопрос в подзаголовке, прямой ответ в первом предложении под ним, дальше контекст и пример. Заголовок пишу так, как вопрос реально произнесли бы вслух: «алиса зачем нужна разметка спикабл» ближе к живой речи, чем сухое «что такое speakable». FAQPage, HowTo и Article облегчают модели извлечение такого фрагмента, потому что явно маркируют границы вопроса и ответа в структуре документа.
Поэтому важно собирать не только ключевые слова, но и разговорные формулировки той же темы — вопросительные, с местоимениями, с бытовой лексикой. Модель Алисы переформулирует запрос пользователя перед поиском, и чем ближе формулировка страницы к живому разговорному вопросу, тем выше шанс попасть в пул кандидатов на этом этапе.
Чем мерить результат и почему speakable — сигнал, а не гарантия
Замеряю Алису двумя инструментами. Первый — Search API генеративного ответа Яндекса (официальный интерфейс, через который можно программно получить озвучиваемый ответ и его источники): прогоняю целевые формулировки и смотрю, попал ли домен клиента в источники ответа и кого цитируют рядом. Второй — сегмент AI Traffic в Яндекс.Метрике: отдельно вижу переходы, которые пришли из ответов ассистента, и на какие страницы они ведут. Это прямые замеры, а не косвенная оценка через общую выдачу.
Третий канал — ручной. Гоняю целевые голосовые формулировки через Алису AI и, если у клиента есть колонка, через неё. Фиксирую, читается ли страница вообще и какие источники цитируются вместо неё — часто выясняется, что источник озвучки это справочный ресурс с более чёткой структурой вопрос-ответ, а сам клиент и его конкуренты остаются за кадром.
speakable — экспериментальная разметка без официального подтверждения от Яндекса и в статусе беты у Google. Гарантий цитирования в Алисе она не даёт. На попадание в голосовой ответ влияет комплекс факторов — позиция в топ-20, структура текста, прямые ответы в начале блоков, — и разметка здесь один из младших сигналов в этом комплексе.