Семантика относительных URL-адресов в schema.org Breadcrumbs в JSON-LD

На веб-сайте schema.org приведен пример навигационной цепочки, представленной в формате JSON-LD.

<script type="application/ld+json">
{
 "@context": "http://schema.org",
 "@type": "BreadcrumbList",
 "itemListElement":
 [
  {
   "@type": "ListItem",
   "position": 1,
   "item":
   {
    "@id": "https://example.com/dresses",
    "name": "Dresses"
    }
  },
  {
   "@type": "ListItem",
  "position": 2,
  "item":
   {
     "@id": "https://example.com/dresses/real",
     "name": "Real Dresses"
   }
  }
 ]
}
</script>

Большая часть мне ясна, но я не совсем уверен в семантике ссылок, представленных в этом примере.

Что меня смущает, так это свойства @id. Их значения являются URL-адресами, и похоже, что они должны вести к реальным веб-страницам, на которые ссылаются элементы хлебной крошки. Однако имя свойства предполагает, что URL-адреса могут на самом деле указывать на идентификаторы понятий в некоторой онтологии. Что это?

Вкладка Без разметки содержит неаннотированный фрагмент HTML, предполагающий, что моя первая догадка верна, и URL-адреса действительно ведут на веб-страницы.

<ol>
  <li>
    <a href="https://example.com/dresses">Dresses</a>
  </li>
  <li>
    <a href="https://example.com/dresses/real">Real Dresses</a>
  </li>
</ol>

Так ли это и можно ли использовать относительные URL в этом контексте?

<script type="application/ld+json">
{
 "@context": "http://schema.org",
 "@type": "BreadcrumbList",
 "itemListElement":
 [
  {
   "@type": "ListItem",
   "position": 1,
   "item":
   {
    "@id": "https://dresses.com/dresses",
    "name": "Dresses"
    }
  },
  {
   "@type": "ListItem",
  "position": 2,
  "item":
   {
     "@id": "/dresses/cocktail",
     "name": "Cocktail Dresses"
   }
  }
 ]
}
</script>

person toniedzwiedz    schedule 18.07.2016    source источник


Ответы (4)


Так ли это и можно ли использовать относительные URL-адреса в этом контексте?

В GitLab нас это тоже смутило (см. соответствующий вопрос ), так как тест расширенных результатов Google не работает с относительными URL-адресами, но есть исторические примеры работы относительных URL в продакшене.

Итак, мы попробовали. Мы отправили несколько json+ld с относительными URL-адресами в производство, и один из наших инженеров получил предупреждение о том, что поле идентификатора недействительно.

Краткий ответ: нет, нельзя использовать относительные URL-адреса для json+ld (но можно использовать относительные URL-адреса для разметки, см. этот комментарий), и Google явно ожидает абсолютных URL-адресов. Если это работает сейчас, нет никакой гарантии, что это будет работать в будущем.

person souldzin    schedule 14.11.2020
comment
Привет, спасибо, что указали на это. Правильно ли я понимаю, что GitLab изменился с относительных URL-адресов на абсолютные, и в этот момент Google начал собирать результаты? Это более убедительно, чем валидатор, не выдающий ошибки. Google также может быть более подробным в своих документах, если это необходимо. - person toniedzwiedz; 14.11.2020
comment
@toniedzwiedz, да, ты правильно понял. Изначально у нас не было структурированных данных для хлебных крошек, но недавно мы провели эксперимент, который доказал нам, что требуются абсолютные URL-адреса. Усвоенный урок: постарайтесь не отклоняться слишком далеко от примеров :| - person souldzin; 15.11.2020

У меня был тот же вопрос, и в итоге я провел исследование, которое я задокументировал на https://sergeyski.com/relative-urls-in-structured-data/. Ключевая часть заключается в следующем:

