Перейти до основного вмісту
megapromotingПоговорімо

Експертиза · AEO

Перетворюємо сторінку на дані, які машина читає без здогадів, і перевіряємо результат за допомогою інструмента двигуна.

Структуровані дані, запитання й відповіді у читабельній формі, breadcrumb, вузол організації. З-поміж цих трьох тем саме тут результат можна перевірити, а не лише припустити.

Вже збудованоТри власні реалізації, усі відкриті на диску й перевіряються ззовні сьогодні. Перша: сторінки продукту цього сайту віддають граф розміром 1.479 байт з `WebPage`, `SoftwareApplication` і `BreadcrumbList`, пов’язаними між собою, згенерований з тих самих даних, що й видимий текст — 23 сторінки. Друга: власний модуль аналізу для прямих відповідей, 51 рядок, вісім перевірок з пунктами, явно записаними в коді, з вагою 0,10 в загальному балі аналізатора. Третя: публічний генератор структурованих даних на нашому сайті, п’ять типів, який відповідає 200. Резерв, який ми говоримо в тому самому реченні: той самий модуль аналізу дає 30 зі 100 власній нашій сторінці продукту, бо не вміє читати граф — обмеження інструмента, воно написане нижче, і його треба виправити.

Двигун, який показує пряму відповідь, не компонує текст: він витягує шматок зі сторінки й ставить його під запитання. Щоб витягти без здогадів, йому потрібна однозначна відповідність між запитанням і відповіддю, між продуктом і його станом, між сторінкою та організацією, яка її публікує. Структуровані дані — саме це, не прикраса для SEO, а сторінка, написана вдруге, для читача, який не розуміє вигляд, лише структуру.

Різниця від двох інших тем у тому, що тут результат перевіряється. Не припускають і не сподіваються: берете адресу, даєте її інструменту перевірки двигуна і дивитесь, чи читається блок, які типи він розпізнає і яких полів йому бракує. Саме тому ця сторінка може цитувати більше, ніж сторінка про згенеровані відповіді — і саме тому вона написана як зроблена робота, а не як пропозиція.

Як виглядає ситуація на цьому сайті, пораховано сьогодні, не оцінено: 147 адрес у карті сайту. Двадцять три сторінки продуктів несуть правильний граф у 1.479 байтів. Усі інші несуть рівно один блок, у 265 байтів, із шістьма полями: контекст, тип, ідентифікатор, назва, адреса, опис. Без логотипа, без поштової адреси, без контактної точки і без посилань на публічні профілі — хоча в конфігурації сайту записано шість. Сторінка поширених запитань має десять запитань в HTML, жодного машинночитабельного блоку запитань і не входить до карти сайту.

Частина, яка змінює розмову, — це інвентар уже написаного тексту. У джерелах контенту цього сайту є 233 пари запитання-відповідь на сторінках послуг, 175 на сторінках продуктів і десять на сторінці поширених запитань — 418 загалом, написані, переглянуті, з реальними відповідями. Нуль із них сьогодні у формі, яку читає машина. Зазвичай це і є робота: не створення нового контенту, а переклад наявного. Сайт, у якого не написані запитання, має іншу проблему, більшу, і ми кажемо це наперед.

Що входить

Робота, за складовими

Інвентаризуємо, що машина читає сьогодні з кожної адреси

Запитуємо кожну адресу, витягуємо кожен блок структурованих даних, парсимо його і записуємо типи та розмір. Результат — таблиця, а не враження. На цьому сайті: сторінка продукту повертає два блоки, у 265 і 1.479 байтів, із чотирма типами між ними; головна сторінка, каталог, блог, контакт, поширені запитання і сторінки послуг повертають по одному, у 265 байтів, з одним типом. Тут видно і те, що зламано тихо: блок, який не парситься, не дає жодної видимої помилки, він просто не існує для двигуна.

Перекладаємо вже написані запитання, не вигадуємо нові

