: Schema.org SiteNavigationElement markup Should the Schema.org SiteNavigationElement be structured like this <div itemscope itemtype="http://www.schema.org/SiteNavigationElement"> <ul>
Should the Schema.org SiteNavigationElement be structured like this
<div itemscope itemtype="http://www.schema.org/SiteNavigationElement">
<ul>
<li itemprop="url"><a href="#" itemprop="name">Link 1</a>
</ul>
</div>
or like this?
<div itemscope itemtype="http://www.schema.org/SiteNavigationElement">
<ul>
<li>
<a href="#" itemprop="url"><span itemprop="name">Link 1</span></a>
</li>
</ul>
</div>
More posts by @Debbie626
3 Comments
Sorted by latest first Latest Oldest Best
According to Search Engine Land, it's supposed to look like this:
<ul itemscope itemtype="http://www.schema.org/SiteNavigationElement">
<li itemprop="name">
<a itemprop="url" href="#">Link 1</a>
</li>
<li itemprop="name">
<a itemprop="url" href="#">Link 2</a>
</li>
<li itemprop="name">
<a itemprop="url" href="#">Travel Resources</a>
</li>
</ul>
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. (essentially any element with a src or href attribute) for specifying URLs. In your first example, the value for the url property would not be the URL, but the text "Link 1".
Because properties on a elements (if they have a href attribute) always take the href content (and not the element content) as value, your first example would have the URL as value for the name property (but it expects Text, not URL, of course).
So: Your first example would produce wrong results. Your second example is fine.
Note that it would also be possible to omit the span element. Instead of
<li>
<a href="#" itemprop="url"><span itemprop="name">Link 1</span></a>
</li>
you could use
<li itemprop="name">
<a href="#" itemprop="url">Link 1</a>
</li>
(See also my similar answer to a question on Stack Overflow.)
SiteNavigationElement has a problem for me, and for some other people as well, like we can see in the question posted by @bybe in a comment. we can say that the problem is lack of scope.
Is SiteNavigationElement referred to a single item of the navigation system, and so it is read as: an Element of the Navigation of the Site. Or it is referred to the whole navigation system, and so it is read as: The Navigation Element of the Site
<!DOCTYPE html>
<html>
<head>
<title>test</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<div itemscope itemtype="http://schema.org/WebPageElement">
<link itemprop="additionalType" href="http://schema.org/ItemList" />
<meta itemprop="name" content="navigation_menu" />
<ul>
<li itemprop="additionalType" itemscope itemtype="http://www.schema.org/SiteNavigationElement">
<span itemprop="itemListElement">
<a href="http://www.example.com/link_1" itemprop="url"><span itemprop="name">Link 1</span></a>
</span>
</li>
<li itemprop="additionalType" itemscope itemtype="http://www.schema.org/SiteNavigationElement">
<span itemprop="itemListElement">
<a href="http://www.example.com/link_2" itemprop="url"><span itemprop="name">Link 2</span></a>
</span>
</li>
</ul>
</div>
</body>
</html>
Which is a bit more complex, since not just considers each member of the navigation system as an element who deserves a tag, it also requires a combined syntax, using additionalType to convey the idea that those links are a list of items that belong to something.
Update
I have changed the codes on this answer to the above version, to adapt it to a way that works and validates as microdata and HTML. In the edition history of the question you can see the options I used early. I replaced those codes because
I had an error on the first part, using a property where a type should be. Although Structured Data Testing Tool validated it with no errors
The HTML option, validated fine but as I mentioned, the way to achieve that breaks the microdata parsing method only reading the last Item.
As of the time of this message, doesn't seem to be a way to have two types on a single itemtype. That can be checked on the W3C WebSchemas/additionalTypeProposal, although that hasn't been updated since May 2013.
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.