OpenGraph або Schema.org?


81

Просто цікаво, чи ви, хлопці, віддаєте перевагу протоколу OpenGraph з наступною розміткою, як:

<meta property="og:title" content="The Rock" />
<meta property="og:type" content="movie" />
<meta property="og:url" content="http://www.imdb.com/title/tt0117500/" />

Або протокол Schema.org з

<div itemscope itemtype="http://schema.org/Product">
  <span itemprop="name">Kenmore White 17" Microwave</span>
  <img src="kenmore-microwave-17in.jpg" alt='Kenmore 17" Microwave' />
  <div itemprop="aggregateRating"
    itemscope itemprop="http://schema.org/AggregateRating">

Який із них слід інтегрувати, оскільки, на мою думку, необхідний лише 1? [насправді ви можете інтегрувати лише один або?]

Чесно кажучи, IMHO - я вважаю, що OpenGraph "менш нав'язливий" для загальної кодової бази - оскільки простіше реалізувати Часткові перегляди [за допомогою ASP.NET MVC], тоді як протокол Schema.org вимагає [принаймні на мій погляд] надривних надбудов HTML через ваш код?

Редагувати: Здається, я в підсумку інтегрував обидва - не впевнений, чи дозволено це, але документація на Schema.org незрозуміла. Примітно, що це посилання не надає багато інформації

З: Як schema.org пов’язаний із Facebook Open Graph?
Facebook Open Graph добре виконує свою мету, але не надає детальної інформації, необхідної пошуковим системам для покращення взаємодії з користувачем.

Одна веб-сторінка може мати багато компонентів, і вона може говорити про більше ніж одне. Якщо пошукові системи розуміють різні компоненти сторінки, ми можемо покращити подання даних. Навіть якщо ви розмічаєте свій вміст за допомогою протоколу Facebook Open Graph, schema.org надає механізм надання більш детальної інформації про певні сутності на сторінці.
Наприклад, сторінка про групу може містити будь-яке або все наступне:

  • Список альбомів
  • Ціна за кожен альбом
  • Список пісень для кожного альбому, а також посилання на зразки кожної пісні
  • Список майбутніх шоу Bios учасників групи

Тому я припускаю, що вони сумісні разом.


Наш сайт має OG та мікроформати. Поки я зараз переходжу з мікроформатів на schema.org, ми також точно збережемо теги OG.
Девід Харкнесс,

1
"Протокол Schema.org вимагає надмірних надбудов HTML" - Це неправда, шукайте JSON-LD
BlueRaja - Danny Pflughoeft

Відповіді:


85

Отже, для початку з декількох кліше і зіпсованих метафор - ми трохи говоримо про яблука та апельсини, порівнюючи OG та Schema.org, а коли йдеться про ці метадані, це коні для курсів.

Правильна відповідь залежить від вашого наміру - додавання метаданих на вашу сторінку. Що ви сподіваєтесь отримати? Яка перемога для вас тут? Різні форми метаданих призначені для дещо інших цілей.

Google чітко дав зрозуміти, що відходить від фокусу на мікроформати та фокусується на Schema.org, щоб створити результати з розширеними даними для пошуку. Якщо ви хочете оптимізувати для Google, Bing та інших пошукових систем, додайте розмітку Schema.org. Це напрямок, в який зайшов HTML5.

Розмітка OG Facebook повинна бути додана, якщо ви хочете отримати вигоду від перетворення вмісту на соціальний об’єкт та увімкнення його багатоточкового підключення до соціального графіка, що є всесвітом Facebook.

З мого досвіду, більшість людей прагнуть виграти від обох підходів - робіть, наскільки це можливо, у рейтингу пошуку та збільшуйте охоплення та розподіл через соціальні канали. Тож, IMHO, мабуть, краще бути якомога ретельнішим, додаючи розмітку Schema.org там, де вона відповідає вашому вмісту, та використовувати метадані Open Graph. Вони роблять дещо різні, але доповнюють речі.


9
Я щойно додав інформацію schema.org на свої сторінки продуктів, але вони також вже мають og:imageрядок для facebook / pinterest. Коли я тестую результат в інструменті тестування розширених фрагментів Google, він розпізнає лише зображення og:. Чи використовує Google лише один (перший, що знаходить) протокол для сторінки?
Родольфо

25

Тут ми говоримо про два окремі поняття: синтаксис та словниковий запас .

Протокол Open Graph та Schema.org - це словники . Іншими словниками є, наприклад, Dublin Core , FOAF та SIOC .

Ці словникові запаси, як правило, не пов’язані з певним синтаксисом. Якщо ви хочете описати свій вміст у документах HTML таким словниковим запасом, ви можете використовувати синтаксис RDFa та / або мікродані .

Який із них слід інтегрувати, оскільки, на мою думку, необхідний лише 1? [насправді ви можете інтегрувати лише один або?]

У вашому першому прикладі використовується Open Graph Protocol (= лексика) з RDFa (= синтаксис). У другому прикладі використовується Schema.org (= словниковий запас) із мікроданими (= синтаксис).

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

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