418 пар запитання-відповідь уже існує в джерелах контенту цього сайту, і жодна не в машинночитабельній формі. Блок запитань генерується з тієї самої джерельної інформації, що й видимий текст, а не пишеться вдруге вручну. Правило суворе, і ось чому: якщо в даних з’являються запитання або відповіді, яких немає на сторінці, двигун трактує це як невідповідність, а результатом є втрата спеціального показу, а не плюс.

Один граф на сторінку, з вузлами, які знають одне одного

Замість окремих блоків, що повторюють ті самі дані, — граф, у якому сторінка, головна сутність і навігаційний ланцюжок посилаються одне на одне через ідентифікатор, а організація є одним вузлом для всього сайту. Так виглядають наші сторінки продуктів: сторінка посилається на організацію як на видавця, головна сутність посилається на ту саму організацію як на автора, навігаційний ланцюжок має три реальні сходинки. Деталь, якої не видно: під час запису знак `<` замінюється на його екранувальну послідовність, щоб текст із даних не міг закрити блок і потрапити в сторінку як код. Це один рядок, він у файлі.

Перевіряємо інструментом двигуна, а не нашою думкою

Кожен тип сторінки проходить через інструмент перевірки двигуна, який каже, що він прочитав і якого поля йому бракує. Це єдине місце з трьох тем, де є зовнішній, негайний і відтворюваний вердикт. Те, що ми передаємо, — це знімок вердикту для кожного типу сторінки, а не твердження, що «ми впровадили схему».

Власний модуль аналізу, з пунктами, записаними в коді

Наш модуль для прямих відповідей виконує вісім перевірок із явним нарахуванням балів: наявність будь-якого читабельного блоку 20 балів, поширені запитання 20, покрокові інструкції 10, позначені для голосового читання секції 10, хлібні крихти 10, оцінки 10, організація 10, стаття або продукт 10, із верхньою межею 100. Має вагу 0,10 в загальному балі аналізатора. Бали не сховані в алгоритмі; це вісім рядків, які ви можете прочитати.

Обмеження власного інструменту, сказане перед тим, як ви його знайдете самі

Цей самий модуль читає тип лише на верхньому рівні блоку або в масиві. Граф не має типу на верхньому рівні, тож типи всередині нього не бачаться. Наслідок, виміряний на нашому власному сайті: сторінка продукту отримує 30 із 100 від нашого аналізатора, хоча містить три коректні типи, з яких два зараховуються модулем. Число неправильне, сторінка — ні. Ми написали це тут, бо інструмент, чий дефект ви дізнаєтеся від постачальника, корисніший за той, про який ви дізнаєтеся самі, під час другого запуску.

Вузол організації, один раз для всього сайту

Юридична назва, адреса, контактна точка, логотип і посилання на публічні профілі — в одному вузлі, на який вказують усі сторінки. Це річ, що пов’язує сайт з рештою ваших публічних слідів. На цьому сайті вузол має шість полів і жодного з цих посилань, хоча в конфігурації записано шість профілів. Це нестача, її пораховано, і вона перша в списку на виправлення, бо вирішується в одному місці.

Картка поширення, згенерована з заголовка сторінки

Зображення, яке з’являється, коли хтось ділиться адресою, генерується із заголовка та опису сторінки, у кольорах сайту, щоб попередній перегляд відповідав сторінці, на яку веде. Наші сторінки продуктів мають свій маршрут і повертають справжнє зображення. Нестача, записана як нестача: сторінки послуг у метаданих заявляють адресу зображення, для якої в коді не існує маршруту — якщо запитати напряму, повертає 404. У продакшені наразі віддається загальне зображення, тож дефект з’являється лише після публікації, на 25 сторінках. Його позначено, не приховано.

Що ми ніколи не вносимо в структуровані дані

Примітки та відгуки, які ви не можете підтвердити публічним джерелом. Ціни, які не написані на сторінці. Строки доставки як гарантія. Причина не в обережності: задекларована в даних оцінка без публічного джерела — це саме те, на що націлюється ручне санкціонування, а хибне твердження в машинно-читабельному форматі — це брехня, зроблена для поширення, — та, яку потім цитують. Ми знайшли таке у власному сховищі й нижче пишемо, що це було і що ми зробили.

