Розмітка сторінки, яку зчитує асистент, а не лише пошуковик
Як зробити розмітку сторінки, яку асистент читає разом із пошуковиком: структура, Schema.org, формат відповідей і перевірка.
Редакція ADS BeastОпубліковано 7 хв читання
Розмітка сторінки - це сигнали структури й фактів, які асистент зіставляє з видимим текстом. Пошуковику достатньо, щоб розмітка не суперечила сторінці й давала сніпет. Асистент витягує факти з тексту, порівнює їх зі Schema.org і цитує те, що збіглося. Розбіжність між розміткою і абзацом він або проігнорує, або передасть неправильно.
Коротко
- Асистент читає сторінку в два шари: видимий текст і машинні сигнали (заголовки, списки, таблиці, Schema.org). Факт має бути в обох.
- Заголовки h1–h3 за змістом блоку дають моделі межі смислових фрагментів, з яких вона бере відповідь.
- Schema.org описує факти, але не замінює їх: питання й відповіді в FAQPage мають дослівно збігатися з видимими на сторінці.
- Перше речення кожного блоку містить прямий висновок, бо асистент читає його окремо від контексту.
- Перевірка складається з двох кроків: Rich Results Test для структури і запит до асистента з типовим питанням користувача.
Що асистент читає на сторінці на відміну від пошуковика
Асистент читає сторінку як набір фрагментів, з яких можна взяти готову відповідь, а пошуковик - як документ, з якого треба зробити сніпет і ранжувати його. Це різні задачі, і вимоги до розмітки теж різні.
Пошуковик бере з розмітки підказки для відображення у видачі: зірки рейтингу, ціну, час приготування, питання в розгорнутому блоці. Йому важливо, щоб розмітка була валідна й відповідала видимим даним. Асистент робить інше: він шукає в тексті факти, які можна процитувати у відповіді на конкретне питання, і зіставляє їх із тим, що описано в Schema.org. Якщо в розмітці один факт, а в абзаці інший, модель схибить або проігнорує блок.
Звідси головне правило: розмітка не має суперечити тому, що бачить людина. Це не формальність. Асистент фактично перевіряє сторінку на узгодженість, і кожна розбіжність знижує шанс, що саме ваш фрагмент потрапить у відповідь.
Як структура заголовків впливає на витяг відповіді
Заголовки h1–h3 задають межі смислових блоків, з яких асистент витягує відповідь. Кожен H2 має бути законченим питанням або тезисом, а перший абзац під ним - давати відповідь у двох-трьох реченнях.
Практика проста: спершу сформулюйте питання, на яке відповідає блок, потім напишіть відповідь, і лише після цього - деталі. Абзац має бути зрозумілим без сусідніх блоків, бо модель часто витягує його окремо від решти сторінки.
Три помилки, які трапляються найчастіше:
- Заголовок-жарт або маркетингова формула замість тезису. Модель не розуміє, про що блок, і пропускає його.
- Вступ на два абзаци перед відповіддю. Корисний факт опиняється в третьому абзаці, і його вже складніше витягнути.
- Заголовки одного рівня без вкладеності. Тоді h3 не відділяють кроки чи варіанти, і структура розсипається.
Для переліків використовуйте списки, для порівнянь - таблиці. Це не прикраси: список і таблиця дають моделі готовий формат, з якого легко взяти пару «умова - значення». Розповідь про те саме звичайним абзацом змушує модель перебудовувати зв'язки самостійно, і вона частіше помиляється.
Яку роль відіграє Schema.org у відповідях асистента
Schema.org описує факти сторінки машинною мовою, і асистент використовує цей опис як додаткове джерело для зіставлення. Розмітка не замінює текст, а підтверджує його.
Найчастіше на сторінці потрібні три типи:
- FAQPage - для блоку питань і відповідей. Кожне питання й кожна відповідь мають дослівно збігатися з видимим текстом.
- Product - для сторінки товару чи послуги: назва, опис, характеристики, наявність.
- Organization - для даних про компанію: назва, контакти, профілі.
Валідність перевіряють у Rich Results Test. Валідна розмітка ще не означає узгоджену: тест покаже, що структура правильна, але не покаже, що факти в ній збігаються з абзацами. Це різні перевірки, і робити треба обидві.
Окремо про FAQ. Жорсткого ліміту питань немає, обмеження задає сама сторінка: кожне питання має відповідати реальному запиту користувача. Практичний орієнтир - 5–10 пар на сторінку, кожна відповідь на 2–4 речення. Більше додавайте, лише якщо є що сказати по суті, а не для обсягу.
Як писати відповіді, які асистент цитує
Перше речення відповіді містить прямий висновок без вступів. Далі - одне-два уточнення з конкретикою: умови, обмеження, назва дії.
Це стосується і голосових асистентів. Вони читають відповідь окремо від питання, тому займенники на кшталт «це» на початку речення ламають смисл. «Це працює лише для сторінок товару» без контексту звучить як загадка. «Розмітка Product працює для сторінок товару й послуги» - як відповідь.
Порівняйте два підходи до одного факту:
| Підхід | Як виглядає | Що з ним робить асистент |
|---|---|---|
| Вступний | «Багато хто питає, чи потрібна розмітка. Насправді все залежить від задачі...» | Пропускає початок, шукає факт далі, часто цитує обрізано |
| Прямий | «Розмітка потрібна сторінкам, які відповідають на конкретні питання: FAQ, товар, послуга.» | Бере речення цілком як готову відповідь |
Різниця не в стилі, а в тому, чи є в першому реченні факт. Якщо немає, модель шукає його в наступних і може взяти не той.
Порівняння: що дає розмітка пошуковику і що асистенту
| Вимога | Пошуковик | AI-асистент |
|---|---|---|
| Валідність Schema.org | Обов'язкова для розширеного сніпета | Потрібна, але сама по собі не дає цитування |
| Збіг розмітки з видимим текстом | Бажаний | Обов'язковий: розбіжність веде до помилки або пропуску |
| Структура заголовків | Впливає на релевантність | Визначає межі фрагментів для витягу |
| Формат відповіді | Не критичний | Перше речення має містити висновок |
| Списки й таблиці | Підказка для сніпета | Готовий формат для пари «умова - значення» |
| Перевірка | Rich Results Test | Rich Results Test плюс запит до асистента |
Таблиця показує, де вимоги збігаються, а де асистент суворіший. Найбільша різниця - у пункті про збіг: пошуковик пробачить дрібну неточність, асистент - ні, бо він будує відповідь саме на зіставленні.
Покроково: розмітка сторінки під асистента
- Розбийте сторінку на блоки за питаннями, на які вона відповідає. Кожен блок отримує H2-тезис і перший абзац із прямим висновком.
- Перетворіть переліки на марковані списки, а порівняння - на таблиці. Розповідь про варіанти замініть структурою.
- Визначте, які типи Schema.org описують факти сторінки: FAQPage для питань, Product для товару чи послуги, Organization для компанії.
- Впишіть у розмітку ті самі формулювання, що й у видимому тексті. Особливо це стосується питань і відповідей у FAQPage.
- Перевірте валідність у Rich Results Test і виправте помилки структури.
- Задайте асистенту типове питання користувача і подивіться, що він цитує. Якщо цитата містить факт, якого немає в тексті, або блок пропущено - шукайте розбіжність між розміткою й видимим контентом.
- Повторюйте перевірку після кожної суттєвої правки шаблону сторінки.
Крок 6 варто робити не один раз, а на кількох формулюваннях: асистент може відповідати по-різному залежно від того, як поставлене питання. Це нормально і саме тому перевірка не зводиться до одного запиту.
Як перевірити, що асистент бачить розмітку так само, як пошуковик
Порівняйте два джерела: звіт Rich Results Test для структури й запит до асистента з типовим питанням користувача. Якщо асистент цитує факт, якого немає в тексті, або пропускає блок - проблема в розбіжності між розміткою й видимим контентом.
Ця перевірка показує те, чого не бачить жоден валідатор: чи збігаються факти. Rich Results Test відповідає на питання «чи правильно побудована розмітка», а запит до асистента - на питання «чи бере він звідси відповідь». Друге важливіше для трафіку з відповідей, і саме його зазвичай не перевіряють.
Що робити з результатом:
- Асистент цитує не той факт - перевірте, чи немає двох версій цього факту на сторінці (у тексті й у розмітці).
- Асистент пропускає блок - перевірте, чи є в першому абзаці прямий висновок і чи не захований він під вступом.
- Асистент плутає блоки між собою - перевірте, чи не збігаються заголовки за змістом і чи є h3 там, де блок ділиться на кроки.
Тримати всю цю картину в голові на багатьох сторінках складно, і саме тут допомагає моніторинг згадок бренду в ШІ-відповідях: видно, як асистенти цитують сторінки і що змінюється після правок.
Де розмітка сторінки дає збій
Найчастіша причина збою - розмітка й текст розходяться. Друга за частотою - розмітка є, але факти в ній описані загально, без конкретики, яку можна процитувати.
Ось як це виглядає на практиці. У FAQPage стоїть відповідь «Так, це можливо». У видимому тексті - «Це можливо для сторінок товару, для блогів - ні». Асистент отримує два різні факти й не може вибрати, який правильний. Найімовірніше, він пропустить блок.
Друга помилка - шаблонні заголовки. «Переваги», «Особливості», «Висновки» не несуть тезису, і модель не розуміє, про що блок. Замініть їх на конкретні: «Що дає FAQPage у відповідях асистента», «Як перевірити збіг розмітки й тексту».
Третя - надмірна розмітка. Коли на сторінці описано все підряд, асистент отримує багато сигналів і мало фактів. Краще менше типів, але з точними даними.
Від чого залежить результат: від того, наскільки сторінка відповідає на реальні питання, наскільки послідовно викладені факти й наскільки регулярно ви перевіряєте, що асистент бачить. Гарантувати цитування не можна - це залежить і від конкуренції у відповіді, і від того, як модель обирає джерела. Але усунути розбіжності між розміткою й текстом - цілком у ваших руках, і це найбільша частина роботи.
Що зробити далі
Візьміть одну сторінку, яка відповідає на питання користувачів, і пройдіть її за списком вище: заголовки, списки й таблиці, Schema.org, збіг формулювань. Потім задайте асистенту те питання, на яке сторінка має відповідати, і порівняйте цитату з текстом. Якщо розбіжностей кілька, почніть із FAQPage - там вони найпомітніші. Про те, як зробити перший абзац цитованим, читайте в матеріалі про цитованість тексту, а ширший контекст роботи з відповідями двигунів - у статті про генеративну оптимізацію.