Автор: Олександр Коваленко

Перевірка мікророзмітки: валідатор Schema.org онлайн як інструмент для розробника та SEO-спеціаліста

Одна зайва кома в блоці JSON-LD може непомітно вимкнути всю структуровану розмітку сторінки, і пошуковик просто пропустить її без жодного попередження в інтерфейсі сайту. Саме тому перевірка мікророзмітки стала обов'язковим етапом роботи з будь-якою сторінкою, яка претендує на розширений результат у пошуковій видачі. У PromoPilot™ цей етап винесено в окремий безкоштовний валідатор, який читає JSON-LD, Microdata та RDFa, перевіряє синтаксис, словник schema.org і вимоги Google до полів, а також показує рядок і стовпець помилки. Далі йдеться про те, як працює така перевірка, на що звертати увагу і де її межі.

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

Розуміння цього розподілу ролей важливе для вибору інструменту. Валідатор відповідає на питання «чи правильно написана розмітка», але не відповідає на питання «чи отримає сторінка розширений результат». Для останнього потрібен офіційний тест Google. Ми свідомо розділяємо ці завдання: спочатку виправити синтаксис і структуру, потім звірити з вимогами, і лише після цього перевіряти фінальний результат інструментом пошуковика.

Формати розмітки: JSON-LD, Microdata, RDFa

Розмітка може бути записана в трьох основних форматах, і кожен з них має свою логіку розташування в HTML. JSON-LD зберігається окремим блоком script з типом application/ld+json і не змішується з видимою розміткою сторінки. Microdata вбудовує атрибути itemscope, itemtype та itemprop безпосередньо в теги елементів. RDFa використовує схожий принцип, але з атрибутами typeof, property і vocab. Саме через таку вбудованість Microdata і RDFa частіше ламаються при редагуванні шаблонів, адже зміна верстки може випадково зачепити атрибути розмітки.

Google рекомендує JSON-LD саме через відокремленість від верстки. Блок можна додати, оновити або видалити, не торкаючись дизайну сторінки, а сам код легше читати, перевіряти й генерувати програмно. Проте в legacy-сайтах, які роками працювали на CMS із вбудованою розміткою, Microdata і RDFa досі трапляються в значній кількості. Переписувати їх вручну не завжди доцільно, але важливо розуміти, що пошуковик розпізнає всі три формати, і змішане використання на одній сторінці допустиме, якщо воно не створює дублів.

Визначити формат на конкретній сторінці найпростіше, переглянувши джерело HTML і знайшовши відповідні ознаки: блок script з JSON-LD, атрибути itemprop або property. Коли на сторінці присутні одночасно кілька форматів, валідатор збирає всі знайдені об'єкти, щоб було видно, які з них описують одну й ту саму сутність. Це особливо корисно, коли тема оформлення додає власну Microdata-розмітку, а SEO-плагін — JSON-LD для того самого товару чи статті.

• JSON-LD — рекомендований формат, відокремлений від верстки, зручний для генерації та перевірки.
• Microdata — вбудований в атрибути HTML, часто зустрічається в старих шаблонах і при ручному оформленні.
• RDFa — близький до Microdata за логікою, використовується переважно в академічних та державних ресурсах.
• Змішане використання — допустиме, але вимагає перевірки на дублікати однакових сутностей.

Критерії вибору валідатора

Перший критерій — підтримка всіх трьох форматів і можливість перевірки з різних джерел. Інструмент, який працює лише з JSON-LD, не покаже проблем у Microdata на старих сторінках. Зручно, коли можна ввести URL сторінки, вставити HTML-код або окремий фрагмент JSON. Перевірка за URL потрібна для аудиту вже опублікованого сайту, а вставка коду — для перевірки до публікації, коли розмітка ще лишається в чернетці.

Другий критерій — глибина перевірки. Синтаксис JSON — лише перший рівень. Значно важливіше, чи відповідає тип і властивості актуальній версії словника schema.org. Помилка в назві властивості, наприклад datepublished замість datePublished, не порушує синтаксис, але робить властивість невідомою для пошуковика. Так само важливо, чи інструмент попереджає про властивості, які не належать обраному типу, або про застарілі терміни. Саме на цьому рівні найчастіше виникають приховані проблеми.

Третій критерій — звірка з вимогами Google для розширених результатів. Тут важливо розрізняти критичні помилки та попередження. Відсутність обов'язкового поля означає, що об'єкт не отримає розширеного результату. Відсутність рекомендованого поля — це шанс на кращий результат, але не блокування. Хороший валідатор розділяє ці рівні, щоб розробник розумів, що виправляти першочергово.

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

