7

So the whole idea of JSON revolves around object->arrays presented in a simple text format. The LD variant is no different. When combined with Schema.org it turns into a flexible display API that many things can consume, very similar to legacy feeds. Unlike feeds though, it's primarily consumed by search engines as inline script data on the page, and that makes things tedious and annoying from an independent API or automation perspective.

So, why do search engines want JSON-LD + Schema.org to go against the API grain in regards to forcing sites to use inline data? Why must we make our code that much larger with duplicate data such as main content for human viewing and then separately defined again within the JSON-LD script(s)? What I mean is, if LD is intended for semantic consumption, why can't we put the LD objects into a separate page, route, or file? The data duplication in source drives me nuts, especially for long content!

As it stands now, no search engine validators understand the following use case:

  • Example.com has a full templated page for each product, with a url like https://www.example.com/this-product-name. This page is validated HTML with all the bells and whistles. It does not include any Schema.org markup within the templated view.

  • Example.com also has a JSON-LD generation function which comes right from a controller, and makes an API endpoint for each product. All that is returned is the LD object->arrays in JSON format...no template. This is ready for consumption and similar to the way to an XML feed works for aggregators. Adding /json to the URL renders this kind of LD API object response instead of the full templated page. So the route would be: https://www.example.com/this-product-name/json

  • The full templated page for each product includes a <link /> in <head> that points to its alternate LD endpoint described above. This is the same way ATOM feeds operate, pointing a visitor to the "alternate format for the data" which their feed readers consume. So the alternate for the LD would look like this: <link rel="alternate" type="application/ld+json" title="This Products Consumption API (JSON-LD + Schema.org)" href="https://www.example.com/this-product-name/json"/>

  • The JSON-LD response includes sameAs and something like potentialAction pointing back to the full templated version of the page (the first bullet point above). This is similar to how alternate works in ATOM feeds themselves...making a circle of alternates.

  • The ATOM feed also includes these alternates, exposing the /json endpoints. Basically there is a 3 (or more) way going on between templated page, JSON-LD endpoint, ATOM feed, etc. All the data is the same, it's just different methods of displaying consumption formats for different purposes.

  • Running https://www.example.com/this-product-name through the snippet test results in "no structured data found" even when including the path to the script src like <script type="application/ld+json" src="https://www.example.com/this-product-name/json"></script>. Running consumption endpoint https://www.example.com/this-product-name/json through results in correct validation.

So is it just the validation tool, or is there really no way to get the bots to understand the alternate assimilation? Is there any way I can get the JSON-LD off my templated page and into an alternate API route, like JSON spec itself does so well already? Am I missing some huge reason why search engines chose to require LD put exclusively inline instead of allowing sane-endpoint abilities?

Improve this question
4
  • 1
    Note that this is fine from the perspectives of Schema.org (the vocabulary) and JSON-LD (one of many syntaxes), and this or similar ways (e.g., with content negotiation) are often used for Linked Data. It’s "just" that the Schema.org sponsors (i.e., the search engines) don’t support it.
    – unor
    Commented Jul 23, 2015 at 14:30
  • 1
    @unor very good point(s). Would love to hear input from Google on why everything is inline only. I'm sure their bots would enjoy the JSON-LD endpoints too
    – dhaupin
    Commented Jul 23, 2015 at 21:51
  • 1
    @unor edited that to make the distinction.
    – dhaupin
    Commented Jul 23, 2015 at 22:00
  • Adding a comment in an attempt to bump this. It's been nearly 6 years. Things have changed. Schema.org is more comprehensive and Google supports more and more structured data formats and increasingly uses Page Speed as an important metric. Surely it makes sense to use the rel="alternate" syntax suggested so this data (JSON is a "data interchange format" according to Wikipedia) can be read separately to the markup intended for human consumption.
    – pmiddy
    Commented Feb 23, 2021 at 8:08

1 Answer 1

Reset to default
2

That answer is actually quite simple. Spiders retrieve a page and process that page and only that page. Links to other resources are queued for visiting by another spider. Search Engines ignore script tags that have a source. Javascript by design does NOT contain data, and search engines are hungry for data..

The main benefit over using json-ld over itemscope and itemprop is that you're markup itself is not cluttered with microdata.

If you don't want to include 'raw' data into your page, you should consider using RFDa schemas. Does schemas can be specified link the .

Personally I use MicroFormats where possible, because I find that the least intrusive of all microdata formats as those properties are disguised as CSS classes. Classis for which I actually assign styling..

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.