: Why don't search engines support JSON-LD + Schema.org as seperated endpoints via rel="alternate" or script src? So the whole idea of JSON revolves around object->arrays presented in a simple text
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 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: 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 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 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?
More posts by @Si4351233
1 Comments
Sorted by latest first Latest Oldest Best
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..
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.