Semantics of relative URLs in schema.org Breadcrumbs in JSON-LD

Question

The schema.org website gives an example of a breadcrumb represented in 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>

Most of it is clear to me but I'm not absolutely certain about the semantics of the links provided in this example.

What I find confusing are the @id properties. Their values are URLs and it looks like these should lead to actual web pages linked to by the breadcrumb items. However, the name of the property suggests that the URLs might actually point to concept identifiers in some ontology. Which is it?

The Without Markup tab contains an unannotated piece of HTML suggesting that my first guess is correct and the URLs actually lead to web pages.

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

Is this the case and is it okay to use relative URLs in this context?

<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>

Answer 1

I had the same question and end up doing research which I documented on https://sergeyski.com/relative-urls-in-structured-data/. Key part is this:

If you paste markup directly into google validator and there is a relative path - validator doesn't know which domain it belongs to and just appends its own domain (https://search.google.com). Once you deploy changes and test with real url you'll see that validator will append correct domain, so you can definitely use relative urls in structured data.

Answer 2

Is this the case and is it okay to use relative URLs in this context?

Over at GitLab, we were confused by this too (see relevant issue) since Google's Rich Results Test blows up with relative URL's, but there are historic examples of relative URL's working in production.

So, we tried it out. We pushed some json+ld with relative URL's to production and one of our engineers received an alert that the id field was invalid.

Short answer - no it is not okay to use relative URL's for json+ld (but is okay to have relative URL's for markup, see this comment) and Google clearly expects absolute URL's. If it happens to work now, there's no guarantee that it will in the future.

Answer 3

All URLs should be absolute. You can use the official testing tool https://search.google.com/structured-data/testing-tool/u/0/ that is going to give an error in relative URLs.