Онлайн-валідатори проти автоматизованих рішень

Для однієї-двох сторінок ручна перевірка через веб-інтерфейс цілком достатня. Вставив код або URL, побачив список помилок, виправив, перевірив знову. Цей підхід займає кілька хвилин і не потребує жодних налаштувань. Він добре підходить для шаблонів, які змінюються рідко, і для швидкої діагностики, коли потрібно зрозуміти причину конкретної проблеми.

Коли сторінок сотні або тисячі, ручний підхід перестає працювати. Тоді доцільно використовувати скрипт або API, який обходить список URL, збирає розмітку і формує звіт. Той самий принцип можна вбудувати в процес збірки сайту або в CI-конвеєр, щоб зміна шаблону автоматично перевірялася до публікації. Так помилка не потрапляє на продакшн, а розробник отримує сигнал одразу після коміту.

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

Синтаксичні помилки JSON-LD і їх діагностика

Синтаксичні помилки найпідступніші тим, що розмітка візуально виглядає правильною. Людське око легко пропускає зайву кому після останнього елемента масиву, незакриту фігурну дужку в глибоко вкладеному об'єкті або прямі та «типографські» лапки, які схожі в редакторі, але для парсера є різними символами. Один такий знак робить недійсним увесь блок, і пошуковик не намагається «домислити» пропущене.

Окремий клас проблем пов'язаний з екрануванням. Якщо в тексті опису товару є лапки, зворотні слеші або перенесення рядка, їх потрібно правильно екранувати в JSON. Часто це трапляється, коли опис копіюється з редактора або бази даних, де такі символи не були підготовлені для JSON. Ще одна типова ситуація — невидимі символи, наприклад нульової ширини, які потрапили з буфера обміну і ламають значення в полі назви чи опису. Їх неможливо побачити у звичайному перегляді, тому валідатор із детальним звітом стає надійнішим помічником.

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

Діагностика за номером рядка працює добре, поки JSON записаний з відступами. Але мінімізований JSON в один рядок робить номер рядка майже марним: помилка вказує на першу позицію, а не на справжнє місце. У такому разі корисно спочатку відформатувати код і лише потім перевіряти. Багато розробників роблять це ще до вставки в шаблон сайту, і це правильна звичка, яка економить час.

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

Важливо розрізняти помилку парсингу і помилку семантичної валідації. Перша означає, що JSON взагалі не читається як структура даних. Друга означає, що структура коректна, але вміст не відповідає схемі: невідома властивість, неправильне значення переліку або формат дати, що не відповідає ISO 8601. Перша виправляється винятково синтаксично, друга потребує знання словника і логіки сутності.

Помилки, що виникають через CMS і шаблони

Динамічна розмітка, яка генерується з порожніх полів, — одна з найчастіших причин проблем на сайтах із CMS. Шаблон може виводити властивість "author" з порожнім значенням або з шаблонним рядком, який не був заповнений. Пошуковик отримує формально валідний JSON, але з непридатними даними, і це знижує довіру до всієї розмітки. Правильна практика — не виводити властивість взагалі, якщо її значення відсутнє.

Дублювання блоків розмітки від плагінів і теми створює іншу складність. Один SEO-плагін додає Organization, тема сайту додає ще одну Organization з трохи іншими даними, а окремий плагін для хлібних крихт додає BreadcrumbList. Пошуковик бачить дві конкуруючі сутності одного типу, і не завжди зрозуміло, яку з них враховувати. Найкращий спосіб уникнути цього — визначити одну відповідальну систему для кожного типу сутності і вимкнути дублі в інших місцях.

Конфлікт кількох генераторів розмітки на одній сторінці проявляється найчастіше після оновлення плагінів або зміни теми. Раніше все працювало, а після оновлення з'являється другий блок Article або зникає властивість, яку попередній генератор заповнював. Регулярна перевірка сторінок після будь-яких змін у CMS дозволяє помітити такі регресії до того, як вони вплинуть на видачу.

Зв'язування сутностей через @graph і @id допомагає навести порядок там, де кілька генераторів конкурують. Замість того щоб кожен плагін описував організацію окремо, можна мати один опис з унікальним @id, на який посилаються інші блоки. Валідатор показує, куди веде кожне таке посилання, і попереджає, якщо посилання веде в нікуди.

