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
/jsonto the URL renders this kind of LD API object response instead of the full templated page. So the route would be:
The full templated page for each product includes a
<head>that points to its
alternateLD endpoint described above. This is the same way
ATOMfeeds 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
sameAsand something like
potentialActionpointing back to the full templated version of the page (the first bullet point above). This is similar to how
alternateworks in ATOM feeds themselves...making a circle of alternates.
The ATOM feed also includes these alternates, exposing the
/jsonendpoints. 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?