The @id keyword allows you to give a node a URI. This URI identifies the node.
See Node Identifiers in the JSON-LD spec.
(The equivalent in Microdata is the itemid attribute, and the equivalent in RDFa Lite is the resource attribute.)
Why are identifiers useful?
You can reference a node instead of repeating it (see my example).
Other authors can do the ...
schema.org: Article, BlogPosting
If something is a schema:BlogPosting, it is an schema:Article, too, isn't it? As schema:BlogPosting is a more specific schema:Article:
More specific types
So you have an schema:Article, and now you may decide if one of these more specific types applies to your content. If not, stay ...
The mainEntityOfPage property is used to give the URL of a page on which the thing is the main entity. It might become clearer if you look at the inverse property mainEntity: this gives the main entity for a page (see an example).
For example, for a web page that contains a single blog post, you could provide one of these:
BlogPosting → mainEntityOfPage → ...
Something like this, though of course other properties are required for this to meet Google's requirements for article features in search results.
<div itemscope itemtype="http://schema.org/Article">
<!-- blah blah -->
<div itemprop="publisher" itemscope itemtype="https://schema.org/Organization">
<div itemprop="logo" itemscope ...
schema.org/BlogPosting image permits ImageObject and URL, however Google only permits ImageObject, hence the error. The intended markup is:
<!-- my code -->
<div itemprop="image" itemscope itemtype="http://schema.org/ImageObject">
<img src="image.jpg" itemprop="url">
Another discrepancy is schema.org/...
Turns out, because BlogPosting is one of the types supported by Google as a possible Rich Snippet, they apply more validation:
Google Search Documentation Guidelines for Articles
This requires an Article's Publisher's logo to be of type ImageObject and have a width and height in pixels. BlogPosting is a subtype of Article.
This updated snippet validates ...
The script element can be used for two things:
And for data, the spec defines:
When used to include data blocks, the data must be embedded inline […]
So you may use the src attribute only for scripts, not for data.
→ As JSON-LD is data, you have to inline it.
While linking a JSON-LD file is possible with the link element, ...
A brilliant and helpful answer by @Arth above.
To complement the answer above (not compete with it), here is the same Structured Data using the same schema.org vocabulary, but this time in JSON-LD:
There is this: https://schema.org/QAPage
and these: https://schema.org/Question + https://schema.org/Answer
Which you can indeed use …
and validate: https://search.google.com/structured-data/testing-tool
To build your own FAQ page.
<div itemscope itemtype="http://schema.org/Question">
<h1 itemprop="text">What does FAQ stand for?</h1>...
Schema.org does not require any properties, so having a BlogPosting without an image property is totally fine. (And, other than omitting the property, there is no way to denote that you don’t have an image.)
(I’d even guess that not providing an image would be the norm, as the image property is not for just any image that is contained in the blog post, but ...
The vocabulary Schema.org has the types Question and Answer (added in version 1.1 from 2014-04-04).
This is not only for Q&A sites, but also for FAQs, as Question explicitly mentions (bold emphasis mine):
A specific question - e.g. from a user seeking answers online, or collected in a Frequently Asked Questions (FAQ) document.
Tool from Yandex
The "Structured data validator" supports JSON-LD.
Alexander Shubin (working for Yandex) wrote:
Pls, take into account that in order to check JSON-LD you need to put it in tag (since this is how it should be embedded into html).
"@type" : "...
Google recommends using microdata, but it does support three formats: microdata, microformats, and RDFa. A big reason to choose microdata would be that the examples that Google gives on it's website and those on schema.org are in the microdata format.
Here is a site that has a huge table of the various advantages and disadvantages of the three formats. ...
JSON-LD doesn’t care. Which makes sense, because the data is the same, no matter from where in the document it gets extracted.
From the perspective of HTML, you should only include it in the head if the JSON-LD is about your web page or about what your web page represents, because the head element is defined to contain metadata for the document. But it’s ...
your code contains error, thats why two authors aren't recognized. If you have more then one author, you should add them as list without entity duplication. Here the correct code:
Reading the following link from Google Developers - Data types - Local Business in the Local business properties section you have:
[...] The ID should be stable and unchanging over time. Google Search treats the URL as an opaque string and it does not have to be a working link. If the business has multiple locations, make sure the @id is unique for each ...
What is known (= what search engines document)
It can enable features in the search engine interface.
Providing certain structured data can give you the chance to get a certain user-visible feature. This can be the case for your page, for your whole site, or for general information not coupled to a search result (e.g., in sidebars, in carousels etc.).
Microdata can only be used on HTML elements as defined by HTML5. According to HTML5, the svg element is not in the HTML namespace. WHATWG’s HTML spec explicitly mentions that Microdata doesn’t work for svg (quoted on 2014-01-02):
Currently, the itemscope, itemprop, and other microdata attributes are only defined for HTML elements. This means that ...
A quick point on this. A site I work on recently got a manual action penalty from Google for having organization JSON-LD markup across every single page on their domain. It didn't affect rankings of course but would have impacted all other structured data until resolved. It's one of the minor pitfalls of JSON-LD; that you can put it anywhere and if Google ...
Google Search doesn’t seem to support Rich Snippets for homepages.
This is currently not documented, but confirmed by the Google employee @methode (on SO):
We (Google) don't accept rich snippets for homepages; rich snippet annotations should be placed on leaf pages.
In JSON-LD (instead of Microdata/RDFa) you have to repeat the property and its value for each node.
Instead of using a separate script element for each node, you could also use a single script element that contains all your nodes as value of @graph. That way you only have to define the @context (and possibly custom properties) one time.
The structured data of the website social profiles are correct.
From the tests I made it doesn't have to do with the fact that it's a local business, but with the google search preferences used when performing the search or a problem when Google generates the profile box.
For https://www.google.com/search?q=dispute+bills it shows the full results:
But then ...
As closetnoc suggests in comments, the 50,000 URL limit for sitemaps refers to the number of URLs in the sitemap file itself. ie. the number of <loc> elements. This is an individual sitemap limit, not a website limit. (The file must also be no larger than 50MB*1 (uncompressed) - so whichever comes first.)
(*1 Previously 10MB.)
Then you can also have ...
It should be fine to use different syntaxes on the same page.
It has one drawback, though: If you want to connect entities specified in different syntaxes, you can’t nest them. You have to use URIs instead. (But note that not necessarily all consumers of the data follow such URI references.)
Example showing nesting vs. referencing
You can connect a ...
Microdata doesn’t have a concept of "site"; each page is separate. So you should include all relevant metadata on every page where the corresponding content is visible (but only one time per page).
Think of a browser-add on that displays all Microdata name-value pairs in a sidebar: why should the user have to visit a specific page of your site to see the ...
If it has a price and/or if it can be booked, you have to use an Offer item.
The item that gets offered could be a Product (this is not only for tangible things!), a Service, an Event, or a CreativeWork.
I think in your case Event might make sense, but this ultimately depends on your specific case (your understanding of the tour/travel packages) and which ...
You can use both properties (headline and name) for the same content.
<h1 itemprop="headline name">Title of the post</h1>
Google requires headline for their Articles search feature (and it doesn’t seem to use name for anything else). If you don’t care about this feature, you could of course ignore the error.
My related answers on Stack ...
You should use CollectionPage instead of WebPage, not in addition to it. CollectionPage is a more specific WebPage.
It seems that significantLink (for URL values) as well as hasPart (for CreativeWork values) could be used. But I think hasPart is the better choice here, because significantLink could also be used for pages that don’t belong to the category (...
I think each value should represent a single area.
If you were using the more expressive AdministrativeArea/GeoShape/Place values, you would (by definition) use one type per area (a Place always represents a single place etc.), so there is no reason to assume that a Text value would be handled in a different manner. Furthermore, the definition of areaServed ...