Але якщо ви хочете розмітити свій вміст за допомогою семантичних метаданих, не маючи на увазі конкретного випадку використання, ви можете дотримуватися одного синтаксису та використовувати той словник, який відповідає вашому вмісту. Особисто я б вибрав RDFa ( Lite ). Він заснований на RDF , який також працює з іншими форматами, крім HTML. Це рекомендація W3C (мікродані - ні). І більшість словників, які ви знайдете, визначено у RDF (S). Дивіться мою відповідь про майбутнє RDFa та мікроданих .


12

Їх можна безпечно використовувати разом. В даний час ці два зусилля використовують різні синтаксиси для кодування даних у HTML (W3C RDFa або Microdata), але на W3C ведуться активні дискусії щодо можливого зближення цих конструкцій. Або принаймні більшої сумісності. Чи відбудеться також зближення на рівні словникового запасу між Schema.org та OGP, чи службами, які споживають обидва, ще належить з’ясувати. Але тим часом вони обидва додають вартість і їх можна сміливо поєднувати.


11

Все залежить від того, чи намагаєтесь ви розмітити свій веб-сайт для соціального світу (facebook) або пошукових систем. Рекомендуються обидва варіанти, але якщо у вас є час лише на один, тоді визначте маркетинговий фокус компанії. OGP є величезним для facebook, але не має жодної потреби в SEO. Seo повністю покладається на мікро-дані і є способом правильного створення html5.

HTML5Doctor на мікроданих http://html5doctor.com/microdata/

Google говорить про розмітку: http://www.google.com/support/webmasters/bin/answer.py?answer=1211158

Бінг говорить про розмітку: http://onlinehelp.microsoft.com/en-us/bing/hh207238.aspx


Оновлення

Для тих, хто знайшов цю відповідь, багато чого змінилося з моменту її першого розміщення. Schema.org широко використовується усіма основними пошуковими системами, а потім і деякими, але розмітка тепер краща за JSON-LD. Чудова стаття від SEO Skeptic, в якій викладено зміни, внесені Google.

Структуровані дані Google надають документацію у форматі JSON-LD і дуже вітаються, хоча RDFa та мікродані все ще частково підтримуються.

JSON-LD слід використовувати разом із будь-якими соціальними каналами, на які ви намагаєтесь націлити OGP для Facebook, Twitter Cards для Twitter тощо.


"Оскільки Facebook підключений до Bing Maps; можна було б припустити, що OGP застаріє". Це великий стрибок логіки. Facebook все ще дуже незалежний від Bing та MS.
mahemoff

1
Це було в той час, коли напрямок здавалося іншим. Дякую за повернення моєї уваги до цього.
Matthew Sprankle

3

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

<html prefix="og: http://ogp.me/ns#">

в голівці кожної сторінки, яка має ogp.

Ви можете перевірити, чи працює ogp або схема, використовуючи інструмент тестування розширених фрагментів

http://www.google.com/webmasters/tools/richsnippets

У випадку зі схемою ви можете перевірити за допомогою SDTT: інструмент тестування структурованих даних

https://search.google.com/structured-data/testing-tool


2

Чому б не використовувати json-ld для розмітки? Я думаю про реалізацію розмітки на основі json-ld schema.org. Таким чином це не буде нав'язливим. Мій привид блог використовує це. Не знаю, чи він ще добре підтримується пошуковими системами. Але всі приклади на schema.org тепер включають реалізацію для json-ld. дивіться тут http://schema.org/WebPage

І всі мої програми використовують твіттери, теги fb opengraph та теги мікроформатів, такі як rel та структуровані метадані schema.org. І мені здається, що реалізація метаданих schema.org є найбільш корисною. Тож заміна цього останнього біта на json-ld і підтримка чистоти коду - це приємно. Забагато тегів, і рекомендується тримати ваш html маленьким;)


0

RDFa og служить уніфікованим способом кращого розпізнавання вмісту REST для розгляду при вбудовуванні в контейнери, не передбачені на момент створення. Якщо контейнер заздалегідь визначений як результати пошуку, то мікродані schema.org добре зрозумілі пошуковим ботам. За презентацію og відповідає видавець контейнера, і така свобода якості може імпровізувати ранжування пошуку, тоді як schema.org імпровізує зрозумілість результатів пошуку в контексті задуму творця вмісту. Словники зазвичай ігноруються при використанні з конкуруючим методом семантичної розмітки, тому найкраще використовувати мікродані лише з schema.org та og лише з RDFa. І мікродані, і RDFa можуть співіснувати в одному документі.


-1

rdfa (opengraph) та мікродані (схема) не можна використовувати на одній і тій же сторінці html

"3) Ми продовжуватимемо підтримувати наші існуючі формати розмітки розширених фрагментів. Якщо ви вже зробили розмітку на своїх сторінках за допомогою мікроформатів або RDFa, ми будемо продовжувати її підтримувати. Одне застереження, на яке слід звернути увагу: хоча це нормально використовуйте нову розмітку schema.org або продовжуйте використовувати існуючі мікроформати або розмітку RDFa, вам слід уникати змішування форматів разом на одній веб-сторінці, оскільки це може заплутати наші парсери. "

SRC: http://googlewebmastercentral.blogspot.in/2011/06/introducing-schemaorg-search-engines.html

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.