Як користуватись генератором Article Schema?
Інструмент підтримує Article, BlogPosting та NewsArticle, тому підходить для корпоративних блогів, медіа, експертних розділів та інших сайтів із редакційним контентом. Генератор мікророзмітки Article передає в JSON-LD заголовок, автора, дати публікації, зображення та інші відомості, які пошукова система може порівняти зі змістом сторінки.
Робота з генератором починається з вибору типу матеріалу та заповнення даних, які вже опубліковані або опубліковані на сторінці. Не потрібно додавати відомості лише задля більш повного JSON-LD: структуровані дані повинні збігатися з реальним змістом статті, ім'ям автора, датами та доступними для користувача зображеннями.
Після заповнення форми генератор Article Schema формує JSON-LD, який можна перевірити, скопіювати та передати розробнику або додати через передбачений CMS механізм. Перед використанням варто ще раз порівняти значення в розмітці із самою сторінкою, особливо якщо матеріал оновлювався після першої публікації.
1. Виберіть тип Article Schema
Schema.org містить загальний тип Article і конкретніші варіанти окремих видів публікацій. Вибір залежить від характеру матеріалу, а не від того, який тип здається сильнішим з погляду SEO. Для корпоративної статті зазвичай підходить BlogPosting, для редакційної публікації можна використовувати Article, а для новин – NewsArticle.
Генератор Article Schema має допомагати вибрати максимально точний тип без штучного ускладнення структури. Якщо публікація не відноситься до контенту новин і не ведеться як запис блогу, загальний Article залишається нормальним варіантом. Тип розмітки описує матеріал і не змінює його призначення для користувача.
Article
Article підходить для інформаційних, аналітичних та редакційних матеріалів, яким не потрібна вужча класифікація. Наприклад, його можна використовувати для великого експертного огляду, дослідження галузі чи публікації, яка розміщена в інформаційному розділі сайту, але формально не належить до корпоративного блогу.
Цей тип передає пошуковій системі основні відомості про матеріал: назву, автора, зображення, дати та інші властивості. Вибирати Article лише заради більш загального охоплення не потрібно. Якщо зміст точно відповідає BlogPosting або NewsArticle, більш конкретний тип зазвичай описує сторінку зрозуміліше.
BlogPosting
BlogPosting призначений для записів блогу, експертних публікацій, освітніх матеріалів та статей контент-маркетингу. Якщо компанія регулярно публікує матеріали в розділі /blog/, а кожен запис має автор, дату та окрему URL-адресу, такий тип зазвичай відповідає структурі сторінки.
Пошукові фрази blog post schema generator і blogposting schema generator зазвичай ведуть до інструментів із тим самим принципом роботи. Користувач вводить дані публікації, отримує JSON-LD та додає його на сторінку. При цьому назва розділу сама не визначає тип: орієнтуватися потрібно на реальний формат матеріалу.
NewsArticle
NewsArticle використовують для публікацій новин і журналістів, коли сторінка дійсно містить новину, а не звичайний інформаційний текст. Для такого матеріалу особливо важливими є коректні дати, авторство, зображення та збіг структурованих даних з видимою користувачеві інформацією.
Присвоєння NewsArticle звичайній статті не створює додаткових переваг і може зробити менш точною розмітку. Цей тип також не гарантує потрапляння матеріалу до Google News або блоку Top Stories. Пошукові системи оцінюють сторінку за сукупністю технічних та змістовних сигналів.
2. Заповніть дані статті
Після вибору типу необхідно заповнити відомості, що описують конкретну публікацію. Основні поля генератора зазвичай відповідають властивостям Schema.org та містять заголовок, URL, автора, дати та зображення. Додаткові поля можуть надсилати мову, розділ сайту, видавця або короткий опис матеріалу.
Краще заповнювати лише дані, які можна підтвердити вмістом сторінки або іншими доступними користувачем елементами сайту. Якщо автор невідомий, дата оновлення відсутня або зображення недоступне пошуковому роботі, вигадані значення не зроблять структуровані дані якіснішими.
Заголовок та URL статті
Властивість headline містить назву матеріалу і має збігатися за змістом із заголовком опублікованої сторінки. Штучно додавати до нього додаткові ключові фрази для мікророзмітки не потрібно. Якщо генератор передбачає description, опис також має точно передавати зміст статті.
URL-адресу вказують для тієї сторінки, яку описує об'єкт Article. При використанні mainEntityOfPage потрібно передати коректний зв'язок між статтею та її основною сторінкою. Канонічна адреса публікації, URL у розмітці та фактично індексована версія сторінки не повинні суперечити одна одній.
Автор матеріалу
Властивість author допомагає явно вказати людину чи організацію, які відповідають за публікацію. Для експертних матеріалів зазвичай використовують тип Person, вказуючи справжнє ім'я автора і, якщо є, посилання на його профіль, сторінку редакції або іншу сторінку з додатковою інформацією.
Для матеріалів, опублікованих від імені компанії, у потрібних випадках можна використовувати Organization. Однак підміняти реального автора назвою бренду лише заради заповнення поля не потрібно. Якщо на сторінці вказаний спеціаліст, структуровані дані повинні зберігати ту саму інформацію.
Дати публікації та оновлення
datePublished передає початкову дату публікації, а dateModified – дату останньої істотної зміни матеріалу. Ці значення корисно розрізняти, коли стаття регулярно актуалізується, але її вихідна дата залишається частиною історії публікації та відображається користувачеві.
Для передачі дат використовують формат ISO 8601, який читається однозначно програмними системами. Не варто змінювати dateModified після кожної дрібної технічної правки шаблону або виправлення помилки. Поле має відображати реальне оновлення змісту, якщо відповідна дата також використовується на сторінці.
Зображення статті
Властивість image має вести на зображення, яке відноситься до змісту публікації та доступне пошуковій роботі. Найкраще використовувати якісну ілюстрацію або фотографію, що представляє матеріал, а не випадковий елемент інтерфейсу, іконку сайту або загальний логотип компанії.
URL-адреса має відкриватися без авторизації та технічних блокувань. Якщо для статті використовуються кілька зображень, Schema.org допускає передачу відповідного набору даних. При цьому кожне зображення має бути пов'язане з публікацією та не суперечити тому, що бачить користувач.
Дані видавця
publisher описує видавця матеріалу та зазвичай містить сутність Organization з назвою компанії або медіа. У структуру також можна додати URL-адресу та логотип організації, якщо ці відомості дійсно відносяться до сайту та відповідають загальної інформації про бренд.
Не варто сприймати publisher як поле, яке необхідно заповнити за будь-яку ціну. Набір властивостей, що використовуються, залежить від публікації та доступних даних. Генератор повинен допомагати створити точну розмітку, а не змушувати користувача вигадувати значення для кожної можливої якості Schema.org.
3. Згенеруйте JSON-LD
Коли основні поля заповнені, генератор перетворює введені дані у структурований об'єкт JSON-LD. Зазвичай готовий результат розміщується всередині конструкції <script type="application/ld+json">, яку можна додати в HTML сторінки без зміни видимого тексту статті та її звичайної розмітки.
Перед копіюванням корисно ще раз переглянути значення автора, дат, URL та зображень. Якщо інтерфейс підтримує форматований та мініфікований режими, для перевірки зручніше читати форматований варіант. Після зміни форми JSON-LD бажано генерувати заново, щоб не виправляти структуру вручну.
Формат article schema generator зазвичай має на увазі саме такий сценарій: заповнення форми, отримання JSON-LD, перевірку та подальше впровадження. Деякі інструменти додатково дозволяють завантажити готовий JSON, завантажити приклад або відразу відкрити результат у сервісі перевірки структурованих даних.
4. Перевірте готову розмітку
Навіть коректно згенерований JSON-LD потрібно перевірити після створення, а потім знову після розміщення на реальній сторінці. На етапі генерації можна виявити синтаксичні помилки та пропущені властивості, але після впровадження з'являються додаткові ризики: конфлікт із CMS, дублювання Schema або неправильна URL-адреса.
Для перевірки використовують Google Rich Results Test та Schema.org Validator. Після публікації корисно перевірити саму URL, а не тільки скопійований фрагмент коду. Такий підхід показує підсумкову версію сторінки, яку отримує пошуковий робот разом із усіма шаблонними та автоматично доданими структурованими даними.
Як Article Schema впливає на SEO?
Структуровані дані допомагають пошуковій системі отримати однозначні відомості про публікацію, включаючи автора, дату, зображення та тип матеріалу. Вони не замінюють текст, технічну якість сторінки, внутрішню перелінковку або нормальну індексацію, тому оцінювати Article Schema окремо від решти SEO елементів неправильно.
Article schema generator скорочує шлях від даних статті до готового JSON-LD, але результат залежить від якості вихідної інформації. Якщо в коді передано неправильні дати, вигадані автори або недоступні зображення, автоматична генерація не виправить ці помилки.
Допомагає пошуковій системі зрозуміти зміст сторінки
Звичайна HTML-сторінка містить багато елементів, серед яких пошуковій системі доводиться визначати основний матеріал, автора, дати та відносини між сутностями. Structured data передає ці зв'язки у явному вигляді та зменшує неоднозначність при машинній обробці документа.
Особливо це корисно на великих сайтах, де один шаблон використовується для тисяч публікацій. Єдина Article-розмітка допомагає підтримувати однакову структуру даних, якщо CMS коректно виводить headline, author, image, datePublished та інші властивості кожної сторінки.
Може покращити подання статті у пошуку
Коректні структуровані дані можуть використовуватися пошуковою системою для формування розширеного представлення матеріалів, якщо сторінка відповідає вимогам конкретного пошукового результату. Саме наявність JSON-LD не означає, що розширений формат обов'язково з'явиться для кожного документа.
Тому в тексті та інтерфейсі генератора не варто обіцяти зростання CTR або отримання rich results після вставки коду. Пошукова система самостійно вирішує, як показувати сторінку з огляду на якість матеріалу, доступність даних та інші фактори.
Article Schema не є прямим фактором ранжування
Наявність Article Schema сама собою не перекладає сторінку вище конкурента з порівнянним змістом. Мікророзмітка передає додаткові структуровані відомості та допомагає пошуковим системам інтерпретувати матеріал, але не замінює релевантність тексту та якість сайту.
З практичної точки зору спочатку потрібно вирішити питання індексації, canonical, внутрішніх посилань, контенту та технічних помилок. Після цього структуровані дані додають зрозумілий машинний шар, який має залишатися узгодженим із підсумковою версією публікації.
Чи потрібна Article Schema для Top Stories?
Article-розмітка не є обов'язковою умовою влучення публікації в Top Stories. Тому додавати NewsArticle заради цього блоку або змінювати тип звичайного матеріалу без фактичних підстав не потрібно. Тип повинен відповідати змісту сторінки, незалежно від передбачуваного формату видачі.
При цьому коректні структурні дані допомагають пошуковій системі точніше отримати дані публікації. Для сайту новин це корисна частина загальної технічної реалізації, але результат залежить також від якості контенту, доступності сторінки, зображень та інших факторів.
Я розглядаю Article Schema як додатковий шар даних для пошукової системи. Чим точніше в JSON-LD збігаються автор, заголовок, дати, зображення та інші властивості з реальною сторінкою, тим менше неоднозначності під час її обробки. Тому спочатку я упорядковую матеріал і його HTML, а потім додаю структуровані дані. Розмітка повинна описувати опубліковану сторінку і не створювати відомостей, яких користувач на ній не бачить.
Часті помилки в Article Schema
Більшість проблем пов'язано не з синтаксисом JSON, а з розбіжністю структурованих даних і реального вмісту сторінки. Код може пройти базову перевірку, але містити іншого автора, неправильну дату, закрите зображення або тип публікації, який не відповідає матеріалу.
На проєктах із CMS додатковий ризик створює дублювання. Один Article може формуватися темою, другий SEO-плагіном, третій користувач додає вручну. Перед використанням нового генератора необхідно зрозуміти, які структуровані дані вже є на сторінці.
Розмітка не відповідає видимому змісту
Якщо JSON-LD повідомляє одну інформацію, а користувач бачить іншу, розмітка стає ненадійною. Наприклад, не можна вказувати іншого автора, змінювати дату публікації або передавати зображення, яке взагалі не відноситься до матеріалу та відсутнє у контексті сторінки.
Перед публікацією варто звірити headline, author, image, datePublished, dateModified та URL. Для автоматичної системи таку перевірку можна включити до шаблону або технічного чекера, щоб помилки не поширювалися відразу на весь розділ сайту.
Вибрано неправильний тип статті
Тип Schema вибирають за реальним форматом контенту. Звичайне керівництво компанії не стає новиною після вибору NewsArticle, а статична сторінка послуги не перетворюється на блоговий запис лише через великий текст.
Якщо сумнів залишається між загальним та більш специфічним типом, краще перевірити призначення сторінки у структурі сайту. Коректна семантика корисніша за спробу використовувати більш вузький варіант без фактичних підстав.
Некоректні дати
Помилки з'являються, коли datePublished і dateModified переплутані, формуються в різних часових поясах або автоматично змінюються після збереження документа. В результаті пошукова система отримує дату, яка не відповідає редакційній історії матеріалу.
Для CMS краще зберігати первинну публікацію та суттєве оновлення окремо. Якщо дата відображається читачеві, вона повинна співпадати з JSON-LD. Значення слід передавати у стандартному форматі, який однозначно розпізнається програмними системами.
Зображення недоступне пошуковому роботі
Посилання в image має вести реально доступний файл. Проблеми виникають через закритий CDN, тимчасові URL-адреси, неправильні редиректи, заборону індексації або видалення зображення після оновлення сторінки.
Перевіряти потрібно саму адресу файлу, а не тільки відображення картинки в браузері редактора. Зображення також має належати до змісту публікації. Випадковий логотип, декоративна іконка або пуста заглушка погано описують матеріал.
Автор вказаний неоднозначно
Запис на кшталт Admin або Редактор без додаткового контексту рідко допомагає зрозуміти, хто відповідає за матеріал. Якщо сайт публікує експертний контент, краще використовувати справжнє ім'я автора та пов'язану сторінку профілю зі зрозумілою інформацією.
При цьому не можна створювати фіктивних фахівців лише для покращення структури даних. Якщо матеріали справді випускає редакція, потрібно описувати реальну модель авторства та узгодити її з тим, що користувач бачить на сторінці.
На сторінці кілька конфліктуючих Article Schema
Дублі часто з'являються після підключення нового SEO-плагіну або ручного впровадження JSON-LD поверх існуючої розмітки. Два об'єкти самі собою не завжди є помилкою, але вони мають описувати різні сутності і не суперечити одне одному.
Якщо один Article повідомляє автора Івана, а інший – назва компанії, або вони містять різні дати однієї публікації, структуру потрібно виправити. Перед додаванням нового коду корисно перевірити сторінку валідатором і знайти всі існуючі об'єкти.
У JSON-LD додано вигадані дані
Не можна вигадувати авторів, дати, рейтинги, відгуки чи видавців для заповнення всіх полів генератора. Structured data має описувати існуючий вміст та реальні сутності сайту, інакше формально повний об'єкт передає пошуковій системі недостовірну інформацію.
Краще залишити поле, що не застосовується незаповненим, ніж підставити випадкове значення. Такий принцип є особливо важливим для автоматичних генераторів, де один неправильний шаблон здатний створити однакову помилку на тисячах URL.
Що саме ми робили
Стоматологія · Київ і Чернігів
+44% кліків із пошуку
Домен без історії, сайт на конструкторі. Зібрали семантику під послуги й обидва міста, переробили посадкові сторінки, з нуля побудували посилальний профіль. За чотири місяці: 34,8 тис. кліків, покази 1,32 → 1,76 млн, DR 0 → 41.
E-commerce · міжнародний ринок
+96% кліків за два місяці
Каталог цифрових 3D-моделей. Кластеризували семантику, перебудували хабові сторінки, закрили дублі та помилки індексації. Користувачі з Google 247 → 532, CTR 2,4% → 4%.
Медичний центр · Україна
+68,75% видимості за перший місяць
Вузька видимість і мала семантика на старті. Семантика, структура посадкових, метадані та перелінковка, поступове посилення посиланнями.
Відповіді на ваші запитання
Що таке генератор Article Schema?
Генератор Article Schema створює JSON-LD для сторінки зі статтею за даними, які користувач вводить. Зазвичай форма містить тип публікації, headline, автора, URL, зображення, datePublished, dateModified та відомості про видавця.
Після заповнення полів article schema generator формує готову структуру Schema.org, яку можна скопіювати та перевірити валідатором. Інструмент зменшує обсяг ручної технічної роботи, але користувач все одно повинен перевірити достовірність даних.
Чим Article відрізняється від BlogPosting?
Article є загальним типом для редакційних та інформаційних публікацій, а BlogPosting точніше описує окремий запис блогу. Обидва типи можуть містити автора, зображення, дати та інші подібні властивості.
Якщо матеріал опублікований у корпоративному чи експертному блозі як окремий запис, зазвичай логічно вибрати BlogPosting. Для публікації іншого редакційного формату можна використовувати загальний Article, якщо специфічніший тип не відповідає змісту.
Коли потрібно використовувати NewsArticle?
NewsArticle використовують для матеріалів, які справді є новинами або журналістськими публікаціями. Такий тип підходить інтернет-ЗМІ, редакційним розділам новин та іншим сторінкам, де подія висвітлюється у форматі самостійного новинного матеріалу.
Використовувати NewsArticle для звичайного SEO-тексту, інструкції чи корпоративної статті без контексту новин не потрібно. Вибір цього типу також не гарантує потрапляння публікації у Top Stories або Google News.
Які поля потрібно заповнити в Article Schema?
Для більшості публікацій корисно вказати headline, author, image, datePublished і за наявності істотних оновлень dateModified. Додатково можна передати опис, publisher, articleSection, inLanguage, mainEntityOfPage та інші застосовні властивості.
Фіксованого універсального набору, який потрібно заповнювати за будь-яку ціну, немає. Розмітка повинна мати достовірні дані конкретної сторінки. Якщо властивості не можна підтвердити змістом сайту, вигадувати значення тільки для заповненої форми не слід.
Куди вставляти готовий JSON-LD?
Готовий JSON-LD додають HTML сторінки всередині <script type="application/ld+json">. На сайтах із CMS код краще виводити автоматично через шаблон публікації, щоб дані оновлювалися разом із автором, зображенням, URL та датами.
Після впровадження потрібно перевірити саме опубліковану сторінку, оскільки тема чи SEO-модуль можуть уже виводити власну розмітку. Така перевірка допомагає вчасно знайти дублі та об'єкти Article, що суперечать один одному.
Як перевірити Article Schema?
Для технічної перевірки можна використовувати Google Rich Results Test та Schema.org Validator. Перший допомагає побачити структуровані дані в контексті пошукових можливостей, що підтримуються Google, а другий перевіряє загальну структуру типів і властивостей Schema.org.
Після публікації потрібно протестувати реальну URL-адресу, а не лише окремий JSON-LD. Для індексованої сторінки також можна використовувати URL Inspection у Search Console та переконатися, що Google отримує актуальну версію документа.
Чи допомагає Article Schema підвищити позиції Google?
Сама присутність Article Schema не гарантує підвищення позиції сторінки. Structured data допомагає пошуковій системі точніше визначити властивості публікації, але ранжування залежить від змісту, релевантності, технічного стану сайту, посилань та інших сигналів.
Тому генератор мікророзмітки Article потрібно використовувати як частину технічного налаштування сторінки. Якщо матеріал закритий від індексації, має дублі або слабкий зміст, додавання коректного JSON-LD не вирішить проблему самостійно.
Чи можна використовувати Article Schema разом із іншою мікророзміткою?
На одній сторінці можна використати кілька типів Schema.org, якщо кожен об'єкт відповідає реальному змісту. Наприклад, стаття може одночасно мати Article, хлібні крихти BreadcrumbList і дані організації Organization.
При цьому об'єкти не повинні суперечити один одному або дублювати одну сутність із різними значеннями. Після додавання кількох типів краще перевірити підсумкову сторінку і переконатися, що зв'язки між сутностями сформовані коректно.
Суміжні послуги
Генератор Organization Schema
Безкоштовний генератор Organization Schema: створіть JSON-LD розмітку компанії, додайте назву, логотип, адресу, контакти та sameAs, скопіюйте код та перевірте його валідність.
Генератор BreadcrumbList Schema
Breadcrumb Schema Generator для створення JSON-LD розмітки BreadcrumbList. Додайте назви та URL, отримайте готовий код та перевірте його для Google.
Генератор Product Schema
Product Schema Generator онлайн: створіть JSON-LD мікророзмітку товару з ціною, наявністю, брендом, рейтингом та Offer. Скопіюйте код та перевірте його перед публікацією.
Article Schema корисна там, де сторінка дійсно містить самостійну публікацію та пошуковій системі потрібно передати її властивості у структурованому вигляді. Вибір між Article, BlogPosting та NewsArticle залежить від формату матеріалу, а якість розмітки визначається точністю автора, дат, зображень, URL та інших даних.
Використовуйте генератор Article Schema, заповніть лише достовірні відомості, перевірте готовий JSON-LD та протестуйте опубліковану URL після впровадження. Для великого сайту перенесіть перевірену структуру шаблону CMS, щоб розмітка оновлювалася разом з кожною публікацією і не вимагала ручної підтримки.
Відповідаємо протягом робочого дня. Без розсилок і дзвінків «просто нагадати».
Подивиться сайт сам, а не передасть менеджеру.
Докладніше: Генератор Article Schema
Що таке Article Schema?
Article Schema – тип структурованих даних Schema.org для опису статей та інших редакційних матеріалів. Розмітка передає вміст сторінки в машиночитаній структурі, де окремо позначаються заголовок, автор, зображення, дати публікації, дата оновлення та пов'язані відомості.
Назви article json ld generator, article markup generator і article structured data generator зазвичай позначають один клас інструментів. Вони допомагають зібрати Article-розмітку без ручного написання JSON-LD. Генератор мікророзмітки Article скорочує технічну роботу, але зміст отриманого коду все одно потрібно перевіряти перед використанням.
Як Article Schema пов'язана зі Schema.org?
Schema.org містить загальний словник типів та властивостей, якими сайти можуть описувати сутність у структурованому вигляді. Article входить у цей словник і має більш конкретні дочірні типи, серед яких для звичайних сайтів найчастіше зустрічаються BlogPosting та NewsArticle.
Властивості на кшталт headline, author, image, datePublished і dateModified дають однозначні позначення даним публікації. Пошукова система може використовувати таку інформацію для обробки сторінки. При цьому Schema.org описує структуру даних ширше ніж вимоги конкретної пошукової системи.
Що таке JSON-LD?
JSON-LD – формат передачі пов'язаних структурованих даних на основі JSON. На вебсторінці такий код зазвичай розміщують усередині тега <script type="application/ld+json">, тому розробнику не потрібно додавати властивості Schema.org безпосередньо до кожної частини видимої HTML-розмітки.
Цей формат зручний для автоматичної генерації, CMS та серверного рендерингу. Розмітку можна створити окремо, перевірити валідатором і вивести в шаблоні статті. JSON-LD повинен залишатися доступним пошуковому роботі та описувати ту саму інформацію, яку користувач отримує під час перегляду сторінки.
Чим Article Schema відрізняється від звичайної HTML-розмітки?
HTML визначає структуру документа для браузера та користувача: заголовки, абзаци, посилання, зображення та інші елементи сторінки. Наприклад, тег H1 показує основний заголовок документа, а елемент <img> виводить зображення, яке бачить користувач усередині статті.
Article Schema додає машиночитане опис самої сутності публікації. Вона явно пов'язує заголовок з headline, автором з author, а дату з datePublished. Звичайний HTML і структуровані дані працюють паралельно, тому JSON-LD не замінює правильну структуру сторінки та не виправляє слабкий контент.
Article, BlogPosting та NewsArticle – у чому різниця?
Три типи відносяться до одного сімейства Schema.org, але описують різні формати публікацій. Загальний Article підходить для широкого кола матеріалів, BlogPosting точніше описує запис блогу, а NewsArticle призначений для новинного та журналістського контенту.
Вибір краще робити за фактичним призначенням сторінки, а не за назвою ключового запиту або передбачуваного SEO-ефекту. Якщо публікація відповідає більш специфічному типу, його використання робить дані зрозумілішими та знижує ймовірність смислового розходження між JSON-LD та видимою частиною документа.
| Тип Schema | Для якого контенту підходить | Типовий приклад | Коли вибирати |
|---|---|---|---|
| Article | Інформаційні та редакційні матеріали | Аналітичний огляд галузі | Коли точніший тип не потрібний |
| BlogPosting | Записи блогу та експертні публікації | Стаття у корпоративному блозі | Коли матеріал є окремим записом блогу |
| NewsArticle | Новини та журналістські публікації | Новина інтернет-видання | Коли сторінка дійсно відноситься до контенту новин |
Схема вибору може виглядати так:
Публікація
│
├── Запис блогу ─────────> BlogPosting
│
├── Новинний матеріал ────> NewsArticle
│
└── Інший матеріал ──────> Article
Коли використовувати Article?
Article підходить для публікацій, які мають редакційну чи інформаційну природу, але не належать безпосередньо до формату блогу чи новини. Це може бути галузевий огляд, великий експертний матеріал, дослідження чи публікація у інформаційному розділі корпоративного сайту.
Використання загального типу нормально, якщо вужчий тип не описує матеріал точніше. Не потрібно вибирати NewsArticle для звичайного керівництва або BlogPosting лише тому, що стаття регулярно оновлюється. Семантика Schema повинна дотримуватися змісту конкретної сторінки.
Коли використовувати BlogPosting?
BlogPosting варто вибирати для записів блогу, де публікація має окрему URL-адресу, автора, дату та місце в загальній структурі матеріалів сайту. Такий формат часто використовують корпоративні блоги, освітні платформи, SaaS-компанії, агенції та експертні проєкти.
Якщо користувач шукає blog post schema generator, йому зазвичай потрібний готовий JSON-LD для такого формату. Генератор повинен передати дані публікації без зміни їхнього сенсу та допомогти зберегти однакову структуру розмітки для різних статей одного розділу.
Коли використовувати NewsArticle?
NewsArticle відповідає новинним матеріалам та журналістським публікаціям, для яких дата виходу та авторство є частиною редакційного контексту. Сторінка має дійсно виконувати функцію новин, а дані в Schema повинні збігатися з інформацією, опублікованою для читача.
Розмітка NewsArticle сама по собі не забезпечує потрапляння в блоки новин Google. Тому змінювати тип звичайної статті для Top Stories безглуздо. Коректна класифікація знижує неоднозначність даних, але пошукова видимість залежить від якості сторінки та інших сигналів.
Які дані можна додати до Article JSON-LD?
Набір властивостей залежить від типу матеріалу, структури сайту та фактично доступної інформації. Для більшості публікацій корисно передати заголовок, автора, зображення та дати, а при необхідності доповнити об'єкт описом, мовою, рубрикою, видавцем та зв'язком з основною сторінкою.
Google не вимагає фіксованого універсального набору обов'язкових властивостей для кожної Article-розмітки. Тому краще додавати застосовні та достовірні дані, ніж заповнювати поля формально. Генератор Article Schema повинен допомагати користувачеві зібрати зрозумілу структуру без вигаданих значень.
Основні властивості статті
До основних даних відносяться властивості, які найчастіше можна однозначно зіставити з видимою частиною публікації. Вони допомагають пошуковій системі зрозуміти, як називається матеріал, хто його підготував, коли він з'явився та які зображення безпосередньо пов'язані з його змістом.
При автоматичному впровадженні ці поля краще отримувати із CMS, щоб значення оновлювалися разом із статтею. Ручний JSON-LD вимагає додаткового контролю після кожної зміни сторінки, особливо якщо редактор змінює автора, зображення або дату останнього суттєвого оновлення.
headline
headline містить заголовок публікації і повинен передавати його без штучних додавань заради SEO. У більшості випадків значення можна брати з основного заголовка матеріалу або поля CMS, якщо воно не розходиться з тим, що користувач бачить на сторінці.
Не слід перетворювати headline на окремий SEO-Title з додатковими ключовими словами, містами та комерційними модифікаторами. Якщо назва матеріалу змінилася, JSON-LD теж потрібно оновити, інакше пошукова система отримає різні версії того самого елемента.
author
author вказує автора публікації та може посилатися на сутність Person чи Organization. Для експертного матеріалу корисно передавати реальне ім'я спеціаліста та URL-адресу його сторінки, якщо на сайті існує повноцінний профіль з інформацією про автора.
Якщо публікацію підготувала редакція, структура залежить від того, як авторство відображається на сайті. Не варто створювати людину, яку користувач ніде не бачить. Розмітка повинна повторювати реальні редакційні дані, а не заповнюватися виключно для повноти JSON-LD.
image
image пов'язує публікацію із зображенням, яке представляє її вміст. Для статті зазвичай підходить основна ілюстрація, фотографія або інше графічне зображення, яке використовується безпосередньо в матеріалі та доступне за стабільним URL.
Файл не повинен бути закритим через robots.txt, авторизацію або тимчасове посилання. При оновленні головної ілюстрації бажано одночасно змінювати значення структурованих даних. Використання логотипу замість зображення статті знижує точність опису сутності.
datePublished
datePublished містить початкову дату публікації матеріалу. Якщо стаття вперше з'явилася 10 березня, а потім була суттєво доповнена у червні, перша дата має зберігатися як дата публікації, якщо редакційна політика сайту відображає її користувача.
Для автоматизованого сайту це значення краще брати зі постійного поля CMS, яке не змінюється при звичайному редагуванні. Такий підхід унеможливлює ситуацію, коли кожне збереження документа випадково створює нову дату першої публікації.
dateModified
dateModified відображає дату останнього суттєвого оновлення змісту. Її можна змінювати після додавання нових даних, переробки розділів, зміни висновків або іншої редагування, яка дійсно впливає на опублікований матеріал.
Не оновлюйте поле після зміни кольору кнопки, системного шаблону або виправлення однієї помилки. Якщо дата оновлення відображається користувачеві, значення JSON-LD має відповідати їй. Для передачі дати найкраще використовувати стандартний формат ISO 8601.
Додаткові властивості
Додаткові властивості допомагають точніше описати контекст публікації, але наявність залежить від конкретної сторінки. На одному сайті може бути корисний articleSection, на іншому - inLanguage або publisher, а частина даних може вже передаватися через пов'язані сутності Organization і WebSite.
Додавати кожну доступну властивість Schema.org без потреби не потрібно. Чим складніше JSON-LD, тим важче контролювати його узгодженість із реальним змістом сторінки. Робоча розмітка повинна залишатися зрозумілою та передбачуваною під час наступних оновлень.
description
description містить короткий опис змісту статті. Його можна формувати з фактичного анонсу матеріалу або окремого поля CMS, якщо текст точно відповідає публікації і не створює нового змісту, якого немає в основному документі.
Description у Schema та HTML meta description можуть збігатися, але такий збіг не є обов'язковою технічною умовою. Обидва тексти мають коректно описувати сторінку. Штучне перерахування ключових запитів усередині властивості погіршує читання даних.
articleSection
articleSection допомагає вказати рубрику або тематичний розділ, до якого належить матеріал. Для блогу це може бути SEO, аналітика, розробка, маркетинг або інша реально існуюча категорія сайту, яка використовується у навігації та структурі публікацій.
Не варто створювати окреме значення лише для структурованих даних, якщо такої рубрики більше немає. При масштабному контентному проєкті articleSection зручно формувати автоматично з категорії статті, щоб Schema залишалася однаковою для всіх публікацій розділу.
вLanguage
inLanguage означає мову матеріалу і особливо корисний для сайтів з кількома мовними версіями. Значення має відповідати фактичної мови сторінки, а не мови інтерфейсу браузера чи географічному регіону відвідувача.
Для мультимовного сайту кожна локалізована публікація має отримувати власну коректну мову разом зі своїм URL та текстом. Ця властивість не замінює hreflang, тому що hreflang вирішує інше завдання та пов'язує альтернативні мовні версії URL.
mainEntityOfPage
mainEntityOfPage показує зв'язок Article з основною сторінкою, на якій опубліковано матеріал. Властивість допомагає явно вказати, що ця стаття є головним об'єктом конкретного документа, а не другорядним елементом всередині іншої сторінки.
При заповненні потрібно використовувати правильну URL самої публікації. Не слід вказувати головну сторінку сайту, категорію блогу чи адресу іншого матеріалу. Для канонічної сторінки дані повинні залишатися узгодженими з canonical та фактичною індексацією URL.
publisher
publisher передає дані видавця публікації. На корпоративному сайті це зазвичай організація, якій належить ресурс, а інтернет-медіа – редакція чи компанія, що випускає матеріал. Для сутності можна використовувати назву, URL та доступний логотип.
Значення краще пов'язувати із загальною інформацією Organization, яка вже використовується на сайті. Якщо назва компанії у шапці, Organization Schema та Article publisher різниться без причини, така структура створює непотрібну неоднозначність.
keywords та wordCount
keywords може описувати тематичні поняття матеріалу, а wordCount – обсяг тексту у словах. Ці властивості відносяться до додаткових даних і не повинні використовуватися як спосіб передати пошуковій системі список ключових запитів, що просуваються.
Якщо CMS вміє розраховувати WordCount автоматично, значення можна формувати при публікації або оновленні матеріалу. Ручний підрахунок швидко старіє після редакторських правок. Keywords теж краще використовувати лише за наявності зрозумілого джерела даних.
Як додати Article Schema на сайт?
Спосіб впровадження залежить від CMS та архітектури проєкту. Для окремих матеріалів JSON-LD можна додати вручну, але на великому сайті безпечніше формувати розмітку з полів статті автоматично. Тоді дані автора, URL, зображення та дати оновлюються разом із самою публікацією.
Перед масовим використанням варто перевірити шаблон на декількох типових сторінках. Окремо потрібно переконатися, що сайт вже не виводить Article Schema через SEO-плагін, тему чи інший модуль, інакше новий код може створити другий об'єкт із суперечливими значеннями.
Вставка JSON-LD у HTML
Готова розмітка розміщується всередині тега <script type="application/ld+json">. Пошуковий робот повинен отримати цей код разом зі сторінкою та мати доступ до всіх URL, які вказані всередині об'єкта, включаючи зображення, профіль автора та адресу самої публікації.
Ручна вставка підходить для невеликої кількості сторінок, але вимагає контролю після кожної зміни матеріалу. Якщо редактор оновив автора або головну ілюстрацію, а JSON-LD залишився тим самим, структуровані дані починають розходитись із реальною сторінкою.
Додавання через CMS
На сайті з великою кількістю публікацій краще створювати Article Schema автоматично з полів CMS. Заголовок можна брати з назви матеріалу, автора – з профілю користувача, зображення – з основного media-поля, а дати – із системних значень публікації та оновлення.
Такий підхід зменшує кількість ручних помилок та краще переживає масштабування контенту. При зміні шаблону розробник керує одним механізмом генерації замість сотень сторінок. При цьому кожне поле потрібно перевіряти на значення, щоб CMS не виводила порожні властивості.
Article Schema на SSR-сайтах
Для Next.js, Nuxt та інших SSR-рішень зручно формувати JSON-LD одночасно із серверною HTML-сторінкою. Пошуковий робот отримує структуровані дані відразу при завантаженні документа, без залежності від додаткової дії користувача або складної клієнтської логіки.
На багатомовному проєкті генератор повинен враховувати мову, URL та дані конкретної локалізації. Російська, українська та англійська версії однієї статті можуть мати різні headline, description та URL автора, тому значення не можна без перевірки копіювати між локалями.
Як перевірити Article Schema після створення?
Перевіряти потрібно спочатку код, а потім опубліковану сторінку повністю. Окремий JSON-LD може бути синтаксично правильним, але після впровадження сайт здатний вивести другий Article, змінити URL або підставити дані з іншого шаблону, які не було видно в генераторі.
Для повноцінної перевірки корисно поєднувати кілька інструментів. Google Rich Results Test показує дані в контексті пошукових можливостей, що підтримуються, Schema.org Validator перевіряє структуру за словником Schema.org, а Search Console допомагає аналізувати вже доступну Google сторінку.
Google Rich Results Test
Google Rich Results Test підходить для перевірки структурованих даних, які використовуються Google у підтримуваних форматах пошукової видачі. В інструмент можна передати опублікований URL або код, після чого перевірити знайдені сутності, помилки та попередження.
Попередження не завжди означає, що сторінка технічно зламана, тому кожне повідомлення слід читати в контексті конкретної властивості. Після впровадження краще тестувати реальну URL-адресу, оскільки вона показує фактичну сторінку разом із шаблонною розміткою сайту.
Schema.org Validator
Schema.org Validator допомагає перевірити структуру об'єкта за загальним словником Schema.org. Такий аналіз корисний, коли потрібно побачити типи та властивості поза обмеженнями конкретних rich results Google або перевірити складний об'єкт з кількома пов'язаними сутностями.
Валідатор не оцінює якість самого тексту та не перевіряє достовірність автора, дат чи видавця. Тому відсутність технічної помилки ще не означає, що розмітка змістовно коректна. Значення потрібно окремо порівнювати із реальною сторінкою.
Перевірка опублікованої сторінки
Після розміщення JSON-LD потрібно відкрити підсумкову URL-адресу і перевірити вихідний HTML, структуровані дані та доступність пов'язаних ресурсів. Для матеріалу, що вже індексується, додатково можна використовувати URL Inspection в Google Search Console і подивитися, чи доступна Google актуальна версія сторінки.
Перевірка особливо потрібна після зміни CMS, шаблону чи SEO-модуля. Оновлення сайту здатне додати другу Schema або видалити частину полів без видимої помилки на сторінці, тому періодичний технічний контроль допомагає знаходити такі проблеми раніше.
На які сторінки підходить Article Schema?
Article Schema підходить для сторінок, де основною сутністю дійсно є самостійна публікація із заголовком, змістом та редакційним контекстом. Зазвичай це статті блогу, новини, дослідження, експертні матеріали, аналітичні огляди та освітні публікації.
Перед впровадженням варто визначити тип кожної групи URL, щоб не розповсюджувати Article на сторінки, що належать до товарів, категорій чи послуг. Генератор розмітки зручніше використовувати після такої класифікації, оскільки форма не визначає призначення документа.
Найчастіше Article-розмітка підходить для наступних сторінок:
- статей корпоративного чи експертного блогу, де є окремий автор та дата публікації;
- новинних матеріалів, що випускаються редакцією та відносяться до поточних подій;
- досліджень, аналітичних оглядів та змістовних галузевих публікацій;
- освітніх матеріалів, інструкцій та посібників, якщо основна сутність сторінки залишається статтею;
- редакційних оглядів, де зміст оформлений як самостійна публікація, а не картка товару.
Для інших типів сторінок потрібно спочатку перевірити, чи існує більш відповідна суть Schema.org. Такий поділ допомагає уникнути ситуації, коли одна розмітка застосовується механічно до всього сайту.
Зазвичай Article не варто використовувати для наступних документів:
- головною сторінкою, де основним об'єктом є сайт або організація;
- категорії блогу чи каталогу, що містить список кількох матеріалів;
- картки товару, на яку основним об'єктом виступає Product;
- сторінки контактів чи інформації про компанію;
- комерційного лендингу послуги, якщо він не є самостійною редакційною публікацією.
Після класифікації можна налаштувати автоматичне виведення Schema на рівні шаблонів. Тоді генератор Article Schema знадобиться для перевірки структури, тестових сторінок або проєктів, де автоматична мікророзмітка поки що не налаштована.