API для валідатора від Яндекса. А також чому валідатори мікророзмітки видають різні відповіді?

Деякий час тому ми випустили API для свого валідатора мікророзмітки. І сьогодні я хочу поговорити як про API, так і взагалі про валідаторах. Щоб, наприклад, зрозуміти, чому результати різних валідаторів розрізняються.

Валідатори бувають різних типів і розробляються для різних цілей. Загалом їх можна поділити на два типи: універсальні і спеціалізовані. Універсальні – наш валідатор, Structured data testing tool від Google,Validator.nu, Structured Data Linter, Markup Validator від Bing перевіряють відразу кілька стандартів розмітки. При цьому валідатори від пошукових систем перевіряють розмітку ще й на відповідність документації до своїх продуктів на її основі. Спеціалізовані валідатори, такі як JSON-LD Playground, Open Graph Object Debugger, – це інструменти від розробників самих стандартів. З допомогою Open Graph Object Debugger можна перевірити правильність розмітки Open Graph, а JSON-LD Playground показує, як розмітка JSON-LD буде розбиратися роботами.



Ми взяли різні приклади розмітки і порівняли відповіді цих валідаторів, щоб знайти найкраще.

1. Використання content у тегах, відмінних від meta.
Специфікація мікроданих не передбачає використання content в атрибутах, відмінних від тегів meta. Але останнім часом таке використання зустрічається все частіше, тому цікаво подивитися, як такий приклад розбирають різні валідатори.

Приклад розмітки:
<div itemscope itemtype="http://schema.org/Review">
<div itemprop="dateCreated" content="2015-06-07 20:10:47">Останнє оновлення: вчора 20:10</div>
</div>