Если вы вставите разметку прямо в валидатор Google и там будет относительный путь - валидатор не знает, какому домену он принадлежит, и просто добавляет свой собственный домен (https://search.google.com). После того, как вы внесете изменения и протестируете с реальным URL-адресом, вы увидите, что валидатор добавит правильный домен, поэтому вы определенно можете использовать относительные URL-адреса в структурированных данных.

person sergeyski.com    schedule 02.03.2019
comment
Берегись! Этот ответ кажется уже не точным. По нашему опыту мы получили ошибки даже в развернутой среде с использованием относительных URL-адресов. Абсолютный URL-адрес кажется ожидаемым стандартом, поэтому, вероятно, лучше придерживаться его. - person souldzin; 14.11.2020
comment
@souldzin Я только что дважды проверил тест из статьи, и я не получаю ошибок как при использовании старого инструмента тестирования структуры, так и при использовании нового инструмента тестирования расширенных результатов. - person sergeyski.com; 14.11.2020
comment
Кажется, я не могу найти тест статьи с использованием json-ld и/или со структурированными данными, требующими @id, так что, может быть, этот контекст важен? - person souldzin; 14.11.2020
comment
@souldzin Я думаю, вы правы насчет контекста, json-ld действительно не работает так же хорошо, как структурированная разметка, в которой нет этой проблемы - вы можете увидеть сравнение, используя silver-picayune-cork.glitch.me. Нет ошибок для относительных URL-адресов в разметке по сравнению с json-ld. Это заставляет меня задаться вопросом, используется ли js для синтаксического анализа разметки, поскольку, когда вы используете document.links[0].href, а href является относительным URL-адресом, вы все равно получаете абсолютный ответ. Что ж, я буду придерживаться структурированной разметки, когда это возможно. Бонус: похоже, вы можете генерировать json-ld на стороне клиента, поэтому добавить базовый URL-адрес очень просто — используйте это на свой страх и риск :) - person sergeyski.com; 18.11.2020

Все URL должны быть абсолютными. Вы можете использовать официальный инструмент тестирования https://search.google.com/structured-data/testing-tool/u/0/, который выдаст ошибку в относительных URL-адресах.

person Christian    schedule 26.04.2018
comment
Этого не было, когда я задавал вопрос. Спасибо за ваш ответ, я посмотрю на него, когда у меня будет минутка. - person toniedzwiedz; 26.04.2018
comment
На момент написания этого комментария инструмент структурированных данных Google не выдавал ошибку для относительных URL-адресов. Однако перед ними добавляется домен search.google.com. - person sergeyski.com; 02.03.2019
comment
В дополнение к моему предыдущему комментарию я вижу, что инструмент структурированной разметки показывает ошибки для изображений с относительными URL-адресами для типа статьи. Это так сбивает с толку. - person sergeyski.com; 02.03.2019

По моему должно быть нормально.

Проверьте: https://search.google.com/structured-data/testing-tool

Пример тестовых данных с относительными URL-адресами:

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [{
    "@type": "ListItem",
    "position": 1,
    "item": {
      "@id": "http://www.example.com/",
      "name": "Home"
    }
  },{
    "@type": "ListItem",
    "position": 2,
    "item": {
      "@id": "/furniture/",
      "name": "Furniture"
    }
  },{
    "@type": "ListItem",
    "position": 3,
    "item": {
      "@id": "/furniture/kitchen/",
      "name": "Kitchen"
    }
  }]
}
</script>

Обновить Только что проверил еще раз: О, Google, добавьте домен http://www.example.com/ для элементов без абсолютного URL-адреса в выводе инструмента тестирования структурных данных. Так что отбросьте мое сообщение, я не уверен, поддерживаются ли относительные пути, вместо этого используйте абсолютные.

person rzasap    schedule 18.07.2016
comment
Не уверен, что вы имеете в виду, говоря, что первая ссылка должна быть абсолютной. Инструмент не возвращает ошибок или предупреждений, когда все URL-адреса являются относительными. - person toniedzwiedz; 18.07.2016
comment
Игнорировать мое сообщение о первой ссылке - person rzasap; 18.07.2016
comment
@rzasap: нет проблем, что Google отображает пример домена для относительных URL-адресов; это обычная практика в подобных инструментах (думаю, они делают это, чтобы сообщить своим пользователям, что значение действительно интерпретируется как URL, а не просто как текстовая строка). - person unor; 18.07.2016
comment
@rzasap В конце концов я все равно вынес все URL-адреса, так как мне пришлось переписать пути. Я по-прежнему думаю, что относительные значения в порядке, поскольку валидатор не считает это ошибкой, и я ожидаю, что домен, из которого обслуживается документ JSON-LD, будет считаться хостом. - person toniedzwiedz; 02.08.2016