Як це виглядає

Шлях, крок за кроком.

01

Сьогоднішній інвентар, адреса за адресою

Перша поставка — це таблиця: кожна адреса, кожен блок, розпізнані типи, розмір у байтах і блоки, які не парсяться. Відтепер кожне твердження має рядок за собою. Це також момент, коли з’являються блоки, що залишилися від попередньої версії сайту і суперечать сьогоднішній сторінці.

02

Вузол організації та хлібні крихти

Вони робляться один раз і застосовуються всюди: один вузол для організації, з ідентифікатором, на який вказують усі сторінки, і хлібні крихти, що відповідають реальній структурі адрес. Порядок не підлягає обговоренню — інакше ви виправляєте сто сторінок заради того, що вирішується в одному файлі.

03

Існуючі запитання, подані у формі

Блок запитань генерується з того самого джерела, що й видимий список на сторінці. Ми також постачаємо список адрес, де запитання є в тексті, але не були задекларовані — на цьому сайті вийшло 418 записаних пар і жодної задекларованої.

04

Зовнішня перевірка, для кожного типу сторінки

Ми пропускаємо через інструмент рушія по одній сторінці кожного типу й надаємо вердикт: які типи було прочитано, яких полів бракує, які попередження з’явилися. Ми нічого не оголошуємо завершеним лише на підставі того, що блок «є в коді».

05

Перевірка, яка залишається після нас

Скрипт, який запускається після кожної публікації та падає, якщо блок перестав парситися, якщо тип зник із шаблону сторінки або якщо блок запитань від’єднався від видимого тексту. Без нього робота еродує точно так само, як і будь-яка неписана домовленість: хтось додає новий шаблон і забуває, а ніхто не помічає, бо на екрані нічого не виглядає зламаним.

1Інвентар2traducere3validareщо машина читає сьогодні з кожної адреси, що ми декларуємо з уже наявного текстуscris, ce spune unealta motorului despre rezultat.
Шлях, у 3 кроки

Дані

Чого торкаємося, де воно лежить і скільки лишається

Запитання, які ставить кожен, у кого є відповідальний за захист даних, — поставлені тут раніше, ніж їх поставить він.

Що ми читаємо з вашого сайту
Лише публічний HTML і блоки даних, які вже там є. Для інвентаризації нам не потрібен доступ до адміністрування. Для валідації нам не потрібно нічого додаткового: інструмент двигуна працює на публічній адресі.
Що нам потрібно від вас і чого ми не можемо вигадати
Факти про вузол організації: точна юридична назва, адреса, графік роботи, контактний номер і реальні публічні профілі. Структуровані дані, що суперечать реальності, гірші за їхню відсутність — це перевірюване і хибне твердження, опубліковане вами у форматі, створеному для автоматичного читання.
Що ніколи не входить у дані
Персональні дані працівників або клієнтів. Оцінки без публічного джерела. Ціни, яких немає на сторінці. Запитання і відповіді, яких відвідувач не бачить. Практичне правило: якщо людина, яка відкриває сторінку, не може знайти там інформацію, їй не місце в блоці.
Звідки генеруються блоки
З того самого джерела даних, що й видимий текст, а не з паралельного файлу. Це єдиний спосіб, щоб вони не розійшлися: хтось змінює відповідь на сторінці, блок змінюється разом із нею. Блок, написаний вручну, відстає за кілька місяців, і ніхто не помічає, бо цього не видно.
Де зберігаються результати і як довго
Таблиця інвентаризації, висновки інструмента валідації та перевірка після публікації зберігаються у версіонованому вигляді в репозиторії проєкту, поруч із кодом. Вони живуть стільки, скільки живе репозиторій. Вони не містять нічого, чого вже немає на сайті: інвентар структурованих даних — це зчитування публічних сторінок, а не витягування з ваших систем.

Випадок

418 запитань написані, жодне не в тій формі, яку читає машина

Ситуація

