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 ...
Microdata extends HTML5 in a way that link and meta elements can be used in the body, if they contain an itemprop attribute.
If the itemprop attribute is present on link or meta, they are flow content and phrasing content. The link and meta elements may be used where phrasing content is expected if the itemprop attribute is present.
This extension is ...
Schema.org neither requires nor recommends specific image dimensions. For an ImageObject, you may specify the image’s height and width with the height and width properties.
Consumers of the data would have their own rules, if any at all.
In case of Google Search
For some Rich Snippets that use the image property, no dimensions are specified.
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/...
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 ...
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 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 → ...
The document that recommends JSON-LD is more recent and it clearly states that Google recommends using JSON-LD where possible (over Microdata) specifically for the following reasons:
"The markup does not have to be interleaved with the user-visible text, which makes nested data items easier to express, such as the Country of a PostalAddress of a MusicVenue ...
W3Schools does not set the industry standards on HTML coding. They are simply a 3rd party reference site that is not affiliated with the W3C in anyway. W3Schools and other sites are often wrong when using cutting edge coding technologies such as Schema and Responsive design. When using fairly new code your one stop shop should be W3C as set the compliance ...
The three big search engines, Google, Bing and Yahoo (and more recently, Yandex), have agreed to understand 1 single microdata vocabulary. This is Schema.org, which has examples of placement.
This formats your results as Rich Snippets, the search engine results which have pictures and fivestar ratings, etc, displayed on the search result page. While this ...
Typically, user agents wouldn’t dereference these URIs.
There should be absolutely no problem in using the Schema.org HTTP URIs on a HTTPS site. In fact, many other vocabularies (used for Microdata or RDFa) provide only HTTP URIs, so you have no choice there. I’d even say it’s bad practice to provide multiple vocabulary URIs for the same concept, as ...
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:
Both are solutions for semantically annotating your content, but in very different ways:
Microdata extends HTML5 (e.g., by introducing new attributes like itemprop), while Microformats only uses existing HTML mechanisms (like class and rel attributes).
With Microdata, you can use almost any vocabulary (a popular one is Schema.org), with Microformats you can ...
What the spec says
Yes, that behaviour is correct. Section 5.4 of the W3C Microdata spec describes which value gets used.
In most cases, the element’s content gets used as itemprop value, but in some cases, an attribute’s value gets used as itemprop value.
This is the case for these six attributes¹: content², src, href, data, value, datetime.
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. ...
You could use the itemref attribute.
From the Microdata (W3C Working Group Note) spec:
4.2 The basic syntax:
Properties that are not descendants of the element with the itemscope attribute can be associated with the item using the itemref attribute. This attribute takes a list of IDs of elements to crawl in addition to crawling the children of the ...
This should work because it still uses the logo and URL itemprops within the itemscope of 'Organisation' which is ultimately the markup it is looking for.
<div itemscope itemtype="http://schema.org/Organization">
<a itemprop="url" href="http://www.example.com/">
<img itemprop="logo" src="http://www.example.com/logo.png" />
These are no resources which get usually accessed by the browser but simply a fancy way to declare a name space, i.e. all SVG images share the same XML name space which is defined by the URL and same with xlink. This means you should treat any of these xmlns just as some kind of special string and leave them unchanged.
Your rich snippet data needs to be visible to users. From Google's rich snippet troubleshooting:
Is your marked-up content hidden from users?
In general, Google won't display any content in rich snippets that is not visible to human user. It can be tempting to add all the content relevant for a rich snippet in one place on the page, mark it up, and ...
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 ...
Including the current page in the breadcrumbs is not required by Google:
Each breadcrumb item should appear in order, with the first item
representing the top-level page, and the final item representing the
parent of the current page.
Therefore, it should not matter if it is marked up at all.
However, the effects of marking it up with everything ...
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 ...
Your plan of using meta data for microdata is not viable. Here is Google's FAQ about why it isn't showing your data in the search results:
Is your marked-up content hidden from users?
In general, Google won't display any content in rich snippets that is not visible to human user. Don't hide the content that you have marked up for rich snippets ...
Historically, Google said they ignored structured data which was not used to markup visible content.
Because your snippet shows both date published and date updated as visible on-page content but the Moz example shows date published as non-visible meta data, I'd try tweaking that and seeing if it works to get Google to show the last update date instead.
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:
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 ...
Yes, it's OK to have Schema Product Properties for multiple products on a page, as demonstrated here:
Schema.org Markup of a SERP / Product Listing
(And in the top example of this related question)
If Google's Structured Data Testing Tool displays each of the items under the Extracted structured data section with the correct data, as it does here (using ...
Your questions seem to be:
Can I specify itemprop="url" on li?
Can I specify itemprop="name" on a?
The answer to both of these questions is: No, you should not do that. Microdata defines special parsing rules for elements like a.
Schema.org’s url property expects a URL as value. Microdata defines that you have to use elements like a/area/link/etc. (...
Don’t use protocol-relative Schema.org URIs:
I wouldn’t expect all Microdata consumers to handle these URIs correctly (while it’s common for links or embedded resources, values of the itemtype attribute typically don’t get dereferenced).
They fail when a different protocol than HTTP/HTTPS is used (for example, file). It’s not just that the link is broken ...
What is the correct usage of using the brand schema from schema.org?
There is not one "correct usage" – it depends on what you want to convey.
If you want to say something about a brand, you can use Schema.org’s Brand type.
The Product type has the property brand, which takes a Brand item as value. This would allow you to reference the Brand from each of ...