as title, I need to insert two json LD in my pages.
The requirement is:
1) insert in all pages a json LD relating to "#type": "Organization"
2) insert in product pages a json LD relating to "#type": "car"
I read the documentation but I did'nt find an example with two json LD in page.
So my question is: can I put two json LD in the same page?
thanks in advance
Yes, you can put multiple JSON-LD blocks into your page. Btw. you can use the Google Structured Data Testing Tool to test your markup.
Related
Issue with JSON LD CODE
To start with I am trying to use this code in weebly, buy using embed code option and then I click on the edit custom HTML and enter this code. However, after entering this nothing shows up as in the recipe is not shown on the page and a blank page is shown.
this code is picked on schema.org, for recipes.
Could anyone please help me out in what exactly went wrong. I really appreciate your assistance. FYI- I am new to this. I am trying to set up my own food website and and wanted to schema to for SEO improvement. Any other suggestions are welcome. Thanks in advance.
Please refer this link for the JSON-LD CODE. IT WILL BE AT THE END OF THE PAGE. https://schema.org/Recipe
When you add a JSON-LD block in the HTML, it doesn’t change anything visibly on the page. The script element is hidden by default in all browsers, and you typically want to keep it like that (users typically have no interest in your JSON-LD code).
To check if adding the JSON-LD worked correctly, open the page in a browser and check the source code of the page. You should see the script element with your JSON-LD.
You have to add the content (that should be visible to your users) regularly with HTML. The JSON-LD exists next to your content (duplicating the data like name, photo URL etc.), it doesn’t replace your content.
Summary
I'm implementing Schema.org JSON-LD structured Data into a React application that's very content heavy. I've got it all set up properly, but I'm questioning whether the way I set it up is best practice or acceptable?
The Question
I have tags minified throughout the body of my code within each element. I question this approach because it seems inefficient to have script tags all throughout the body rather than trying to consolidate them in the head tag under 1 big script tag with all the JSON-LD.
Example:
Let's say I have an eCommerce category with a lot of products on the page. Each product is contained in a <div>. Within each product div I'm providing a schema.org tag.
<div className="product-1-example">
<script type="application/ld+json">{"#context":"http://schema.org/", "#type":"Product","name":"3rd thing"}</script>
</div>
<div className="product-2-example">
<script type="application/ld+json">{"#context":"http://schema.org/", "#type":"Product","name":"3rd thing"}</script>
</div>
Here's a screenshot if the example above doesn't help of how the code is outputting:
Is this an OK approach? It just seems bizarre to me to have script tags like this all over the place? The problem I'm having as well is that because of my component structure, I can't really bundle up 1 nice tag at the top with all the consolidated structured data (i.e. grouping all the product JSON-LD data into 1). I could maybe build a script tag at the top with most of the data, and then fill out the rest with microdata?
The only way to really know is to test with the systems you want to read your markup.
There is no reason doing it that way is wrong. And I presume its done that way as its added at the point the system is processing those entities. Maybe neater to have each add their own script at the top instead of inline if possible.
I personally prefer to keep entities in their own scripts. If there is a bug in one, it will not stop the others from being parsed. You can have entities cross reference to each other by their ids.
Try not to mix with microdata. You can't cross reference ids between the two.
You probably also need to think about your entity structure. Typically you only want one main top level entity that represents what the page is about. Some other top level entities are fine as they are considered WebPage related, e.g. BreadcrumbList. But you don;t want to send mixed messages. e.g. if you mark up 10 products, which is the one the page is about? If you mark up a Product and Article. is the page an Article or about a Product?
I'm using Google's Structured Data Testing Tool to investigate why Google isn't finding any structured data on my page.
On first loading the URL (https://www.languagesunited.co.uk), I get an "Uncategorised Error":
JSON-LD Missing '}' or object member name.
Within the test tool source windows, I can making a small change to the page (add a space somewhere) and re-run the validation, and it validates (except for the url needing to be www.example.com for the tool to work).
I'd be grateful for any advice if anyone has had a similar problem.
After some experimenting with different options and getting different results with the test tool, the answer was very simple. There were some invalid whitespace characters in my structured data. Switching on the "show invisibles" option in my editor allowed me to replace these with spaces, and the data validated successfully.
Both are, most likely, bugs in the SDTT.
If you paste the markup (instead of letting it fetch the URL), the SDTT detects the structured data immediately (letting it fetch first and then editing something in the detected markup is the same idea). So there’s probably something wrong with their URL fetching.
For the issue with the example domain, see these questions:
Google structured data error: “All values provided for http://www.example.com/ must have the same domain.”
Google SDTT error: “All values provided for http://www.example.com/ must have the same domain.”
Schema.org and ContactPoint use with validation failure: “All values provided for http://www.example.com/ must have the same domain.” (on Webmasters SE)
I've just realized that Google Structured Data Validation Tool requires you (or us) to include context, In example:
'#context': 'https://schema.org',
(schema.org includes it in all their examples, i.e.:
Example encoded as JSON-LD in a HTML script tag.
<script type="application/ld+json">
{
"#context": "https://schema.org/",
"#type": "Person",
"name": "Christopher Froome",
"sponsor":
{
"#type": "Organization",
"name": "Sky",
"url": "http://www.skysports.com/"
}
}
</script>
If you do so you will start getting results again.
In the demo, it can analyze plain text
But in the API reference all REST APIs require url. And they don't seem to support analyze text directly. I tried to use text in a POST form anyway. But I got error.
{
"status": "ERROR",
"statusInfo": "invalid-url"
}
This is more a documentation issue, than a coding issue. In the documentation you will see three buttons. Select the Text one to get the documentation on Text calls.
I have been able to set up and search through some documents from a database using this tutorial:
a)
http://www.ibm.com/developerworks/opensource/library/os-xapianomega/index.html?cmp=dw&cpb=dwope&ct=dwnew&cr=dwnen&ccy=zz&csr=110410
The data field is added to every document in the indexing process started with this bash call:
$ omindex --db info --url information /mnt/data0/Information
The call indexes all the files in the dir at /mnt/data0/Information and saves it at a database named
info. According to the last section in the documentation here:
http://xapian.org/docs/omega/overview.html
According to the above documentation, you can set the fields that go into the data field of a document by editing the OmegaScript Template but I have not been able to find this template anywhere. I am hoping I can get some guidance from someone who is familiar with editing an OmegaScript to set up the data field.
I ultimately want data to have the following fields:
sample
caption
type
The standard ones without the url field.
OmegaScript templates are used by omega to render search results (in its web interface), and are stored in the template_dir as mentioned in the IBM tutorial section on the Omega web interface. omindex will have created the fields you require — that documentation also mentions that the OmegaScript command you want to extract those fields is $field{}, which is documented along with all the OmegaScript commands.
So to just display the three fields you would want a fragment of OmegaScript something like:
$hitlist{
Sample: $field{sample}
Caption: $field{caption}
MIME type: $field{type}
}
(which isn't formatted as HTML, but has the advantage of being hopefully clearer as to what is happening).