Наш власний сайт, 147 адрес у мапі сайту, з нещодавно переписаним текстом, запитання за запитанням. Усі сторінки відповідали 200 і виглядали коректно. Питання для старту було не «що ще додати», а «з того, що є на сторінці, що доходить до машини».

Що ми збудували

Ми запросили репрезентативні сторінки для кожного типу, витягнули й розпарсили кожен блок структурованих даних, порахували типи та байти. Ми відтворили поверх живого HTML логіку власного модуля аналізу, щоб побачити, який бал сайт виставляє сам собі. Ми прочитали компоненти структурованих даних у репозиторії, включно з тими, що ніде не використовуються. І ми порахували наявні пари запитання-відповідь у вихідних матеріалах контенту.

Що вийшло

Двадцять три сторінки продукту мають коректний граф на 1.479 байтів із трьома взаємопов’язаними типами. Усі інші мають один блок на 265 байтів із шістьма полями і жодним елементом ідентичності — без логотипа, без адреси, без контактної точки, без посилань на шість профілів, прописаних у конфігурації. Сторінка поширених запитань має десять запитань в HTML, жодного оголошеного блоку і відсутня в мапі сайту. У джерелах є 418 написаних пар запитання-відповідь: 233 на послугу, 175 на продукт, десять на сторінку запитань. Оголошених — нуль. Наш власний модуль дає сторінці продукту 30 зі 100, бо не читає типи з графа. А в репозиторії ми знайшли три невикористані компоненти, які декларували агреговану оцінку з підписаними відгуками, каталог цін і покроковий посібник із термінами — перевірено на продакшені, що жоден із них не віддається.

Чого цей випадок не каже

Нічого з наведеного вище не було виправлено в день, коли це було написано. Інвентар і висновки — це результат цього етапу; виправлення — це наступний етап, і в нього свій порядок: спочатку те, що вирішується в одному файлі, потім те, що потребує роботи в кожному шаблоні. І ще раз, бо це важливо: валідний блок не купує особливе відображення. Він робить його можливим. Решту вирішує документація двигуна, а вона змінюється.

Питання

Про що нас питають, перш ніж зателефонувати

Чи гарантують структуровані дані мені збагачений фрагмент у результатах?

Ні. Спеціальне відображення надає двигун, а не позначка. Валідні дані є умовою входу, а не купівлею результату. Це добре видно навіть на типі позначки, який продають усюди: документація Google пише, що збагачений результат для поширених запитань показується лише для відомих і авторитетних урядових і медичних сайтів — обмеження, що набуло чинності у вересні 2023 року. Отже, постачальник, який сьогодні продає вам «збагачені фрагменти з FAQ», або не читав документацію, або сподівається, що її не читали ви.

Тоді навіщо взагалі оголошувати запитання, якщо вони не з’являються як фрагмент?

Тому що спеціальне відображення — лише один із споживачів формату. Правильно оголошений блок запитань однозначно вказує, який текст є запитанням, а який — відповіддю, — інформація, яку використовують двигуни для витягування фрагментів, асистенти, що читають сторінку на запит користувача, і будь-яка система, яка бере контент, не бачачи вигляду. Є ще й ефект, про який менше говорять: обов’язок оголошувати пари змушує вас мати реальні відповіді на реальні запитання. Сайти, які не можуть заповнити формат, зазвичай не мають що оголошувати.

Що це робить щодо SEO та видимості в згенерованих відповідях?

Із формою, а не з інвентарем і не з компоновкою. SEO відповідає на «чи може двигун дістатися до кожної сторінки і чи знає він, яка є офіційною версією». Видимість у згенерованих відповідях відповідає на «чи можу я бути використаний як джерело», де результат не можна пообіцяти. Тут відповідають на «чи може машина взяти точну інформацію зі сторінки, не вгадуючи», і це єдиний із трьох випадків із зовнішнім вердиктом: ви даєте адресу інструменту перевірки й одразу отримуєте відповідь.

Чи можу я вказати в даних запитання або інформацію, яких немає на сторінці?