• Не виводьте властивості з порожніми або шаблонними значеннями, краще взагалі не виводити їх.
• Визначте одну систему-власника для кожного типу сутності на сайті.
• Перевіряйте сторінки після оновлення плагінів, тем і змін у шаблонах.
• Використовуйте @graph і @id, щоб одна сутність мала один опис.

Типи Schema.org: вибір правильної сутності

Словник schema.org побудований ієрархічно. Thing є коренем, від якого походять майже всі типи. CreativeWork охоплює статті, відео, рецепти та інші створені матеріали. Organization описує компанії й установи, Product — товари, Event — події. Кожен нащадок успадковує властивості батьківського типу і додає власні. Розуміння цієї ієрархії допомагає обрати тип, який найточніше описує сторінку.

Правильний вибір означає найспецифічніший доречний тип. Для статті новин краще підходить NewsArticle, ніж загальний Article, якщо це справді новина. Для страви в кулінарному розділі доречний Recipe. Водночас не варто зловживати узагальненими типами там, де існує точніший варіант, але й не варто вигадувати специфічний тип, який не відповідає змісту. Якщо сторінка є блогом з оглядами, Review і Article можуть бути доречними разом, залежно від того, що є основним предметом. Для того щоб швидко зробити перевірку мікророзмітки, достатньо вставити код сторінки або її адресу у валідатор Schema.org, який одразу покаже синтаксичні помилки та некоректні властивості.

Важливо пам'ятати, що допустимість властивості за схемою і її підтримка Google — різні речі. Schema.org може дозволяти властивість для певного типу, але Google для цього типу розширеного результату її не використовує. Така розмітка коректна за стандартом і не ламає сторінку, але не дає додаткової користі в пошуку. Тому перед заповненням рідкісних властивостей варто перевірити документацію Google для відповідного типу.

Обов'язкові та рекомендовані властивості

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

Відмінність між валідною розміткою і розміткою, що дає право на розширений результат, часто не очевидна новачкам. Валідна розмітка пройшла синтаксичну й структурну перевірку, але може не містити полів, які Google вимагає для показу. Розмітка, що дає право, відповідає не лише схемі, а й вимогам конкретного типу розширеного результату. Саме тому валідатор окремо звіряє обов'язкові поля Google, а не лише словник schema.org.

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

Відповідність розмітки видимому контенту

Головне правило структурованих даних полягає в тому, що розмітка має відображати те, що користувач бачить на сторінці. Якщо в JSON-LD зазначено ціну 1200, а на сторінці написано 1500, це порушення, навіть якщо кожне поле окремо валідне. Так само рейтинг із зірками без жодного видимого відгуку на сторінці є типовим порушенням, яке Google може розглядати як маніпуляцію.

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

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

Вимоги до розширених результатів за типами

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

Ці вимоги змінюються з часом, і це важливо враховувати. Деякі типи розширених результатів Google перестав показувати або обмежив їх певними категоріями сайтів. Розмітка при цьому залишається коректною для schema.org, але для пошукової видачі вже не дає ефекту. Тому варто регулярно перевіряти актуальність документації Google Search Central і не покладатися на старі поради, які можуть бути застарілими.

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

Перевірка готовності до показу в пошуку

Послідовність перевірки має бути логічною. Спочатку валідатор синтаксису переконується, що JSON читається без помилок. Далі валідатор Schema.org перевіряє типи, властивості і значення за словником. Потім інструмент розширених результатів Google показує, чи відповідає сторінка вимогам конкретного типу і чи може вона претендувати на відображення. Такий порядок дозволяє виправляти проблеми від фундаментальних до другорядних і не витрачати час на поля, якщо структура зламана.

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

Час до появи результатів після виправлення залежить від частоти переобходу сторінки пошуковим роботом. Для часто оновлюваних сайтів це може бути кілька днів, для рідко змінюваних — тижні. Запит на переобхід через інструменти для веб-майстрів прискорює процес, але не змушує пошуковик миттєво оновити видачу. Розумно дочекатися переобходу, а потім перевірити результат тестовим інструментом.

Валідна розмітка — це квиток на участь у розширеній видачі, але не сама видача: відповідає за неї якість сторінки і рішення пошуковика.

Практичний порядок роботи з розміткою

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

Далі виправляйте синтаксис, бо це найшвидший виграш. Потім приведіть типи і властивості у відповідність до словника, прибравши невідомі терміни і застарілі поля. На третьому кроці заповніть обов'язкові поля Google для тих типів, які важливі для вашого бізнесу. Лише після цього переходьте до рекомендованих полів і до оптимізації зв'язків через @graph.

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

Висновок

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

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