Валідатор Яндекса ігнорує content у тегах, відмінних від meta (зараз ми додаємо можливість використання такої конструкції і в парсере, і в валидаторе у зв'язку з тим, що це стає повсюдною практикою):



Валідатор Google видає продуктові помилки:



Validator.nu попереджає, що не можна використовувати атрибут content з нею, і пропонує подивитися, які атрибути можна використовувати:



Structured Data Linter, так само як і валідатор Яндекса, ігнорує content і попереджає про неправильне форматі часу:



Як правильно? Ми теж задаємося цим питанням. До недавніх пір ми вважали, що не повинні ігнорувати вимоги специфікації мікроданих. Але в зв'язку з тим, що у прикладах документації Schema.org така поведінка часто зустрічається, ми збираємося більш м'яко перевіряти такі випадки в валидаторе і використовувати дані з атрибута content у пошуку.

2. Стаття з розміткою Open Graph і Applinks.

Open Graph – давно відома всім розмітка, допомагає налаштувати відображення посилань в соціальних мережах, а Applinks – набирає популярність стандарт для міжплатформної зв'язку додатків. Давайте подивимося, наскільки добре з ним знайомі валідатори.

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



Валідатор Google показує тільки розмітку Applinks, без Open Graph та іншої розмітки. При цьому помилок немає і префікс al розпізнається як префікс за замовчуванням:



Structured Data Linter не розгортає RDFa, попереджає про HTML-помилки і про некоректну тип даних для og:url:



Open Graph Object Debugger попереджає про vk:app_id. Мабуть, про нього не знає з причини своєї закордонної природи:



А також розпізнає Applinks:



Validator.nu при перевірці цієї сторінки не видає ніяких результатів.

Як правильно? За правилами всі префікси, які не визначені в специфікації RDFa, повинні бути явно вказано атрибутом prefix. Але, як і у випадку з атрибутом content, практика не завжди узгоджується з теорією. І багато споживачі розмітки, наприклад Vk.com не вимагають явної вказівки на префікс. Тому нещодавно ми стали вважати деякі найбільш популярні префікси (vk, fb, twitter та деякі інші) префіксами за замовчуванням і перестали попереджати про них. Інші (наприклад, al) ми поки не додали в список префіксів за замовчуванням і очікуємо від вебмайстрів їх явного визначення. У будь-якому випадку ми рекомендуємо явно вказувати всі префікси, які ви використовуєте на своїй сторінці.

3. Розмітка JSON-LD з контекстом, відмінним від Schema.org.

Приклад розмітки:

{
"@context": "http://asjsonld.mybluemix.net",
"@type": "Post",
"actor": {
"@type": "Person",
"@id": "acct:sally@example.org",
"displayName": "Sally"
},
"object": {
"@type": "Note",
"content": "This is a simple note"
},
"published": "2015-01-25T12:34:56Z"
}

Яндекс.Валідатор розгортає контекст:



Валідатор Google підставляє example.com замість контексту:



JSON-LD Playground розбирає так само, як і Яндекс.Валідатор:



Інші валідатори ніяк не розбирають подібний приклад. Здається, тут очевидний кращий результат перевірки.

4. Приклад з JSON-LD і порожнім контекстом.

Приклад розмітки:

< script type="application/ld+json">
{
"@context": {
"name": "",
"description": "http://schema.org/description",
"image": {
"@id": "http://schema.org/image",
"@type": "@id"
}
},
"@type": "Article",
"author": "John Doe",
"interactionCount": [
"UserTweets:1203",
"UserComments:78"
],
"name": "How to Tie a Reef Knot"
}
</script>

JSON-LD Playground попереджає про порожньому контексті:



Яндекс Валідатор теж попереджає про неможливість розгорнути такий контекст:



Валідатор від Google замість контексту підставляє www.example.com і помилок не бачить:



Як правильно? Здається, чесніше всіх тут JSON-LD Playground. Ми подивилися на них в процесі написання цієї статті і теж почали показувати аналогічне попередження.

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

А якщо вам потрібна автоматизація перевірки, ласкаво просимо в ряди користувачів API. Вже зараз API валідатора використовується різними проектами. Насамперед це великі сайти з великою кількістю сторінок, які використовують API для автоматичної перевірки розмітки (більша частина якої – товарна). Крім того, сервіс, відслідковує стан сайту з точки зору оптимізації, за допомогою API виводить інформацію про наявності і правильності мікророзмітки.

Взагалі за допомогою API валідатора мікророзмітки можна:
  • автоматизувати перевірку мікророзмітки на великій кількості сторінок;
  • розробляти плагіни для різних CMS;
  • витягувати структуровані дані із сайтів для використання у своїх проектах.

У API є ті ж плюшки, які є в нашому звичайному валидаторе:
  1. Валідатор перевіряє всі помилки, які є в специфікації базових стандартів: Microdata, RDFa і JSON-LD. JSON-LD вперше почав перевірятися у травні 2014 року, до цього ні в одному з валідаторів від пошукових систем цей стандарт не підтримувався.
  2. Валідатор не лише повідомляє про помилки стандарту, але і про продуктових помилки. Найчастіше веб-майстри додають розмітку для того, щоб з її допомогою брати участь у будь-яких партнерській програмі. Тому наш валідатор повідомляє, якщо розмітка не відповідає документації який-небудь партнерської програми:
  3. Валідатор дуже строго перевіряє на відповідність специфікаціям, але якщо якісь поправки починають використовуватися повсюдно, ми йдемо від строгості назустріч користувачам. Наприклад, нещодавно ми вирішили не вказувати на використання атрибута content у тегах, відмінних від meta, так як це стало широко використовуватися в Schema.org. Також в Open Graph стали приймати без явної вказівки найбільш уживані префікси: fb, og і vk. Такі приклади ми розібрали вище.
До речі про специфікації: при розробці API ми виявили цікавий факт, який показав, що самі стандарти не завжди їм відповідають.

Мова про самому популярному сьогодні словника, який використовується в синтаксисі RDFa – Open Graph. Величезну популярність він набрав з двох основних причин: очевидна користь від застосування для управління зовнішнім виглядом посилань в соціальних мережах і простота впровадження. Простота впровадження досягається багато в чому за рахунок того, що Open Graph рекомендують розміщувати розмітку в блоці head набором тегів meta. Але це накладає певні обмеження. Одне з яких – реалізація вкладеності і масивів. У класичному RDFa вкладеність визначається на підставі ієрархії HTML-тегів. При цьому порядок проходження властивостей RDFa ігнорується. В структуру HTML-тегів реалізувати не можна, тому вкладеність у Open Graph реалізована незвичайним чином. Якщо потрібно вказати вкладені властивості, їх вказують через двокрапку після батьківських. Наприклад, url зображення (og:image) задається з допомогою og:image:url. Такі властивості в специфікації називаються структурованими. Якщо ви хочете задати масив структурованих властивостей, потрібно просто вказати їх в правильному порядку. Наприклад, у прикладі наведено три зображення. Перше має ширину 300 та висоту 300, про розміри другого нічого не сказано, а третій має висоту 1000.

<meta property="og:image" content="http://example.com/rock.jpg" />
<meta property="og:image:width" content="300" />
<meta property="og:image:height" content="300" />
<meta property="og:image" content="http://example.com/rock2.jpg" />
<meta property="og:image" content="http://example.com/rock3.jpg" />
<meta property="og:image:height" content="1000" />

Для API версії 1.0 ми допрацьовували парсер RDFa, щоб він повністю відповідав офіційної специфікації (раніше деякі складні випадки оброблялися не зовсім коректно). У процесі тестування ми виявили, що структуровані властивості обробляються дуже дивним чином. Виявилося, справа як раз в тому, що позиція в HTML-коді в RDFa абсолютно не важлива. Першою реакцією нашого розробника була пропозиція влаштувати страйк проти неправильного синтаксису в Open Graph і закликати їх до порядку. Але потім ми, звичайно, все полагодили.

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

Якщо у вас будуть питання з приводу роботи API валідатора, задавайте їх у коментарях або скористайтеся формою зворотного зв'язку. Чарівний ключ до API можна отримати тут.

Розмічайте свої сайти, перевіряйте розмітку, отримуйте красиві текстові фрагменти – і нехай все буде добре:)

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.