Ні, і це помилка, яку ми часто знаходимо. Позначка, що описує щось інше, ніж видимий контент, вважається невідповідністю, а наслідок — втрата відображення, іноді ручна санкція. Правило, яке ми застосовуємо, механічне, а не «здорового глузду»: блок генерується з того самого джерела, що й текст на сторінці, тож не може містити того, чого не видно. Коли хтось просить додати в дані відповідь, яку не хоче писати на сторінці, розмова на цьому зупиняється.

У конкурентів є зірки в результатах. Чому у нас ні?

Тому що ми не можемо довести оцінку. Агрегована оцінка, оголошена в даних, має відповідати реальним, публічно перевірюваним відгукам. Без цього це хибне твердження у форматі, що читається автоматично. Тут ми категоричні з конкретної причини: у власному репозиторії ми знайшли компонент, який оголошував оцінку 4,9 з 87 відгуків і шість відгуків, підписаних іменами людей, а також другий, який оголошував каталог із чотирьох пропозицій із цінами. Жоден не рендериться ніде — у продакшені сьогодні використовується один блок, перевірений, — але вони існували за один імпорт до. Ми позначили це в журналі рішень команди, не видалили мовчки.

Які типи ви фактично використовуєте?

Ті, що ми запускаємо: сторінка, основна сутність сторінки, навігаційний ланцюжок, організація та блок запитань. Наш публічний генератор охоплює п’ять типів — місцевий бізнес, організація, стаття, продукт, поширені запитання — і доступний на сайті. Будь-який інший тип обговорюється на запит, після перевірки сумісності з тим, що двигун фактично показує для вашого домену. Чого ми не робимо: не додаємо типи лише тому, що вони є у специфікації. Блок, який жоден двигун не використовує для вашого сайту, — це тягар, а не перевага.

Як ви перевіряєте, що це працює?

У трьох місцях, бо одне бреше. Інструмент перевірки двигуна дає зовнішній вердикт. Наш модуль аналізу дає оцінку з восьми перевірок і балами, записаними в коді, щоб ви могли порівнювати між запусками. А скрипт, запущений після кожної публікації, падає, якщо блок перестав парситися або тип зник. Ми додаємо і межу нашого модуля, щоб ви не відкрили її самі: він ще не читає типи з графа, тож дає нижчий бал, ніж реальність правильно побудованих сторінок — зокрема й наших.

Що псується з часом?

Зв’язок між блоком і сторінкою. Хтось змінює відповідь у тексті, блок лишається зі старою, і на екрані нічого не виглядає зламаним — тому це місяцями лишається непоміченим. Друге, що псується, — це блоки, що лишилися від попередньої версії сайту й описують пропозицію, якої вже немає. Обидва мають одне й те саме виправлення: блоки генеруються з джерела тексту, а те, що не генерується, видаляється.

Що ви фактично передаєте?

Таблицю інвентарю з кожною адресою, кожним блоком, типами та байтами. Реалізовані блоки, згенеровані з джерела контенту. Вердикт інструмента перевірки для кожного типу сторінки. Скрипт перевірки, запущений після публікації. І список решти прогалин, записаних як прогалини — на цьому сайті, наприклад, вузол організації без посилань на профілі, сторінка запитань, відсутня в карті сайту, і шлях до зображення для поширення, заявлений у метаданих, якого немає в коді.

На чому ґрунтуються твердження вище (13 джерел)
  1. Документація Google пише, що збагачений результат для часто задаваних питань показується лише для відомих і авторитетних державних і медичних сайтів, обмеження оголошене у вересні 2023 рокуhttps://developers.google.com/search/docs/appearance/structured-data/faqpage · 2026-09-06
  2. Карта сайту має 147 адресhttps://www.megapromoting.com/sitemap.xml · 2026-09-06

11 з них — це код і файли з наших репозиторіїв. Ми не публікуємо їхні назви чи номери рядків: разом, на одній сторінці, це надто точно описало б, як побудовані системи, які належать не лише нам. Ми проходимо їх разом із вами, у репозиторії, за запитом — перевірка залишається можливою, просто вона відбувається в розмові.

Що вам хотілося б налагодити?

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

Поговорімо